The optimiser made a plan and the desk rebuilt it by hand before eight

If the desk rebuilds part of the plan every single morning, the plan is missing constraints the desk is holding. That is the first thing to assume, ahead of change resistance, ahead of trust, ahead of the interface. A dispatcher who moves the same 12 stops every day is not rejecting optimisation. They are patching it, by hand, at speed, against a specification nobody has ever written down.

The distinction that matters is recurrence. A plan that gets edited differently every day is being edited by judgement — traffic news, a phone call, a driver ringing in sick — and that is a healthy desk doing its job. A plan where the same edit reappears on 3 consecutive days is a plan with a hole in its model. Everything else in routing, dispatch and optimisation depends on knowing which of the two you have, and you cannot tell by watching.

Two weeks of edits, each with a reason attached

The instrumentation is small and the discipline is the hard part. You are building a dataset whose unit of observation is one manual change, and whose purpose is to survive an argument with an operations manager who believes the desk is simply set in its ways.

1. Freeze the published plan. Before the desk touches anything, snapshot the plan version, the vehicle assignment for every stop, and the sequence position. Without this baseline you are comparing the final plan against nothing.
2. Capture each change as a diff, not as a final state. One record per edit: edit type, the stop or vehicle affected, the planner, the timestamp, and the before-and-after values.
3. Offer 6 to 8 reason codes and no more. Something like access restriction, customer relationship, wrong time window, vehicle will not fit, service time too short, load will not fit, promise at risk, other. A longer list gets one code used for everything, and the free-text box beside it is where the real information lands.
4. Run it for 10 working days at minimum. Fewer and you cannot tell a Tuesday from a pattern; 10 days also picks up the weekly rhythm of a delivery schedule, which is where most territory edits live.
5. Cluster by edit type and stop, never by planner. Two different dispatchers making the same edit independently is the strongest evidence this exercise can produce, and grouping by person hides it.
6. Rank each cluster by frequency multiplied by the plan minutes it added or removed. A frequent edit that costs nothing is a preference. An occasional edit that adds 40 minutes to a round is a constraint worth modelling.

The five edits that keep coming back

Across delivery, collection and service work the recurring clusters are remarkably consistent, and 4 of the 5 are data faults rather than modelling faults. The 5th is a different animal.

A dispatcher's hands are the requirements document. Nobody has read it, because nobody ever wrote it down.

When the last row is what you are looking at

The first 4 rows are fixable by putting a fact into a field. The 5th is not, and it is the one most often misdiagnosed as stubbornness. If the solver is minimising total distance or total driving hours while the desk's own performance is measured on windows kept and customer complaints avoided, the two are optimising different things and the desk will win, because the desk is the one being appraised. No amount of training closes that gap. The weights in the objective function are a policy statement, and somebody chose them — usually whoever configured the software, usually without being told they were making a commercial decision. That argument has its own page in what optimal meant and who chose it.

The tell is that these edits do not target specific stops. They redraw boundaries and rebalance whole rounds, and the dispatcher struggles to give a reason code for them because the reason is a value judgement rather than a fact about a customer.

Testing a claimed constraint before you encode it

Not everything the desk says is a constraint is one. Habits accumulate, and a rule that made sense when one depot served forty customers survives long after the reason has gone. 3 questions separate the 2, and all three are answerable from data you already hold.

• What happens if we break it? If the answer is a failed delivery, a locked gate or a penalty clause, it is hard. If the answer is that someone will be annoyed, it is a cost, and it belongs in the objective as a penalty rather than in the model as a wall.
• Has anyone else ever served this stop successfully? Query the delivery history. A customer who has been served by 9 different drivers over 12 months does not need a driver lock, whatever the desk believes.
• Does it apply to the stop or to the day? A constraint tied to a stop is stable and worth encoding. A constraint that only bites on the day a particular product is loaded is conditional, and encoding it unconditionally will produce plans the desk edits in the opposite direction — which is how a fix creates a new recurring edit.

Deciding what to model and what to leave in a human's hands

Every confirmed constraint ends at one of two places, and the second is a legitimate destination rather than a failure. Model it when it is stable, affects a meaningful share of stops, and can be expressed in the engine you have. Leave it human when it changes week to week, touches under roughly 2 per cent of stops, or cannot be represented without contorting the model.

Leaving it human is not the same as leaving it as an override. The mechanism that makes it work is a pre-assignment: the desk pins the stop to a vehicle before the solve, and the solver treats the pin as an input it may not break. The edit stops being a correction after the fact and becomes a constraint the plan was built around, which means the plan's own reported travel time is finally telling the truth. Capacity dimensions are the common case where an engine genuinely cannot express what the desk knows — a load that is simultaneously heavy, bulky and in cages is the subject of modelling weight, volume, pallets and cages together.

Four reasons the desk will keep rebuilding anyway

• The plan arrives after the desk needs it. If the solve finishes at 06:40 and the first of 24 vans loads at 06:30, the desk rebuilds from yesterday's plan regardless of quality — the deadline problem set out in the solve still has not finished and the first van is loaded.
• The plan comes back with stops missing. Nothing destroys confidence faster than a plan the desk has to complete, and the causes are diagnosable one constraint family at a time in the plan came back complete and forty stops are not in it.
• The vehicle list does not match the yard. If the optimiser plans around a van that is off the road, or starts a route from a depot the vehicle left last night, every plan needs correcting before it can be read. Which telematics path feeds that state is a real decision — see device ingest versus a provider API.
• The desk has no way to see why a stop sits where it does. An unexplained sequence gets relitigated every morning by whoever opens it first, and the fix is an explanation surface rather than a better plan.

Once the recurring edits are down to a handful, the logging itself becomes the thing worth keeping. A standing job that clusters last month's overrides and flags any new pattern turns a one-off exercise into a permanent feedback loop between the desk and the model, which is ordinary operations automation rather than anything exotic. Whoever builds it should be able to explain the model's constraint set to the desk in plain language — a fair test to apply when choosing an AI development partner, and the difference between a working plan and shelfware in most logistics and mobility projects.

• route optimisation
• dispatch
• constraints
• adoption