It’s not a people problem or a tools problem. It’s a model problem.
Every MSP owner thinks they’ve solved dispatch. Most of them are still getting burned by the same bottlenecks they were three years ago.
That’s not a people problem or a tools problem. It’s a model problem. And until you can see the model clearly, you can’t fix it.
Decades ago, Michael E. Gerber made a case in The E-Myth Revisited that has aged into something close to gospel for modern operators. “The system runs the business. The people run the system,” he wrote. The businesses that scale are the ones that build their processes into the system itself, not the ones that rely on people to remember, document, or enforce them. A modern service delivery posture isn’t possible on top of a dispatch model that depends on someone holding it all in their head. Your dispatch operating model is either pulling your service delivery forward or holding it back.
The Model Most MSPs Are Running
Walk into the average MSP service desk and you’ll find some version of the same thing: a dispatcher, human or digital, looking at a queue and pushing tickets out to technicians. Someone decides who gets what. That decision gets made over and over again, all day, every day.
This is Push dispatch. And it comes in three flavors, each one feeling like an upgrade over the last.
Here’s the pattern that traps most MSPs on this ladder: when dispatch breaks, the default move is to hire a person with the right skill set to plug the hole. That instinct feels responsible. It also keeps you on the Push path indefinitely. Each stage that follows is a refinement of “hire someone to fix it,” not a move toward building the process into the system.
Stage 1 — Manual Push. Your dispatcher assigns everything by hand. They know which techs are good at what, who’s slammed, who has bandwidth. It works because one person holds all the context in their head. That person becomes the single point of failure for your entire service operation. The trigger to evolve usually shows up the first time they take a vacation.
Stage 2 — Structured Push. You’ve built SLA tiers into your PSA. You’ve got workflow rules, priority queues, escalation paths. The dispatcher still owns every call, but now there’s a system underneath them. Most MSPs plateau here and assume they’ve arrived. The trigger to evolve shows up when ticket volume outpaces what any one person can route.
Stage 3 — Hybrid. You’ve added an AI triage layer or skill-based routing on top of your PSA. The good tickets route themselves. The messy ones still land on the dispatcher’s desk, and the dispatcher is now also the troubleshooter when the automation gets it wrong. They’re not doing less work. They’re doing different work, and they’re still the ceiling.
Push is Push, whether a human is making the call or an algorithm is. Every assignment decision flows through a single point. Stages 1 through 3 all share the same flaw Gerber warned about: the process lives in people, not in the system.
The Model That Actually Scales
Stage 4 — Structured Pull is a different operating system, not a better Push.
This is where Gerber’s principle finally shows up in dispatch. The process is built into the software itself. Work is ranked, filtered, and made available based on rules the business has agreed to in advance. When a technician is ready for their next ticket, they pull the highest-priority job that matches their skills and availability. The dispatcher isn’t making the call anymore. The system is.
Picture a Tuesday morning. A tech wraps a ticket at 10:14 AM. They open their queue and see the next-best ticket already prioritized for them, ranked against the SLA clock and matched to their skill set. They accept it and start work. The work was already waiting.
Pull isn’t just a more efficient way to assign tickets. It’s the operating foundation that makes modern service delivery achievable — proactive communication, predictable SLAs, technician utilization that actually scales. Without it, every other improvement is bolted onto a model that can’t carry the weight.
And the dispatcher isn’t going anywhere. Pull doesn’t eliminate the role, it elevates it. Instead of making the same hundred small decisions over and over, your dispatcher manages flow, handles exceptions, and finally has time for the work that actually requires human judgment.
The industry is already moving in this direction. ConnectWise’s acquisition of zofiQ in early 2026 made the bet explicit: ticket intake, triage, classification, and routing are the operational layer where service desks now compete. The companies that handle that layer natively, inside the PSA, are the ones positioned to scale. The companies still running it through a dispatcher’s memory aren’t.
Where Does Your MSP Sit?
Four stages, one direction of travel:
- Manual Push — Dispatcher assigns everything by hand. Tribal knowledge rules.
- Structured Push — Rules and SLAs exist, but the dispatcher still owns every call.
- Hybrid — Partial automation, inconsistent execution. The dispatcher fills the gaps.
- Structured Pull — System ranks. Technicians pull. Dispatcher manages flow and exceptions.
Most MSPs reading this are at Stage 2 or Stage 3. Stage 3 is the most uncomfortable place to be honest about, because you’ve already invested in change and the results haven’t matched the promise. That’s not a failure of execution. It’s a signal that you’ve maxed out what Push can do.
The Question Worth Asking
The MSPs building toward a modern service delivery operation aren’t asking which Push tool to buy next. They’re asking whether their dispatch model can support where they’re trying to go.
Gerber’s point still holds, thirty years later. The system runs the business. The people run the system. When your dispatch process lives in software, your operation can scale. When it lives in people, it can’t.
Where on the Dispatch Operating Model is your MSP today, and where will it be in two years?
