How to write a demo script: four parts, one buyer question

A demo script is a short document that names one buyer question and the handful of product moments that answer it. Four parts do the job: opening context, problem cue, product beat and closing action. This guide covers what goes in each, how to get from discovery notes to an outline, what to say in the first thirty seconds, how to keep the script accurate after a release, and what changes when an AI agent runs the demo instead of you.

What does a demo script need to contain?

Four sections, and no more.

• Opening context. One or two sentences about the buyer's situation. Their problem, their workflow, their friction, not your product.
• Problem cue. The specific moment of pain the demo is meant to fix, in one sentence. If you cannot name it, the demo has no job.
• Product beat. The sequence of product actions that resolves the problem cue. Each beat maps to something real on screen: a state, a click, an output.
• Closing action. What you ask the buyer to do next. One ask, not three.

Keep the whole thing to a page. A script that long takes a few minutes to update after a release, and one that runs to forty slides of narration takes an afternoon, so nobody updates it.

Leave some things out on purpose. A feature inventory gives you more beats that can break later. Internal jargon rarely matches what the buyer sees on screen. Edge cases like "if they ask about X, we can show Y" belong in a separate objection file, not in the main script.

How do you turn discovery notes into a demo script?

Keep only the notes that describe something the buyer said they already feel, and drop the ones that describe something you want them to feel. Call snippets, objection logs and interview notes are useful when they capture the buyer's own words for the problem. Those words become the opening context and the problem cue. Everything else is background.

Then shape what is left into three moves: name the problem, show the solution in action, name the result. "Right now your team handles approvals by hand, which means a day of delay." Then show the moment where the product changes that, without narrating it. Then say what it means: "That is one less chase per request." If a beat does not fit one of those three slots, it does not belong in this version.

Before you outline, write down the single buyer question the demo answers. Not "does this product work?", which is too broad. Something like "can this replace our approval workflow in Slack?" Every beat either moves toward the answer or gets cut.

A worked example. The raw notes say: "slow approvals, too many Slack threads, no audit trail, wants SSO, asked about pricing." The outline becomes four lines. Opening: approvals are slow. Problem cue: a request is buried in a Slack thread. Product beat: the approval flow, with its audit trail. Closing action: a trial with their own workflow. SSO and pricing go in the objection file, ready if they come up.

What should the first thirty seconds of a demo script say?

They should name the friction the buyer already feels, before you mention your company, your category or a dashboard overview. "You are running approvals through Slack threads, which means no audit trail and no way to escalate without a DM chain." That sentence earns the next one.

Then show one specific scene, not a summary of the product: a dashboard in a particular state, a workflow with a particular trigger, an object the buyer recognizes from their own work. One concrete moment gives the buyer something to project onto. Five features mentioned briefly give them nothing to hold.

Make the move from problem to product feel like a direct response. "Here is how that looks in the product" is enough. Skip the setup slide and the architecture preamble, and click to the thing.

How do you tie each beat to what the product actually shows?

Write each beat as a concrete product state, not as a topic. Not "we show the dashboard" but "we show the dashboard with one approval request, three days overdue, assigned to the viewer." That detail is what makes the beat maintainable, because when the product changes you can see which beats it touches.

Four places where a mismatch loses the buyer at once.

• Labels. The script says "click Approve" and the button now says "Submit for review."
• Steps. The script shows three clicks and the flow now takes two.
• Outcomes. The script promises the audit trail "immediately" and there is now a delay.
• Screens. The script mentions a screen that was removed or renamed, and the demo dead-ends.

Take a hypothetical release that renames "Approve" to "Submit for review" and moves it into a side panel. The beat that said "click Approve in the main view" now says "open the side panel and click Submit for review." Because the script names the label, finding that beat takes thirty seconds. In a script that says "approve the request," you would walk the whole demo to find out what broke.

How do you keep a demo script current after a release?

Give it one owner and one habit: after every release, walk the script against the live product and fix what no longer matches. With a one-page script that takes about ten minutes. Put the date of the last walk at the top, so anyone can tell whether the script was checked against what is in production.

Not every release forces an edit. These do.

• A UI label the script names verbatim.
• A flow that gained or lost a step.
• A feature the script uses as proof that now works differently.
• A screen that was removed, renamed or moved.

