Demo video script: a simple framework you can fill in tonight

Most demo video scripts fail for the same reason. They were written before anyone pressed record, by someone imagining the screen. The narrator then reads a paragraph about the feature while the cursor is still on the login page, and the viewer spends the first minute waiting for something to happen. The fix is to write the script around what the viewer sees at each second, and only then decide what to say about it.

This is a framework for doing that. It’s a cue sheet more than a screenplay, and it’s short enough to fill in during an evening.

Why a demo video script needs its own shape

A demo competes with the viewer’s own goals. They’re evaluating, which means they’re asking questions the whole time, and most of those questions are simple. What is this? Does it fit the problem I have? How hard would it be to start? What would I lose without it? A good script answers those questions in roughly the order they arise, and it does so by showing rather than telling.

A tutorial is different. Its viewer already wants to do the task, so the script can afford to be instructional. A demo’s viewer is still deciding whether to care. Writing a demo as if it were a tutorial, with a full tour and a recitation of every feature, is the most common way they go wrong.

A cue sheet, not a screenplay

The format I’d use is a table with one row per beat of the video. Each row holds three things: the time range, what’s on screen, and what’s said. The table makes the relationship between narration and screen visible, which a paragraph hides.

A beat is a unit of the video with one job. The five beats below cover most product demos, and each one can be as short as a few seconds.

1. Result. Show the finished outcome in the first eight seconds. The viewer sees the destination before they’re asked to travel.
2. Stake. Name the problem in the viewer’s words, in one sentence, with one concrete example. This is where you earn the next minute.
3. Path. Walk through the flow, one outcome, in the order the viewer would do it. This is most of the video.
4. Proof. Show a moment that makes the result believable: a number updating, a message arriving, a file opening. It’s the part a skeptical viewer is waiting for.
5. Next step. Tell the viewer the single thing to do now, and where to do it.

Here’s a budget for a ninety-second demo. The table gives the words per beat, which at a calm explainer pace of roughly 130 to 150 words per minute works out to about 200 words in total.

The path gets the most time and the most words, which is correct, because it’s the only beat with real new information. The other four frame it.

The stake beat, in the viewer’s words

The stake beat is where most scripts quietly go wrong, because the writer describes the problem the way the company thinks about it. “Onboarding friction in the approvals workflow” is a phrase from a planning document. A buyer would say “new hires keep asking me where the approvals are.” The stake should sound like the second version.

The fastest way to find the viewer’s words is to listen to where they already talk. Pull the subject lines from support tickets, read a few sales call notes, and look at the questions people type into search. A few rewrites show the difference.

Once you have the viewer’s sentence, the stake beat needs one concrete example and nothing more. A single moment the viewer recognizes, like a Friday status update that takes an hour, does more than a paragraph describing the category. Keep it under twenty seconds, then move to the path, where the product comes in.

Scripting for a sixty-second or five-minute demo

The five-part shape scales, but the budget moves. A sixty-second demo has little room for a stake beat longer than five seconds, so the result and the stake often merge. The opening shows the finished state, and one line names the problem it solves. The path shrinks to one or two actions, and the proof beat becomes the result itself, since there’s no time for a separate demonstration. The next step is a short line and a link.

A five-minute demo does the opposite. The stake can take thirty seconds, and the path grows into several sub-flows, each with its own small result. The risk at this length is drift, where the viewer loses the thread of why they’re watching. The fix is a one-sentence recap at the end of each sub-flow that restates the outcome, so the viewer always knows where they stand against the stake.

In both cases the word budget follows the same rate. At a calm pace, sixty seconds is roughly 130 to 150 words, and a five-minute script runs to several hundred words more than most writers expect. Check the total before you record. A script that runs long tends to get cut in a hurry during the edit, and the cuts usually land in the wrong places.

Write to the screen, not the feature list

The most useful habit in demo scripting is to describe what the viewer will see, not what the product can do. A feature list sounds impressive on the page and tells the viewer nothing they can picture.

Take a made-up project tool called Quillbook. The feature-list version of a line sounds like this: “Quillbook has smart task boards with custom fields, automations and integrations with your calendar.” It’s accurate and forgettable. The screen-led version describes an action and its result: “Drag this card to Review. The reviewer gets a notification, and the due date moves to tomorrow. That’s the whole handoff.”

The right-hand column is harder to write, because you have to watch the screen while you write it. That’s the point. It forces the script to match what’s actually happening.

The recording order: silent pass, then voice

Most demo scripts go wrong at the timing step, because the timing was guessed. Fix the order of work and the timing takes care of itself.

