Field Service & Dispatch Agents

8 min read

Y24
Playbook · Domain Playbooks

Field service & dispatch agents.

The scheduling problem you are tempted to hand the model is the one part of field service that was already solved — a constraint solver beats an LLM at assigning technicians and always will. The agent's money is at the two edges the solver cannot read: deciding what is actually broken so the right parts go on the truck, and renegotiating the promise when the day falls apart. Build for those, and treat every write to the dispatch board as an outward-facing commitment rather than a tool call.

STEP 1

Do not let the model schedule.

Routing and assignment is a vehicle-routing problem with time windows, and the field has spent forty years on it. Solvers handle skills matching, travel time, shift boundaries and overtime rules simultaneously and give you an optimum you can explain. A model asked the same question produces a plausible-looking board that violates a certification requirement in row nine.

  • The solver owns assignment; the agent owns the inputs and the exceptions. That division is not a compromise — the solver's answers are only as good as the job duration, skill code and parts list it was handed, and those come from unstructured human text.
  • Constraint violations are silent in a model and loud in a solver. A solver either returns infeasible or names the binding constraint. That explanation is what a dispatcher needs to override it, and you lose it the moment the model does the assigning.
  • Where the model does help the solver: estimating job duration from the description and history, inferring the skill code, deciding whether a job is genuinely urgent or has a customer who says everything is urgent. Each is a bounded prediction feeding a solver input, and each is separately testable.
  • Which sets the architecture: agent → structured job record → solver → board, with the agent never writing an assignment directly. The read-only-first discipline in DevOps & SRE agents is the same argument on a different blast radius.
STEP 2

Intake decides the day, because the truck is packed before anyone drives.

The dominant cost in field service is the second visit. A technician who arrives without the right part has burned a slot, a drive, and the customer's morning, and the cause is almost always upstream: a description like "the heater is making a noise" turned into a work order nobody could stock against.

  • Model intake as a diagnosis narrowing, not a form fill. The output that matters is the smallest set of likely faults plus the parts each implies — including the honest "cannot narrow this remotely", which correctly triggers a diagnostic visit instead of a doomed repair visit.
  • Photos and model plates are the highest-value input you can ask for. A serial number read off a photo resolves the exact unit, its revision, and its compatible parts, and it converts a guess into a lookup against your own catalogue.
  • Mine the history that already exists. Prior visits to this address, this asset's fault record, and what the last three technicians who saw this symptom actually replaced — retrieval over your own service records outperforms any general knowledge the model has about the equipment.
  • Score abstention above confident error. A wrong parts list is worse than no parts list, because it manufactures false confidence in the scheduler and in the technician. This is the same evaluation stance as data & analytics agents take toward a confidently wrong number.

If you build one thing here, build intake. First-time-fix rate is the number the whole business is organised around, it moves on parts availability, and parts availability is decided by a paragraph of customer text that nobody currently reads carefully.

STEP 3

An appointment window is a promise. Two-phase every write.

The agent's tool call books a slot; the customer receives "Thursday between 8 and 12" and rearranges their life around it. That makes a board write an irreversible outward-facing action with a person on the other end, and the usual retry semantics are actively dangerous against it.

  • Reserve, then confirm. A hold with a short expiry, then an explicit confirmation once the customer has agreed and the parts are verified as available. A single write that both allocates the slot and notifies the customer has no safe failure mode.
  • Idempotency keys on every booking call. A timeout on the reservation must never be retried into two slots for one job — the standard treatment in idempotency & retries, and field service is where it bites hardest because the duplicate is visible to a customer.
  • Cancellation is not undo. Freeing the slot restores the board and does nothing about the message already sent. Design the compensating action as a real apology-and-rebook flow, not as a rollback — the distinction undo & reversibility insists on.
  • Put the limits in the tool signature. The booking tool should not accept a slot outside the technician's shift, beyond the SLA window, or against a job whose parts are unconfirmed. A constraint expressed in the schema is enforced; one expressed in the prompt is a suggestion, per tool design principles.
