It’s 9:07 AM on a Monday. Your service board has 34 open tickets. A new one just came in a client’s email server is throwing errors. Another client called to say their scheduled maintenance from Friday was never confirmed. Two of your technicians are already buried. One is sitting idle, waiting for someone to tell them what to do next.
Nobody is in charge of any of this.
That’s not a technology problem. It’s a dispatching problem.
Most MSPs understand – at least in theory – that someone needs to manage the flow of work across the service team. What far fewer MSPs have is a clear picture of what that function actually involves, what a trained dispatcher does differently from an untrained one, and what it costs when the role is left undefined.
This post breaks all of that down.
The Service Board Is Managed Chaos Without a Dispatcher
Here’s how most MSPs handle incoming service requests without a dedicated dispatcher: whoever is available takes a call, logs a ticket (maybe), assigns it to themselves or a teammate based on who they think is free, and moves on. If it falls through the cracks, it falls through the cracks.
The result is predictable. SLAs slip. High-priority tickets sit behind lower-priority work because nobody is actively triaging the queue. Clients get radio silence for hours — or days — and assume they’re being ignored. Technicians self-select their own work, which means the tickets they find interesting get done first, not the ones that are most urgent or most profitable.
The fix isn’t a better PSA. It isn’t a new ticketing system. It’s a person whose entire job is owning the flow of work — watching the board, making routing decisions, enforcing standards, and keeping every ticket moving toward resolution.
That person is your dispatcher.
What a Dispatcher Actually Owns
The dispatcher role in a well-run MSP is not administrative. It is operational. A trained dispatcher owns five core functions:
1. Intake — catching every request before it falls through
Every incoming service request — phone call, email, client portal submission — gets logged the moment it arrives. The dispatcher is responsible for ensuring no request enters a gray zone where it hasn’t been formally acknowledged, categorized, and queued. In practice, this means monitoring multiple intake channels simultaneously and establishing a consistent logging standard so every ticket enters the PSA with the right information attached.
2. Ticket fundamentals — setting the right details from the start
A ticket that is miscategorized at intake creates problems downstream. The dispatcher confirms the essential fields before any ticket is routed: which service agreement applies, what the priority level is, the correct ticket type and subtype, and whether escalation criteria are met. This sounds administrative. It isn’t. Getting these details right determines which technician handles the ticket, how quickly, and whether it counts against the right client’s SLA clock.
3. Routing — matching every ticket to the right technician at the right time
This is the judgment call at the center of the dispatcher’s role. Routing is not just finding an available technician. It means matching the ticket’s technical requirements to the specific technician best suited to resolve it, at a point in their day when they can give it proper attention, in a way that keeps the whole team’s utilization balanced. A dispatcher who routes well keeps technician utilization at or above 75% — the threshold most MSPs need to hit for service delivery to be profitable. A dispatcher who routes poorly either overloads certain technicians while others sit idle, or sends the wrong tech to the wrong problem and creates rework.
4. SLA compliance monitoring — no ticket goes dark on your watch
Open tickets don’t manage themselves. A trained dispatcher watches every open ticket against its SLA threshold and takes action before a breach occurs — not after. This means identifying tickets approaching their response or resolution deadlines, escalating to the right person, and communicating proactively with the client when timing is at risk. The dispatcher does not wait for a client to call asking for an update. They send the update first.
5. Client communication — so your technicians can stay focused
When a ticket is delayed, rescheduled, or reassigned, someone needs to tell the client. In most MSPs without a dispatcher, that communication either doesn’t happen or it falls on a technician who now has to stop technical work to handle a client conversation. The dispatcher owns this. Every delay gets communicated. Every reschedule gets confirmed. Clients always know their ticket’s status — which is one of the single highest-impact drivers of client satisfaction in managed services.
Dispatcher vs. Service Manager: Where the Lines Are Drawn
These two roles are frequently confused, and the confusion is understandable — both are operational, both are focused on the service team, and in smaller MSPs a single person may handle elements of both. But the roles are distinct.
The dispatcher is reactive and real-time. Their job is managing the flow of work right now — the board as it looks today, the tickets arriving this hour, the technician schedule for this afternoon. Their view is tactical.
The MSP Service Manager is strategic and retrospective. Their job is measuring how the service team performed last month, coaching technicians on skill gaps, reviewing agreement profitability, managing hiring, and reporting service department gross profit to ownership. Their view is managerial.
A useful way to think about it: the dispatcher keeps the train running on time today. The service manager decides which routes are worth running at all.
In a five-person MSP, one person might wear both hats. In a fifteen-person MSP, they should be two distinct functions. The mistake most owners make is assuming that a service manager can absorb dispatch responsibilities without either role suffering. They can’t — not without measurable cost to both the operational health of the service board and the strategic health of the service team.
What Happens When Techs Self-Assign (The Real Cost)
Let’s put a number on what happens when dispatching is absent or unstructured.
When technicians self-assign tickets, they naturally gravitate toward work they find interesting or straightforward. High-complexity tickets get deferred. Tickets from clients they have better relationships with get prioritized over tickets from clients they don’t know as well. The result is a service board that moves based on technician preference rather than client priority.
The downstream cost shows up in three places:
SLA breach rates increase. Without someone actively monitoring open tickets against their SLA clocks, breaches happen not because the work wasn’t done — but because no one was watching the timer. A single SLA breach on the wrong agreement can trigger a service credit, a difficult client conversation, or a renewal-at-risk conversation.
Technician utilization drops. When technicians pick their own work, the most confident ones tend to accumulate tickets while others wait. Team-level utilization becomes uneven — and average utilization tends to drop below the threshold where your service margins make sense. The same revenue, with lower billable utilization, produces a worse effective hourly rate on every technician hour you’re paying for.
Client satisfaction erodes silently. The client who never hears back about their ticket doesn’t always call to complain. They renew their agreement, wait until the contract anniversary, and leave. By the time you know there was a problem, the relationship is already damaged. Proactive client communication — the kind only a dispatcher can reliably provide — is one of the most effective client retention tools available to an MSP.
What Makes a Trained Dispatcher Different from an Untrained One
The gap between a dispatcher who has been formally trained and one who has figured it out on the job is not small.
An untrained dispatcher often understands the surface mechanics — logging tickets, assigning technicians — but lacks the framework to handle the judgment calls: how to triage when two high-priority tickets arrive simultaneously, how to communicate a delay to a client without escalating tension, how to monitor utilization in real time and adjust routing dynamically as the day changes, how to use PSA automation to reduce manual load on repetitive intake tasks.
A trained dispatcher operates from a system. They have a defined intake model. They know the prioritization framework. They understand how to read a service board at a glance, identify the tickets most at risk, and act before a problem becomes a client complaint. They know which KPIs tell them whether the service operation is running well — and what to do when those numbers start moving in the wrong direction.
That’s not something most dispatchers develop by osmosis. It requires structured training.
The BMK Dispatcher Certification is a two-day, in-person course built exclusively for MSP dispatchers. It covers dispatching models and prioritization frameworks, time entry and approval processes, PSA best practices and automation foundations, the KPIs that measure dispatcher performance, and effective communication with both technical teams and clients. Graduates leave with a working system — not just a better understanding of the role.
Building the Dispatch Function at Your MSP
If you’re reading this and thinking, “we don’t really have a dispatcher — we have a technician who does some dispatching,” that’s one of the most common situations we see at BMK Community. It’s also one of the most expensive.
The path forward isn’t complicated, but it requires a deliberate decision. Identify who owns dispatch. Give them the time and mandate to do it without being pulled onto the tools. Define the standards — how tickets get categorized, how SLAs get tracked, what client communication looks like, what utilization target the team is being managed toward. And invest in training so that person has a framework, not just good intentions.
A properly functioning dispatch function doesn’t just make your service board look cleaner. It changes what you can bill, what your clients experience, and how your technicians feel about their work. It is one of the highest-leverage operational investments an MSP owner can make.
Ready to Build a Real Dispatch Function?
The BMK Dispatcher Certification is a two-day, in-person course designed to turn your dispatcher, whether that’s a dedicated role or a technician who’s been pulled into dispatch responsibilities into a trained operator with a real system.
The course covers MSP dispatching models, PSA best practices, ticket prioritization, SLA enforcement, technician utilization management, and client communication standards. It is built exclusively for the MSP industry.
Enroll in the BMK Dispatcher Certification →
Not sure if you need a dedicated dispatcher yet? **Talk to our team,** we’ll help you assess where your current service operation stands and what it would take to build the function properly.
BMK Community provides professional certification programs for MSP dispatchers, service managers, and sales professionals. Our in-person courses are built exclusively for the managed services industry. Headquartered in Washington, DC, serving MSPs across the United States.
