The MSP Quarterly Business Review Template (QBR)

Most quarterly reviews are a ticket report read aloud. The MSP presents uptime, closed tickets, and a patch percentage, the client nods, and everyone leaves having learned nothing. Nine hundred tickets closed means nothing to an owner who has no idea whether nine hundred is good.

A review is worth an hour of the client's time when it does two things. It tells them whether their technology is getting better or worse, and it puts a decision in front of them. Everything else is filler.

The agenda

Sixty minutes, and the shape matters. Spend the first third on what happened, the middle third on what it means, and the last third on what to do. Most MSPs invert this and run out of time before the part that pays for the meeting.

0–5
Where we left off last quarterThe commitments from the last review, each one marked done, in progress, or not started. Start here even when the news is bad. Especially then.
5–15
The quarter in numbersVolume, response times, and the two or three metrics this client actually cares about. Trend lines, not totals.
15–25
What we learned about your environmentThe findings. Patterns behind the tickets, systems creating recurring work, anything that changed.
25–35
Risk registerWhat is exposed today, what it would cost to close, and what happens if it is not closed. The register carries over quarter to quarter.
35–45
Contracts and renewals coming upWarranties, licenses, connectivity, the firewall support contract. Twelve months forward, so nothing arrives as a surprise.
45–55
The roadmap and the budgetWhat we recommend next quarter and next year, priced, against the three and five year view.
55–60
Decisions and ownersWhat was approved, what was deferred, what each side is doing before the next review, with dates.

Send the deck a day ahead. Not to save meeting time, but because the person who has to approve spending usually wants to look at a number before they are asked about it in a room.

Numbers worth showing

Pick five. Every metric past that dilutes the ones that matter, and clients remember at most three things from any meeting.

Ticket volume, trended over four quarters. A single quarter's number is noise. The direction is the story, and if it is rising you should have an explanation ready.
Time to first response, against what the agreement promises. Show the misses rather than hiding them in an average.
The top three ticket categories. This is the one clients engage with, because it tells them where their people are losing time.
Repeat tickets. The same user or the same machine appearing again and again is a project waiting to be approved.
One security number. MFA coverage, patch compliance, or endpoints reporting. Pick the one that is furthest from where it should be.

Uptime is not on that list on purpose. It is either 99 point something or there was an outage everybody already remembers, and in neither case does the number teach the client anything.

The risk register

This is the part of the meeting that produces revenue, and it works because it is boring and consistent. Same table every quarter, items carried forward until they are resolved or the client accepts them.

Five columns

What
The risk, in the client's language. “The server holding the accounting system is out of warranty,” not “EOL hardware in production.”
Since
The date it first appeared on this register. An item that has been open four quarters is its own argument.
Impact
What happens if it is not addressed, stated concretely. Days of downtime, an uninsurable loss, a failed audit.
Cost
A real number to resolve it. Ranges are fine. Blank is not.
Status
Approved, deferred by the client, or awaiting a decision. Who deferred it, and when, matters as much as the item.

When a client defers something, record it and move on without argument. You are not building a case. You are building a document that answers the question everyone asks after an incident, which is whether anyone knew.

Renewals and contracts

Almost nobody covers this, and clients value it more than the technical content. You are the only vendor with visibility across all of it.

Show twelve months forward, with dates:

Hardware warranties, and what a machine costs to replace when its warranty ends
Software licenses and subscription true-ups, including the ones finance renews without asking
Internet and connectivity contracts, with the auto-renewal date and the notice period
Firewall and network equipment support contracts
Domain and certificate expiries
The client's own agreement with you

The connectivity contracts are where this earns its keep. Internet agreements auto-renew for another term on a thirty day notice window, and nobody is watching the calendar. Catching one of those a quarter early is worth real money to the client and costs you nothing but attention.

The roadmap

Start with four quarters out, each with a small number of items and a budget. Not a wish list. The refresh schedule, the projects that follow from the risk register, and anything the client's own plans require.

Update it every quarter rather than rebuilding it. A roadmap the client has seen four times is one they have started planning around, and by the third or fourth review the conversation shifts from whether to do the work to when.

Put a number on the year. Owners plan annually and think in budgets, and an IT roadmap without a total is the one thing they cannot take to their own planning process.

Then show the three year and the five year alongside it. The annual number answers what to spend next year. The longer horizons answer a different question, which is whether the client is facing a normal run of expenses or a cliff.

Three horizons

1 year
Committed and near certain. Approved projects, renewals with known dates, and the hardware already past warranty.This is the number that goes into the client's budget.
3 years
The refresh cycle. Every machine, server, and network device with its replacement year, plus the projects the risk register implies.Most of the lumpiness lives here. A twenty machine refresh landing in one year is the thing to catch early.
5 years
Direction rather than precision. Server or cloud, the phone system, the line of business application the vendor is winding down.Order of magnitude is enough. The point is that nothing on this list should ever arrive as a surprise.

Smooth the peaks where you can. If the three year view shows fifteen workstations all aging out in the same quarter, propose replacing five a year starting now. Clients approve a predictable annual number far more readily than one large one, and it is easier work for you.

How to end it

The last five minutes decide whether the meeting mattered. Read back three things and get agreement on each.

What was approved, and who is starting it.
What the client owes you, with a date. An approval, a vendor introduction, thirty minutes with a department head.
The date of the next review. Book it in the room. Chasing it later costs three emails and it slips a month.

Send a written summary the same day. Two paragraphs and the decision list is enough. Written on the day it happened, it becomes the record that opens the next review.

Frequency, and who to invite

Quarterly is the default and it is not right for everyone. A forty person client with a stable environment is well served by two a year plus a shorter check-in. A client mid-project or under compliance pressure may need monthly. Set the cadence deliberately and by client rather than as a policy.

In the room you want whoever approves spending and whoever feels the pain. Those are usually two people. If only the owner attends, you get budget authority with no operational detail. If only the operations manager attends, you get a well-informed meeting that cannot approve anything.

Why these get skipped

Every MSP knows reviews matter and most run them inconsistently. The reason is almost always preparation time. Four hours of pulling reports, chasing the technician who knows what happened, and rebuilding a deck from last quarter's file is enough friction to make the meeting slide, and once it slides twice it stops being a rhythm.

The fix is to stop treating the review as a document you assemble and start treating it as a record you keep. If the findings from onboarding, the risk items, the renewals, and the roadmap all live in one place and get updated as the work happens, the quarterly review is a meeting you walk into rather than a project you schedule.

That record starts on day one. The onboarding checklist ends with the same three artifacts this meeting opens with, and the assessment questions are where the first version of them comes from.