There is a version of MSP dispatch that looks productive from the outside and is quietly failing.
Tickets are getting closed. The queue is moving. Technicians are busy. Nobody is panicking.
And yet response times are creeping up. A client escalated last week over something that should have been caught earlier. Your utilization numbers don’t add up when you look at them honestly. A few SLAs were breached last month — not many, but more than zero.
The problem isn’t that the dispatcher isn’t working. The problem is that the dispatcher isn’t measuring. And without measurement, the only feedback signal available is the complaint — which always arrives too late, after the damage is already done.
A dispatcher who tracks the right metrics doesn’t wait for complaints. They see the problem forming in the data and address it before it reaches a client. That’s the difference between reactive dispatch and professional dispatch — and it’s one of the clearest markers of whether the function has been properly trained or simply staffed.
These are the five KPIs every MSP dispatcher should be tracking, what each one tells you, and what a trained dispatcher does when the number moves in the wrong direction.
Why most dispatchers are flying blind
The average MSP dispatcher has access to more data than they know what to do with. The PSA captures timestamp on every ticket event — when it was created, when it was first responded to, when it was assigned, when it was resolved, how much time was logged against it. The data exists.
What most dispatchers lack is a defined set of metrics they are personally accountable for, a baseline to measure against, and a protocol for what to do when a metric deteriorates.
Without those three things, the data in the PSA is background noise. The dispatcher is managing by feel — which works fine when volume is low and the team is experienced, and breaks down exactly when you need it most: when volume spikes, when a tech is out, when a difficult client is having a bad week, when the board is under pressure and the margin for error is zero.
KPIs don’t create a good dispatcher. But a good dispatcher who tracks the right KPIs becomes a significantly better one — because they have a system that tells them where to look and what to do, rather than relying entirely on judgment developed over years of trial and error.
KPI #1: Technician utilization rate
What it measures: The percentage of available technician hours that are being spent on billable or productive work, as opposed to administrative tasks, idle time, or internal projects.
How to calculate it: Billable hours logged divided by total available hours in the period, expressed as a percentage. If a technician has 40 available hours in a week and logs 30 billable hours, their utilization rate is 75%.
The target: 75% is the standard benchmark for MSP service teams. Below 65% consistently suggests the dispatcher is not filling the board efficiently — either tickets aren’t being routed promptly, the technician’s schedule has too many gaps, or work is being distributed unevenly across the team. Above 85% consistently is a different warning sign: the technician is approaching burnout territory, and quality will begin to degrade before they say anything about it.
What a trained dispatcher does when it’s off: If utilization is low for a specific technician, the dispatcher looks at their current ticket assignment and identifies whether there is backlog that could be routed their way. If utilization is low across the team, the dispatcher reviews whether incoming tickets are being captured promptly and whether routing is creating bottlenecks. If utilization is consistently high across the team, the dispatcher flags this to the service manager as a capacity issue — not a dispatch issue.
The dispatcher’s job is to optimize distribution within the existing capacity. Identifying when capacity itself is the constraint is equally important.
KPI #2: Average first response time by priority tier
What it measures: The average time elapsed between when a ticket is created and when a technician makes first meaningful contact with the client, broken down by priority level.
How to calculate it: Most PSAs can generate this report directly. The key is to segment by priority tier — a P1 response time target is fundamentally different from a P3 target, and averaging across them obscures the picture.
The target: This varies by the SLA structure your MSP has defined for each client agreement, but a common benchmark is P1 under 15 minutes, P2 under 1 hour, P3 under 4 hours, P4 under 8 hours. The dispatcher should know these thresholds for every active agreement and track performance against them, not against a generic average.
What a trained dispatcher does when it’s off: A response time that is consistently missing target on a specific priority tier points to one of three causes: the ticket is being created at the right priority but routed too slowly, the priority is being set incorrectly at intake so the ticket isn’t getting the urgency it deserves, or the technician capacity for that priority tier isn’t sufficient during certain time windows. Each cause has a different solution. A dispatcher who only sees the average number can’t distinguish between them. A dispatcher who watches the metric at the tier level can.
When a P1 or P2 is approaching its response threshold and hasn’t been acknowledged, the dispatcher escalates immediately — not after the breach, not when the client calls.
KPI #3: SLA breach rate
What it measures: The percentage of tickets in a given period where the agreed SLA — either response time, resolution time, or both — was not met.
How to calculate it: Number of tickets that breached SLA divided by total tickets closed in the period, expressed as a percentage. Track separately for response SLA and resolution SLA, because they point to different problems.
The target: Zero is the goal. In practice, a well-run MSP service operation should be well under 5% breach rate on a consistent basis. Anything above that warrants a root cause review, not just an acknowledgment.
What a trained dispatcher does when it’s off: SLA breach rate is a lagging indicator — it tells you what already went wrong. The dispatcher’s real job is to prevent breaches from happening, which means monitoring the leading indicators: ticket age relative to SLA threshold, workload distribution, and escalation triggers. When a ticket is approaching its SLA window and is not yet resolved, the dispatcher escalates before the breach, contacts the client proactively, and adjusts routing if the assigned technician is unable to complete it in time.
When breach rate is trending upward over multiple weeks, the dispatcher brings this to the service manager with the data — which tickets, which clients, which technicians, which priority tiers. Pattern identification is the service manager’s job. Surfacing the pattern is the dispatcher’s.
KPI #4: Ticket backlog trend
What it measures: The week-over-week change in the number of open tickets on the service board. Not the absolute number — the trend.
How to track it: Take a snapshot of open ticket count at the same time each week — Friday at end of day is a common reference point. Track whether the number is growing, shrinking, or stable over time.
Why the trend matters more than the number: An MSP with 80 open tickets and a declining trend is in a healthier position than one with 40 open tickets and a growing trend. The absolute number reflects the current state. The trend reflects whether the operation is keeping up with incoming demand or falling behind it.
What a trained dispatcher does when it’s off: A growing backlog over two or more consecutive weeks is a signal that intake volume is exceeding resolution capacity. The dispatcher’s response is to review the board for tickets that can be fast-tracked, identify technicians with available capacity who can be redirected to backlog reduction, and flag the trend to the service manager before it becomes a client-visible problem. In some cases, a growing backlog reflects a routing inefficiency — tickets sitting unassigned or miscategorized — rather than a true capacity constraint. The dispatcher is positioned to distinguish between the two.
A stable or shrinking backlog doesn’t mean the dispatcher’s job is done — it means the system is working, and the work is to keep it that way.
KPI #5: Ticket reopen rate
What it measures: The percentage of closed tickets that are reopened by the client within a defined window — typically 72 hours — because the issue was not fully resolved on the first attempt.
How to calculate it: Number of tickets reopened within 72 hours of closure divided by total tickets closed in the period, expressed as a percentage.
Why it matters: Ticket reopen rate is a proxy for First Time Resolution rate — one of the most important service quality metrics in the MSP industry. A high reopen rate means tickets are being closed prematurely: the technician marked the issue resolved before the client confirmed it, or resolved the symptom without addressing the root cause. Either way, the client experiences the same issue twice, contacts your team a second time, and forms an impression of your service quality that is hard to reverse.
From the dispatcher’s perspective, reopen rate is also a workload signal. Every reopened ticket represents double the labor — the original resolution attempt plus the follow-up — which consumes capacity that could have been applied to new incoming work.
What a trained dispatcher does when it’s off: The dispatcher can’t control how a technician resolves a ticket, but they can flag the pattern. When a specific technician has a reopen rate that is consistently above the team average, that data goes to the service manager as a coaching input. When a specific client has an elevated reopen rate across multiple technicians, it may reflect an expectation or communication mismatch that the dispatcher can surface before it becomes a CSAT issue.
Reopen rate is one of the metrics that most clearly illustrates the relationship between the dispatcher function and the service manager function: the dispatcher sees the data, the service manager acts on it.
How a certified dispatcher uses these together
These five metrics don’t operate in isolation. A trained dispatcher reads them as a system — understanding how movement in one number relates to movement in another.
Low utilization and high response time together suggest a routing problem: the capacity exists but it isn’t being applied to incoming work quickly enough. High SLA breach rate and high reopen rate together suggest a quality problem downstream of dispatch — and the dispatcher’s job is to surface that pattern clearly enough for the service manager to address it. A growing backlog alongside stable utilization suggests that incoming volume has increased and capacity needs to be reviewed at the staffing level.
Reading these relationships — not just reporting individual numbers — is what separates a dispatcher who manages the board from one who optimizes it. That level of operational literacy is the outcome of structured, MSP-specific training. It doesn’t develop automatically from time in the seat.
The BMK Dispatcher Certification is a two-day, in-person course that teaches dispatchers exactly this kind of systems-level thinking — alongside the ticket intake model, PSA best practices, SLA management, and communication standards that form the operational foundation of a high-performing MSP service board. It is built for dispatchers who are ready to move from reactive to professional, and for MSP owners who want the dispatch function running on a defined framework rather than instinct.
Ready to build a dispatch function that measures itself and improves over time? Explore the BMK Dispatcher Certification or book a free consultation with our team to talk through where your service operation stands today.
BMK Community provides professional certification courses for MSP Dispatchers, Service Managers, Sales Professionals, and Sales Managers — built exclusively for the managed services industry. Based in Washington, DC, serving MSPs across the United States.
