Nobody Should Be Paid to Decide Who Gets the Ticket

An MSP leader told me recently that one of his team leads spends roughly 30% of his week on dispatch. Not solving tickets. Not coaching. Deciding who gets what.

That’s a day and a half, every week, of a senior person’s time spent being a routing table with a salary and a pension.

He wasn’t complaining, either. He said it the way you’d describe the weather. That’s the part that stuck with me — dispatch overhead has been normalized to the point where MSPs don’t count it as a cost anymore.

It is. And it’s one of the few costs in this business that’s now genuinely optional.

Two models, and why most MSPs are stuck between them

Almost every service desk runs one of two dispatch models.

Pull (queue-based). Tickets land in a shared queue. Technicians self-select. Nobody assigns anything.

Push (assigned). Someone — a dispatcher, a team lead, a coordinator — assigns each ticket to a named technician.

Pull is cheap to operate and terrible for accountability. Cherry-picking is inevitable: the easy tickets evaporate, the ugly ones age. Nobody owns anything until they choose to, which means nobody owns the thing nobody wants to choose.

Push gives you accountability, priority control, and a real capacity picture. It costs you a human being’s time, permanently, forever.

Most MSPs I talk to are on pull and want to be on push. They just can’t justify the headcount. So they compromise: pull with a team lead who intervenes when things go sideways — which is to say, push, done reactively, by someone whose actual job is something else.

Why MSPs resist automated dispatch (and they’re not wrong)

When I suggest letting a system handle assignment, I hear the same three objections. All three are legitimate.

”The system doesn’t know who’s actually available”

A technician is on site. Another is deep in a project block. A third is technically free but has three tickets about to breach. A naive assignment engine sees three available technicians and picks the wrong one.

This is the real objection, and it’s a data problem before it’s an AI problem. If your PSA doesn’t reflect on-site status, project allocation, or PTO with any accuracy, no dispatcher — human or otherwise — can route well.

”The system doesn’t know who’s good at what”

Skill matching is where most MSPs’ data is weakest. Technician skill profiles either don’t exist or were filled in during onboarding two years ago and never touched again. The knowledge of who’s genuinely strong on networking versus M365 lives entirely in the team lead’s head.

”I’ll lose control”

Fair. This is the one nobody says out loud, but it’s underneath the other two.

The answer is not full automation

I’ll say this plainly, because it’s where I differ from a lot of the AI marketing in this channel: I don’t think you should hand dispatch to a machine and walk away on day one. Full delegation is the destination — but you earn it in stages, category by category, not by flipping a switch.

The model that actually works — the one our partners land on after the initial enthusiasm settles — is human-in-the-loop dispatch. The system proposes an assignment, using priority, category, skill match, current load, and SLA risk. A human confirms or overrides. The override takes two seconds.

What this changes isn’t the decision. It’s the cognitive load of the decision. Your team lead stops evaluating 60 tickets from scratch and starts reviewing 60 pre-made recommendations. That’s the difference between an hour and ten minutes.

And critically: every override is a signal. A dispatch system that learns from what your team leads correct gets better; a static routing rule set doesn’t.

One partner is explicitly targeting a move from about 175 end users per technician to 250 without hiring. You do not close a gap that size by working harder. You close it by deleting categories of work — and dispatch decisions are the most deletable work on a service desk, because they generate zero client value and consume senior time.

The failure mode nobody warns you about

Here’s a failure mode I’ve watched play out in dispatch rollouts, and I’d rather you learn it from this article than from your own.

The assignment engine does its job — right technician, right priority, right time. And the team leads keep manually dispatching everything through the PSA anyway.

Why? Because the assigned technician isn’t being notified. The assignment happens in the record, but no notification fires. So from the technician’s point of view, nothing has happened, and from the team lead’s point of view, the tickets still need dispatching. The automation works perfectly and produces zero value, because the notification loop is open.

If you take one operational lesson from this piece, make it this: an automated action that nobody is told about is not automation. Before you go live on dispatch, map every notification path. Who gets told, through which channel, and what happens if that channel isn’t being watched. It’s why notification mapping is a standard part of Mizo’s dispatch onboarding, not an afterthought.

A staged path that actually works

Don’t flip from pull to fully assisted push in one week. Stage it.

Stage 1 — Automate classification only. Let the system set type, subtype, priority, and category. Change nothing about who gets tickets. This builds the classification quality that everything downstream depends on, and it’s low-risk enough that nobody panics.

Stage 2 — Suggest, don’t assign. The system recommends an owner; a human clicks to confirm. Track your override rate weekly. A high override rate is information, not failure — read the overrides and find out what the system doesn’t know about your business.

Stage 3 — Auto-assign the confident cases. Once override rates on a given category drop to something you’re comfortable with, let those flow through untouched. Keep the ambiguous ones in review.

Stage 4 — Review, don’t dispatch. Your team lead’s dispatch time drops to a morning glance at exceptions. That’s the destination.

Most MSPs can get to stage 2 in a couple of weeks. Stage 3 depends almost entirely on how good your data was in stage 1.

This staged path is exactly how Mizo rolls out dispatch. The Triage Agent handles stage 1 — type, subtype, priority, category on every ticket at arrival. The Dispatch Agent proposes assignments from skill match, load, and SLA risk, learns from every override, and auto-assigns only the categories you’ve delegated. The autonomy level is yours to set — from suggest-only to fully delegated — per client and per category.

The real point

I ran a service desk for years. I dispatched tickets myself, then paid other people to, then paid better people to. At no point did any client ever pay us a dollar for that work.

Dispatch is pure internal friction. It exists because tickets arrive faster than humans can sort them, and because sorting requires context that used to live only in a person’s head.

That second part isn’t true anymore. Which means the job is going away — and the MSPs that get there first will be running the same headcount against materially more endpoints than the ones that don’t.

What would your best team lead do with a day and a half back every week? That’s the question. It’s not really about dispatch at all.

Written by a former MSP operator who spent too many mornings assigning tickets by hand.