A vendor demo is a rehearsed performance on curated data. It is designed to show the product's strengths and route around its weaknesses, and it does that job extremely well. The only way to learn anything is to take control of the script.
Take control of the format
Send this to every vendor, at least a week ahead:
We will run a two-hour session. We will provide sample data in advance. We would like you to work through the scenarios below, live, in the product. Please do not present slides. We will ask questions during the session and expect to drive the interface ourselves for part of it.
Vendors who resist this are telling you something useful before the session starts.
Ask for the keyboard. Attempt three ordinary tasks yourself with no coaching: add a stop, move a stop between routes, and find yesterday's route for one vehicle.
Provide your own data
Anonymised, but real:
- 200–500 of your actual stops with real addresses, volumes and time windows
- Your real vehicle list with genuine capacities and restrictions
- Your real service times, including the awkward customers
- Two or three genuinely difficult customers with unusual constraints
Curated demo data hides everything. Your data reveals whether the geocoder handles your addresses, whether the constraint model expresses your reality, and whether the plan looks like something a planner would accept.
The scenarios
Adapt these to your operation and time-box each one.
1. Build a plan (20 minutes). Import our data, configure the constraints, run the optimisation. We want to see the whole sequence, including the configuration screens — not a pre-built plan.
Watch for: how long configuration takes, how many settings are involved, whether the plan looks sensible to your planner, and how the vendor reacts when something does not work.
2. Break it (10 minutes). Add a customer with an impossible constraint. Does the system explain the infeasibility, or silently drop the stop?
3. Manual intervention (10 minutes). Pin two stops to a specific driver. Move a stop from route 3 to route 7. Re-optimise around the pins. Does the plan respect them, and what does it show you about the cost of the change?
4. Compare scenarios (10 minutes). Run the same data with a different objective — minimise vehicles instead of distance. Show both plans side by side with cost, distance, hours and vehicle count.
5. Dispatch and disruption (15 minutes). Publish the plan. Now a vehicle breaks down at 11:00 with 18 stops remaining. Reassign the work. Show what the affected customers are told.
6. The driver app, on a device (20 minutes). In aeroplane mode: complete a normal stop, then an awkward one with a partial delivery and a damaged item. Force-close the app. Reopen. Restart the device. Restore connectivity and show the sync result. Count the taps.
7. Reporting (10 minutes). Show yesterday's plan versus actual. Then build a report we have not asked for in advance, live.
8. Administration (10 minutes). Add a new vehicle. Add a new user with access to one depot only. Change a customer's service time. All without vendor assistance.
9. Integration (10 minutes). Show the API documentation. Show a webhook firing. Show the export of a full data set.
10. Questions (15 minutes). Including the ones from our vendor questions list.
What to watch for
| Signal | Interpretation |
|---|---|
| "We'd normally configure that beforehand" | Configuration is harder than presented |
| "That's on the roadmap" | It does not exist; score it zero |
| The presenter avoids a screen | Something there is weak |
| Frequent switching between modules | The workflow is fragmented |
| Any pre-recorded video | Live behaviour differs |
| "That would be a professional services item" | Recurring cost you have not budgeted |
| Genuine acknowledgement of a weakness | A trustworthy vendor |
That last row deserves weight. A vendor who says "we're not the strongest at that, here is how our customers handle it" is far more likely to be a good partner than one who claims every capability.
Who should attend
- A planner who will use the system daily — the most important attendee
- A driver, for the mobile app section — the second most important, and the one usually missing
- An operations manager
- Someone technical for the integration section
- The project lead
Not: a large audience of stakeholders. Six people who will score the product beat fifteen who will watch it.
Score immediately
Debrief within thirty minutes of the session ending, before impressions blur. Score against your weighted checklist while the evidence is fresh, and record what you saw alongside each score. Scores recorded a week later are recollections of the presenter's confidence rather than of the product.
Frequently asked questions
How long should a demo be?
Two hours for a first session, with a second, deeper session for the shortlist. Longer sessions lose the audience; shorter ones cannot cover the driver app and integration properly, which are exactly the areas that matter.
Should we let vendors demo whatever they want?
Give them fifteen minutes at the start to show what they consider distinctive, then run your script. That short window occasionally surfaces something genuinely useful you had not thought to ask about.
What if the vendor cannot use our data?
Ask why. Sometimes it is a legitimate technical constraint requiring a longer setup; often it is that their demo environment cannot handle real address quality. Either way, insist on a proof of concept with your data before committing.
Should drivers really attend?
Yes. The driver app is where most of the daily value is captured or lost, and drivers spot usability problems that office staff cannot see. Their scores on the mobile section should carry real weight.
How many vendors should we demo?
Two or three. Beyond that, evaluation quality falls, sessions blur together and scoring becomes unreliable regardless of how disciplined your process is.
