Test the route before you drive it

Most operational changes are tested live: you change the routes, the shifts or the layout, and find out on Monday whether it worked. A small model that compares options before you change anything is often the cheapest improvement available. It does not need to be perfect. It needs to be better than guessing.

Why test changes before making them?

Because the real world is an expensive laboratory. Every failed configuration costs time, money and the patience of the people who have to work with it. And when changes are made by hand and judged by feel, it is hard to know which ones actually helped.

At Amazon Spain I was responsible for route planning in a national delivery network. Routes were configured by hand, node by node, by experienced planners. That worked, but it left capacity on the table, and there was no way to try a different configuration without trying it on the road.

What did the model do?

It answered one practical question: given tomorrow’s stores, locations and volumes, and the real constraints, what is the best way to group stops into routes, and how many vans do we need?

The constraints were the ones planners already knew: van capacity, delivery windows and hours on the road. The model took a day’s plan as input and returned a set of routes. Planners could then run several scenarios for a node, compare them, and change the configuration only once they knew which option was better.

The model was written in Python. I used AI to write and test the code much faster than I could have alone, while keeping full ownership of the logic: every assumption was mine, checked against what planners knew to be true. That combination, domain knowledge plus AI as a building tool, is what made it practical to build alongside the day-to-day planning work.

What changed?

The model became part of the weekly planning routine, with dashboards for stops per route, vehicle utilisation and route time. Nodes were reconfigured one at a time, each after its scenarios had been compared.

Across the network, route efficiency rose by 27% and vehicle utilisation by 39%. Most of that came not from clever mathematics but from making better decisions visible before they were made.

Does this only work for logistics?

No. Any decision that involves arranging limited resources under constraints can be tested this way:

• Shift patterns: how many people, on which days, to cover demand without overtime.
• Delivery or service zones: which customers each team or vehicle should cover.
• Warehouse or workshop layout: where things go so that people walk less.
• Appointment scheduling: how to fill capacity without long waiting times.

In each case the logic is the same: describe the constraints, generate options, compare them, and only then change the operation.

How do you start without a data team?

Smaller than you think.

1. Write down the decision and its constraints. One page: what you are deciding, what you cannot change, and what “better” means (fewer kilometres, less overtime, more jobs per day).
2. Start in a spreadsheet. Many first versions are a table of options and a few formulas. If it helps you compare two configurations honestly, it is already useful.
3. Move to code when the spreadsheet breaks. When there are too many options to list by hand, a short Python script can generate and score them. With AI as a coding assistant, this is now within reach of anyone who understands the problem well, provided they check the logic.
4. Test one change at a time. Compare the model’s prediction with what actually happened. That is how the model earns trust.
5. Make it routine. A model used once is a project. A model used every week is a capability.

What is the broader lesson?

AI is most useful in operations not as the product but as the tool that makes better tools cheap to build. The value comes from understanding the problem well enough to describe it, and from testing changes before your customers and staff have to live with them.

If there is a decision your team makes by feel every week, it is probably worth a small model. A short build is often enough to find out.