A TimeZest perspective · Dispatch
Your dispatcher isn’t the problem.
Your dispatch model is.
Every morning, your dispatcher builds something remarkable — mapping out the day with care, ticket by ticket, trusting the structure holds. They’re not failing you. The model they’re working in is.
The Case | Push vs Pull Dispatch
The way MSPs dispatch work hasn’t changed in 25 years.
The way MSPs work has.
Every MSP dispatcher knows the ritual. You review unassigned tickets, and start to assign them out, matching technicians to tickets based on priority, skill, availability, and whatever context you can hold in your head. It’s methodical. It’s deliberate. And for a long time, it was the only option.
1
The Model the Industry Was Built On
A whiteboard in an app.
This is Push dispatch: a centralized model where someone pushes every ticket to every technician, all day, every day. It’s the model the MSP industry was built on.
The tools got better. The whiteboard got digitized, then became a PSA module. But the underlying model never changed. Whether it’s a dedicated dispatcher, multiple dispatchers splitting the load, or a service manager handling dispatch on top of everything else, someone is still evaluating each ticket individually, assigning work based on memory and judgment, and owning every decision about who works what and when.
Legend has it that the original PSA dispatch model was built from an actual whiteboard
The Shorthand
Push: someone pushes every ticket to every technician, all day, every day.
2
Where Push Starts to Break
Not a failure of effort.
A failure of architecture.
Ticket volumes grow. Client complexity increases. SLA tiers multiply. Technician specializations deepen. And whoever is running dispatch — whether that’s a dedicated role or a service manager wearing the hat alongside ten others — becomes the bottleneck.
The symptoms are familiar. Tickets sit in queue while the wrong technician works the wrong issue. A priority shift mid-morning triggers a cascade of reassignments, each one requiring coordination, context transfer, and communication. Technicians start the day with ten or fifteen tickets that might end up reassigned, sometimes multiple times. The people running dispatch spend more time reorganizing the day than managing it.
Then the real risk shows up: someone leaves.
The Bottleneck
Whoever runs dispatch — even if it’s a service manager wearing the hat alongside ten others — becomes the limiting resource for the whole team.
A dedicated dispatcher gets promoted or burns out. A service manager who’d been handling dispatch as a side responsibility finally can’t keep up. And the institutional knowledge they carried — which technician handles which client, which tickets need special routing, which SLAs are closest to breach — walks out with them. The team scrambles, and everyone remembers just how much was held together by someone’s memory rather than a system.
This isn’t a failure of effort. It’s a failure of architecture. Push dispatch places every decision on the people running it, and every disruption — a technician calling out, a client rescheduling, a ticket escalating — ripples through every other decision they’ve already made. The more complex the operation gets, the more fragile the model becomes.
Key-person Risk
The mental model that holds the operation together walks out the door with the person who carried it.
3
Why MSPs are Moving to Pull
The decision about what comes next is made by the system.
A growing number of MSPs are adopting a fundamentally different approach: Pull dispatch.
In a Pull model, technicians don’t receive a stack of tickets each morning. Instead, when a technician is ready for their next piece of work, they pull it from a queue that’s already been ranked and prioritized — by SLA risk, urgency, skill fit, ticket age, and client context. The decision about what comes next is made by the system, directed by the dispatcher. The technician executes.
With Push you’re building a house of cards.
With Pull, you’re stacking the deck for your techs.
The queue is intelligently ordered before anyone touches it. Technicians pull from the top, not from wherever they’d prefer.
The dispatcher’s role changes too, and for the better. Instead of making every assignment from scratch, dispatchers become flow managers: monitoring the queue, handling exceptions, overriding when judgment calls are needed, and focusing on the escalations and client conversations that genuinely require a human. The cognitive load drops. The decision volume drops. The value of the role goes up.
For service managers who’ve been doubling as dispatchers, Pull can be the difference between spending an hour a day on dispatch and spending the entire day buried in it.
An Important Distinction
Pull is not technicians choosing whatever they want. It’s constrained choice within guardrails.
For technicians, the shift is just as meaningful. The morning pile of tickets disappears. So does the ambiguity about what to work next, the debate over why they got a particular assignment, and the temptation to cherry-pick the easier work and defer the rest. When the next ticket is determined by the system rather than a colleague, the pushback and negotiation that quietly drain team dynamics start to fade.
For the business, Pull dispatch addresses the single biggest operational risk in service delivery: key-person dependency. When dispatch logic is codified in a system rather than stored in someone’s head, the operation keeps running through PTO, turnover, and growth. A new dispatcher can be effective in days, not months, because the system already knows how the team should work.
What Changes for Techs
No morning pile. No ambiguity. No debate over why this ticket landed on their queue.
THE SHIFT IS STRUCTURAL
MSPs that move to Pull aren’t optimizing their current process — they’re replacing the underlying model.
Push dispatch was the best approach available when the tools didn’t exist to do it differently. The tools exist now — and it’s the reason we built Dispatch HQ.
More Stable Sequencing
Better SLA Performance
Dispatch teams freed for the work that actually requires their expertise
Two Models
Understanding Push and Pull is where dispatch starts to scale.
Your MSP’s stack has transformed in the last two decades. RMM is automated. Security runs without your team. Documentation practically writes itself. But dispatch? Dispatch still looks a lot like it did 25 years ago — a dispatcher, a queue, and a fresh round of judgment calls every single day.
That’s the Push model. It’s not broken. It’s just unevolved.
PUSH DISPATCH
Understanding Push and Pull is where dispatch starts to scale.
Tickets flow in, get triaged, prioritized, and handed out — one at a time, all day long. Works acceptably at small scale. Buckles with growth.
PULL DISPATCH
Technicians pull the next right ticket when they have capacity.
From a queue the system has already ranked by priority, SLA window, and skill fit. The ranking happens before anyone has to decide.
Pull isn’t technicians choosing whatever they want. The system does the ranking, and technicians execute from an intelligently ordered queue. That’s a very different thing from autonomy.
Where Does Your MSP Fit?
Most MSPs aren’t purely Push or Pull — they’re somewhere in between.
YOU’RE MOST LIKELY HERE
STAGE 1
Manual Push
Dispatcher assigns everything by hand. Tribal Knowledge rules.
STAGE 2
Structured Push
Rules and SLAs exist, but the dispatcher still owns every call.
StAGE 3
Hybrid
Partial automation, inconsistent execution. The dispatcher fills the gaps.
STAGE 4
Structured Pull
System ranks. Technicians pull. Dispatcher manages flow and exceptions.
Why Pull Works at Scale
The operational case shows up in your SLA numbers — and your dispatcher’s stress level.
01
The reassignment cascade shrinks.
One priority ticket no longer triggers four downstream moves. When the system does the ranking, the ripple effects flatten.
02
The debate ends.
A system can’t be negotiated with. The back-and-forth over why a tech got a specific ticket disappears when the answer isn’t coming from another human.
03
Your dispatcher transforms.
Pull shifts them from decision-maker on every ticket to flow manager for the whole team. A more sustainable role, and a more valuable one.
04
Dispatch becomes muscle memory.
If your best dispatcher takes PTO, gets promoted, or wins the lottery, the wheels come off. Pull codifies the logic so operations keep running, whether your dispatcher is in the office or not.
The Point
The MSPs who scale past 15 technicians without burning out their dispatcher almost always move toward Pull, whether they call it that or not. However, it starts to become a problem long before that threshold.
Two Halves of The Same Problem
Dispatch answers what and who.
Scheduling answers when.
Dispatch
Who + What
The right technician for the right ticket, ranked by priority, SLA, and skill fit.
Priority
SLA Fit
Skill Match
Scheduling
When
The right moment for that ticket — for the client, for the tech, for the calendar.
