Summary. Field routing is two distinct problems wearing one name: sequencing the stops on a single route, and splitting stops across several people. The first is a travelling-salesman problem and is cheap to solve well; the second is a capacitated vehicle-routing problem and is substantially harder, because assignment and sequencing interact. Both depend on a distance model, and road-network distances cost money per query — a constraint that should shape the architecture rather than be worked around.
What problem this solves
A field day divides into time in front of customers and time getting there. Only one earns anything, and travel routinely consumes a third of the working day. Improvements here are not marginal: a 15% reduction in travel is several extra calls a week per person, with no hiring and no longer hours.
In field service the stakes shift from efficiency to obligation, because jobs carry promised time windows — poor sequencing does not just waste fuel, it breaks commitments.
Two problems, not one
The distance model decides accuracy and cost
Straight-line distance is free and immediately wrong in any real city, where rivers, one-way systems and motorways decide the true cost between two points. Two stops 400 metres apart across a railway line can be a fifteen-minute drive.
Road-network distances are accurate and come from a routing service, so each optimization run has a real per-query cost. That single fact should shape the architecture. The naive design — re-optimize everything nightly — produces a bill that scales with routes multiplied by frequency, for benefit that is usually zero on a stable retail territory where the same outlets are visited in the same pattern every week.
The alternative is to make optimization an action someone triggers when a route has genuinely changed, and to offer a free geometric fallback (nearest-neighbour from a coverage midpoint) for cases that do not justify a paid call.
The three-sequence model
Most systems store one sequence and treat deviation from it as non-compliance. That discards the most territory-specific information anyone has.
A route can usefully hold three orderings at once, each versioned with its distance, estimated duration and how many stops it moves:
- Planned — what a human set. Encodes constraints nobody wrote down: the wholesaler who takes orders before 10am, the market that opens at 11.
- Optimized — computed over road distances. Minimises travel and knows nothing about the market's opening time.
- Most followed — derived from the order field staff actually drove on previous visits, route-wide or per person.
The third is the interesting one. Consistent deviation is usually not indiscipline; it is local knowledge arriving through the only channel available to it. Storing it as a fact — this is the order this route is actually driven — turns "why aren't you following the plan?" into "your order is 4km longer, what does it know that we don't?" Only one of those questions produces information.
Territory splitting: what the solver must be told
Assignment quality is determined almost entirely by which constraints the model receives. The ones that matter:
- Service duration per stop — without it the model assumes visits are free and produces a plan that fits only if nobody speaks to anyone.
- Shift start and end — the window the day must fit inside.
- Capacity — the workload a person can carry, and whether it is enforced or advisory.
- Balance tolerance — how much imbalance is acceptable before a plan is rejected. This is a business decision expressed as a number, and it is the most useful single dial.
- Demand weighting — a look-back window so accounts are weighted by what they actually buy, not counted equally.
- Solver time limit — these problems do not have a cheap exact answer; you buy quality with compute and stop when it is good enough.
What optimizers get wrong
An optimizer values only what it is told to value. Given distance alone it will schedule the difficult account at 5pm on Friday, vary a shop's visit time every week, and separate a customer from the rep who has served them for six years — all defensible under the objective, all damaging.
Predictability has genuine commercial worth in a relationship business and appears nowhere in a distance metric. The correct response is architectural rather than algorithmic: treat solver output as a proposal a planner reviews and accepts, and show the comparison (distance, duration, stops moved) rather than declaring a winner.
How xMatix implements it
In xMatix Field Sales, sequences are versioned objects on the visit route — planned, road-network optimized, and most-followed learned from visit history — each stored with total distance, estimated duration and stops resequenced. Making one current is an explicit act that applies to subsequent visit plans, so a route never silently changes under the person driving it. A free nearest-neighbour option exists alongside the paid road-network path, and optimization runs are user-triggered by design.
Territory splitting uses a capacitated solver over road distances, with service minutes, shift windows, truck mode, balance tolerance, capacity enforcement, demand look-back and a solver time limit all exposed as tenant settings rather than hard-coded assumptions. Output lands as visit routes and stops in the same structures that drive generated visit plans, so an accepted re-plan flows into daily execution without a migration step, and individual stops can still be transferred between routes afterwards.
In xMatix Field Service, the same thinking applies to a day's job list through a dispatch console with map, timeline and board views, including an action that fills unassigned work into free slots without disturbing assignments a dispatcher has already made.
Continuous intra-day re-optimization is not part of the current product.