How Route Optimisation Actually Works
Sending the nearest technician to each new call feels efficient and produces a worse day than planning the whole sequence in advance. Understanding why explains most of what route optimisation is for.
A routing engine minimises total drive time subject to constraints — promised windows, shift bounds, skills, priority. The objective is simple; the constraints are what make it hard.
And the thing nobody warns you about: continuous re-optimisation has a cost of its own. A technician whose afternoon changes four times stops trusting the schedule, which is a worse outcome than a few extra miles.
What the engine is solving
Route optimisation has three components, and every platform’s version is some arrangement of them.
The objective — usually total drive time across the team, sometimes total mileage, occasionally a blend that also weights overtime or customer priority.
The constraints — conditions that must hold. Promised arrival windows. Shift start and end times. Skill and certification requirements. Break entitlements. Vehicle or equipment limitations.
The variables — who goes where, and in what order.
The reason this is genuinely difficult is combinatorial. Five stops for one technician has 120 possible orderings. Twenty stops across four technicians is a number no human evaluates, which is why the engine exists.
Why nearest-technician assignment fails
Assigning each new call to whoever is closest right now is called a greedy approach: it takes the best available option at each step without considering what that does to later steps.
The practical version of this: a dispatcher assigning calls as they arrive, always to whoever is nearest, is running a greedy algorithm by hand. Each individual decision defends itself, and the day still ends with unnecessary miles.
The fix is not a better instinct. It is sequencing the known work before the day starts, then handling only genuine emergencies reactively.
The constraints that actually bind
| Constraint | Effect on the solution |
|---|---|
| Promised arrival windows | The most restrictive by far. Each one removes options from the whole sequence. See arrival windows |
| Skill and certification | A hard filter. Reduces who can take a job before geography is considered |
| Shift bounds | Caps total work. Overtime is either forbidden or penalised in the objective |
| Job duration | Wrong durations produce a route that is optimal for a day that does not exist |
| Priority | Agreement holders and emergencies override geographic sense |
| Truck stock | Rarely modelled well. Usually handled by the dispatcher instead |
The fourth row is the one worth dwelling on. Routing quality is capped by duration accuracy. An engine given a 45-minute estimate for a 70-minute job produces a beautifully sequenced schedule that collapses by mid-morning. This is why the durations covered in why job duration estimates break your schedule matter more than the optimiser itself.
Static and dynamic optimisation
Static means the route is built once, before the day starts, from the known work. Simple, predictable, and adequate for shops whose work is mostly booked in advance — maintenance-heavy operations in shoulder seasons, for instance.
Dynamic means the engine re-optimises as the day changes: a job overruns, an emergency lands, a technician’s van breaks down. Remaining stops get re-sequenced automatically and affected customers get updated times.
Dynamic is clearly more capable. It also introduces a cost that vendors do not discuss.
If the engine re-sequences every time anything changes, a technician’s afternoon looks different every time they check their phone. Their next three stops at 10am are not their next three stops at 11am.
The effect is that technicians stop reading ahead. They cannot mentally prepare for the next job, cannot plan a parts run, cannot judge whether to take lunch now. Some quietly revert to phoning the office — which is the exact behaviour the system was bought to eliminate.
What to look for: a platform that locks the next one or two stops and only re-optimises beyond them. Ask about this specifically; it is the difference between a system technicians trust and one they work around.
Zones as an alternative
Not every shop needs a solver. Territory assignment achieves much of the benefit with none of the complexity.
Divide your service area into zones and assign technicians to zones rather than optimising across the whole territory. Drive times fall because nobody crosses the map. Technicians develop local knowledge — traffic patterns, building access, the housing stock. And customers see the same face, which matters more than efficiency for retention.
The trade-off is flexibility. A busy zone and a quiet zone on the same day means one technician is overloaded while another has capacity, and rigid zones prevent the obvious fix.
The practical middle ground that most shops land on: zones as the default, with the dispatcher free to cross boundaries for emergencies and to balance a lopsided day. It captures most of the drive-time benefit while keeping the escape hatch.
Where the drive times come from
An optimiser needs to know how long it takes to get between any two addresses. Three sources, in ascending order of usefulness:
Straight-line distance with an assumed speed. Fast to compute, wrong in any territory with rivers, motorways or one-way systems. Rare in modern platforms.
Road-network estimates. Actual routing over real roads. The standard, and adequate.
Road-network estimates with live or historical traffic. Meaningfully better in urban territories, where a route that takes 15 minutes at 10am takes 35 at 4:30pm.
If you work a city, ask specifically whether traffic conditions are factored in and whether the model varies by time of day. If you work rural routes, it matters much less — the roads are the roads.
What optimisation cannot fix
Worth being clear about, because it is often sold as a solution to problems it does not touch.
Too much work for the headcount. An optimiser makes an overloaded day slightly less bad. It does not create capacity. That is what capacity planning is for.
A territory that is too large. If your service area cannot be covered profitably, better sequencing does not change the arithmetic. Shrinking the territory or adding a base does.
Wrong durations. Stated three times in this article because it is the single most common reason optimisation disappoints.
Too many promised windows. Six hard constraints in a technician’s day leave the engine almost nothing to optimise.
Technicians not updating status. Dynamic re-optimisation runs on real-time position and job state. Without accurate status, it optimises against a fiction.
Frequently asked questions
Is it better to assign the nearest technician to each call?
How much drive time can route optimisation actually save?
Should the system re-optimise routes all day?
Are zones better than dynamic routing?
Does route optimisation account for traffic?
Why did optimisation not reduce our drive time?
What to do next
- Fix your durations before evaluating any optimiser. Routing quality is capped by duration accuracy and nothing else changes that.
- Count promised windows per technician per day. Above four or five, the engine has little room to work.
- Ask any vendor whether the next stops are locked during re-optimisation. Route churn is the failure mode nobody demos.
- Try zones first if you are under eight technicians. It is free and it captures a surprising share of the benefit.
- Why job duration estimates break your schedule — the ceiling on routing quality
- Arrival windows — the constraint that binds hardest
- How a dispatch board works — seeing the result of re-optimisation
The routes illustrated here are schematic examples used to explain a principle, not measurements. Optimisation capability, traffic modelling and re-sequencing behaviour vary considerably between platforms — confirm how any specific system works by asking for a live demonstration.