You’ve seen the demo. The slides look great. But your planners have one question that no slide can answer: will it work on our routes?
That’s exactly what a proof of concept (PoC) is for.
In short, a PTV OptiFlow proof of concept lets you run PTV OptiFlow on your own planning situation, next to the way you plan today, so you can compare real results before you decide anything. In this post, we’ll cover what a PoC is, how it fits into the path from PTV Route Optimiser to PTV OptiFlow, what a real life implementation looked like, and how to judge the results.
What is a PTV OptiFlow proof of concept?
A proof of concept is a test with your own data and your own rules. Not a generic demo.
For teams still using PTV Route Optimiser, our legacy routing product, we offer an interface that links it to PTV OptiFlow. Both can run in parallel, so your current planning keeps going while you see what PTV OptiFlow would do with the same work.
That matters because nobody wants to bet tomorrow’s deliveries on an experiment.
Where the PoC fits in the upgrade path
The path from PTV Route Optimiser to PTV OptiFlow be summed up in five steps:
- Contact. You talk to the PTV Logistics team.
- Match. The team looks at how your planning works today and what you need.
- Business case. You build the case for the change.
- Proof of concept. You test PTV OptiFlow, with both products running in parallel.
- Start saving. You move to PTV OptiFlow.
So the PoC comes after the business case and before you commit. It’s where the numbers stop being estimates.
Tip: Not sure you’re ready for step 4? Start at step 1. A conversation doesn’t commit you to anything, so get in touch with our team and try PTV OptiFlow on your own routes.
What a PoC looked like at Distrilog
Let’s make this concrete with a real life implementation. Distrilog, a Belgian logistics provider with 350 vehicles, had been planning with PTV Route Optimiser ST. Its planners built a first plan and then adjusted it by hand for customer and driver preferences. When Distrilog decided to try PTV OptiFlow, it began with a business case and a pilot at a single depot.
Here’s how it went:
- A business case first. Distrilog built it from historical data.
- A pilot at one depot. In April 2025, it started at the Olen depot.
- Both systems side by side. The pilot ran for about six weeks with PTV Route Optimiser and PTV OptiFlow in parallel.
- Staged cutovers. Once the pilot worked, the rest of the planning moved over in stages.
- Tuning. Distrilog adjusted PTV OptiFlow’s parameters daily at first. Today it does so once or twice a week.
Notice the pattern: Start small, compare, then expand. Your PoC doesn’t have to follow Distrilog’s exact shape. But it’s a useful picture of what “proof” can mean in practice.
Note: This is one customer’s timeline. Results and timing can vary depending on the size of your network, the quality of your data, the number of depots and the rules you plan with.
How to judge your results
A PoC is only useful if you know what you’re looking for. Before you start, agree on a few questions with your team:
- Is the plan good? Compare routes, kilometers and driving time against your current plan.
- Does it respect your rules? Check delivery windows, vehicle specifications and other constraints.
- Can planners work with it? Try dragging orders between routes and locking the ones that must not change.
- Do arrival times hold up? Compare predicted arrival times with what actually happens.
Here’s another real life example of how a short test can go: De Graaf Logistics, which had been using PTV Route Optimiser ST, tried PTV OptiFlow with just two days of its own data.
“After the first day, we were immediately impressed,” says Tim de Haan, Transport Manager at De Graaf Logistics.
Your next step
Talk to the team about a proof of concept. Or, if you’d like to understand the products first, start with what’s the difference between PTV Route Optimiser and PTV OptiFlow.