AI Agent for MSP Dispatch: Your PSA Doesn't Know Who's Actually Free

A service manager was reviewing dispatch recommendations and noticed the same technician kept coming up. On paper it made sense: she had two open tickets, both with estimates, and she was the lightest queue on the board.

Part of our guide to AI agent for MSPs.

Their internal scheduling tool told a different story. She was committed to roughly 72 hours of project work over the next two weeks. That time lived on a project board the dispatch agent couldn’t see. As far as the ticket queue was concerned, she was nearly idle.

A week later, at a different MSP, a technician started getting dispatch recommendations while he was on vacation. His queue was empty, which made him look like the best candidate. Of course it was empty. He was on a beach. Nobody had marked him out of office in the PSA.

Neither of these is an AI failure. The agent did exactly what a very literal dispatcher would do with the data it had. The problem is that most PSAs don’t know who is actually available, and your human dispatcher has been quietly filling that gap for years.

Your dispatcher knows things your PSA doesn’t

When a senior person dispatches tickets by hand, they’re working from two sources. One is the PSA: open tickets, SLAs, categories. The other is everything else: she’s slammed with the migration this week, he’s onsite until Thursday, don’t give her anything big, she’s out Friday.

That second source never gets written down because it doesn’t need to be. The dispatcher applies it automatically.

An AI agent for MSP dispatch only gets the first source. If the capacity picture in your PSA is wrong, the agent’s recommendations will be confidently wrong in exactly the ways your dispatcher never is. That’s usually the moment people decide automated dispatch “doesn’t understand our business.”

It understands your PSA perfectly. Your PSA just doesn’t understand your business.

Where the PSA lies about capacity

Time off that was never entered

This is the most common gap and the easiest to fix. Vacation gets approved over Teams or email, goes on someone’s personal calendar, and never makes it into the PSA’s schedule. An empty queue then looks like spare capacity instead of absence.

Project work on a separate board

Many MSPs run service tickets and project work in different places: a separate project board, a scheduling tool, or calendar blocks. If dispatch only counts service tickets, anyone doing heavy project work looks underused. These are often your most experienced people, which makes the misrecommendation worse.

Onsite and travel time

A technician who is driving between client sites or sitting in a server room can’t pick up a remote ticket in 20 minutes, even if their queue is light. If onsite visits aren’t scheduled in the PSA, they’re invisible.

People who are only partly on the service desk

The owner who still takes tickets. The senior tech who spends half the week on vCIO work. The team lead who dispatches in the morning and fixes things in the afternoon. A PSA that assumes everyone has a full-time service desk capacity will over-assign all of them.

”Empty queue” is ambiguous

An empty queue can mean someone is free, someone is off, or someone just closed everything before lunch. Ticket count alone can’t tell those apart. That’s why counting tickets is such a poor proxy for load.

What good availability data looks like

You don’t need a new tool for this. You need a few rules your team actually follows.

Make “not in the PSA” mean “available.” Adopt one rule: if your time off isn’t blocked in the PSA calendar or marked out of office, dispatch will treat you as available. That’s fair, easy to explain, and it fixes the vacation problem within a week, because people who get dispatched on their day off start entering time off.

Let the agent read project allocations. Give dispatch read-only access to wherever project time is scheduled, so committed hours count against capacity. If that isn’t possible yet, cap available service hours for heavy project people with a dispatch rule. For example: “Technicians on the Projects team take at most two new service tickets per day.”

Schedule onsite visits as time blocks. Not just as a note on the ticket. If it’s on the calendar, dispatch can route around it.

Write partial capacity down as rules. “The owner only receives escalations.” “Tier 3 does not take password resets.” “Team leads get no new tickets after 1 PM.” These are the unspoken rules your dispatcher applies. Written down, they become hard filters that remove someone from consideration entirely instead of hoping the model infers it.

Weigh work, not ticket counts. A good dispatch model considers estimated remaining work and how much new work someone has received recently compared with their scheduled hours, not just how many tickets are open. Otherwise the technician who closes quickly gets punished with more work, and the one sitting on an aging ticket gets skipped forever.

Read your overrides as a data audit

If you’re running dispatch in suggest mode, and early on you should be (here’s the staged approach), every override is useful information. Ask the team lead to record a one-word reason when they change a recommendation. After two weeks, sort them.

You’ll usually find they fall into three buckets:

• “Not available.” Missing time off, project work, or onsite visits. That’s a data gap. Fix the calendar, not the agent.
• “Wrong skill.” The agent doesn’t yet know who is good at what. This improves as closed tickets build each technician’s history, and you can speed it up with rules for specialties like networking or a specific line-of-business app.
• “Client preference.” This client always gets the same tech. That’s a client-specific rule. Write it down where the agent can read it. The client-specific context layer covers where those rules should live.

When “not available” overrides drop to near zero, your availability data is good enough to let dispatch assign on its own for the categories you’re comfortable with.

A 30-minute dispatch readiness check

Before you let any AI agent for MSP dispatch assign tickets automatically, run through this with your service manager:

1. Is everyone’s time off for the next two weeks in the PSA? Check, don’t ask.
2. Where does project time live, and can dispatch see it?
3. Are onsite visits scheduled as calendar blocks?
4. Who is only partly on the service desk, and is that written as a rule?
5. Which clients have a dedicated technician, and is that written down?
6. When the agent assigns a ticket, does the technician actually get notified?

If you can’t answer yes to the first three, stay in suggest mode. The agent may be ready. Your calendar isn’t.

How Mizo’s Dispatch Agent handles availability

Mizo’s Dispatch Agent shortlists the right team, then ranks technicians in a fixed order. Availability comes first: working hours and time off are checked, and anyone unavailable is excluded outright. Then SLA fit based on how quickly each person has resolved similar tickets, then workload based on open work, estimated remaining effort, and recent intake relative to scheduled hours. Skill match breaks ties.

Your dispatch rules apply before any of that as hard eligibility filters, so “the owner only gets escalations” actually means it. Dispatch can run in suggest mode or assign automatically, and you can choose per workflow.

What it can’t do is see a vacation that only exists in a Teams message. That part is on you, and it’s worth the ten minutes.

👉 See Mizo’s dispatch recommendations on your own board, in suggest mode, before anything gets assigned. Book a demo.

FAQ

Why does AI dispatch assign tickets to technicians who are busy or away?

Because the PSA shows them as available. Time off that isn’t in the PSA, project work tracked on a separate board, and unscheduled onsite visits all make busy technicians look idle.

What data does an AI agent for MSP dispatch need?

At minimum: working hours, time off, open tickets with estimates, and team membership. For accurate recommendations, add project allocations, onsite schedules, and written rules for partial capacity and client preferences.

Should dispatch be based on ticket count?

No. Ticket count ignores ticket size and recent intake. Weigh estimated remaining work and recent assignments against scheduled hours so fast closers aren’t punished with more work.

When is it safe to turn on automatic dispatch?

When overrides for “not available” are close to zero for a couple of weeks. That’s the sign your availability data is reliable. Start with the categories where overrides are lowest.