Demo template: Critique of previous version
Reference: The “record analysis” style demo (Description, Tags, Demo Link, How to Use, Key Features, Workflow).
Use: Inform the revised demo template structure.
What worked well
- Demo Link — Essential. Always have a single, stable URL so anyone can run or share the demo.
- How to Use — Concrete steps (click X, then Y) so a new presenter can run it without guessing.
- Key Features — Short list of capabilities; good for scanning and for Notion/cards.
- Workflow — Numbered flow (1 → 2 → 3) gives a clear run order and story.
- Tags — Helpful for filtering in Notion (vertical, tech, use case). Keep as optional metadata.
- Description — One paragraph that says what the demo does; good for tooltips and search.
Gaps and issues
1. No “when to use” or audience
The template doesn’t say who this demo is for or when to use it (discovery vs. technical vs. campaign). So:
- Sales doesn’t know which lead gets which demo.
- Multiple demos for the same service can overlap or get used randomly.
Fix: Add Demo type (discovery / deep-dive / campaign) and Audience (role + optional vertical).
2. Key Features are labels only
“Smart Patient Analysis”, “Automated Action Detection” are feature names. They don’t tell the presenter what to say or what the prospect should notice. In a live call, that leaves it to the presenter to ad-lib.
Fix: For each key feature, add a one-line what to show/say (or “so what” for the prospect).
3. How to Use vs. Workflow overlap
- How to Use = click-by-click (operational).
- Workflow = conceptual steps (story).
Both are useful but overlap. Without clear labels, it’s easy to duplicate content or confuse “what I do” vs. “what I say.”
Fix: Keep both; label clearly:
- How to run it = steps for the presenter (clicks, tabs, order).
- Workflow / story flow = narrative for the prospect (what we’re showing and why, in order).
4. No goal or CTA
There’s no one takeaway or next step. So the demo can end without a clear “so what?” or “what happens next?”
Fix: Add Takeaway (one thing they should remember) and CTA (e.g. “Schedule audit” or “Send proposal”).
5. No proof or metrics to call out
Nothing tells the presenter which metric or case to mention. That makes demos inconsistent and underuses proof.
Fix: Add Proof to reference (metric, case name, or one line to say).
6. No link to service/offer
In a three-DB system (Offers, Service Catalog, Demos), a demo should tie back to the service line and Offer. Otherwise you can’t filter “all demos for Edge-to-Activation” or ensure the demo matches the offer.
Fix: Add Service / Offer link (or property in Notion).
7. Description is product-focused
The description explains what the system does, not what the prospect will see and why it matters. For a presenter, “what they’ll take away” is more useful than a feature list.
Fix: Keep a short Description for search/tooltips; add Takeaway (one sentence for the prospect).
8. Tags are ad hoc
Tags like “analysis”, “patient records”, “AI” are useful but unstructured. Over time you get inconsistent tags across demos.
Fix: Keep Tags; optionally standardize (e.g. Service, Vertical, Tech) in the README or Notion schema.
Summary
| Element | Keep? | Change |
|---|---|---|
| Description | Yes | Add a one-line Takeaway for the prospect. |
| Tags | Yes | Optional; consider standard categories. |
| Demo Link | Yes | Required. |
| How to Use | Yes | Rename to How to run it (presenter steps). |
| Key Features | Yes | Add what to show/say per feature. |
| Workflow | Yes | Treat as story flow for the prospect; keep numbered. |
| Demo type / Audience | Add | When to use, who it’s for. |
| Goal / CTA | Add | One takeaway, next step. |
| Proof to reference | Add | Metric, case, or line to say. |
| Service / Offer link | Add | Which service and offer this demo supports. |
Next: apply this in demo-template.md as the single recommended structure.