Every software demo you will ever see has been rehearsed. The data is clean, the workflow is the flattering one, the record saves on the first try. None of that is dishonest — it's a demo. But watched passively, it tells you almost nothing about how the system will behave in your office on a Tuesday. Your job in a demo isn't to watch. It's to steer — off the happy path.
Eight Things to Make Them Show You
Bring a list and work through it. Ask the vendor to show — live, on screen, not described:
- A duplicate record. Enter 123 Main St and 123 Main Street as two properties, then ask how the utility clerk would ever find out. When she does find out, merge them — without losing the three years of test history attached to the wrong one.
- A rejected submission. A test report from a tester whose certification expired last month. Does the system notice the expiration date, or does the report sail through and turn the assembly green? If it's caught, what does the tester see, and what's the resubmittal path?
- An inactive asset. A property goes vacant and the RPZ comes out during a remodel. Mark it inactive. Does it still get next year's test-due notice by certified mail? Does it still drag down your compliance rate?
- A bad address. Type a service address the county assessor has never heard of. Does the system stop you, warn you, or accept it silently and let the returned mail tell you in six weeks?
- Missing data. Save an assembly with no serial number and no test due date. Can the record exist? Where does it surface, and who works the queue of half-records — or is there no queue, just records that quietly never come due?
- Permissions. Log in as the billing clerk, read-only, right now. Try to change a test date. Then show who granted that permission and when.
- Audit history. Open the record you just mangled and read its history out loud. Does it say why the due date moved, or just that someone moved it at 2:14 p.m.?
- Reporting. Build one of your reports on the spot — assemblies overdue more than ninety days, grouped by pressure zone. Yours, not the canned one with their sample data in it.
Read the Response, Not Just the Screen
How the vendor handles each request is data of its own:
- Shown immediately, without flinching — the system handles it, and they've been asked before
- That's configurable — possibly true; ask to see the configuration, today
- We'd handle that in implementation — a future promise priced as a present feature
- That almost never comes up — it comes up weekly; the vendor doesn't know your work
This is also where your RFP language gets tested. If the proposal claimed the system handles exceptions, don't let exceptions be described in a demo. Make one appear on screen, with the audit trail visible behind it.
Send the List Ahead
Send all eight to vendors in advance. This isn't about ambushing anyone — a vendor who handles every case with notice still proves the system can do it. A vendor who can't handle them with two weeks' notice has answered your question early, cheaply, and in writing.
A rehearsed demo evaluates the vendor's presentation skills. A steered demo evaluates the product. Eight requests, one afternoon — and a decision made on evidence instead of choreography.