MSP QBR scorecard: five numbers that turn a polite deck into funded work

An MSP QBR scorecard is the first page of the review: five numbers the client can say yes, no, or later to. Everything else goes in the appendix.

Most QBR decks get this backwards. They open with tickets closed, SLA attainment in green, a patch compliance percentage, and a backup success chart. The client nods. The account lead feels prepared. Forty minutes later everyone agrees to "revisit the firewall next quarter," which is what they agreed last quarter too.

Those metrics are fine for the appendix. None of them asks the client for anything, and a client can't approve a ticket count. They can approve replacing eleven machines before they fail during tax season.

This post gives you the five numbers, the decision each one forces, a one-page layout you can copy, a worked example, and a talk track. It assumes you already run QBRs. If the meeting format itself is the problem, start with the 20-minute MSP QBR template and come back.

The rule for page one

A number earns a spot on page one only if it ends in a client decision. There are three decisions worth asking for:

1. Fund it. Approve the work, the phase, or the budget line.
2. Schedule it. Defer with a date and an owner, so it comes back on purpose.
3. Accept it. Decline the work and record that the client owns the risk.

If a metric can't end in one of those three, move it to the appendix. Ticket trends, CSAT, SLA detail, and backup job history still matter. They belong in the appendix as supporting detail.

This is also how the scorecard differs from a client health score. The health score is internal. It tells your team which client needs attention this month. The QBR scorecard is the page the client sees, and every row on it asks them to decide something.

The five numbers

1. Aging hardware exposure

Count the devices past your replacement threshold and attach a replacement range in dollars. Include workstations, servers, firewalls, switches, and access points. Then name the ones that matter most to the business.

The row should read like this: "11 devices past our replacement threshold. Replacement range $19,000 to $24,000. The firewall and both core switches are in that count."

A device list doesn't get funded. A dollar range with the firewall called out does. If you need to work out the threshold and timing first, the hardware lifecycle roadmap covers how to separate age, warranty, and support status before you bring a number to the client.

2. Unsupported software and platforms

Count everything running past vendor support: operating systems, line-of-business apps, database versions, firewall firmware, VPN clients. For each item, name the business owner and the path: upgrade, replace, isolate, or document an exception.

Windows 10 is the easy example. Microsoft's lifecycle page lists Windows 10 Home and Pro end of support as October 14, 2025. Plenty of clients still have a few machines on it, usually tied to an app or a piece of lab equipment nobody wants to touch. That's a decision, so put it on the page. The Windows 10 EOL action plan has the upgrade, replace, bridge, or document decision tree.

This number is quiet in most QBRs because it feels less urgent than a dead server. It shouldn't be. CIS Control 2 asks organizations to actively manage all software on the network so that only authorized software is installed and can run. If the client never decided about the old accounting database, your MSP is carrying that risk without anyone saying so.

3. Security gaps by decision owner

Do not put every control finding in front of a business owner. Nobody approves a list that long. Group the open gaps by who has to act:

The client budget and client policy rows are the ones to ask about. The MSP work row is yours to fix before the next QBR, and it belongs on the page anyway. Clients notice when you report your own misses first.

If you haven't written down who owns what, the shared responsibility matrix template sorts it out before the meeting instead of during it.

4. Renewal exposure in the next 180 days

Total the renewals coming up in the next six months: software subscriptions, hardware warranties, domains, certificates, support contracts, and the cyber insurance policy if its questionnaire touches your controls. Then mark two subsets: renewals tied to tools you've recommended replacing, and renewals that depend on security work the client hasn't approved yet.

The row reads: "$31,500 renewing in the next 180 days. $6,000 is for tools on the replacement list. $4,500 depends on security work that isn't approved."

Renewals are where QBR advice usually dies. The client sees an invoice, pays it, and the replacement project slides another year. Putting the renewal next to the recommendation gives the client a real choice: renew as-is, consolidate, or approve the work first. The renewal calendar template keeps the notice deadlines straight so this row isn't a surprise.

5. Unfunded recommended work

This is the one MSPs skip because it feels salesy. Show it anyway.

