Route planning that survives contact with Tuesday

At 07:00 the plan is beautiful. Fourteen runs, every vehicle used, the long lane leaving first and the city work stacked behind it. By 09:30 a driver has called in sick, a consignee’s dock is closed until after lunch, and a customer who books three pallets a week wants eleven collected today.

The plan is not the product. The replan is. Most planning tools are sold on the first plan — the optimiser, the map, the tidy colour blocks — and evaluated on it too, in a demo where nothing goes wrong. What decides whether the tool is worth having is the cost of the second plan, and the third, on an ordinary Tuesday afternoon with the phone going.

What makes the second plan expensive

Watch a dispatcher replan and you can count the cost in what they have to do by hand. A booking moves from run 12 to run 9. Does the tool move it, or do you delete it from one and re-key it into the other? Do the stop sequence, the distance and the arrival times recompute, or does run 9 keep yesterday’s numbers with an extra stop bolted on the end? Does the driver’s app show the change without anyone ringing them? Does the paperwork follow — the consignment note now belongs to another vehicle and possibly another driver.

Each of those, done by hand, is a minute and a chance to be wrong. Ten changes before lunch is an hour of re-keying and a handful of small errors that surface at 16:00 as a delivery nobody made.

So the first thing to test is not the optimiser. It is this: take a planned booking, move it to another run, and count what you had to touch afterwards.

Availability is a question with more than one answer

The other thing that makes a replan slow is not knowing what you have. Which vehicles are free at 11:00 sounds like one question and is at least four:

• Not already on a run. The obvious one, and the only one some tools answer — including the return leg, not just the outbound.
• Not grounded. A vehicle that failed its check this morning is not a vehicle, whatever the board says. If inspection results and the planning board are separate systems, the board will cheerfully offer you a truck the workshop has already taken off the road.
• Not in the workshop, and not due in. A service booked for 13:00 makes a vehicle available for a morning job and not an afternoon one.
• Road legal for the whole job. Roadworthiness and tachograph calibration dates that expire mid-run; ADR certification, a tail lift, a reefer that this load needs.

Then the driver: hours remaining, licences, and whether they are on shift at all.

A tool that answers only the first question is not wrong so much as incomplete, and the incompleteness always lands the same way — as a plan that looks fine and cannot be executed. The useful behaviour is refusal at the point of planning, with the reason attached: out of service since 06:40, failed brake check. A warning you can click past is one you will click past at 15:00 on a bad day.

One trade-off worth naming out loud: refusals have to be narrow. A system that blocks dispatch for everything it is unsure about becomes a system planners route around — they plan in the spreadsheet and enter it afterwards, which is worse than having no system. A defensible line is that statutory items making the vehicle illegal to drive, and safety groundings, refuse; insurance renewal in nine days, an unresolved minor defect, a date expiring next month — warn, and let the planner decide. Where a tool draws that line is a fair question in procurement, and a bad thing to discover in week three.

Telling people, without the phone chain

The replan is not finished when the screen is right. Three parties have to learn about it, and by default they learn by telephone: the driver who has gained a stop, the driver who has lost one, and the customer whose 14:00 just became 16:30.

That chain is where the afternoon actually goes. What replaces it is unglamorous:

• The driver sees today’s stops as they now are, with the change arriving as a push rather than a call — and with the new address and contact on the stop, not just a company name.
• The customer sees the change themselves. A portal or a tracking link answers the question at the moment the customer has it, which is rarely a moment you are free to take a call.
• The office — whoever owns that account — knows the promise moved before the customer rings to ask.

The honest caveat is that automatic notification only helps if it is selective. A system that pushes an update every time a plan is touched trains everybody to ignore it, and then the one message that mattered is ignored too. Fewer and meaningful: the stop moved to another day, the window changed materially, the delivery failed. We wrote separately about honest ETAs and the status calls a customer portal removes.

Truck-aware routing gets one paragraph

Yes, the route has to know it is a truck: gross and axle weights, height and length, bridges, tunnels with dangerous-goods restrictions, urban access rules, and the country-by-country variation in maximum weights and dimensions across the EU. It matters — a car route will send a four-metre trailer under a bridge that does not admit one. But it is a solved and buyable capability, configured once and changing rarely, and it is not what makes Tuesday hard. A tool with excellent truck routing and an expensive replan will still cost you the afternoon. The detail is in its own article.

Optimisation, and judgement

A word on automatic optimisation, since it is what most planning tools lead with. Solvers are good at the version of the problem you can write down: distances, time windows, capacities, costs. They are poorer at the version in the planner’s head — this consignee unloads faster if you arrive before the lunch break; this driver knows the site and the gate code; this customer is being courted and is not getting a 17:00 slot this week.

The arrangement that survives is the solver proposing and the planner disposing, and that carries a requirement: it must be possible to overrule a suggestion and have the override stay, rather than be quietly undone the next time the plan is recalculated. A suggestion you cannot pin is a suggestion you stop asking for.

What to try in a demo

Ask for an ordinary morning on your own data, then break it:

1. Move a planned booking from one run to another. Count the manual steps, and check that sequence, distance and times recomputed.
2. Fail an inspection on a vehicle, then try to plan it. Does the board refuse, warn, or offer it as though nothing happened?
3. Drop an urgent order in at 11:00. How long until you know which vehicles can take it, and on what evidence?
4. Cancel a stop mid-run and watch what the driver’s app and the customer see, how soon, and whether anyone had to do it by hand.
5. Do all of it a second time. The second replan is the one that tells you whether the tool is helping or merely recording.

Where navichain stands on these

navichain plans on a dispatch board and a planning sheet: bookings are dragged onto trucks, and what will not fit is flagged before you commit. Availability accounts for the vehicles already on a run and for the ones the workshop has taken away — a failed inspection grounds the vehicle in the same system that plans it, and a critical defect keeps it grounded. Changes reach the driver’s app and the customer’s own portal without a phone chain, and notifications go to the person concerned rather than to everyone. Route planning is unlimited on every plan; it is not a capability you upgrade into. Pricing is public, from 995 kr a month, billed monthly with no lock-in — the platform page shows what is inside, and our checklist for choosing a TMS is the place to start if you are earlier in the process.