Writing a demo script from video research
The demo that converts opens in a moment the prospect recognises, uses their words for it, and finishes one job completely.
The short answer: open on the moment practitioners describe as the worst part of the workflow, in their vocabulary, then complete that one job end to end — pre-empting the two or three objections your research already found — instead of touring features. Ten to eighteen sources is normally enough to build the narrative.
The default demo is an inventory. It walks the navigation left to right, pauses on each area long enough to say what it does, and finishes with settings and integrations. It is easy to build because the product already provides the outline, and it converts poorly for exactly that reason: the outline belongs to the software rather than to the buyer.
The opening scene is a research finding
Attention in a demo is decided in the first twenty seconds, and the only reliable way to hold it is to start somewhere the viewer already lives. Public practitioner content hands you that place directly: across a corpus, people repeatedly name the moment the job gets painful, and they name it with unusual specificity because they are describing something they did last week.
What you want is the sharpest recurring version of that moment. Not the category-level problem, which everyone claims to solve, but the concrete scene — the export that has to be redone, the second screen opened to cross-check, the message sent to ask whether something was already approved. Opening there converts because recognition happens before persuasion has to.
| Beat | Source in the research | What it must accomplish |
|---|---|---|
| Opening scene | Most-repeated painful moment | Recognition in under twenty seconds |
| Naming the job | Practitioner vocabulary for the workflow | Sounding like an insider, not a vendor |
| First relief | The workaround people currently invent | Showing the shortcut they wish existed |
| Completion | Where the workflow actually ends | Finishing one job, not sampling four |
| Objection pre-empt | Recurring public objections | Answering before it is asked |
| Handoff | Who receives the output downstream | Proving it fits their real chain |
Borrow the vocabulary exactly
Every market has words it uses for its own work, and those words are rarely the ones on the vendor’s navigation. Practitioners talk about the close, the pull, the packet, the run, the handoff; the software calls them records, entities and workflows. A demo narrated in software vocabulary makes the prospect do translation work throughout.
Lifting the market’s terms into the script is close to free and does more for credibility than any amount of polish. It is the same mechanic as turning research into landing-page copy, applied to speech rather than to a page, and it depends on the same source discipline: the phrase has to come from the corpus, not from a paraphrase of it.
If practitioners consistently call something a hack, a mess or a nightmare, use their word for it once, early. Sanitising the language into vendor-neutral phrasing is the fastest way to sound like someone who has read about the job rather than watched it being done.
Finish one job rather than sampling four
The strongest structural choice available is to complete a single workflow from trigger to output. Coverage feels safer — it shows breadth, it reassures the team that nothing was left out — and it is consistently less persuasive, because a prospect evaluating whether a tool can replace a process needs to see the process end.
Research tells you where the end actually is, and it is usually further downstream than the product team assumes. The job often does not finish when the record is saved; it finishes when someone else has accepted it, or when a number matches, or when a report leaves the building. Showing that handoff is what converts a feature demonstration into a workflow replacement, and it draws on the same map as designing onboarding from where people stall.
Realistic data is a research artefact
Demo data quietly carries a lot of signal. Records named the way the market names them, at the volumes it actually deals with, with the messy edge cases it complains about, tells a prospect you have seen the job. Twelve tidy fictional rows tells them you have not.
Public content supplies this: screen recordings show naming conventions, list lengths, and the specific irregularities practitioners keep having to handle. Building the demo dataset from those observations costs an afternoon and defuses a common silent objection — that the product looks good on toy data and will fall over on real data.
- ✗Opens on the dashboard
- ✗Follows the product navigation
- ✗Samples four areas, completes none
- ✗Clean fictional data, no edge cases
- ✓Opens on the recurring painful moment
- ✓Follows the practitioner's workflow order
- ✓Completes one job through to handoff
- ✓Data shaped like the real thing
Pre-empt the objections research already found
Objections that recur in public content are not risks to be managed — they are known questions the prospect is already holding, and raising them yourself is the cheapest credibility available. Two or three is the right number; more starts to sound anxious.
Place each one where it naturally arises rather than at the end. When the demo reaches the step where people usually ask about migration, say the migration answer there. The catalogue of which objections matter comes straight out of finding buyer objections in creator content, and the ones about leaving an existing tool are usually the heaviest — the reasons are set out in switching costs and why people stay.
One script per segment, not one per product
The same product shown to two segments needs two opening scenes, because the painful moment differs. An operations lead and a specialist doing the work daily are not moved by the same beat, and a single averaged demo under-serves both.
The efficient version is a shared spine — the completed workflow — with segment-specific opening, vocabulary and objection set. That segmentation is only cheap if the ICP work has been done first, which is the argument in defining your ICP from video research, and it pays off again in the qualification questions from the customer-interview script.
Test the script against the corpus, not the team
Internal review pulls a demo toward completeness: someone will want the reporting shown, someone else the permissions model. The useful check is different — take the script back to the research and ask whether every beat corresponds to something a practitioner actually said mattered.
Beats that cannot be traced to a source are candidates for cutting, and the demo gets shorter and better every time you run that pass. The same traceability rule keeps roadmaps honest, as in prioritising features with research evidence, and it is what makes the demo re-derivable when the market moves rather than a fixed script that slowly ages.
What the pass costs
A demo narrative for one segment normally takes ten to eighteen sources, weighted toward screen recordings and day-in-the-life content rather than overviews. As of September 2026 that fits the Hobby plan at $19 a month with 25 videos and 2 projects; Pro at $59 covers 80 videos and 8 projects if you are building scripts for several segments, and Studio at $199 covers 250 videos, 20 projects and 3 seats. Every plan starts with a 7-day free trial — see the pricing page.
Turn screen recordings and day-in-the-life content into a beat-by-beat narrative with the source moment attached to every claim. 7-day free trial.
Closing thought
The best demos are not the ones that show the most. They are the ones where the prospect stops watching a product and starts watching their own Thursday afternoon get shorter.
Frequently asked
Why does a feature-tour demo convert badly?
Because it is organised around your product structure rather than the prospect's day. A tour asks the viewer to translate every screen into their own situation, and most stop translating after the second one. A demo built from research opens inside a moment they recognise.
Where does the opening scene come from?
From the moment practitioners describe as the worst part of the workflow, in their words. Research gives you that moment with its vocabulary intact, which means the first fifteen seconds of the demo sound like the prospect's own description of their problem rather than your category pitch.
How long should a demo be?
Long enough to complete one workflow end to end and no longer. A single completed job is more persuasive than four partial capabilities, because completion is what the prospect is actually buying and partial coverage reads as a product that stops halfway.
Should the demo use realistic data?
Yes, and the realism should come from research rather than imagination. Sample records that match the naming conventions, volumes and messiness practitioners actually work with signal that you understand the job; a clean fictional dataset signals that you have never seen one.
How do I handle objections inside the demo?
Pre-empt the top two or three by name at the moment they naturally arise, rather than waiting for questions. Objections that surface repeatedly in public content are the ones the prospect is already holding, and answering them unprompted reads as candour rather than defensiveness.
Is this different from a sales script?
The demo script is the narrative and sequence of what you show; a sales script covers discovery, qualification and close. They share the same research, but the demo has one job: making the prospect see their own workflow finish.
What does the research behind a demo cost?
As of September 2026, Hobby is $19 a month for 25 videos and 2 projects, Pro is $59 for 80 videos and 8 projects, and Studio is $199 for 250 videos, 20 projects and 3 seats, all with a 7-day free trial. A demo narrative for one segment usually needs ten to eighteen sources.