Route Optimisation With Machine Learning for Delivery Fleets

The part of routing that is not machine learning

Most fleets that ask us about AI route optimisation already own route planning software, or have a planner who is very good with a map. The routes still run late. The usual reason is not that the sequence of stops is wrong. It is that the plan assumed eleven minutes between two drops that take twenty-two at half past eight, and four minutes on site at a customer where the driver always waits for a signature.

Deciding the order of stops across a fleet is a vehicle routing problem. It has been studied for decades and open-source solvers such as Google OR-Tools handle it well, including time windows, vehicle capacity and driver breaks. A neural network does not beat a proper solver at this, and anyone who tells you otherwise is selling the model rather than the result.

Where machine learning earns its place in route planning

The solver is only as good as the numbers you feed it. That is where a model helps.

1. Travel time prediction. Drive time between two points by hour and weekday, learned from your own telematics rather than a generic map estimate. Urban vans and rural lorries behave very differently.
2. Service time prediction. How long a driver actually spends at each stop, based on the customer, the parcel count, the building type and whether it is a first delivery. This is the input most planners guess, and it is frequently the biggest error.
3. Volume forecasting. How many stops tomorrow, by area, so you roster the right number of vans before the orders close.
4. Failed delivery risk. Which drops are likely to fail so they can be moved to a window when someone is in.

A worked example for a regional fleet

Take a regional wholesaler running 18 vans and roughly 700 drops a day across a mix of city centre and business parks. The planner builds routes each evening using map-based drive times and a flat eight minutes per stop.

Looking at three months of GPS pings and proof-of-delivery timestamps, the pattern is typical: drive-time estimates are close enough outside rush hour, but service time varies from two minutes at a trade counter to over twenty at a hospital goods-in. The flat eight minutes means some routes finish at 2pm and others miss their last three windows.

Replacing the flat figure with a predicted service time per stop, and feeding it to the same solver, is a modest piece of work. It usually matters more than any cleverness in the routing algorithm itself. We would expect that kind of change to rebalance routes so the fleet stops sending out a nineteenth van on busy days, though the size of the gain depends entirely on how wrong the old assumptions were.

What data you need

Six to twelve months of history is plenty. Less than two months will not capture seasonal or school-holiday traffic effects, so any model trained on it should be treated as provisional.

When route optimisation with ML is the wrong spend

If you run five vans on fixed milk-round routes, stop here. A good planner and a sensible routing tool will get you most of the value, and a model adds maintenance for very little return.

• Routes rarely change day to day, so there is nothing to re-optimise
• Proof of delivery is recorded on paper, so service time cannot be measured
• The real constraint is loading time at the depot, which no routing model touches
• Drivers ignore the planned sequence anyway, and nobody is going to change that

That last one deserves a straight answer. We have seen more routing projects fail on driver adoption than on maths. If the plan does not match what drivers know about the patch, they will override it, and they will often be right. Build a way for their corrections to flow back into the service time model.

How we would build it

At SpiderHunts we start by measuring the gap between planned and actual times on existing routes, because that gap is the size of the prize. If planned and actual are within a few minutes, the problem is somewhere else.

1. Clean the telematics and proof-of-delivery data into stop-level actuals
2. Build a service time model first, since it is usually the largest error
3. Add hour-of-day drive time adjustments on top of the map estimates
4. Feed both into an existing solver or a routing tool with an API
5. Run new plans in parallel with the planner's for two to four weeks
6. Track planned-versus-actual per route every week after go-live

The models are gradient-boosted trees in most cases, trained in Python and served behind a small API the routing tool calls each evening. Our machine learning development work on this kind of project is mostly data engineering, which is honest if unexciting. If you want the wider context on logistics systems, our piece on software for logistics and delivery covers the rest of the stack.

What it costs and how long it takes

For a fleet that already has telematics and electronic proof of delivery, a first version with predicted service and drive times plugged into a solver is typically an eight to twelve week project. Most of the cost is joining the data sources and building the feedback loop. Ongoing cost is small: retraining monthly and watching for drift when you take on a new customer type or open a new depot.

If you do not have stop-level timestamps yet, the first project is capturing them. That is not a machine learning project, and it is the right place to start.

Frequently asked questions