6 November 2026Petr Kubíček 8 min

Product Demo Script: Template and Examples for SaaS

A product demo script is a written plan for what you will say and show in a demo, in what order, and what you want the buyer to do at the end. It is not a word-for-word speech. It is a structure that keeps you on the buyer’s problem instead of drifting through the menu of features. This article gives you the five parts every good script contains, a copyable 15-minute template, a worked example for a fictional SaaS product, the differences between a live and a self-serve demo, and the mistakes that most often sink a demo.

What a good product demo script contains

Almost every demo that works follows the same five-part arc. The details change with the product and the buyer, but the order rarely does.

Hook. One or two sentences that show you understand why the buyer is here. It restates their situation, not your company history.
Problem. The specific pain, in the buyer’s words, and what it costs them today: time, errors, lost deals.
Solution. The shortest path through the product that removes that pain. Three to five steps, not a feature tour.
Proof. Evidence that it works: a result, a customer in a similar situation, a number you can stand behind. If you have no proof yet, say so and offer a pilot instead of inventing it.
Call to action. A single, concrete next step with a date or a link: a trial, a technical call, a pilot, a quote.

The script is built backwards from the call to action. If you cannot say in one sentence what the buyer should do after the demo, no amount of polish in the middle will rescue it.

A 15-minute product demo script template

Copy this structure and replace the bracketed parts. The timings assume a live demo with a buyer who has already shown interest; shorten the discovery step if you already know their situation.

0:00–2:00 · Opening and agenda. “Thanks for making time. You mentioned [pain] — I will show you how [product] handles that, then we will agree on a next step. Is that still the right focus?”
2:00–5:00 · Discovery. Ask two or three questions: “How do you handle [process] today?”, “What does it cost you when it goes wrong?”, “Who else is involved in the decision?” Write the answers down; you will repeat them in the next step.
5:00–11:00 · Solution walkthrough. Start from the result, then show how to get there: “Here is the [report/outcome] you need. This is how it is produced.” Show three to five steps that map to the pain from discovery. Use the buyer’s own words for every label.
11:00–13:00 · Proof. “A team like yours, [customer type], used this to [result].” Only use results you can document.
13:00–15:00 · Objections and call to action. “What questions or concerns do you have?” Answer the top one, then ask: “Would a [trial / pilot / technical call] by [date] be a sensible next step?”

Print the template or keep it on a second screen. A script is a safety net, not something to read aloud.

Live demo script vs self-serve demo script

The five parts stay the same, but the medium changes what you can control.

Element	Live demo	Self-serve demo
Discovery	Asked out loud, answers shape the demo	Replaced by a short choice at the start (“What do you want to achieve?”) or by questions the buyer asks
Pacing	You read the room and adjust	The buyer sets the pace; each step must make sense on its own
Objections	Handled in the moment	Must be anticipated in the script or answered by an assistant
Call to action	Agreed in conversation	A visible button at every stage, not only at the end
Length	15–30 minutes	Short modules of 1–3 minutes

If you write a script for a self-serve demo, keep each module independent and give it one outcome. For the full picture of formats and measurement, see our guide to the self-serve product demo. An AI presenter such as Sales Robots’ Prezentér takes this one step further: it uses the same script logic (problem, solution, proof, next step) but responds to the buyer’s questions in real time and records what they cared about, so the discovery step is not lost when nobody from your team is in the room.

Example: a demo script for a SaaS product

The product below is fictional and used only to show how the template fills in. Imagine “RouteLedger”, expense software for a 40-person logistics company whose finance lead complains about month-end reconciliation.

Hook. “You said month-end close takes your team about a week because receipts arrive late and do not match the card statements. I will show you how RouteLedger removes the matching step.”

Problem. “Today each driver emails receipts, someone types them in, and finance matches them to the statement by hand. When they do not match, you chase people.”

Solution, in four steps. (1) A driver photographs a receipt in the mobile app. (2) The amount, date and supplier are read automatically. (3) The receipt is matched to the card transaction. (4) Finance sees only the exceptions. “Notice that finance never opens the ones that match. That is where the week goes.”

Proof. “A transport company of similar size cut its close from five days to two.” Replace this with a real, documented result — if you do not have one, offer a two-week pilot on one team instead.

Call to action. “Would it make sense to run a pilot with your two busiest depots next month? I can send the setup checklist today.”

Notice what the script leaves out: the settings screen, the admin roles, the integrations list. They exist, but they do not serve the buyer’s stated pain, so they wait for the technical call.

Common mistakes in demo scripts

Too many features. A tour of everything shows breadth and hides value. Pick the three features that solve the pain from discovery.
No proof. Claims without evidence read as marketing. One real customer result or a pilot offer is stronger than ten adjectives.
No call to action. The demo ends with “any questions?” and the buyer drifts away. Always propose one dated next step.
Starting with your company. Five minutes of history before the problem loses the buyer. Open with their situation.
Scripting the words, not the structure. Reading a script sounds robotic. Script the order and the key sentences; improvise the rest.
Skipping discovery. A demo that is not tied to the buyer’s answers is a generic presentation.

For a broader overview of demo types and when to use each, read our product demo guide. If you are turning a script into an online experience, the step-by-step plan in how to create an online product demo covers format, content and testing.

FAQ

What is a product demo script?

A product demo script is a written plan for a demo: the order of topics, the key sentences, what to show at each step and the next step you will ask the buyer to take. It is a structure to follow, not a speech to read aloud.

How long should a product demo be?

A live demo for an interested buyer usually works in 15 to 30 minutes, including discovery and questions. A self-serve demo works better as short modules of one to three minutes, so each visitor can stop at the point where they have what they need.

What should a product demo script include?

Five parts: a hook that shows you understand the buyer’s situation, the problem and its cost, the shortest path through the product that solves it, proof that it works, and one concrete call to action.

How is a self-serve demo script different from a live one?

In a live demo you ask questions and adjust on the spot. In a self-serve demo the buyer is alone, so each step must make sense by itself, objections must be answered in advance or by an assistant, and the call to action should be visible throughout instead of only at the end.

Should I follow the script word for word?

No. Script the structure, the key sentences and the call to action, and improvise the rest. Reading word for word sounds rehearsed and prevents you from responding to what the buyer says.

Want a demo prospects run themselves?

Prezentér is an interactive product demo — it walks prospects through, answers questions by voice or text, and hands you a qualified lead. No waiting for a meeting.

Discover Prezentér