An AI Mission for Field Service Dispatch

Field service has spent twenty years perfecting the route and almost no time on the question the route depends on: can the person you are sending actually finish the job when they get there?

The dispatch board at a quarter to seven in the morning is a genuinely impressive artifact. Overnight, an optimizer has taken ninety-odd open work orders, the locations of nineteen technicians, a set of promised arrival windows, traffic history, and a duration estimate for each job, and it has produced routes that look like art — tight loops, minimal backtracking, almost no dead mileage. At 9:12 a technician arrives at a commercial rooftop unit that has been reported as "not cooling." He is on time, in the right order, having driven eleven fewer miles than he would have under last year's manual board. He spends nineteen minutes on the roof, finds a failed condenser fan motor with a control board that has been cooked along with it, and discovers that his van carries the motor but not that board. The site stays hot. He writes it up, calls it in, and drives to his next stop, where the same optimizer has him arriving three minutes early.

Nothing in the system will record that morning as a failure. The route was efficient, the arrival was punctual, the visit was completed, the utilization number will look fine at the end of the week. What actually happened is that a truck, a technician, a parking spot, an hour of a customer's facilities manager, and a slot that could have gone to someone else were all consumed to produce a diagnosis that a well-informed system could have reached before anyone was assigned. The visit was perfectly routed and structurally incapable of resolving the fault. That is the shape of the problem in field service, and it is invisible precisely because the metrics that surround dispatch are all measuring the wrong half of it.

The variable the optimizer cannot see

Every dispatch optimizer in wide use is, underneath, a solver for a variant of the travelling salesman problem with time windows and resource constraints. It takes the set of jobs as given and finds the cheapest way to visit them. The inputs it consumes are the inputs that geometry needs — coordinates, durations, windows, a coarse skill tag on each technician, sometimes a crude flag for whether a van is stocked for a job "type." What it does not take as an input, because nobody has been able to give it one, is the content of the job: what is really broken, which parts the repair will consume, which certification or manufacturer authorization the work legally requires, whether the site needs a lift or a permit, whether a warranty dictates a different procedure entirely. The optimizer is minimizing travel across a set of assignments whose feasibility it has never checked, and it cannot check it, because the feasibility question lives in a body of context the solver was never designed to read.

The result is a quiet and very expensive asymmetry. Saving eighteen minutes of drive time is worth something real; sending a technician who cannot complete the repair costs the drive time twice, the diagnostic labor twice, a scheduling slot that could have absorbed another customer, the days the asset stays down, and the part of the customer relationship that erodes every time someone explains that the person who came out will have to come back. One of those numbers is on the dashboard and the other is smeared across three systems where nobody sums it. So the organization optimizes the one it can see, gets better at it every year, and cannot work out why cost per resolved fault refuses to improve in step.

Underneath the routing problem sits an inventory problem that routing has no vocabulary for. Van stock is typically set by a replenishment rule tuned to historical consumption, which is a reasonable way to stock a truck for the average of the past and a poor way to stock it for tomorrow's actual job list — a list that is knowable the night before and is never consulted. Certification has the same defect. A technician's credentials are usually encoded as a handful of skill tags far coarser than the real requirement, which may hinge on a refrigerant class, a manufacturer's authorized-servicer status for one product line, a site safety induction, or a licensing rule that applies to one category of work and not another. When the tag is coarse, dispatch is guessing, and the guess gets resolved on a rooftop at 9:12 in the morning instead of at a desk the night before.

First-visit resolution is the objective the business actually has

Once you see the mismatch, the fix is not a better solver. It is a different objective function. Field service does not produce visits; it produces resolved faults, and every intermediate metric that treats a visit as the unit of output will eventually reward a well-organized failure. A route that is ten percent longer but converts a materially larger share of visits into completed repairs on the first attempt is not a worse route — it is a better business, and it will show up as a better business in almost every downstream number: fewer total truck rolls for the same demand, lower parts expediting, less overtime absorbing the rework, more capacity available without hiring, and assets that spend less of their life waiting for a second appointment.

