MSPortal

QBRs & reporting / Answer

How do you build a QBR for an MSP client?

Short answer

To build a QBR for an MSP client, start with the client's business goals and last quarter's commitments, pull the quarter's service, security, device and spending data, and pick the three or four points that matter most. Turn each into a recommendation with a cost, an owner and a date, then package it as a short agenda and deck. Check every figure before the client sees it.

By MSPortal · Updated

On this page

What a QBR is actually for

A quarterly business review is the meeting where a client's decision-makers see what their IT did last quarter, what is at risk and what they should decide next. It is not a ticket recap. A client who leaves knowing what happened, what it means for the business and what they agreed to do next has had a useful review, even if the deck was short.

That changes how you build one. Work backwards from the decisions you want the client to make, and include only the data that supports those decisions. Everything else goes in an appendix or stays out. If you are setting up reviews for the first time, what a vCIO does and how to start vCIO services cover the role behind them.

Step by step: building the QBR

1. Confirm the audience and the client's goals

Find out who will attend. An owner wants risk and money, a finance lead wants budget against plan, and an office manager wants to know why the printer tickets keep coming back. Write down two or three business goals for the client, such as opening a second office, passing a cyber insurance renewal or hiring ten people. Every recommendation should connect to one of them.

2. Review last quarter's commitments

Open the notes from the previous review. List what was agreed, who owned it and whether it is done. Start the new QBR with this list. Clients trust a review more when it begins with "here is what we said we would do, and here is where it stands", including the items that slipped.

3. Gather the quarter's data

Pull the same set of figures every quarter so the client can compare like with like.

AreaWhat to pullTypical source
ServiceTickets opened and closed, open backlog, recurring issues, satisfaction responsesPSA
DevicesDevice count, devices out of warranty or due for replacement, devices that have stopped checking inRMM, warranty lookups
SecuritySecurity alerts and how they were handled, Microsoft 365 security settings, backup successSecurity tools, Microsoft 365, backup
ComplianceChecks passed and failed against the standard you track, open remediation itemsCompliance tool or spreadsheet
PeopleSecurity awareness training completion, licence count against staff countTraining platform, Microsoft 365
MoneyBudget against actual spend, upcoming renewals and refresh costsPSA invoices, budget

Use a fixed date range, such as the last full quarter, and note where data is missing. A gap you explain is better than a gap the client finds.

4. Find the story

Look for three or four things that changed or matter. Typical examples: a recurring issue that drove a large share of tickets, laptops that will fall out of warranty before the next review, a failed compliance check that an insurer asks about, or spending running ahead of budget. Rank them by business impact, not by how interesting they are technically. See which metrics to report for a fuller list.

5. Turn findings into recommendations

For each finding, write one recommendation the client can approve, defer or reject:

  • What you recommend, in one plain sentence
  • Why it matters to the business
  • Estimated cost and effort
  • Who owns it on each side
  • When it should happen, by quarter

Recommendations without a cost and a date tend to be discussed and then forgotten. Add the approved ones to the client's technology roadmap and budget.

6. Build the agenda and deck

Keep the deck short. One slide per section, with the detail in an appendix. What a QBR should include has a section-by-section outline. Lead with the summary and decisions, not with ticket charts.

7. Check it and send a pre-read

Check every figure against its source, confirm the company and date range, and read the narrative as the client would. Send a one-page summary a few days before the meeting so decision-makers arrive ready to decide. Then run the meeting and send written notes afterwards.

A QBR preparation checklist

  • Attendees confirmed, and their main concerns noted
  • Last quarter's commitments listed with status
  • Data pulled for the same date range as last time
  • Three or four findings ranked by business impact
  • Each recommendation has a cost, an owner and a target quarter
  • Roadmap and budget updated with proposed items
  • Figures checked against their sources
  • Pre-read sent before the meeting
  • Meeting booked, and the next review date proposed

Common QBR mistakes

  • Leading with ticket counts. Volume alone tells a client little. Explain what drove it and what you will do about it.
  • Using jargon. Clients may not know what an RMM, a patch ring or a CIS Benchmark is. Say "devices that are missing security updates" instead.
  • Changing the metrics every quarter. Clients cannot see progress if the measures keep moving.
  • No decisions. A review that ends without an agreed next step is a status update.
  • Building every deck by hand. When each review takes hours to assemble, clients get them less often. Automating the preparation keeps the cadence regular.

How MSPortal builds a QBR

MSPortal builds the QBR from data it has already synced from your PSA, RMM, Microsoft 365, security and backup tools, and puts the result in the client's own portal. Its reporting module offers two ways to build the report:

  • Block reports. Pick a template or add blocks for tickets, devices and warranties, compliance, Microsoft 365, backup, security tools, training, satisfaction, the roadmap and budgets. Each block fills from the latest synced data for the company and date range.
  • Full reports. Choose a report type such as a QBR, plus the audience and tone, and AI drafts the executive summary, key metrics, risks, recommendations and action plan from the selected sources, with sources cited and data gaps listed. A review panel flags missing sections and citations it could not verify. AI drafts the report, and your team reviews and edits it before publishing.

Recommendations live in Planner, the roadmap clients can see, and approved items can be added to the client's budget. For a parent company, one report can cover every location. When the report is ready, add it to the meeting agenda and present it from the meeting page. Drafts stay hidden from the client until you publish them. The vCIO workflow shows how assessment, roadmap, budget and review fit together, and the sample client review shows a finished example. Product details are in the reporting guide.

How long should a QBR deck be?

Short enough to finish with time for decisions. One slide per section works for most clients: a summary, last quarter's commitments, service, security, devices, roadmap, budget and decisions. Put device lists and detailed ticket breakdowns in an appendix that the client can read afterwards.

How often should an MSP hold a QBR?

Quarterly suits most clients with an active roadmap. Smaller or stable clients may prefer twice a year, and clients going through a migration or compliance project may want monthly check-ins. Agree the cadence with the client and keep it consistent so each review can compare against the last.

Who should prepare the QBR at an MSP?

Usually the account manager or vCIO who owns the relationship, with input from the service lead on recurring issues and from finance on spending. One person should own the final narrative and check every figure, even when parts of the preparation are automated.

What data do I need before building a QBR?

At minimum, ticket history for the period, the client's device list with warranty dates, security and backup status, any compliance results and the budget or recent invoices. Notes from the previous review are just as important, because the new review should report on what was agreed last time.