Add up the work you've recommended that the client hasn't approved: remediation projects, lifecycle replacements, cleanup, roadmap items. Show what's open, what got funded this quarter, and the difference.

"$58,000 in recommended work. $14,000 funded this quarter. $44,000 still waiting."

That number does two jobs. It shows the client what's queued up behind them, in one figure instead of six slides. It also tells your team whether QBRs are working. If the waiting number grows every quarter and the funded number stays flat, the meeting is producing advice and no decisions. Usually the fix is a smaller first phase or a clearer business reason. The project prioritization matrix helps pick which item to lead with.

The one-page layout

The page has five rows and one decision column.

Keep it plain. A plain page is easier to approve. Charts and trend lines go in the appendix, where the people who care about them can find them.

Copy the scorecard

Paste this into your QBR document or client record, one block per client:

Client:
QBR date:
Decision maker in the room:

1. Aging hardware
   Devices past threshold:
   Replacement range: $        to $
   Critical devices in that count:
   Decision: Fund / Schedule (date:      ) / Accept
   Owner:

2. Unsupported software
   Items past vendor support:
   Path for each (upgrade / replace / isolate / exception):
   Decision: Fund / Schedule (date:      ) / Accept
   Owner:

3. Security gaps by owner
   Client budget:      Client policy:      MSP work:
   Shared:             Accepted exception:
   Decisions needed today:
   Owner:

4. Renewal exposure (next 180 days)
   Total: $
   Tied to tools on replacement list: $
   Depends on unapproved work: $
   Decision: Renew / Consolidate / Do the work first
   Owner:

5. Unfunded recommended work
   Recommended: $       Funded this quarter: $       Waiting: $
   Decision: Approve phase / Defer with date / Decline
   Owner:

Decisions made today:
Risks accepted in writing:
Follow-ups with dates:

The last three lines matter most. If they're blank after the meeting, the meeting didn't work.

A worked example

Here's a made-up 45-person accounting firm, scored the week before its fall QBR. The numbers are fictional and only there to show how the page reads.

Notice the asks. There are five rows but really three decisions for the managing partner: the network hardware, the MFA licenses, and whether to renew a tool you've recommended replacing. Your two MSP work gaps don't need approval. You just report that they'll be closed before the next review.

The rest of the deck can run as long as it likes. The partner leaves knowing what they agreed to.

The talk track

Open with the page, not the ticket summary. Something like:

"This page is the business view of your environment. Support has been stable this quarter, and the details are in the back if you want them. What I need from you today is three decisions: the network hardware, the MFA licenses, and whether we renew the old backup tool or fold it into the replacement. For each one we can approve it, put it on the calendar with a date, or you can decide to carry the risk and we'll write that down."

Then stop talking and let them pick.

The "write that down" part is important. A documented no is a fine outcome. It's a lot better than a vague maybe, and it protects your MSP when the risk you flagged turns into an incident six months later.

Where the numbers go after the meeting

A scorecard that dies in a PDF is a nicer-looking status report. Every decision needs a home before you leave the room:

• Funded items become scoped work and a quote.
• Scheduled items go on the client roadmap with the date the client agreed to.
• Accepted risks go in a written log the client signs.
• Budget asks that need the next fiscal year go into the client IT budget.

This is also where vCIO margin lives or leaks. If your team spends a day assembling QBR data and the meeting produces no funded work, the client got free consulting. The vCIO pricing guide covers how to price that advisory time so it isn't free.

Where Scopable fits

The hard part of this scorecard is the prep. Device ages live in the RMM, gaps live in assessments, renewals live in agreements and spreadsheets, and recommended work lives in old quotes and somebody's memory.

Scopable's vCIO and QBR workflow ties the review to the client record. QBR sections can pull from assessment results, compliance scores, opportunities, agreements, and roadmap context already in the account, so you start from the client's current data instead of a blank deck. You review the sections, add notes, and export the QBR as a PDF. After the meeting, decisions go into follow-up work, budget planning, quote scope, or accepted-risk history. Scopable doesn't make the call for you. The scorecard and the ask are still your team's job.

To build your next QBR from the client record, start Scopable for free.