There is a pattern that emerges when businesses implement route optimization software and then report that the results did not meet expectations.
In almost every case, the software is not the problem. The problem is what was fed into it, or what was not.
Route optimization is only as good as the constraints it is given and the processes built around it. The six mistakes below are not theoretical.
They are the ones that appear repeatedly in operations that are using optimization tools but not getting the full benefit of them.
Planning routes without accurate time window data
A route that arrives at a customer when they’re doing inventory or taking a break is not even worth calling an optimized route.
And forget about a route that calls at a residents house at 11am when their ‘ available time is actually 3pm in the afternoon.
Time window data is pretty much the most important bit of information you can give a route planner because if its wrong, the whole thing falls apart.
The algorithm will churn out the quickest route its got from the data it’s been given – but if the data’s rubbish then the route its spouts out is going to fail in the field and you’ll end up thinking its a bug in the system when the problem is actually the data.
The solution to this isn’t rocket science – you need to check that your stop data has got the times right before you go and build a system for tracking and updating the time windows you’ve got.
Make getting those time windows right a key performance indicator so if someone comes to you with a complaint that ‘ the data’s wrong’ you can say ‘hang on a minute, what are the hours of the customer – I thought we had that set right’.
And it goes without saying that the algorithm can’t do very much with information it doesn’t have.
Optimizing for distance without accounting for stop duration
Two stops that are right next door to each other arent exactly equivalent if one takes five minutes to make and the other takes an hour because as soon as you factor in the extra time then suddenly the route looks completely different.
If you’ve got a commercial delivery that needs a signature and inspection then that is going to take a lot longer than a simple residential delivery round the door.
And if your route is just optimizing for distance without any regard to how long things actually take then you get these dramatic cascades of delays in the afternoon where everyones ETAs get pushed back because the times just add up.
The ones who do it right are the ones who track the actual time each stop takes – by who they are, where they are and what time of day it is.
The data that comes back from the analytics of Locate2u and some other places captures stop duration from existing data so that information then feeds back in and makes the next route more realistic.
The route gets more accurate over time because its based on what actually happens rather than just some assumed average.
Treating the morning plan as final
A route built before the day starts is built on assumptions about a day that has not happened yet. Traffic changes. Drivers run over at a stop. Customers call to reschedule.
Last-minute orders arrive after dispatch.
Operations that treat the morning plan as unchangeable spend the rest of the day absorbing the consequences of every deviation — late arrivals, missed windows, drivers making judgment calls about sequence changes that the operations manager finds out about at the end of the day.
Running optimization without integrating order data
Route optimisation that starts with a manually compiled list of addresses is already compromised.
The list was typed, which means errors entered the system.
It was compiled at a point in time, which means orders placed after that point are not on it. It was formatted for a routing tool, which means it went through a conversion step that introduced its own risks.
Every manual step between the order management system and the route optimization engine is a step where information degrades.
Integration eliminates the degradation.
When the optimization engine reads directly from the order management system, the data is current, accurate, and complete. New orders appear in the optimization without manual intervention.
Address errors that exist in the source system are the only errors that reach the driver, and those are easy to find and fix because they show up consistently.
Ignoring vehicle load capacity in the optimization inputs
An optimization that accounts for distance and time windows but ignores vehicle load capacity produces routes that overload some vehicles and underload others.
In operations where every vehicle is identical, this is a theoretical problem. In operations with mixed fleets — vans, trucks, bikes, refrigerated vehicles — it is an operational one.
A driver who arrives at the depot and cannot fit all the stops assigned to their route is a disruption that cascades through the day.
Vehicle capacity should be a hard constraint in the optimization, not a check performed after routes are generated.
When the software knows what each vehicle can carry, it distributes volume intelligently.
The fleet runs at higher utilisation because the algorithm is solving the load distribution problem simultaneously with the routing problem, which is what makes the solution globally rather than locally optimal.
Not using proof of delivery data to improve future planning
Locate2u’s route optimization software connects proof of delivery data to route analytics.
Operations managers can identify the stops and patterns that are generating the most deviation between planned and actual, and adjust their planning inputs accordingly.
The mistake of not using this data is expensive not because of any single poor delivery, but because the same inefficiencies recur every day they are not addressed.
