Service Desk AI for MSPs: Seven Dispatch Guardrails That Stop AI Undoing Your Team's Work

One week after an MSP turned on AI dispatch, their service desk manager sent us a list.

Junk tickets were getting through intake and being dispatched to technicians. An internal ticket that one tech had assigned to a colleague got reassigned to someone else. A few tickets landed on the Sales board even though there was an explicit rule against it. Monitoring alerts were being moved off the alerts board. A closed spam ticket was reopened and assigned. And because some tickets lost their owner along the way, the whole team was getting “unassigned ticket” notifications.

Triage, meanwhile, was performing well. The problem was dispatch acting on tickets it should never have touched, and sometimes overriding decisions triage, or a human, had already made correctly.

We fixed it in a single working session. Nothing was wrong with the model. The configuration was missing guardrails that every MSP needs and few write down. Here they are, so you can set them before go-live instead of after.

Why dispatch needs stricter rules than triage

Triage mostly adds information: a summary, a category, a priority, a type. If it’s slightly off, a technician corrects it and moves on.

Dispatch changes ownership. It moves tickets between boards and people. A wrong dispatch decision means a ticket sits in the wrong queue, a technician gets work that isn’t theirs, or someone’s in-progress work is pulled out from under them. Service desk AI for MSPs has to be more conservative about who owns a ticket than about what the ticket says.

Guardrail 1: Never reassign a ticket that’s already assigned

If a human has already assigned a ticket, dispatch should leave it alone. The person who assigned it usually knew something the AI didn’t: a conversation with the client, a handoff, a technician who’s already on site.

Rule: if the ticket has an owner, don’t change the owner. If it truly has none, assign it per your dispatch logic or, for internal tickets, to the person who created it.

Guardrail 2: Internal tickets are off-limits

Internal tickets, the ones your team creates for itself, follow different rules. They’re often assigned deliberately, have no SLA, and aren’t client work.

Rule: define what “internal” means at your MSP (an internal board, a title prefix, an internal company) and tell dispatch never to reassign, re-route, or change status or priority on those tickets.

Guardrail 3: Only dispatch from the boards you mean

Dispatch should only pick up tickets from the boards where new client work arrives. In the case above, a low-signal intake board, where junk and spam are parked and closed, had been included in the dispatch configuration. So dispatch dutifully picked up closed junk and sent it to technicians.

Rule: list the boards dispatch may read from. Exclude junk, spam, archive, and any board where tickets are parked on purpose.

Guardrail 4: Explicitly exclude destination boards

Some boards should never receive a ticket from automated dispatch: Sales, Projects or Professional Services, Internal, and often Onboarding/Offboarding unless the request clearly matches.

Rule: maintain an exclusion list of destination boards. Anything from an external client defaults to the Help Desk, never to Sales or Internal.

Guardrail 5: Leave monitoring alerts where they live

Alert tickets from your RMM, EDR, backup, and email security tools often have their own board and their own team. Moving them into the general help desk clutters the queue and breaks the workflow your NOC or SOC relies on.

Rule: alert tickets stay on the alert board. Dispatch can assign within it if you want, but shouldn’t move them out.

Guardrail 6: Junk gets labeled, not dispatched

Spam campaigns change shape. A wave of tickets in another language, or from lookalike domains, can get past intake filters for a while. When that happens, the worst outcome is that they get dispatched to technicians as real work.

Rule: if intake marks a ticket as junk, dispatch should never act on it. When in doubt, leave it in place, labeled, for a human to confirm. See clearing the tickets nobody needs to read for how to tune intake.

Guardrail 7: Boards with special meaning need narrow rules

Some boards exist for a specific purpose. A “Client Experience” board might be meant for tickets where a client is clearly very happy or very unhappy. Without a narrow definition, an AI might route anything that sounds emotional there, or nothing at all.

Rule: for each special-purpose board, write one sentence that says exactly when a ticket belongs there. “Only route here if the client expresses strong satisfaction or dissatisfaction with our service.” Narrow beats broad.

Bonus: keep your rules clean

After a week of fixes, rules accumulate. Two rules say slightly different things about the same board, or an old rule from before a client changed service tiers still applies. That’s how a ticket for a co-managed client ends up routed to the onsite team.

Review your dispatch rules monthly. Remove duplicates, resolve conflicts, and delete rules for clients or boards that no longer exist. We covered where these rules tend to hide in client-specific rules and the context layer.

A go-live checklist for AI dispatch

Before you switch dispatch from recommendations to autonomous mode:

1. Which boards can dispatch read from?
2. Which boards can it never send tickets to?
3. What counts as an internal ticket?
4. What happens to tickets that are already assigned?
5. Where do alert tickets live, and can dispatch move them?
6. What does dispatch do with tickets intake marked as junk?
7. What’s the exact definition of each special-purpose board?
8. Who reviews dispatch decisions daily for the first two weeks?

How Mizo handles dispatch guardrails

Mizo’s dispatch agent runs in ConnectWise, Autotask, and HaloPSA and is configured in plain language:

• Board scoping controls which boards dispatch reads from and which it can route to.
• Rules in plain language handle internal tickets, already-assigned tickets, alert boards, and special-purpose boards, globally or per client.
• Technician availability and workload are considered, so tickets go to someone who’s working and not overloaded. See dispatch and technician availability.
• Recommendation mode first. Dispatch suggests, a human approves, and you switch to autonomous when the suggestions are consistently right.
• Reasoning on every ticket, so when a decision looks wrong you can see why it was made and fix the rule in minutes.

Learn more about our approach to AI dispatch for MSPs.

👉 Planning an AI dispatch rollout? Book a demo and we’ll walk through this checklist against your boards.

FAQ

What is service desk AI for MSPs?

It’s AI that works inside your PSA to handle intake, triage, dispatch, and client communication across all your clients, with per-client rules and human approval where needed.

Why did AI dispatch reassign tickets my team already assigned?

Usually because no rule told it to respect existing assignments. Add a guardrail that leaves assigned tickets alone and never touches internal tickets.

Should AI dispatch move monitoring alert tickets?

Generally no. Alert tickets usually belong on a dedicated board with their own workflow. Let dispatch assign within that board if useful, but keep them there.

How long should AI dispatch run in recommendation mode?

Typically one to two weeks, with a daily review. Switch to autonomous once recommendations are consistently correct for your boards and rules.