Spend a morning in a transport office and you will see the real job quickly. The system may show hundreds of consignments moving exactly as planned. Nobody is looking at those.
The calls, messages and decisions are about eleven consignments. Those eleven are the work. Everything else happened by itself.
That is the central fact about logistics software, and it is routinely missed. The planned path is well understood, largely automated and commercially uninteresting because everyone can do it. The margin, the customer relationships and the operational risk all live in the exceptions.
Those exceptions are usually handled by a person with fifteen years of experience, a phone and a spreadsheet they built themselves. If the software does little for that person, it misses the work that matters most.
The planned journey already works
When a client asks for a new transport system, the requirements usually describe the happy path in enormous detail. They cover bookings, routes, allocations, ETAs and proof of delivery.
All of that is necessary. None of it is where the difficulty is. A supplier who builds exactly that will deliver something that works perfectly and changes nothing about how the business runs.
The reason is simple. The planned path was already working. It was working on the old system, and before that it was working on a whiteboard.
Replacing a functioning process with a nicer version of the same process is a cost. The improvement is available where the current process is expensive. In logistics, the expensive process is a senior person reconstructing what happened, deciding what to do and telling four parties about it individually.
A late vehicle needs a decision, not another red flag
The vocabulary gets in the way. Systems often treat any deviation as failure. They show a red row, a warning or an alert.
A vehicle arriving two hours late because of an accident on the motorway is a completely normal event that requires a decision. The software’s job is to help somebody decide.
That distinction changes what you build. A flag is a notification with a number on it. A hundred of them becomes a screen nobody reads.
A decision support surface does more useful work. It presents the deviation, the options, the consequence of each option and the ability to act, in one place.
The measure of success is how quickly the exception is resolved and everyone affected has been told. Detection matters, but resolution is where the operational value appears.
Give each exception its own record
The single highest value change we make on these projects is usually to give exceptions an existence. In most systems the exception is implicit. It is the difference between two states, visible only if you happen to compare them, and owned by nobody until somebody notices.
We turn it into a first class record, meaning a normal record the system can store, assign and measure. It has an owner, an age, a category, a decision and an outcome.
Once that exists, the operations manager can answer questions that were previously unanswerable.
- How many exceptions did we have last month.
- Which type is growing.
- Which customer generates disproportionately many.
- How long does the average one sit before anyone touches it.
- Which ones did we resolve in a way that cost us money we could have avoided.
None of that is exotic technology. It is a table, a state machine and a screen. The state machine is the set of statuses an exception moves through as people work it.
The reason it is transformative is that it converts institutional knowledge held in one person’s head into an operational metric the business can manage.
Record why the planner chose that action
Most systems record what happened. Very few record why somebody did what they did about it. The why is the valuable part.
When a planner reallocates a load to a different vehicle, the reason is a fact about the business. The original vehicle was going to breach drivers’ hours, or the customer’s receiving window closes at four, or that particular site cannot take a trailer of that length.
Recording the reason costs one dropdown. It turns your exception log into a map of where the business is actually constrained.
After six months, that log tells you which depots generate the most rework, which customers have requirements that are systematically mispriced, and which routes are planned with insufficient slack. That is a commercial asset, and it accumulates only if somebody decided to capture it on day one.
AI helps with the messy information around the edges
This is one of the few domains where the current generation of models earns its place immediately. The useful area is the unstructured mess around the edges.
Route optimisation is a well solved operations research problem that does not need a language model. A significant fraction of exception handling is reading.
That reading includes emails from customers, driver messages, delivery notes photographed badly, and a PDF from a partner in a format that changes quarterly.
Extracting the eleven fields that matter from that mess is exactly what these models are good at. It is also the part that currently consumes an experienced person’s afternoon.
We treat it as a defined job with a confidence score, a held-out test set and anything below threshold routed to a human rather than guessed. That is the same discipline we apply anywhere a model touches an operational process.
AI can sort the queue before a person decides
When forty exceptions arrive in an hour, the skill is knowing which three matter. That judgement is currently in the head of the person who has been there longest. It is the capability that walks out of the door when they retire.
A model trained on the historical log, with the decisions and outcomes attached, can rank a queue surprisingly well. Crucially, it should rank rather than decide, at least for a long time.
The person keeps the authority and gets a sorted list rather than an unsorted one. Every acceptance or rejection of the ranking is training data.
That is the shape we advocate for almost any operational use of a model: advise first, and earn the right to act later. It is the same argument we make about plant floors.
Good visibility means people hear from you before they call
A large proportion of the phone calls in a transport office are somebody asking where something is. Every one of those calls is a failure of the system to tell them before they wondered.
A customer portal may be part of the answer, but a portal requires the customer to go and look. The useful change is proactive notification tied to the exception model.
When a consignment deviates in a way that will affect a promise made to someone, that someone hears about it from you. They get a revised commitment before they call.
This is straightforward to build and it is the thing customers remember, because the industry norm is silence followed by an apology.
A transport system has to exchange data with everyone else
Nobody in this sector operates alone. There are customer systems, carrier systems, customs platforms, warehouse management and telematics. Each has its own idea of what a consignment is.
A new system that cannot exchange data with those is going to be ignored regardless of quality. The alternative to adoption is somebody keying the same data twice.
The hard part is never the transport protocol, which is the technical way the systems send data to each other. The hard part is agreeing what the data means.
A field called delivery date can mean the promised date in one system, the planned date in another and the achieved date in a third. That reconciliation is genuine analysis work. It belongs at the start of the project, and every estimate that omits it is wrong by a substantial margin.
The yard needs software built for the yard
There is a second environment in this sector that gets designed for badly. It is the yard rather than the office.
Drivers, loaders and yard staff are outdoors, often in poor light, frequently wearing gloves, and holding a rugged device with a screen that was chosen for durability rather than legibility.
The software they are given is usually a compressed version of the office interface. That is the wrong answer, because their job is different from the planner’s job and has about four actions in it.
What works is the same discipline that works on a construction site.
- Large targets.
- High contrast.
- Minimal typing.
- Every action available offline.
Offline matters because a metal-framed warehouse is a reliable way to lose a signal. Proof of delivery in particular has to be capturable with no connection at all.
The moment of delivery is the moment that matters commercially, and it is frequently the worst connected moment of the day. Capture locally, queue, reconcile later, and never make the driver wait at a customer’s gate for a server.
The commercial argument is straightforward. A proof of delivery that arrives four hours late is a proof of delivery that cannot be invoiced against today. In a business running on thin margins and long payment terms, that lag has a real cost attached to it.
Data quality has to be part of daily operations
Every logistics business we have worked with has a data quality problem. Every one of them has at some point run a cleanup project that fixed it temporarily.
The problem comes back because the data is generated at the edges, under time pressure. It is entered by people who are measured on throughput rather than on accuracy. Nothing in the process gives them a reason to care about a field they will never look at again.
The durable fix is to make bad data visible to the person who created it, quickly. Good data also has to be slightly easier than bad data rather than slightly harder.
If a driver selects a reason code from a list of twenty ordered alphabetically, they will select the first plausible one every time.
If the list is four items, ordered by what actually happens at that site and chosen from the historical log, the codes start meaning something within a fortnight.
The second half is to stop collecting anything nobody uses. Most of these systems ask for fields that were requested years ago by somebody who has left. Every unused field trains people that the form is bureaucracy rather than information.
We audit that explicitly at the start. For each field, we ask who reads it and what decision changes because of it. The list of fields that survive is usually about half.
Measure the exception work directly
These are the measures we use for exception work.
- Exceptions per thousand consignments, by category, trended.
- Median and 95th percentile time from exception created to decision made.
- Proportion resolved without a phone call.
- Proportion where the affected customer was told before they asked.
- Cost of resolution, where it can be attributed, because some exceptions are far more expensive than others and the ranking is rarely what people assume.
The exception log showed the real problem
A client moving around nine thousand consignments a week believed their problem was ETA accuracy. They wanted better predictions.
The exception log, once it existed, said something different. Sixty one percent of their exception handling time went on a single category: receiving sites refusing deliveries outside a booking window that had not been communicated to the planner at the time of allocation.
No amount of ETA improvement would have touched that. The fix was to make the receiving constraint a property of the site rather than a note in a customer email, and to validate it at allocation rather than at arrival. Eleven days of work.
Exception volume fell by just under half. The prediction model they originally asked for was never built, because once the dominant category was removed the remaining volume was comfortably handled by the people already doing it.
Building for exceptions can look plainer in a demo
Building for exceptions means the system will look worse in a demo. The happy path screens are fewer and plainer, and much of the value is in a queue that looks like a to-do list.
Buyers comparing two proposals will often prefer the one with the richer planning interface, because planning is what a demo can show.
We lose work over this occasionally and still recommend it, because the planning interface is where the money is rarely found. The eleven consignments somebody is on the phone about are where the money is. They were on the phone before the new system arrived and will be afterwards unless somebody built for them deliberately.
More on how we work in this sector on our logistics and supply chain page.
