Choosing route planning software in 2026: 5 tests before you sign

Monday, seven thirty in the morning. Your planner opens Friday's spreadsheet, drags stops around and hopes the time windows line up. Out on the dock, three drivers sit with the engine running, waiting to find out which route is theirs.

That Monday is fixable. But buying last-mile route planning software doesn't fix it on its own. Buying the one that survives your actual operation does, with your constraints and your surprises.

And that's the hard part, because every tool looks the same in a demo. They all draw stops on a map, they all sequence them in seconds, they all promise fewer kilometres. The difference doesn't show up on demo day. It shows up in week three, when the plan breaks at seven in the morning and someone has five minutes to decide.

These are the five tests that separate the tool that stays in your operation from the one that ends up in the folder of abandoned projects.

Before comparing tools, write down your worst Monday

Most evaluations start by comparing feature lists. That's the wrong order: any vendor can tick every box.

Start from your operation instead. Take the hardest day of the last month and write it down in four lines: how many stops, how many vehicles and of what type, which time windows are untouchable, and what broke that day. That's your test bench. Every demo you sit through has to solve that specific day, not a generic case with twenty sample stops in the city centre.

If a vendor won't work with your data, you already have your answer.

1. Real constraints, not just distance

Working out the shortest route is the easy part. The knot appears when your refrigerated van can't carry more than 800 kilos, the city-centre customer only accepts deliveries before 10:00, unloading at that industrial estate takes 25 minutes, and the new driver doesn't know the area.

A useful tool lets you define all of that before it calculates: weight, volume, time windows, service times and driver skills. If it only works with points on a map, what you get is a pretty route your planner will retouch by hand every morning. The retouching eats the savings.

How to test it: ask the demo to load your constraints, not theirs. Then watch what happens when two of them contradict each other. An honest system tells you which stop doesn't fit and why. A bad one hands you an impossible route with a straight face.

2. What happens when the plan breaks mid-morning

Your driver leaves with twenty stops. At the third, nobody's home. At the seventh, a street closed for roadworks. At eleven, an urgent order lands that has to go out today.

That's the normal day. If the software only knows how to plan at seven in the morning, the rest of the day goes back to the phone and to one person's memory. And with it come the time windows that get missed without anyone noticing until the customer calls.

Look for the ability to move stops between routes and recalculate from the dashboard, with the driver getting the change on their phone without a call. Replanning mid-morning is the normal case, not the exception, so treat it as a core capability rather than an add-on.

How to test it: break the plan on purpose during the demo. Remove a vehicle, add two urgent stops, and count the clicks until the driver has the new route.

3. Visibility you can act on, not surveillance

Knowing where each driver is only has value if it reaches you in time to do something. If you find out about the delay when the customer has already called, you have a map, not visibility.

What you need on a single live panel is specific: which stops are left per vehicle, how far the estimated arrival time has drifted, and which routes will miss their window if nobody touches anything. With that you can warn the customer before they get annoyed, or move two stops to a driver who's running light.

One thing that matters more than it looks: the visibility has to be useful for the driver too. Seeing their own route, their progress and their finishing time is what makes them use the tool instead of enduring it. And if the driver doesn't use it, your data is fiction.

How to test it: ask what the driver sees on their phone. Ask for a screenshot of their screen, not just the planner's.

4. Data that gets in and out on its own

If your team has to copy orders from the ERP into the routing tool, then type the results back into the ERP, the time you gain planning you lose in double entry. With a bonus: every manual copy is a mistyped address waiting its turn.

Check that there are three ways in and out: file import so you can start tomorrow, API and webhooks to connect your ERP, WMS or online store, and automatic export of execution data to wherever you already report.

That last one always gets forgotten, and it's what holds up continuous improvement. If a system can't tell you what happened yesterday stop by stop, it won't help you argue next quarter's budget either.

How to test it: ask to see the technical documentation, openly, without signing anything. If it isn't public, ask why.

5. How long until it's actually running

A project that needs weeks of configuration and days of training doesn't fit an operation where every morning counts. And there's a worse risk than slowness: the longer the ramp-up, the more likely the project stalls halfway when peak season arrives.

Ask about time to the first real route on the street, not time to project close. Ask what the driver needs to get going too: if something has to be installed and configured on every phone, adoption will jam around vehicle number six. With Routal, teams are usually dispatching in under 48 hours, and the driver only needs their phone or a web link.

How to test it: make the evaluation itself the ramp-up. If you haven't dispatched a real day within two days, you already know how long the full rollout will take.

What shouldn't decide your purchase

Three things carry a lot of weight in evaluations and predict the outcome rather badly.

• The feature list. Everyone ticks the same boxes. What changes is how many clicks each box costs on a busy Tuesday.
• The promised savings percentage. 30% on an operation they've never seen means nothing. 8% on yesterday's stops does.
• Price per stop in isolation. Compare it with what you pay today for a van circling lost for an hour, a failed delivery, or the Saturday someone spends sorting out Monday.

The test that really decides: one real day

In the end, the evaluation comes down to one thing. Take the stops from one of your days, with their windows and their constraints, and run them through the tool while you watch.

Look at three numbers and one feeling. The numbers: kilometres and hours against your manual plan, stops left out and why, and minutes for the whole process from file to the driver's phone. The feeling: whether your planner could do it alone tomorrow, with no help.

That last point is what most often decides whether a piece of software stays or gets dropped. According to a Capgemini report on last-mile delivery, the final leg accounts for up to 53% of total shipping cost. That's too much money to leave in the hands of a tool that only works when the day goes to plan.

Start with the simplest step: look at tomorrow's routes and count how many of your constraints your current tool can't take into account. That number is your starting point.

If you'd like to see it with your own data, book a demo and bring the stops from a real day. Preferably a bad one.