MSP QBR metrics: the reference table of what to report and where it comes from

Service delivery: did we do the job

These four answer the client's first question, which is whether they are getting what they pay for. Every one of them comes from the PSA ticket record.

• Ticket volume: the count of tickets created in the period. Source: ticket created date. Trap: raw volume rises with headcount, so present it per user or alongside the seat count, otherwise growth looks like deterioration.
• First response time: the median time from ticket creation to the first human response. Source: created date and first outbound activity timestamp. Trap: report the median and the 90th percentile, never the mean. One ticket left over a weekend moves a mean and tells the client nothing.
• Resolution time: the median time from creation to resolved status. Source: created and resolved timestamps. Trap: exclude tickets waiting on the client unless you are prepared to explain why a client-caused delay counts against you, and say in the footnote which convention you used.
• SLA attainment: the percentage of tickets meeting their response or resolution target, computed separately for each. Source: ticket priority, target, and the timestamps above. Trap: an aggregate percentage across all priorities hides a systematic failure on the highest priority tier. Break it out by priority or do not report it.

Demand: what is driving the volume

These turn a service report into a business conversation, because they point at a cause the client can spend money to remove.

• Volume by category: ticket count grouped by issue type or board category. Source: the ticket type or subtype field. Trap: this is only as good as your technicians' categorisation discipline, so check the uncategorised percentage before you present the chart.
• Volume by user or site: the count grouped by requester or location. Source: the ticket contact record. Trap: naming individuals in a client-facing document is a judgement call. Aggregate to site or department unless the client has asked otherwise.
• Recurring issues: the same category appearing above a threshold across consecutive periods. Source: derived from category over time. Trap: this is the most valuable chart in the deck and the one most often missing, because it needs the previous quarters and not just this one.
• Volume trend across four quarters: the same figure over the last four periods. Source: as above, over a longer window. Trap: a single quarter is not a trend, and a single quarter presented as one is how a normal fluctuation becomes an alarming slide.

Environment: what state is the estate in

These come from the RMM or asset inventory rather than the ticket system, and they are what makes the budget conversation possible.

• Assets past end of warranty: the count and percentage of devices whose warranty expiry is in the past. Source: asset warranty end date. Trap: warranty data ages badly and is often incomplete on assets added by hand. Report the coverage of your own data alongside the figure.
• Assets aging out in the next 12 months: devices whose age crosses your refresh threshold within the year. Source: purchase or first-seen date against your refresh policy. Trap: state the threshold you used on the slide, because a four-year and a five-year policy produce very different numbers from the same fleet.
• Operating system and patch currency: the share of endpoints on a supported OS build and within your patch window. Source: RMM agent inventory. Trap: unmanaged devices do not appear in the RMM at all, so this metric flatters the estate by exactly the size of your blind spot.
• Backup success rate: successful backup jobs as a percentage of scheduled jobs over the period. Source: the backup tool. Trap: a success rate is not a restore test. Report both, or say plainly that you have not restore-tested.

Money: what should we spend next

These three are the reason the finance person is in the meeting, and they are computed rather than estimated.

• Hardware refresh budget for the next 12 months: the count of assets crossing the refresh threshold multiplied by your standard replacement cost per device class. Source: asset ages plus your own cost table. Trap: use your actual current cost per class and date the table, because a cost figure from last year makes the whole budget wrong.
• Planned project spend, phased: roadmap items with cost, distributed across the quarters they land in. Source: your roadmap. Trap: phasing matters more than the total. A client can absorb a number spread over four quarters that would be rejected as a single line.
• Licence and renewal exposure: subscription and licence renewals falling in the period with their amounts and dates. Source: your agreement or procurement records. Trap: renewals are where surprise spending comes from, and they are the easiest thing on this list to leave out of a budget slide.

The metrics to leave out of a client-facing review

Some genuinely useful numbers do not belong in front of a client. Reporting them anyway is one of the fastest ways to lose control of the meeting.

• Technician utilisation and per-technician throughput: these are internal management metrics. In a client meeting they invite a conversation about your staffing rather than their environment.
• Gross margin on the account: never. It is a real number, and it is a negotiation you are volunteering to have.
• Raw counts with no denominator: 412 tickets means nothing without the seat count and the previous quarter next to it.
• Any metric you cannot explain the computation of in one sentence. If the client asks how you got that number and you have to go and look, the number was not ready.

Making the numbers reproducible

The test of a reporting process is whether two people in your team, given the same quarter, produce the same figures. If they do not, the metric definitions live in someone's head rather than in your process. Write the definition, the formula and the source field for every client-facing metric down once, keep them with your report template, and put a footnote on the slide for every convention you chose: whether client-wait time is excluded, which refresh threshold you used, and what percentage of assets have warranty data. Those footnotes are what makes the number defensible when someone challenges it.