It’s 7:48 AM on a Monday, and Sarah, your dispatcher of four years, has the flu.
By 9:15 AM, two things are true. The first: your service manager is no longer working on the strategic project you hired her to drive this quarter. She’s reading through the overnight ticket queue, trying to remember which techs handle SonicWall escalations and which ones the law firm in Cherry Hill insists on. The second: you are quietly, deeply unsettled by how much of your service operation is tied to one person being at her desk.
This is the dispatcher problem most MSPs have but almost nobody names out loud.
The hidden architecture
When a dispatcher is good at their job, the work disappears. Tickets get to the right techs. Priorities reshuffle when the day changes. Clients don’t feel the chaos. From the outside, it looks like the system is doing the work.
It isn’t. The system is doing the bookkeeping. The dispatcher is doing the work, and most of what they’re doing lives in their head.
They know that when Brian is on the schedule, the Phillips account ticket goes to him because he was on the original install. They know the IT lead at your top client only escalates when something is genuinely on fire, so when his name shows up in the inbox, that ticket moves up. They know which clients can wait until tomorrow and which ones can’t, regardless of what the priority field says.
None of this is in your PSA. It’s institutional memory, operational knowledge that builds up day by day, conversation by conversation, ticket by ticket, until it’s woven so tightly into how the business runs that you can’t separate it from the person carrying it.
The ten-item Word doc
Ask most MSPs to show you their dispatch documentation and you’ll get something like this: ten bullets in a Word doc. Check the inbox every fifteen minutes. Confirm priority and agreement. Ask the user three questions for password resets. Escalate Tier 3 to the senior team.
That isn’t how dispatch actually works. That’s the cover sheet. The actual logic, the judgment calls, the client politics, the tech personality map, the sense of which ticket will balloon if it isn’t handled by 11 AM, happens in real time, in your dispatcher’s head, every day. And it has been quietly accumulating there for years.
This is what makes the role so hard to back up. You can document a process. You can’t easily document four years of pattern recognition.
The unicorn problem
Most MSP owners have, at some point, had a great dispatcher. Just one. And ever since that person was promoted, moved into project management, or simply left, the owner has been quietly hunting for another one.
A service manager put it cleanly: “Two years ago I had an awesome dispatcher. I’ve been searching for a unicorn ever since.”
The bar is genuinely high. The role calls for someone non-technical enough not to try to fix every ticket themselves, but with enough operational instinct to read the day. Someone with the personality to hold the line when a tech pushes back, without the formal authority of a manager. Someone who can absorb a service manager’s worth of knowledge and apply it under pressure. That person is rare. And when you find them, the clock starts ticking on losing them.
The unicorn isn’t coming back. And honestly, finding a great dispatcher will probably always be hard. But keeping your dispatch operation running shouldn’t depend on finding one.
It isn’t a staffing problem
The instinct, when the dispatcher is the bottleneck, is to think harder about the dispatcher. Hire better. Pay more. Document more carefully. Cross-train a backup. All sensible. All limited by the same constraint, they assume the right answer is to make the human point of failure stronger.
The architecture is what’s wrong. As long as the institutional memory that runs your service operation lives in one person’s head, every vacation week is a liability and every resignation is a crisis. You can mitigate that by making your dispatcher heroic. You can only solve it by changing where the memory lives.
This is the quiet shift the more mature MSPs have started making. Not find a better dispatcher. Not document harder. But moving the actual decision logic, priority weighting, skill matching, sequencing, SLA awareness, out of the dispatcher’s head and into the system, so the dispatcher’s job becomes curating exceptions and managing escalations rather than running the entire engine from memory.
The dispatcher doesn’t become less valuable in that world. They become harder to lose.
The best time to plant a tree
There’s an old line that the best time to plant a tree was twenty years ago. The second-best time is today.
The same applies here. The best time to start moving institutional memory out of one person’s head was the year before your last great dispatcher left. The second-best time is now — while the person who actually knows how your service operation works is still at her desk, still in a position to teach the system everything she knows.
Because eventually, predictably, the chair will be empty for a week. And the question won’t be whether your operation feels it.
The question will be how much.
