In Short
- A route comes back as a distance, a duration and a line on the map. An origin, a destination and the constraints you named go out to the routing provider; what comes back is a measured road distance and a travel time, not an opinion.
- No money is attached to it, on purpose. The routing provider returns distance and time and no cost. So no saving is printed next to the route, because a figure nobody measured sitting beside two that were is how an estimate gets quoted as a fact.
- When it could not be worked out, it says so. No routing credential on the connection, or a provider that returns nothing, comes back as unavailable. It comes back saying so, rather than with the fields left empty, which on a screen is indistinguishable from a good answer.
Drawn This page marks where the line falls. The routing call, the answer it returns and the refusal to guess a cost are in the product. The working day around them is an illustration of the mechanism, not an account of an event: it has not been run against a customer's fleet, and there are no figures here for distance, time or money saved.
Optimal At Six. Not At Ten.
The plan was good when it was built. Then a drop took forty minutes longer than it should have, a road shut, and a customer moved a window. The plan is now the best answer to a question nobody is asking.
Where It Goes Wrong
Routing happens once, the night before or first thing. It is the most carefully made decision of the day, and it is made with the least information anyone will have all day. Everything that will actually shape the day — the gate queue, the closure, the refused delivery, the driver who is running an hour down — has not happened yet.
By mid-morning the plan has drifted, and everybody on the desk knows it. What they do about it is patch it: swap two drops, push one to tomorrow, ring a driver. Sensible, local, and nobody can say whether the patched day is better or worse than the one that would come out of running the whole thing again.
Re-running it is free. Re-planning it by hand is not, so it never gets re-run.
And the cost of the drift is never written down. It leaves as overtime, as a missed window, as a second trip, as fuel. Each of those lands in a different budget, and none of them is labelled with the reason.
This sits with the transport planner and whoever is on the dispatch desk that day. They own it in the hour they have least.
What Happens Instead
Asking for a route is one small request: where it starts, where it ends, and the constraints that matter on this leg. That goes out to the routing provider and comes back as a road distance, a travel time and the line itself, so the answer can be drawn on a map rather than described in a sentence.
The request is small, so asking a second time costs about what asking the first time cost. The question stops being "is it worth re-planning the day" and becomes "what does the route look like now" — one you can put to it as often as the day changes.
What comes back is the leg you asked about: its origin and destination, the distance and the duration the provider actually returned, and the line the route follows. It is an answer to a question you put, which is why it arrives when you ask rather than appearing on its own.
Two refusals are built in, and they are the reason to trust the rest. No saving is printed beside the route, because the routing provider does not return one — internal rule-of-thumb estimates exist elsewhere in the product and are deliberately not copied onto a measured route. And if there is no routing credential on that connection, or the provider returns no route at all, the answer is that it is unavailable. Not an answer with blank fields. A blank field on a screen reads as a measurement, and that is a worse failure than an honest error.
The credential belongs to the connection, not to the machine. Routing is reached with the key attached to the connection that was configured for it, so the grounding is something you set up, can see and can revoke per connection. It is not an environment variable baked into a server that nobody can audit.
A change is proposed, never imposed. A named person on the desk approves it, edits it or rejects it, and rejecting is recorded as a decision rather than as silence. Telling the driver is a separate job and a separate page — a driver can ask and be answered out loud with their hands on the wheel, in talking to drivers without a screen, though the call leaves a transcript rather than an acceptance, and the desk still owns the change. And if the question is bigger than one leg — a supplier dropped, a lane given up for a season — the case for it can be laid out against the rules it collides with first, in testing a plan before you commit to it.
Approving is what sends it, and the reason stays on the record for whoever asks in three months why a truck went that way. One more honesty about that, of the kind this page is built on: where a step behind the approval has nothing implemented behind it — the write into your transport system is the real example — the answer names that step as not executed rather than returning a success that covers the whole action. Approved and done are two different words here, and the software is the one that tells you which it managed.
Who Owns This
Three desks, and what each of them is holding today.
- The transport planner. Today the plan is built the night before or first thing, which makes it the most carefully made decision of the day and the one made with the least information. What changes is that a single leg can be asked about on its own terms — one origin, one destination, the constraints that matter on it — and the answer is a measured road distance and a travel time from the routing provider you connected.
- The dispatch desk. Today the day gets patched: swap two drops, push one to tomorrow, ring a driver. Sensible and local, and nobody can say what the patch cost. What changes is that a leg comes back as a distance and a duration that were actually returned, so two people on the desk are arguing about the same two numbers.
- Operations director. Today the drift leaves the building as overtime, a second trip, a missed window and fuel, each landing in a different budget and none of them labelled with the reason. What changes is that no money is printed beside a route, because the provider returns none — so a figure that was measured and a figure that was guessed never sit on the same line pretending to be the same kind of thing.
How You Will Know It Worked
Every figure below is yours, not ours. We have none of our own to offer you. Write down where you stand today, because the baseline is gone for good the moment things improve.
- How often a route is re-run after dispatch. Most honest answer is never. Take a month and count the days the plan was recalculated rather than patched. This is the number the whole thing turns on.
- Planned against actual, per leg. Out of your transport system: the distance and the time the plan assumed, against the distance and time the vehicle recorded. Keep it per leg, not per day — a day that balances out is hiding two legs that did not.
- Windows missed, and which of them were avoidable. From your delivery records. Split them into the ones that were lost before the truck left and the ones that were lost during the day. The second group is the one this touches.
- Driver overtime and second trips, by depot. From payroll and from your dispatch log. They are the two places the drift leaves the building, and they are usually filed where nobody connects them to routing.
Bring a month of planned-against-actual leg data for one depot.
Questions A Transport Desk Asks
What comes up before anybody talks about a contract.