Most demo scripts fail because they are written as a tour: open the app, go left to right, explain each area. That produces a demo the length of your navigation bar.
The three structures below start from the buyer's question instead. Each is short enough to adapt in an afternoon and specific enough to actually follow under pressure.
Script 1: problem-led, 12 minutes
- 0:00 -- Name the problem back to them. "You said month-end close takes four days and most of it is chasing approvals." One sentence, using their words. No agenda slide.
- 0:30 -- Show the end state first. The finished, approved, closed month. Start at the outcome so everything after has a destination.
- 2:00 -- Walk the path to it. Three steps maximum. Narrate decisions, not clicks -- "I approve this one and reject that one", never "now I click the green button".
- 8:00 -- Break something on purpose. Show a rejection, a missing field, an error. Credibility comes from the unhappy path.
- 10:00 -- Stop and ask. "Where does this differ from how you do it now?" The answer is your next demo, and often the real objection.
Script 2: discovery-led, 20 minutes
Use this when you genuinely do not know their situation yet. The first eight minutes are questions, and the demo is assembled live from the answers -- which only works if you have a library of short flows to pull from.
The structural rule is that you do not open the product until you can name the specific outcome you are about to show. If you cannot, keep asking. A demo that begins before that point becomes a tour by default.
- 0:00 -- Three questions. What does this process look like today, what does it cost you, what have you already tried.
- 8:00 -- Say what you are about to show and why. "Based on that, the part worth seeing is X."
- 9:00 -- One flow, completely. Resist adding a second.
- 16:00 -- Their data, or the closest thing to it. Even a renamed record moves this from generic to plausible.
- 18:00 -- Agree the next step out loud. Not "I will send something over".
Script 3: short-form, 90 seconds, no human
This is the self-serve version, for a homepage or an email. There is no discovery and no adaptation, so it has to pick the single most common problem and address only that.
Written as captions rather than narration, because most viewers have sound off. Each caption is one short line, in the imperative, describing what is happening -- not what the feature is called.
- Step 1. The problem visible on screen. A cluttered inbox, an overdue list, a blank report.
- Steps 2-4. The three actions that fix it. One caption each.
- Step 5. The result, with a number on it if you have one.
- End. One next step. A trial link, not "learn more".
Lines worth keeping
- "Stop me when this stops matching how you work." Converts a monologue into a conversation and surfaces objections early.
- "That is the whole flow." Signals completeness. Buyers routinely assume there is more and worse to come.
- "This part is genuinely manual today." Volunteering a limitation buys more credibility than it costs, and it will come out anyway.
What to cut from every script
Cut the company history, the logo slide, the org chart, and the sentence beginning "as you can see". Cut any feature nobody asked about. Cut the settings page unless configuration is the objection.
A useful test: read the script and mark every line that would still matter if the buyer had five minutes total. What is left is usually the real demo, and it is usually about a third of what was written.
Frequently asked questions
- How do you write a sales demo script?
- Start from the buyer's problem rather than your navigation bar. Name the problem in their words, show the end state first, walk three steps to it, show an error or rejection for credibility, then stop and ask where it differs from how they work today. Anything that would not matter if the buyer had five minutes should be cut.
- How long should a sales demo be?
- About 12 minutes for a problem-led demo where you already know their situation, 20 for a discovery-led one, and 90 seconds for a self-serve version on a website or in an email. Length is usually a symptom: demos run long when they cover features rather than one outcome.
- Should you show errors during a sales demo?
- Yes, deliberately. Showing a rejection, a validation failure or a missing field earns more credibility than a flawless happy path, because experienced buyers assume the happy path was staged. Volunteering a real limitation costs less than having it discovered later.
This is what Demorta does
Click through it — the same kind of demo you can record of your own product.
Try it on your own product
Record your first interactive demo free.
Five demos on the free plan, forever. No credit card, no trial countdown, no sales call. Install the Chrome extension, click through your product once, and you have a shareable link in about ten minutes.
Start free →