In this guide 6 sections
Replace the polished tour with scenarios you bring on paper. Pick the three messiest events from last month, give them to the vendor a day ahead and watch each one run live. A good run needs few clicks and no apology. A weak run needs a promise.
Why the standard demo hides the problem
The usual demo runs on clean data. One customer books, pays in full, is served on time and leaves happy, and every screen the vendor opens was set up that morning to make that story work.
Your business is not that tidy. Money problems and angry phone calls come from the exceptions, a deposit taken twice or a visit nobody logged, so build the demo from those.
Pick three scenarios from last month
Open last month’s records. Find the three jobs that cost staff the most time, and write each as a half-page story, saying what happened, in what order and what the customer expected.
Spread them across the business: one money case, one scheduling case and one repeat-business case make a fair set, and the vendor gets a full day to prepare. Nobody can claim surprise.
- Money: a part payment later refunded in cash and by transfer
- Schedule: a booking moved twice, with the technician changed the second time
- Renewal: an AMC renewed three weeks after the contract lapsed
- Admission: a student who joins mid-term and shifts section
What a good run looks like
Take a pest control example. A customer paid half up front for a quarterly treatment contract, the company missed the first visit, and the customer asked for the advance back. A good run records the refund against that contract, ties it to the original receipt, keeps the visit history intact and shows the remaining balance in one place.
Watch the clicks. If the vendor opens four screens, reaches for a calculator and apologises twice, the product was never built for this situation, whatever the brochure says. One action, one reason code.
Then ask what the owner sees next morning. A good product lists the refund on the dues report, with the contract number and the reason code beside it, and nobody opens a spreadsheet to get there.
What a weak run looks like
Weak runs sound alike. That needs a small customisation. Most customers handle it in Excel. The next release covers it.
None of these is a failure on its own, but each one carries a cost, so note it in a column: free, configurable, custom work or not possible. A chit fund foreman who needs a lapsed member’s prize re-auctioned, with the surety released and the dividend recalculated, will hear one of the four.
Beware of screens built overnight. Ask whether it runs in the live product, or only in a test copy built for your visit and removed the day after.
- Answers that start with a promise about a later release
- Workarounds that rely on the notes field
- Demos shown only on a prepared dataset
- Any step the vendor skips by saying they will cover it later
Score it with your staff in the room
Bring the daily user, not only the owner. A school office clerk or a clinic receptionist, who has keyed fifty admissions before lunch, spots a clumsy screen faster than anyone else in the building.
Fill in the sheet straight after each vendor, while the memory is fresh. Add up totals only when every demo is done. Then ask the front runner to repeat its weakest case on a copy of your own data, with your own staff at the keyboard this time.
Messy day demo sheet
A single sheet with three scenario boxes. Each box holds a short story, the expected result and the steps you want to see. Beside it sit a click count, a rating of free, configurable, custom or not possible, and a line for who attended and what they noticed.
Open a blank worksheet to printQuestions owners ask
Will vendors agree to run my scenarios?
Serious ones do. A vendor who refuses to run a real case before you buy is telling you plainly what support will feel like later.
How long should a scenario demo take?
Ninety minutes covers three scenarios. If a vendor needs far longer to walk through just one of them, the product is probably clumsy for that task, and your staff will feel it daily.
Should I share real customer data?
No. Strip out names, phone numbers and addresses, and keep only the sequence of events, because the vendor needs the shape of the case and not the person behind it.
What if every vendor fails one scenario?
Then the scenario may be rare. Or your process may need a change. Decide whether the task is worth keeping, and whether paying for custom work to support it is justified.