1. Do the flow silently. Run through every click at the speed you’d narrate, with no talking and no cursor wobble. Keep the clock visible.
2. Note the time of each action. Write down the second each click happens and what the screen shows at that moment. That’s your real timeline.
3. Write the narration against those timestamps. Each spoken line should fit the window between two actions, with a little room for the viewer to register the change.
4. Record the voice in one take per beat. A beat-length take is easier to edit and easier to keep natural than one long take.
5. Cut any line that overruns its window. If a line won’t fit, shorten it or move it to a different action.

A sample script for the path beat

Here’s what a path beat looks like once the timing is set. The left column is what’s on screen, and the right is what’s said. Notice that the narration tells the viewer why each step matters, and the screen shows the step itself.

Four lines, about forty words, and the viewer understands the handoff. The rest of the path beat runs the same way, one action at a time.

Edit for a viewer who is checking your claims

Demo viewers are evaluating, and they’re quick to spot overclaiming. A script that promises everything reads as a sales pitch, and the skeptical viewer discounts it. A single honest limitation, stated plainly, often does more for trust than three extra features.

Put one limitation in the path or the next step. “This doesn’t sync to Gantt charts yet, so if that’s how your team plans, skip to the export example.” That’s one sentence, and it tells the viewer you won’t waste their time. Viewers who are a poor fit leave early, which is what you want, and viewers who are a good fit trust the rest of the demo more.

Check every claim against the plan the viewer will actually be on, and against the region they’re in. A recording outlives the roadmap. A feature shown in a demo that isn’t available to the buyer’s plan turns into the first objection on the next call.

A complete pass, in four steps

Here’s the order I’d follow to fill in the cue sheet in one evening.

1. Write the result beat first, as a single sentence describing the finished state. If you can’t write it, you don’t know what the demo is for.
2. Write the stake beat in the viewer’s words, using the problem they’d describe to a colleague rather than your internal term for it.
3. Do the silent pass and fill in the path beat’s timing from the clock, then write the narration against the actions.
4. Write the proof and next-step beats last, because they depend on what the path actually shows.

Read the whole script aloud once, timing it. If it runs long, cut from the path, not from the result or the next step. Those two beats do most of the persuasion, and they’re the shortest parts of the video.

Four mistakes that sink a demo script

Four mistakes account for most weak demo scripts, and each has a fix you can apply in the edit.

The first is the feature dump: a path beat that lists capabilities without showing a single one. The fix is to convert each sentence into an action and a result, as in the Quillbook example above. If a sentence can’t be turned into something on screen, it probably doesn’t belong in a demo.

The second is the missing proof. The script walks through the flow and ends on the result, but nothing shows the result is real. A number that updates, a sent message that arrives in another window, or a file that opens is worth a few seconds, because a skeptical viewer wants evidence rather than a claim.

The third is the vague next step. “Find out more on our website” gives the viewer nothing to do. A specific action, like starting a trial from a named page or booking a fifteen-minute call with a named role, is easier to act on. Show the link on screen as well as in the narration.

The fourth is the script that was never timed. A narration that sounds fine in your head runs over in practice, and the overrun gets absorbed by the path. Time the full script once, read aloud, and cut from the path, not from the result or the next step.

The fifth mistake is trying to cover too much. A demo with three goals, such as showing reporting, automations and integrations in one pass, tends to deliver none of them well. The viewer gets a fast tour and remembers nothing. If the script wants three outcomes, it wants three demos. Pick the one outcome the viewer came for, and let the others wait for their own video.

Where the production tool comes in

The script is the part of demo production that doesn’t need a tool. The recording does. When you’re ready to capture the flow, record it in your browser with RecordlyPro, which zooms in on each click so the control you’re describing stays large while you narrate. For how to choose a recorder for this kind of work, how to choose a screen recorder for product demos lays out the trade-offs, and how to record a software tutorial people actually finish covers the parallel discipline for tutorials, which shares a lot of its structure with this one.

Keep reading

Playbook

Async video: stop scheduling the meeting you could record

A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.

Sofia Meyer October 6, 20262 min read

Playbook

Auto-zoom in screen recordings: what it is and why your demos need it

A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.

Sofia Meyer October 13, 20262 min read

Playbook

How to choose a screen recorder for product demos in 2026

A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.

Sofia Meyer October 16, 20262 min read

Explainer

Dofollow vs nofollow in 2026: what still passes value

The link attributes changed, Google's treatment changed, and a lot of advice is out of date. Here's what dofollow, nofollow, sponsored and ugc actually do now.

The Recordly Team October 10, 20262 min read