Color, spacing and icon changes rarely touch the script. The test is whether the change affects what the presenter says or clicks. If it does, update the beat. If not, leave it.

Keep the previous version, named for the release it matched, somewhere visible but out of the way. When someone asks why a beat changed, the old version answers it, and nobody has to ask which version is current.

How do you use one script for founders, sales and technical buyers?

Keep the spine fixed (problem, product beat, result) and change only the opening context, the proof point and the closing action. Three versions cover most cases.

• Founder pitch. Opens on the market problem, proves it with growth or retention, closes on access to the product.
• Technical buyer. Opens on integration pain, proves it with how the data model or API behaves, closes on a sandbox.
• Sales-led walkthrough. Opens on the job the buyer described in discovery, proves it with a customer result, closes on a trial.

Resist adding a version per persona. You end up with twelve scripts nobody maintains. The problem cue, the beat sequence and the result statement should stay identical across presenters, because that is where drift starts. Presenters can put the opening context in their own words.

What changes when an AI agent runs the demo?

You stop writing lines and start writing material, because the order depends on what the visitor says. A script assumes you control the sequence. An agent talks with the visitor, so a founder and an ops manager can ask for different things in the first minute. Three parts of the script carry over, and each maps to one stage of how Inkly works.

• Opening context becomes the qualifying questions. Instead of guessing the buyer's situation in your first line, the agent asks their role, goal and use case before it shows anything.
• Problem cue and product beats become the workflows it leads with. You decide, for each kind of buyer, which beats come first and what proof goes with them. This is the same work as the script, done once per buyer type rather than once per presentation.
• Closing action becomes what the agent offers and when. A meeting, a trial or a handoff, and what sales receives afterward: the questions the visitor asked and what they explored, as buyer intelligence.

What does not carry over is the exact wording. An agent answers in conversation, so the thing to write down is the substance: the buyer question, the beats, the objections you know and what you want to be true when the visitor leaves. The accuracy checks do carry over. An agent shows your product, so a label that drifted still gets shown. The how it works page walks through the three stages, and agentic demos covers what the agent needs to work well.

Where does Inkly fit, and when is a plain script enough?

Inkly is the AI demo agent that turns website visitors into buyers. It qualifies the visitor, guides them through the product live, answers questions in context and hands buyer intelligence to sales. Inkly starts from your existing product materials, key workflows, existing demos and approved messaging, and a guided validation checks that the experience is accurate before it goes live.

Every plan includes the voice and chat demo agent, and plans are priced by active visitors, where one person counts once a month. Free is $0 for 30 visitors. Pro starts at $150 a month ($120 a month billed yearly) for 150 visitors and adds visitor details, tailoring and qualification. Enterprise is custom and adds the clickable product clone, live product streaming and the CLI. The pricing page has the full table.

A script and a good presenter are enough when your deals start on a call with a founder or sales rep, the audience is small and you want the judgment of a person in the room. An agent earns its place when visitors show up on your site at hours you are not on a call and are not ready to book one. It does not remove the work above. It still needs a buyer question, beats worth showing and an owner who keeps the material accurate.

FAQ

What should a demo script include?

Four sections: opening context, problem cue, product beat and closing action. Each should be short enough that a product change touches one or two lines.

How long should a demo script be?

One page. If updating it after a release takes more than about ten minutes, it covers too much, and the usual fix is cutting beats rather than editing faster.

How do I adapt one script for different audiences?

Keep the problem cue, product beats and result fixed. Change the opening context, the proof point and the closing action. Founder, technical buyer and sales-led walkthrough cover most cases.

Do I still need a demo script if an AI agent runs the demo?

You need the thinking, not the wording. The buyer question, the beats that answer it, the objections you know and the next step you want are what the agent works from. A word-for-word script is less useful, because the conversation decides the order.

What should you do this week?

Write one script for one buyer question, on one page, with each beat tied to a named product state. Walk it against the live product and fix every label that moved. Then put the date at the top and the owner's name beside it. If the demo you actually run differs a lot from the script, the script is the part to fix.

Curious how the agent qualifies and guides a visitor? See how Inkly works.