Machine Learning for Logistics Companies

Most logistics data is already sitting there

A 60-vehicle haulier generates more data in a week than many retailers do in a year: GPS pings, engine events, proof-of-delivery timestamps, driver hours, fuel cards, customer bookings. Almost none of it gets used beyond the invoice and the occasional dispute.

Machine learning for logistics companies is mostly about turning that exhaust into decisions made earlier. Knowing on Thursday that Monday will be 18% busier. Knowing at 10am that a 3pm delivery will be late while there is still time to tell the customer. Knowing that a lane is losing money before you quote the next contract on it.

Where logistics machine learning earns its keep

1. Arrival time prediction. Better ETAs than distance divided by average speed, learning from actual drop times by customer site, time of day and driver. Customers notice this one.
2. Volume forecasting. Parcels, pallets or jobs per depot per day, so you book agency drivers and trunking capacity before the rates go up.
3. Cost-to-serve and job profitability. Predicting the real cost of a job from its characteristics, including waiting time at particular sites, so quotes reflect reality.
4. Failed delivery risk. Scoring which deliveries are likely to fail first time, so you confirm slots or reorder the run.
5. Vehicle maintenance. Using engine fault codes and mileage to catch problems before a roadside breakdown. Our post on predictive maintenance for smaller operations covers the fleet case well.

Is route optimisation machine learning?

Mostly no, and it is worth being clear because it gets sold that way. Deciding the order of 120 drops across 9 vans with time windows is an optimisation problem, solved with established solvers and heuristics. There are good off-the-shelf routing tools and building your own rarely makes sense for an SME.

Where machine learning genuinely improves routing is in the inputs. A solver is only as good as its estimate of how long each drop takes. If your system assumes eight minutes everywhere, but the hospital loading bay takes 25 and the corner shop takes three, the plan is wrong before the first van leaves. Predicting service time per site is a small model with a large effect on route quality.

The solver plans the route. The model tells the solver the truth about how long things take.

The data each model needs

The recurring problem is timestamps that record when someone pressed a button, not when the thing happened. Before modelling, we compare GPS stop times with app completion times. The difference tells you how much of your data to trust.

What it costs and what it returns

Illustrative numbers for a mid-sized operator:

• ETA or service-time model feeding an existing routing tool: eight to twelve weeks including integration
• Depot volume forecast with a daily planning screen: six to ten weeks
• Job profitability model used at quoting: ten to fourteen weeks, most of it cleaning cost data

On the return side, think in avoided cost. If better volume forecasts let a depot book agency drivers two days earlier at the standard rate instead of the short-notice premium, and that happens 40 times a quarter, the saving is easy to calculate from your own rate card. We would rather you did that sum before talking to us than after.

When a logistics firm should not build a model

• Your jobs are mostly the same fixed daily routes for the same customers, where history is already the forecast
• Proof-of-delivery data is incomplete or entered at the end of the shift
• The transport management system cannot accept an external ETA or forecast, and replacing it is off the table
• The real problem is dispatch process, not prediction

The last point deserves a sentence. Many operators we speak to have a planning problem that is really an information problem: jobs arriving by phone, email and portal with no single view. That is automation and integration work, and it should come before any model because the model needs that data in one place anyway.

Getting planners to trust the numbers

Transport planners are sceptical people, usually for good reasons. They have seen systems promise a 7am slot for a site that never opens before nine. A model they do not trust gets overridden quietly, and six months later the business concludes that machine learning does not work.

Two things help. Show the reason next to each prediction, such as "this site averaged 31 minutes on site over the last 20 visits", so the planner can judge it. And track overrides: when planners change a prediction and turn out to be right, that is training data and a signal the model is missing something they know. Treat the planning team as the people who will make the model better, because they will.

How we would start

At SpiderHunts, a logistics engagement usually begins with a two-week data review: we take an export of jobs, tracking and outcomes, measure how reliable the timestamps are, and build one quick baseline model. You get a short written answer on what is predictable and by how much. Some operators stop there with a clearer picture of their own data, which is a perfectly good outcome.

If you want the wider picture of AI in the sector beyond predictive models, including document handling and customer messaging, see AI for logistics and supply chain.

Frequently asked questions