A service call that sits unassigned for 40 minutes is a truck that isn't moving. Our client, a regional HVAC and plumbing contractor running 120 technicians across six branches, was losing hours a day to that gap. Nine dispatchers worked a whiteboard and a scheduling screen, matching roughly 1,600 service calls a week to the right tech, the right skill, and the right part. Average time from call intake to a dispatched technician was 43 minutes. Emergency SLAs were missed a quarter of the time. They didn't need more dispatchers. They needed dispatch to stop being a bottleneck built out of human memory.

The Problem

Field service dispatch looks simple from the outside. A job comes in, somebody sends a technician. In practice each assignment is a small optimization problem with too many variables to solve well under pressure.

A dispatcher had to know which techs were certified on which equipment, who was already running behind, who was closest, who had the right part on the truck, which customers had service agreements that guaranteed a response window, and which techs a specific commercial account had asked for by name. Most of that lived in the heads of the two or three dispatchers who had been there longest.

The numbers were rough:

• Average time from intake to dispatch: 43 minutes
• Weekly service call volume: ~1,600
• First-time fix rate: 68%
• Completed jobs per tech per day: 4.1
• Emergency SLA compliance: 74%

The first-time fix number was the expensive one. Nearly a third of calls needed a second visit, usually because the tech who showed up lacked the certification, the diagnostic tool, or the part. Every repeat visit burns a truck roll, a technician hour, and a customer's patience.

Our Approach

We proposed a decision layer that sits on top of the existing field service management platform. It reads every open job and every technician's live status, scores the possible matches, and assigns the best one. Humans stay in the loop for anything the system isn't sure about.

Three phases across eight weeks.

Phase 1: Getting the Knowledge Out of People's Heads (Weeks 1-3)

Before we could automate assignment we had to make the dispatchers' implicit knowledge explicit. We pulled 26 months of job history, about 170,000 completed calls, each with the technician assigned, the equipment involved, the parts used, the duration, and whether it closed on the first visit.

The pattern that shaped the build: technician-to-job fit predicted first-time fix better than proximity did. Sending the closest tech was often the wrong call. Sending the right tech 20 minutes further out closed the job in one visit far more often. The dispatchers knew this intuitively for the techs they knew well, and guessed for everyone else.

We also ran structured interviews with the three senior dispatchers to capture the rules that never made it into any system, things like which commercial accounts refuse certain techs and which equipment brands require a specialist even when the symptom looks routine.

Phase 2: The Scheduling Engine (Weeks 4-6)

The engine scores every available technician against every open job on six weighted factors: skill and certification match, historical first-time fix rate on that equipment type, current location and projected travel time, remaining capacity in the shift, parts inventory on the truck, and customer or account constraints.

An LLM layer handles intake. Service requests arrive by phone, web form, email, and text, and the descriptions are messy. "AC making a grinding noise upstairs, house is 84 degrees" needs to become a structured job with an equipment type, a likely fault category, a required skill level, and an urgency rating. The model does that classification, and it flags anything ambiguous for a dispatcher rather than guessing.

The design choice that mattered most was continuous reoptimization. The schedule is not built once each morning and defended all day. It rebuilds whenever a job finishes early, a call runs long, an emergency drops in, or a customer cancels. Affected technicians get updated routes pushed to their phones with a short reason attached, because a route change with no explanation is a route change technicians ignore.

Phase 3: Rollout and Trust (Weeks 7-8)

We ran the system in shadow mode for ten days. It made assignments, dispatchers saw them as recommendations, and nobody was forced to follow anything. We tracked how often dispatchers agreed.

Agreement started at 71% and climbed to 89% as we corrected the cases they pushed back on. Most of the early disagreements traced to constraints we hadn't captured, like a technician on light duty after an injury. That shadow period was not a delay. It was how the system earned the right to make decisions unsupervised.

We went live one branch at a time over two weeks.

The Results

Ninety days after full rollout:

• Time from intake to dispatch: 43 minutes to 12 minutes, a 72% reduction
• First-time fix rate: 68% to 81%
• Completed jobs per tech per day: 4.1 to 4.8
• Emergency SLA compliance: 74% to 94%
• Overtime hours: down 23%
• Total drive time: down 19%

The jobs-per-tech number is the one that funded the project. An extra 0.7 completed calls per technician per day across 120 techs is roughly 420 additional billable jobs a week, with no new hires and no new trucks.

Dispatchers didn't lose their jobs. They stopped playing traffic cop and started handling the calls that need a person: the furious customer, the commercial account with a shutdown risk, the job nobody has seen before. Two moved into a proactive customer communication role, calling ahead when a tech was running late. Complaints about "nobody told me" dropped noticeably.

What We Learned

Proximity is a weak signal. The most common dispatch heuristic in the industry, send the closest available tech, actively hurt first-time fix rate. Skill fit beat travel time in almost every scenario we modeled.

Shadow mode is not optional. Dispatchers who watched the system agree with them 89% of the time trusted it. Dispatchers handed a finished system and told to use it would have fought it for months. The ten days we spent proving the model saved far more than they cost.

Explain the reassignment. The first version pushed route changes with no context and technicians called dispatch to ask why, which recreated the bottleneck. Adding a one-line reason to every change removed almost all of those calls.

Capture the exceptions before you go live. Most of our early errors were not model failures. They were rules nobody had written down. Budget real time for interviewing the people who currently hold the system in their heads.

Is This Right for Your Operation?

AI dispatch pays off when you have enough technicians that assignment is genuinely hard, enough job history to learn from, and a first-time fix rate with room to move. Below roughly 40 technicians, a good dispatcher with a good tool usually beats a model.

If dispatch decisions are the reason your trucks sit idle, the fix is rarely more dispatchers. It's better decisions, made faster, with the knowledge pulled out of people's heads and into a system that never forgets which tech is certified on which equipment.

Want to know if your operation is a fit? Book a call and we'll walk through your job data and tell you honestly whether the numbers work.