Rolling Out Roadnet: Lessons From Planning Real Delivery Routes

Route planning software promises fewer kilometres, fuller vans and more predictable days. Whether you get that depends far less on the software than on how you roll it out. A routing engine optimises what you feed it. Feed it outdated addresses, guessed service times and territories nobody has questioned in years, and it will produce well-optimised versions of the same problems.

This article shares the lessons from rolling out Roadnet for a periodic-delivery operation, and what any company planning a Roadnet implementation (or a reset of an existing one) should get right.

Start with the data, not the screens

Vendors agree on this point. Descartes, which sells route planning software, puts it plainly in its own implementation guidance: data and integration are the two greatest implementation risks, and need as much attention as choosing the solution. [1]

For route planning, “data” means more than customer addresses:

• Locations. Exact geocodes, not just street names. A delivery point at the back of an industrial site is not where the map pin lands.
• Service times. How long a stop really takes, by customer type and by volume. Averages hide the difference between a two-minute drop and a twenty-minute install.
• Time windows and access rules. Opening hours, loading-dock restrictions, low-emission zones, vehicle height or weight limits.
• Order volumes and frequencies. What a customer needs per visit, and how often.
• Vehicles and shifts. Capacities, start and end depots, working-time rules.

If those inputs come from history (“we always went on Tuesday”), the engine will respect history. If they come from measurement, it can improve on it. Collecting and checking this data is the least glamorous part of the project, and the part that decides the outcome.

Question the territories before you optimise the routes

Many delivery operations have territories that grew organically: a driver’s patch, a region drawn years ago, a day assigned because a customer once asked for it. Optimising routes inside those boundaries gives a local improvement. Redrawing the boundaries with data is where the larger gains usually sit.

That is a business decision as much as a planning one. Moving customers between days or drivers affects service promises, sales relationships and people’s routines. Make those decisions explicitly, with operations, sales and customer service in the room.

Pilot, measure, then expand

A route planning rollout should not be a big bang. Pick one region or depot, run the new plans, and measure them against an agreed baseline: distance, time on the road, stops per route, on-time performance. Adjust the parameters for local conditions, then move to the next region.

This approach does two things. It catches data and parameter problems while they are still small. And it gives planners and drivers proof, from their own routes, that the new plans work. Vendor guidance recommends the same: validate on a limited scope first, then expand by region or business line. [1]

Bring the drivers and planners with you

Drivers know things no system does: which customer is never there before ten, which street is blocked on market day, where a van can actually park. If the new routes ignore that knowledge, drivers will quietly change them, and the plan and reality drift apart.

Involve experienced drivers when checking service times and access rules. Show planners why the engine chose a sequence, not just what it chose. And make it easy to report a stop that does not work, so the data gets better rather than the workaround becoming permanent.

Keep measuring after go-live

Route planning is not a one-off configuration. Customers move, open or close, volumes change and new constraints appear. Without someone who owns the planning parameters and keeps measuring, routes degrade back toward habit. Set up regular reporting on the same metrics you used in the pilot, and give one person clear ownership of the route planning setup.

What this looked like at Sip-Well

At Sip-Well, Ben led the Roadnet rollout. The approach followed the steps above: analyse the delivery data first, configure Roadnet based on what the data showed, roll out region by region, and keep monitoring afterwards. In the words of Eddy Brotmann, Operations Director, Sip-Well:

Ben’s structured, data-driven approach to the Roadnet rollout gave us confidence from day one. The results exceeded our expectations and fundamentally changed how we plan our deliveries.

Eddy Brotmann, Operations Director, Sip-Well

The full story is on our Sip-Well case study page.

Case study: Sip-Well Roadnet rollout

A short checklist before your Roadnet implementation

1. Geocode and verify every delivery location.
2. Measure real service times by customer type.
3. Capture time windows, access rules and vehicle restrictions.
4. Agree the baseline metrics before the first new plan runs.
5. Review territories and delivery days, not just route sequences.
6. Pilot in one region, adjust, then expand.
7. Involve drivers and planners in validating the plans.
8. Name an owner for planning parameters after go-live.

The bottom line

A Roadnet implementation succeeds or fails on data, territories and people, in that order. The software does the optimisation. Your job is to give it the truth about your operation and to make sure the organisation trusts the result.

Sources

1. Descartes, “Route Planning Buying and Implementation Tips”