Order and shipment history, seasonality and known drivers project volume by lane, site and period. The output only matters if it changes something you commit to in advance — shifts rostered, vehicles booked, space taken.
What it needs
- Several years of history at the granularity you actually plan at. A network total does not help a site manager staff a shift.
- A record of what you turned away or could not move, or the history understates demand exactly where it was tightest.
- Promotions, contract wins and losses marked, or the model learns a one-off customer as a season.
How you would know it worked
Against your current method, which is usually last period plus judgement, on the same lanes over the same window. The published reviews report machine learning beating classical baselines by meaningful margins, but those are the authors’ datasets and not a promise about yours — your own baseline is the only comparison that decides anything.
Where it fails
On lanes dominated by a handful of customers, where one contract decision outweighs any pattern in the history. It also fails after a genuine step change in the network, because a model trained on the old shape is confident and wrong.
Orders, vehicle capacities, time windows and driver hours are solved into routes. This is optimisation rather than learning, and it is one of the two here that involves no machine learning at all.
What it needs
- Accurate service times per drop. Planned times that everyone knows are wrong produce routes nobody runs.
- Real vehicle constraints, including the ones drivers work around informally.
- Access restrictions and delivery windows as they are enforced, not as the customer master says.
How you would know it worked
Planned versus actual, per route, over a month: how many drops moved, how much time was added, how often a driver rebuilt the run themselves. A plan the depot quietly overrides has failed however good the objective function looks.
Where it fails
When the model’s picture of a drop is a customer record and the driver’s is a loading bay with a locked gate at four o’clock. The gap between those two is where these projects die.
Pick history, product dimensions and affinity between items decide where each SKU sits, cutting travel per pick. Also not machine learning — it is counting and arithmetic, and it usually pays back faster than anything else on this list.
What it needs
- Pick-level history with location and timestamp, not order-level summaries.
- Accurate product dimensions and weights, which are very often wrong in the master data.
- A window in which to physically move stock, which is an operational cost people forget to budget.
How you would know it worked
Travel distance or picks per hour, measured before and after on comparable volume. Normalise for volume or a quiet month will look like an improvement.
Where it fails
When the analysis is run once and never again. Slotting decays as the range changes, and a layout optimised for last spring is worse than one nobody optimised.
Telematics, historical transit times, traffic and dwell patterns predict arrival windows for a consignment in flight.
What it needs
- Position data at a frequency that captures dwell, not just departure and arrival.
- Historical actuals per lane, including the bad days rather than a cleaned set.
- A defined event for "arrived", because gate-in, unload and POD are three different times and pretending otherwise makes the whole measurement incoherent.
How you would know it worked
The share of deliveries landing inside the promised window, and the size of the misses when they fall outside. Publishing a narrow window you hit half the time is worse than a wide window you hit reliably.
Where it fails
At the last leg and in yards, where the variance actually lives. A model that nails line-haul and cannot predict a three-hour wait for a door is a model that gets the customer promise wrong.
Telematics fault codes, service history and duty cycle are used to schedule work before a breakdown. The value is a planned VOR instead of a recovery and a failed delivery.
What it needs
- Fault codes retained rather than cleared at service, which many workshops do by default.
- Service history joined to the vehicle across its whole life, including under a previous operator.
- Duty cycle, since the same vehicle on urban multi-drop and on trunking degrades differently.
How you would know it worked
Roadside breakdowns per vehicle per year, against the same period before. Count planned VOR hours too — trading a breakdown for excessive precautionary downtime is not a win.
Where it fails
On mixed fleets with too few of any one model to learn from, and where the maintenance record lives with a contracted workshop who has no reason to give you the detail.
Carrier invoices are reconciled against rate cards, actual weights and dimensions, and the shipment record. Overcharges are usually not fraud — they are re-weighs, accessorials and surcharges that nobody has capacity to check line by line.
What it needs
- Rate cards in a structured form. They frequently arrive as PDFs and turning them into data is the project.
- Dimensional data captured at despatch, or you cannot dispute a re-weigh.
- A shipment record that can be matched to an invoice line, which sounds trivial and rarely is.
How you would know it worked
Recovered or avoided spend as a share of freight cost, and the share of invoice lines checked. The second matters: auditing a small sample and extrapolating from it is an estimate, not a finding.
Where it fails
When the dispute process costs more than the recovery. Finding an error you will never claim back is an expensive way to feel informed.
Every use case above assumes these. Where one is missing, it is the project — not a prerequisite to be waved through in a kick-off meeting.