How to Build a Dispatch Optimization Agent for Field Teams

Dispatch looks like a routing problem and is not. The constraints that decide whether a day goes well are skills, parts, access, and commitments, and a system that optimises travel while ignoring them produces elegant schedules that fail on contact with reality. An agent that models the real constraints and keeps dispatchers in control performs considerably better. This guide covers building one, drawing on FISTA Solutions' AI agents work in field operations. It complements the AI for field operations whitepaper and ai field service management. This article is general guidance, not legal advice.

What actually constrains a dispatch decision?

Not distance. A technician needs the certification for the equipment, the part in the van, access to the site during its available window, and enough time before the next committed appointment. Travel is a cost to minimise subject to all of that, not the objective.

Getting this ordering wrong is the most common failure. An optimiser that saves eleven minutes of driving and causes a revisit has lost several hours and a customer's confidence.

Constraint	Typical status	Impact if ignored
Certification for equipment	Often stale in HR data	Job cannot be done
Parts on van or at depot	Frequently unmodelled	Revisit required
Site access window	Known informally	Wasted travel
Appointment commitment	In system	Customer trust
Technician capability	Assumed from title	Poor first-time fix
Travel time	Well modelled	Cost, not outcome

How should skill matching work?

From evidence, not from titles. HR skills matrices are maintained as a compliance artefact and describe what someone was trained on, sometimes years ago. Completed job history describes what they actually fix successfully and how long it takes them.

Building a capability model from job outcomes — by equipment type, fault category, and site type — and having supervisors validate it produces a matching input that reflects reality. It also surfaces genuine training gaps, which is a second benefit with a clear owner.

Why do parts decide so much?

Because the job stops without the part. A schedule that assumes availability and discovers absence on site has produced a wasted visit, an unhappy customer, and a second dispatch. Van stock levels, depot availability, and replenishment lead times belong in the assignment logic.

The harder version is predicting the part before the visit, from the fault description and equipment history. Where that prediction is reliable enough, first-time fix improves substantially; where it is not, the honest design flags uncertainty and schedules a diagnostic visit rather than promising a repair.

Where does the value concentrate?

In same-day disruption. Overnight optimisation of tomorrow's schedule is useful and largely a solved problem. What breaks the day is the job that overruns by two hours, the technician who calls in sick, and the emergency that must be fitted in — and the dispatcher handling those under time pressure makes decisions with incomplete information.

An agent that re-optimises the remaining day in seconds, weighted by the cost of disturbing commitments the customer already knows about, is the feature dispatchers value most.

Why must dispatcher override be easy?

Because dispatchers hold context the model does not. This customer will only accept this technician. This site requires an escort arranged in advance. This job is more delicate than the record suggests. This technician is new and should not go alone.

Override must be one action, not a fight with the system. And overrides must be logged and analysed, because a pattern of overrides identifies a constraint the model is missing — which is the most efficient route to improving it. See human in the loop ai explained.

How should commitments be weighted?

Explicitly and asymmetrically. Moving an appointment the customer has been told about carries a real cost that pure optimisation treats as zero. So does moving one twice. The objective function should penalise commitment changes at a rate agreed with the service leadership, rather than leaving it implicit.

Contractual response times deserve harder treatment still: a service level breach is a financial event, and it should behave like a near-hard constraint rather than a weighted preference.

What should be measured?

First-time fix rate, commitments met, jobs completed per technician day, and revisit rate. Miles saved is a cost metric that looks good while the expensive outcomes worsen, and it is the one optimisation vendors lead with.

A useful diagnostic is comparing accepted proposals against overridden ones on the same metrics. If overrides outperform, the model is missing something specific and the override log says what.

How does it integrate?

With the field service management system as the system of record for jobs, technicians, and stock. The agent proposes assignments into it, and technicians continue using their existing mobile application. A separate dispatch tool that runs alongside the FSM creates a reconciliation problem nobody wants.

What does the build sequence look like?

Three weeks on the constraint model, including the capability model from job history and the parts position, which is where the knowledge extraction happens. Two weeks on assignment proposals with visible reasoning. Two weeks on same-day re-optimisation. One week on override capture and analysis. Then measurement against a first-time-fix baseline.

What goes wrong?

Optimising travel. Trusting the HR skills matrix. Ignoring parts. Treating commitment changes as free. Making override hard, which makes dispatchers work around the system. And reporting miles saved while revisits rise.

How do subcontractors change the picture?

Where work is delivered partly by third parties, the constraint set widens: subcontractor capacity, rate differences, coverage areas, and the quality record of each firm. Assignment becomes a make-or-buy decision per job, and the naive version sends the cheapest available resource regardless of outcome history.

Holding subcontractor performance data at the same granularity as internal technician data is what makes that decision defensible. It also gives commercial teams evidence for renegotiation, which is usually the first time anyone has measured subcontract quality systematically rather than by complaint volume.

What does it cost to run?

The optimisation itself is inexpensive; constraint solving at field-service scale runs in seconds on ordinary infrastructure. The cost is in data: building and maintaining the capability model, keeping parts positions accurate, and capturing site access facts that currently live in dispatcher notes. Treating that as the real project budget produces better estimates than pricing the solver.

How FISTA Solutions helps

FISTA Solutions builds dispatch systems with evidence-based capability models, parts-aware assignment, explicit commitment weighting, fast same-day re-optimisation, easy override with override analytics, and measurement against first-time fix, through AI agents, AI enablement, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 47% efficiency gains.

To improve first-time fix rather than mileage, message FISTA on WhatsApp, or read the AI for field operations whitepaper.