Score the demo by the exception path, not the happy path.
Every click works on the prepared account and the room nods. Two months later the first stuck case has no owner and no way back. Ask the vendor to show you the awkward path during the demo, and write down what you actually saw.
Score a live vendor demo on four operating dimensions—exception path, ownership, recovery, and state visibility—each 0–2 with evidence you can point to in the recording. Pass only when no dimension is zero and at least two are 2. Happy-path theater without those proofs is not a buying decision.
The demo is evidence, or it is a show
A vendor opens the product on a prepared account. Every click works. The order completes. The dashboard is green. The room nods. Two months later the first stuck case has no owner, no way back, and a status that means three different things.
A live demo is useful when it leaves something you can score and reopen when the contract is on the table. Otherwise it is a show that a rehearsed path can finish under ideal conditions.
Four things that survive the meeting
Score each 0, 1, or 2 while you can still point at the recording.
Exception path. Did they show a stuck case from your world, or only the path they prepared? 0 means the awkward case had no home.
Ownership. When work stops, is there a role in the product, or a person who "knows the account"? 0 means ownership is a phone number.
Recovery. Can they show the check before a retry, and the state after a partial write? 0 means recovery is "just re-run it."
State. Can an operator tell what is proposed, waiting, done, or failed without asking the presenter? 0 means green means "we think it is fine."
Pass only when nothing is zero and at least two scores are 2. A beautiful happy path with a zero is not a buying decision. It is a reason to ask for another sitting, with the missing proof written down.
How the work moves
Score the live demo on operating proof
- Exception path
Walk a named awkward case end-to-end; item does not vanish.
- Ownership
Role or assignee model visible when a human must act.
- Recovery
Half-finished state findable; next safe action shown.
- State visibility
Waiting, failed, and complete distinguishable in the record.
A demo that never leaves the happy path has not shown you the product you will operate.
How to sit through it
Bring two real exceptions from your operation, with the names removed. Ask to see those, not the sample company in the demo tenant.
Score during the meeting or immediately after. Attach the sheet to the buying memo. If the result is conditional, the next demo happens only against the written list of what was missing.
Do not pad a score to keep the relationship warm. A conditional with a date is cleaner than a pass that collapses on the first stuck order.
What the sheet catches
Checkout that cannot survive a declined payment or a split shipment. Escalation that is a human, not a role. Recovery that does not check what already wrote. Status that decorates instead of informing.
These are patterns, not a claim about a particular vendor's telemetry. Use them on the demo in front of you.
Decision guide
Demo theater vs demo evidence
| Consideration | Looks impressive | Scores as evidence |
|---|---|---|
| Path shown | Only the prepared happy path. | At least one real exception type walked through. |
| Human needed | “Contact support” on a slide. | Named role or queue visible in product. |
| After a failure | Blind retry promised verbally. | Incomplete state and safe resume demonstrated. |
| Status | Green banners and vibe. | Operator can tell waiting from failed in the record. |
Put this into practice
Copy the four lines onto a page before the next sitting. Bring your two exceptions. Apply the pass rule before anyone says they liked the product.
If the gaps are handoffs, exceptions, and recovery rather than the look of the screen, that scoping sits under business process automation.
Related work: Sutton Place.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.