That last point is where field service quietly connects to the maintenance economics its customers care most about. Deloitte's work on predictive maintenance has found that anticipating failures rather than reacting to them can reduce unplanned downtime by 30 to 50 percent and cut maintenance costs by 10 to 25 percent — gains that come almost entirely from knowing something about the failure before the response begins. Dispatch is the moment where that knowledge either gets used or gets thrown away. If a service organization can predict what is likely to fail and still assigns the visit on the basis of geography and a skill tag, it has done the hard analytical work and then discarded it at the exact step where it would have paid.

It is worth being skeptical here about what most of the market is selling as a remedy, because the scheduling category has a long history of relabeling. Gartner has predicted that more than forty percent of agentic AI projects will be canceled by the end of 2027, naming escalating costs, unclear value, and "agent washing" — older rule engines and optimizers presented as autonomous without any change in what they can actually reason about. A constraint solver with a natural-language front end is still a constraint solver. It will still take the job list as an opaque set of durations, and it will still have nothing to say about whether the third stop on Tuesday's route can be completed with what is on the truck.

Reasoning about the job before anyone is assigned

What closes the gap is a step that does not currently exist in most dispatch operations: something that reads the job before the job is scheduled. The raw material is already there and almost entirely unread — the customer's description of the symptom, the service history on that specific asset and serial number, the fault codes the equipment has been emitting, the manufacturer's bulletins and manuals, the warranty and contract terms, the notes a technician wrote after the last visit to the same site. A system with a reasoning core and access to enterprise knowledge can hold all of that at once, form a ranked hypothesis about what is wrong, derive from it the parts and credentials the repair will most likely require, check those against van and depot stock and against who is actually authorized, and only then hand the routing problem a set of assignments that are feasible by construction. The travelling salesman problem is still solved — it is simply solved second, over a candidate set already filtered for whether the work can be finished.

This changes the character of the decisions dispatch makes, not merely their speed. Sometimes the right answer becomes counterintuitive: hold the job an extra day so the board arrives, rather than burning a slot on a visit that will only confirm what was already inferable; or split one work order into two because it is really two faults wearing a single complaint. These are judgment calls, and the point of a reasoning layer in front of the board is not to make them automatically but to surface them with the evidence attached, so a dispatcher weighing ninety of them before seven in the morning is deciding rather than guessing. Human-in-the-loop is not a hedge here; it is the correct architecture, because the exceptions are where the expensive money is.

It is worth saying plainly what this is not. Nothing in the argument is about watching technicians more closely or grading them on a number. The failed visit at 9:12 was not the technician's error in any meaningful sense — he was sent to a job nobody had thought about, with a truck stocked by an average, under a credential model too coarse to describe the work. Reasoning about the job in advance makes the assignment worthy of the person receiving it: arriving with the likely fault characterized, the right parts on board, and the manual passage already pulled is the difference between being dispatched and being set up to succeed. This is the field-service expression of what the emerging literature on autonomous enterprise operations describes as moving work from coordination to judgment, and it is the thesis behind running dispatch as an AI mission on a platform like StudioX, where specialist agents handle intake interpretation, parts reservation, and credential matching under policies the service organization owns, and the schedule falls out of decisions that have already been checked for whether they can actually be completed.

The mental model worth carrying away is that dispatch has been misfiled. It has been treated as a logistics problem for so long that the entire toolchain is built around distance, when it is far more accurately a supply chain and qualification problem wearing a logistics costume. The route is the last and least interesting step; the binding constraints are what is in the van and what the technician is authorized to touch, and both are downstream of a diagnostic question nobody currently asks until someone is standing on the roof. Ask it the night before and the geometry gets easy. Skip it, and you will keep building beautiful routes through a week of visits that could never have finished, and calling the result efficiency.