How should dispatch decide which technician goes to which job?
Dispatch is a scoring problem, not a queue. The candidate technician is scored on skill match for that job type, drive distance from their previous stop, remaining hours in their day, and historical performance on similar work. Nearest available is the default in most shops and it is frequently the wrong answer, because a short drive to a mismatched technician creates a return trip.
The four inputs any real assignment weighs
- Capability. Can this technician complete this job type unassisted, including the likely upsell path? A technician who can diagnose but not sell the replacement turns one visit into two.
- Geography. Distance from the prior stop, not distance from the shop. The relevant number is the drive that assignment adds to the day.
- Day shape. Hours remaining, and whether this job is likely to run long. Putting a probable four-hour job into a two-hour hole is how evening cancellations happen.
- Track record. How this technician has historically performed on this job type: completion without a return trip, callback rate, and conversion when options are presented.
Nearest available is a local optimum
Nearest available minimizes the next drive. It does not minimize the day, and it does not consider job value at all. The pathological case is familiar to every dispatcher: the closest technician takes a high-value diagnostic, cannot close it, and the job returns to the board two days later with a colder customer.
The opposite failure is real too. Sending your strongest technician across town for every promising call burns hours in the truck and starves the rest of the board. The correct behavior is a weighted tradeoff, and the weights depend on how tight your day is.
Log the decision, not just the outcome
Almost no company records why a job was assigned the way it was, which makes dispatch impossible to improve. If you capture who else was available and eligible at the moment of assignment, you can compare assignment patterns against outcomes and see whether your board's habits are costing you.
That record is straightforward to build once dispatch data is flowing through an integration layer. It is also the prerequisite for any assistive scoring, because a recommendation with no history behind it is just a different opinion.
Where software helps and where it does not
Software is good at the parts humans do poorly under pressure: holding every constraint at once, remembering performance by job type, and estimating drive time honestly instead of optimistically. It is bad at the parts a good dispatcher does naturally, like knowing that a specific customer needs a specific technician, or that someone is having a hard week.
The workable pattern is a ranked recommendation with the reasoning visible, and a dispatcher who can override it. That is how we approach dispatch support in home services AI work: assist the decision, keep the human accountable for it.
Topics: dispatch · routing · scheduling · technicians
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.