Lesson 1: time windows and data inconsistencies undermine the optimisation
The algorithm is only as good as the data you feed it. For last-mile route planning, that means delivery addresses with a time window. Simple in theory, but in practice time windows are rarely clean. A customer may have a different window on Monday than on Friday, a loading entrance may be closed in the morning but that is not recorded anywhere, or a previously agreed appointment is still in the system even though the customer called in a change. The system calculates with outdated or incomplete information and produces a route the driver has to adjust at the very first stop. Two things help here: a structural data cleanup before you build any automation, and a mechanism that allows exceptions to be reported back and recorded quickly. Automation amplifies whatever is already in your data — including the errors.
Lesson 2: the driver knows what the system does not — and how do you capture that?
An experienced driver knows that the loading dock at customer X is at the rear, that parking at customer Y only works if you arrive before ten, and that the bridge on a particular route is closed to trucks in the afternoon. That kind of knowledge is not in any database. If you automate route planning without preserving that knowledge, you lose operational intelligence that took years to build. The solution is not to make the algorithm smarter, but to build a layer that allows drivers to enter location-specific notes via their app or device, and that stores those notes as structured attribute data on the address record — not as a free-text note, but as a field the route planner incorporates into its calculation. This requires a deliberate choice in your system's data model, and that is custom work. A standard route planner rarely offers this without workarounds.
Lesson 3: the integration with your TMS or WMS is the real bottleneck, not the algorithm
Most organisations that want to automate last-mile route planning already run a TMS or WMS. The problem is that the route planner and the TMS are two separate worlds. Orders arrive in the TMS, the planner manually exports them to the route planning software, the routes come back as a PDF or Excel file, and the planner re-enters the results into the TMS by hand. That is exactly the kind of manual rekeying you want to eliminate, but building the integration is technically the hardest part. Many TMS packages have limited or poorly documented APIs, some systems still run on an on-premise database, and the data flow is bidirectional: routes go out of the TMS to the route planner, and status updates from the driver have to come back. If you want to solve this properly, put the integration question on the table first — before you start selecting a route planning module.
When does a standard route planner suffice, and when does custom development pay off?
A standard route planner from one of the major SaaS providers works well when your routes are relatively predictable, your data is reasonably well maintained, and you do not need deep integration with your core systems. In that case, building something custom is a waste of money and time. But as soon as you have contractual time windows per customer, work with non-standard vehicle restrictions, or need route results to flow back automatically into your TMS for invoicing and status management, a standard package falls short. Not because the algorithm is poor, but because the integration options and data model do not scale with your operation. Custom development pays off when the integration and data model need to follow your specific workflow — not the other way around.
What is the best approach to automating last-mile route planning?
Start with the data, not the tool. Map out which fields your route planner needs, which of those are currently missing or unreliable, and who is responsible for keeping them up to date. Then determine how you want to connect to your TMS or WMS: via an existing API, a middleware integration, or as part of a new system. Only once those two pieces are clear does it make sense to evaluate whether a standard package is sufficient or whether you need a custom solution. An AI layer or worker can help structure driver notes automatically, process time window changes from emails or messages, or write trip deviations back to the correct address record. But that too only works if the data model and the connection to the core system are sound.