By Siddharth GangalA demo script is the bridge between what the buyer said in discovery and what the seller chooses to show. It is not a tour of every menu. The artifact below forces each product moment to answer a confirmed buyer question, pauses for a response, and records the branch before the rep moves on.
Direct answer. Build the script around one discovery-backed objective, two or three timed modules, and a show-tell-ask loop. Show one buyer job, tell only the consequence needed to understand it, then ask the buyer to confirm, correct, or branch. Close with a mutual next step that has an outcome, owners, inputs, and date.
This page owns the reusable artifact. For broader preparation and delivery, use how to give a sales demo and the sales demo best-practices guide. The template is an editorial framework, not a promise that a particular sequence increases conversion.
Start the demo script with discovery
Do not open the product until the script can quote the discovery record accurately. Gong reports an observational analysis of 67,149 recorded demos and says winning demos mirrored discovery topics. The company also cautions that its data cannot answer every strategy question. Use that finding as directional support for discovery mapping, not a causal guarantee.
| Script input | Fill before rehearsal | Do not substitute |
|---|---|---|
| Buyer’s current state | Exact paraphrase and source call/date | A generic industry pain |
| Desired state | Observable outcome in buyer language | An unsupported vendor benefit |
| Decision question | What this demo must help the group decide | “See the platform” |
| Attendee jobs | User, manager, technical, security, financial, executive concerns | Titles without responsibilities |
| Required proof | Approved artifact and its scope | An invented result or unapproved customer name |
| Unknowns | Questions to resolve live | Assumptions stated as facts |
Use the sales call prep guide to assemble participants, history, evidence, technical constraints, and open questions. If discovery is too thin to choose a story, run more discovery instead of scripting a generic walkthrough.
Discovery bridge: “In our last conversation, you described [current state] creating [consequence] for [roles]. You wanted to see whether [desired job] could happen while preserving [constraint]. I built today around that question. Before I share, what has changed or what did I miss?”
Use this timed product demo structure
Protect interaction and the close before filling product time. Salesforce’s sales-call guidance uses an agenda covering needs, solutions, demo, questions, and next steps. For a 30-minute working session, begin with this allocation and change it before the meeting when the audience requires more depth.
| Minutes | Segment | Scripted outcome |
|---|---|---|
| 0–3 | Context and agenda | Confirm time, decision question, discovery bridge, attendee needs |
| 3–5 | Starting state | Orient buyer to persona, data, scenario, and what is synthetic |
| 5–12 | Module 1 | Answer the highest-priority buyer question |
| 12–19 | Module 2 | Show the downstream consequence or required control |
| 19–23 | Module 3 or branch | Serve a second stakeholder or open question |
| 23–26 | Proof and gaps | Separate demonstrated facts, supplied evidence, and unproven items |
| 26–30 | Next step | Agree outcome, owner, input, date, and success evidence |
For a 45- or 60-minute meeting, add time to interaction and required technical depth rather than adding every feature. Salesforce’s product-demo guidance recommends focusing the takeaway, showing instead of merely telling, and presenting a journey.
Write each module with the show-tell-ask loop
Every module gets one buyer job and one loop.
- Set the scene. “You are looking at [role] starting with [realistic state]. The job is [job], under [constraint].”
- Show. Perform the smallest complete workflow. Name the starting record, action, visible state change, and output. Avoid cursor tourism.
- Tell. Explain why that change matters for the role and which discovery requirement it addresses. Limit narration to what the screen cannot establish.
- Ask. “How does this compare with your current path?” “Which control would your team need here?” or “Would this output be sufficient evidence?” Then stop.
- Branch. Continue, deepen, park, correct, or disqualify based on the answer. Log the branch in the script.
Fillable module: Buyer job ___ · discovery quote/source ___ · starting state ___ · three actions maximum ___ · visible output ___ · role consequence ___ · proof ___ · ask ___ · positive branch ___ · concern branch ___ · technical branch ___ · skip condition ___ · target minutes ___.
Branch on buyer responses without losing the story
Branches are designed exits from the main story, not improvisational detours.
| Buyer response | Rep move | Script notation |
|---|---|---|
| “That matches.” | Confirm which part matters, then advance | CONTINUE → next module |
| “We do it differently.” | Ask for the critical difference; adjust or state the gap | CORRECT → revise assumption |
| “Can it also…?” | Relate to decision question; show now only if essential | DEEPEN or PARK with owner/date |
| Technical or security question | Use approved evidence or commit to qualified follow-up | PROVE or ESCALATE |
| Material requirement is unsupported | State the limitation plainly and assess fit | GAP; never fake a path |
| Environment fails | Name failure, switch to tested backup, preserve follow-up evidence | RECOVER; do not conceal |
Put a parking lot on the visible agenda and assign every parked item an owner. If a branch changes the decision, use it. If it is interesting but not decision-relevant, protect the close.
Attach proof without overstating it
Label three evidence types: demonstrated, documented, and proposed. A live product behavior is demonstrated in the configured environment. A security response, help article, contract clause, or permissioned case is documented. A roadmap item, configuration idea, or expected integration is proposed until verified.
For each proof point, script the publisher, artifact, date, population, environment, plan, and limitation. Never turn one customer’s outcome into an expected buyer result. Never load confidential customer or prospect data into an uncontrolled demo environment. Use synthetic data unless approved handling and agreements explicitly permit otherwise.
When pushback becomes substantive, follow the sales call objection-handling guide. A demo script should anticipate branches, not supply slick rebuttals to every concern.
See the complete script in one example
Example: a RevOps buyer evaluating a workflow system. Discovery established that reps find account signals in one tool, draft outreach elsewhere, rebuild context before calls, and update the CRM later. The buyer needs to see continuity without autonomous sending or unreviewed CRM writes.
“You said the issue is not a missing point tool; it is that context disappears between account selection, outreach, the call, and CRM. You also require reps to approve messages and record changes. I’ll show one account through that path, then we can test whether the control points match your policy. Has either requirement changed?”
Module 1—signal to reviewed outreach (7 minutes). Show a synthetic account with a sourced trigger. Open the evidence, generate the channel-specific draft, edit it, and show the review point. Tell: “The important state change is not that text exists; it is that the reason, source, draft, and human approval remain connected.” Ask: “Would your team need approval at the message level, campaign level, or both?” Branch: deepen on permissions; park mailbox delivery because it is outside this module.
Module 2—meeting context to CRM (7 minutes). Show the same account’s prep brief, the supported live-guidance context, then the synthetic post-call note and proposed fields. Tell: “Nothing writes in this scenario until the rep reviews the note and fields.” Ask: “Which fields may a rep approve, and which require a manager or automation policy?” Branch: if custom objects are material, record the schema and move to a technical validation rather than pretending the demo proves it.
Proof and gap statement. “Today you saw the configured synthetic flow and review points. We have not proven your custom-object mapping, failure recovery, or production permissions. Those belong in a sandbox test with your owners.” This sentence increases credibility because it separates the walkthrough from implementation evidence.
Close to a mutual next step
Close on what must be learned or decided next.
“You confirmed [fit evidence], corrected [assumption], and left [risk] unproven. The logical next step is [workshop/pilot/security review] to decide [decision]. [Buyer owner] and [seller owner] will provide [inputs] by [date]. We will test [cases] and consider it successful when [observable criteria]. Should we put that on the calendar now, or is there another gate first?”
A next step is incomplete without outcome, owners, input, date, and success evidence. If the buyer is not ready, agree on the missing information and who owns it rather than scheduling a vague follow-up. Use the sales call follow-up guide to preserve decisions, gaps, and commitments after the meeting.
Rehearse with this 100-point rubric
Practice the interaction, not just navigation. Salesforce recommends role-specific stories, limiting material to available time, leaving room for questions, and recording practice for feedback. Rehearse with a colleague playing a buyer who corrects assumptions, interrupts, requests a tangent, raises a material gap, and stays silent.
| Criterion | Weight | Observable evidence |
|---|---|---|
| Discovery fidelity | 20 | Every module maps to confirmed evidence; unknowns remain labeled. |
| Narrative and role clarity | 15 | Audience, before-state, desired state, and takeaway are easy to follow. |
| Show-tell-ask execution | 20 | Rep shows a job, explains consequence briefly, then stops for a useful question. |
| Proof discipline | 10 | Claims are scoped, sourced, permissioned, and relevant; no invented outcomes. |
| Branch handling | 15 | Rep follows buyer interest, parks tangents, and recovers from failure without hiding it. |
| Timing and accessibility | 10 | Modules and close fit; screen, text, pace, and alternative access work. |
| Next-step quality | 10 | Outcome, owner, input, date, success evidence, and open risk are explicit. |
Rate each from one to five, multiply by weight, total, and divide by five for a score out of 100. Preserve the recordings and notes where permitted. The score measures rehearsal behavior, not win probability. Keep proof accuracy, required accessibility, sensitive-data handling, and truthful limitation disclosure as gates that a weighted score cannot override.
Print the one-page demo script
DEMO OBJECTIVE: buyer decision ___ · current state/source ___ · desired state ___ · attendees/jobs ___ · unknowns ___.
OPEN (___ min): time ___ · discovery bridge ___ · agenda ___ · update question ___.
MODULE 1 (___ min): job ___ · show ___ · tell ___ · ask ___ · proof ___ · branches ___.
MODULE 2 (___ min): job ___ · show ___ · tell ___ · ask ___ · proof ___ · branches ___.
OPTIONAL MODULE (___ min): use only when ___ · skip when ___.
PROOF/GAPS: demonstrated ___ · documented ___ · proposed ___ · not proven ___.
CLOSE (___ min): confirmed ___ · corrected ___ · risk ___ · next outcome ___ · owners ___ · inputs ___ · date ___ · success evidence ___.
BACKUP: reset state ___ · backup environment/video/screens ___ · failure wording ___ · technical owner ___.
Version the script by persona, use case, product release, and evidence date. Retire modules when the product changes. The reusable asset is not a perfect speech; it is a traceable path from discovery to demonstration to a buyer-owned decision.