A proof of concept converts vendor claims into evidence from your own operation. Done well, it de-risks a large purchase for a modest cost. Done badly, it becomes an unmanaged mini-implementation that proves nothing and consumes a quarter.
Decide what question it answers
A PoC should test the two or three things you genuinely cannot determine from a demonstration:
- Will the optimisation engine produce better plans than our current process, on our data?
- Will the driver app work in our coverage conditions with our drivers?
- Can this integrate with our ERP within acceptable effort?
- Will our planners actually use it?
Write the questions down. A PoC without explicit questions becomes a general product trial that everyone interprets differently at the end.
Measure your current performance on the same routes for the four weeks before the PoC. Without it, "the plans looked good" is the strongest conclusion available, and it will not survive a finance review.
Define success before you start
Quantified criteria, agreed with the vendor and internally:
| Question | Success criterion |
|---|---|
| Plan quality | Route hours within or below our current plan on the same days, at equal or better window compliance |
| App reliability | Zero data loss across the period, including offline stops |
| Usability | Drivers complete a normal stop in three interactions or fewer |
| Planner adoption | Manual edits below 10% of stops by week three |
| Integration | Order feed running end-to-end with automated error handling |
| Support | Issues acknowledged within the agreed response time |
Ambiguous criteria produce ambiguous conclusions, and ambiguous conclusions default to whoever argues hardest.
Scope
Small enough to control, large enough to be real.
- One depot, or two contrasting ones if geography varies materially
- Four to eight routes covering your different route types
- Four to six weeks: two to configure and learn, two to four to measure
- Real orders, real drivers, real customers
Include your hardest routes. A PoC on your easiest territory proves that the product works on your easiest territory.
Commercial terms
- Fixed price, ideally free or nominal, with any fee creditable against a purchase
- No obligation to proceed, stated explicitly
- Data deletion at the end if you do not proceed
- Defined vendor effort — how many days of their time are included
- Production pricing agreed in advance. Negotiate the full price before the PoC, while you still have alternatives. Vendors know your leverage falls once your data is in their system.
Running it
Week 0. Baseline measurement. Data extracted and cleaned. Success criteria signed.
Weeks 1–2. Configuration, integration, training. Expect friction; this is where you learn the real implementation effort.
Weeks 3–6. Live operation with weekly review against criteria. Log every issue, its resolution time and the vendor's responsiveness — you are evaluating the vendor as much as the product.
Week 7. Evaluation, written up against the criteria, with a recommendation.
The traps
Scope creep. "While we're here, let's also try…" Every addition dilutes the measurement and extends the timeline.
Vendor doing all the work. If the vendor's consultant configures everything and operates it daily, you have learned nothing about running it yourself. Insist that your people do the configuration, with support.
No baseline. Covered above, and the most common failure.
Testing the easy case. Include difficult customers, poor coverage areas and peak days.
Becoming production by default. Without a defined end date and a decision point, PoCs drift into unmanaged production use with no contract, no support agreement and no security review.
Ignoring the people signal. If planners and drivers dislike it after four weeks of genuine use, that is data, not resistance. It will not improve at scale.
Evaluating the result
Report against the criteria, plus:
- Actual internal effort consumed versus estimated — the best available predictor of full implementation effort
- Issues raised, resolution times and vendor responsiveness
- What surprised you
- What would need to be different at full scale
- Planner and driver assessment, in their own words
That first line is the most valuable output of the whole exercise. PoC effort scaled up is a far better implementation estimate than any vendor proposal.
Common questions
Should we pay for a proof of concept?
A nominal fee creditable against purchase is reasonable and often improves vendor commitment. Substantial fees for a trial are worth resisting, particularly in a competitive process where alternatives exist.
How long should a PoC run?
Four to six weeks. Shorter periods do not survive the learning curve; longer ones drift into production use and lose their evaluation discipline.
Can we run PoCs with two vendors simultaneously?
It is the most rigorous approach and the most demanding on your people. If you do, use the same depot type, the same period and the same criteria, and be honest with both vendors that a parallel trial is running.
What if the PoC fails?
That is a successful PoC — it prevented an expensive mistake. Document why, and check whether the failure was the product, your data, or the scope. Data problems that surfaced during the PoC will affect any product you choose.
Does a PoC delay the project?
By four to six weeks, against an implementation of several months and a contract of several years. The delay is almost always worth it, and the PoC's configuration work usually carries forward into the implementation.
