The 90-second decision your dispatcher makes alone
It is 7:40 AM. A technician calls in sick, a freeze warning just bumped four no-heat calls to the top of the queue, and the truck that was supposed to cover the south route is stuck behind an accident on the interstate. Your dispatcher is now holding three things in their head at once: which customers were promised a same-day arrival window, which technicians are certified for the equipment on those jobs, and what your service agreements actually require versus what's a courtesy. Get it wrong and you eat a missed-SLA penalty, a furious commercial account, or a tech sent two hours out to a job they can't legally complete.
That is the moment worth building AI for. Not "summarize our manuals" and not a chatbot bolted onto your scheduling tool, but the specific squeeze where a dispatcher needs the right service rule, the right customer commitment, and the right technician constraint pulled together faster than they can dig for it themselves. The research on mid-market adoption keeps making the same point in different words: the value isn't the model, it's whether you translated a real bottleneck into a source path, an owner, and a review cadence. See the RSM middle-market AI survey, the San Francisco Fed analysis of AI and small businesses, and the OECD report on AI adoption by small and medium-sized enterprises.
So before anyone writes a prompt, I map four things for one exception type: where the trusted record actually lives (the dispatch software's notes field, the signed service contract, the tech certification roster), who owns the decision when the answer is ambiguous, what output the dispatcher is allowed to act on without a second set of eyes, and which exception jumps straight to a supervisor. The AI's job is to retrieve and rank that context in seconds. The operating design decides what's trusted. Those are not the same project, and confusing them is how field service teams end up with a confident assistant that quietly recommends sending an uncertified tech to a refrigerant job.
Make the answer carry its receipts
Here is the failure mode that bites field service specifically. Your knowledge isn't in one clean wiki. The arrival-window promise is buried in a sales note from eight months ago. The technician constraint is a certification expiry nobody updated. The "we always prioritize this account" rule is a thing your operations lead carries in their head. Feed all of that into a model and ask for a dispatch recommendation, and you'll get a fluent, plausible answer with no way to tell whether it leaned on a current rule or a stale sales note. A wrong dispatch answer doesn't sit in a draft folder. It rolls a truck.
So I require every recommendation to show its receipts. The NIST AI Risk Management Framework gives you the language for context, reviewer accountability, and measurable risk on this exact workflow, and CISA AI Data Security Best Practices tells you how to decide which service rules, customer commitments, technician records, contract notes, and exception history get exposed to the model, retained, logged, or kept out entirely. Customer phone numbers and contract pricing don't belong in the same retrieval pool as routing rules.
Concretely, when the AI proposes "reroute the freeze call to Tech B," the dispatcher should see, on one line: the rule version it pulled (priority policy v.4, not the 2024 draft), the customer commitment it honored (4-hour window per the signed MSA), the technician constraint it checked (Tech B's gas certification, valid through next March), a confidence flag, a field for the dispatcher's accept-or-override, and the escalation path if anything's missing. That packet is the difference between a tool your supervisors trust and one they route around. If a general search assistant is all you need for a low-stakes exception, fine, keep the output as a draft and require signoff. But the moment a recommendation writes back to the schedule or triggers a customer notification, you put deterministic checks around the model, not after it.
Track the metrics that catch a rotting rulebook
The honest measure isn't whether the pilot was busy. Deloitte's State of AI in the Enterprise 2026 keeps pushing the same question: did this produce production value or pilot theater? For dispatch, production value is concrete. A dispatcher can accept, challenge, or escalate a source-backed recommendation in the time they have, without re-digging the whole thing by hand.
Watch five numbers. Recommendation acceptance rate tells you if dispatchers actually trust it. Source-missing rate tells you when the AI answered without a rule behind it, which is your early warning. Time to dispatch decision tells you if it's faster than the dispatcher alone. Escalation correction rate tells you whether the hard cases reached a human who fixed them. And outdated-rule discoveries is the sleeper metric: the first time the AI surfaces a "current" priority policy that contradicts what your ops lead actually enforces, you've found a knowledge-base rot problem the pilot just paid for itself by exposing. If dispatchers can't inspect the rule behind an answer, stop adding AI and go fix the source.
Start narrow and earn the right to expand. Use the manual-work scoring guide to confirm one exception category (say, no-heat reroutes during weather events) is worth automating before you touch the rest. Then run the 90-day AI implementation plan to stage it: clean and version the source rules first, prototype on that one category, train the dispatchers who'll review it, launch, then decide on scale. Index only approved rules and real service history. Require the supervisor to log why each recommendation was accepted or changed, because that log is your training signal and your audit trail at the same time. The system earns more scope when it raises decision confidence and keeps catching stale rules nobody else was going to find.