STEP 4

The board is shared with humans, and last-write-wins loses.

Nearly every field-service pilot is designed as though the agent were the only writer. It is not. A dispatcher is dragging jobs around the same board in real time, a technician is marking a job complete from a van, and a customer is rescheduling through a portal — all against the state the agent read forty seconds ago.

  • Optimistic concurrency, not fire-and-forget. Every write carries the version the agent read; a conflict returns the current state and the agent re-decides. Silently overwriting a dispatcher's manual move is how an agent loses the dispatch team permanently, and you only get one of those.
  • The dispatcher's overrides are labelled training data. Every manual move away from the agent's proposal is a constraint that exists in a human's head and not in your system — a technician who cannot be sent to that site, a customer who requires a two-person crew, a truck missing a ladder rack. Log the override with a reason and you are mining the constraint set you failed to model.
  • Give humans priority by construction. A dispatcher's move should never be reverted by an agent's optimisation pass, even a better one. Pin manually-moved jobs and let the solver work around them.
  • Beware the globally-optimal reshuffle. A rebalance that improves total drive time by 6% while changing eleven technicians' afternoons is a net loss: it destroys the mental model each of them built at 7am. Bound how much of the board a single agent action may move, per the multi-writer discipline in supply chain & logistics agents.
STEP 5

The reschedule conversation is the task with the clearest return.

By 10am the plan is wrong: a job overran, a van broke down, a customer isn't home. Someone must now call eight people, in the right order, and renegotiate. This is high-volume, low-judgement, time-critical work that humans do badly under pressure — and unlike the scheduling itself, it is genuinely a language task.

  • Order the calls by consequence, not by list position. The customer who took a day off work and the SLA-bound commercial site are not the same call, and getting the order right is most of the value.
  • Offer real slots only. The agent must hold the alternative before offering it, or it will cheerfully promise a window that the solver has already given away — the reservation discipline from step 3, now under time pressure.
  • Outbound contact is a regulated act. Calling and texting customers carries consent, disclosure and quiet-hours obligations, and an agent that dials carries them too — see outbound voice agents for the surface, and disclosure & content provenance for saying who is calling.
  • Escalate on affect, not just on intent. An angry customer on the third failed appointment is a retention event, not a scheduling one. The handoff rule should fire on repeat failure and on detected frustration, and it should hand over context rather than a transcript — the pattern in interruption & handoff.
STEP 6

Measure first-time fix and promise integrity, never automation rate.

Automation rate is the metric that gets these programmes cancelled. It rises when the agent books more jobs, and it rises fastest when it books them badly, because a wrong booking is still a booking.

  • First-time-fix rate is the business metric and the honest one. It captures intake quality, parts prediction, and duration estimation in a single number that finance already trusts.
  • Promise integrity — appointments kept within the stated window — is the customer's experience of your agent, and it is the number that degrades first when the solver is being fed optimistic durations.
  • Second-visit rate and truck rolls per resolved job localise the failure. A rising second-visit rate with flat intake volume means the parts prediction is over-confident and should be tuned toward abstention.
  • Dispatcher override rate, trended. Falling means the agent is learning the unmodelled constraints; flat and high means it is proposing work the humans reject and you are paying tokens for rework.
  • Cost per resolved job, not per interaction. The unit economics here are unforgiving: one avoidable truck roll costs more than a month of inference for the whole intake pipeline, which is also why the intake work outranks everything else on this list.

Do this first: pull last quarter's second visits and classify each by root cause — wrong part, wrong skill, wrong duration, customer not home. If wrong-part dominates, your project is an intake and parts-prediction agent and nothing else in this playbook matters yet. If wrong-duration dominates, you have a solver-input problem and the fix is a duration model, not an agent. Field service teams that skip this classification consistently build the scheduling assistant nobody needed.

Related: customer support agents for the intake channel, travel & booking agents for the same reserve-then-confirm problem against third-party inventory, and IT helpdesk agents for the indoor version of the dispatch loop.