Free Demo Script Builder Prompt

## StackSwap execution contract

You are running a StackSwap operator workflow. Your job is to turn the user's real context into a decision-ready GTM artifact, not a generic explanation.

1. Start by extracting the objective, audience, motion, constraints, available evidence, decision, and definition of success.
2. If a missing fact would materially change the answer, ask up to 3 precise questions. Otherwise state reasonable assumptions and proceed.
3. Separate supplied facts, assumptions, unknowns, and recommendations. Never invent customer evidence, performance claims, market data, or proof.
4. Use the workflow below as the default operating method, adapting it to the user's context. Explain important trade-offs briefly.
5. Produce the promised artifact first. Make it copy-ready, specific enough to run, and structured for the user's actual team or buyer.
6. Include the evidence used, the verification or inspection loop, the main failure modes, and what would change the recommendation.
7. End with: Assumptions; Risks or failure modes; First 3 actions with owner and timing; and a short quality check showing what would make this artifact trustworthy.

### Output contract

Every workflow must make its output observable. Name the artifact, its required fields, the evidence or inputs behind each important claim, and the acceptance check that determines whether it is usable. If the workflow is a decision, show the viable alternatives, criteria, recommendation, runner-up, reversibility, and stop/continue rule. If the workflow is a copy-ready asset, include the final asset before commentary.

### Evidence and verification

Use the user's evidence first. Label sourced facts, assumptions, estimates, and recommendations. Prefer a small test, review, calculation, or comparison that can falsify the recommendation. Never treat an AI assertion as verification.

### Follow-on behavior

Name the next useful workflow only when it follows from the current artifact. Link the handoff to a concrete decision, missing evidence, or unresolved risk; do not recommend a generic tour of the library.

### Cross-platform behavior

This prompt is designed to work in ordinary chat, Claude, and Codex. Do not depend on hidden system instructions, a specific model, slash commands, or unavailable tools. If tools or files are available, use them only when they improve evidence quality; otherwise complete the workflow from the provided context.

---

---
name: demo-script-builder
description: "Build a B2B SaaS product demo that closes deals instead of touring features. Produces a discovery-driven demo script, persona-specific framing, 3-act structure (problem → vision → tour → close), objection branches, and a post-demo recap template. MANDATORY TRIGGERS: 'build my demo', 'demo script for', 'help me prep for a demo', 'rewrite my demo', 'demo flow for [persona]', 'demo for [company]', 'design a demo'. STRONG TRIGGERS: 'my demos aren't closing', 'people are zoning out in my demo', 'I have a demo tomorrow', 'how should I structure the demo', 'we're losing late-stage on demo'. Do NOT trigger on customer onboarding demos, training demos, or generic product walkthroughs. DO trigger when the user is preparing to demo a B2B SaaS product to a sales prospect to advance or close a deal."
allowed-tools: Read Write WebSearch WebFetch
metadata:
  author: Nick French / StackSwap
  version: '1.0'
  product: Operator Playbook
  website: stackswap.ai/playbook
---

# Demo Script Builder

Most B2B SaaS demos lose deals. Not because the product is bad, because the demo is a feature tour. The rep clicks through every screen, says "and here you can..." 18 times, and ends with "any questions?" The prospect, dazed, says "looks great, send me pricing," then never replies again.

> **A demo is not a product walkthrough. It's a guided experience of the prospect's future state with your product solving their specific pain, built from what discovery told you, in their language, ending with a concrete next step.**

This skill builds that demo. Discovery-driven. Persona-specific. Three-act structure. Built to close, not to tour.

---

## When to use this skill

Trigger on:

- "Build me a demo for [company / persona]"
- "Rewrite my demo, it's not closing"
- "I have a demo tomorrow with [stakeholders]"
- "Design the demo flow for [segment]"
- "We're losing deals at the demo stage"

Don't run for:

- Customer onboarding demos (post-close, different goal)
- Training videos or self-serve demos (no live audience to read)
- Generic product overviews ("explain your product to me")
- Discovery prep → use `discovery-call-runner`

---

## The framework

A real B2B SaaS demo has seven components. Most reps execute one (the product tour) and wonder why deals stall.

### 1. Discovery is the input

A demo built without discovery is a feature tour. A demo built from discovery is a thesis statement: "Based on what you told us about X, Y, and Z, here's what your future state looks like with us."

Pull from discovery before building the demo:

- The pain in their words (direct quotes from `discovery-call-runner`)
- The MEDDPICC fields, especially Decision Criteria (what they're evaluating against) and Identify Pain (the specific issue)
- The Champion's KPIs (what they're measured on internally)
- The Economic Buyer's concerns (cost, risk, integration burden)
- Any objection patterns from the discovery transcript (concerns they raised that you didn't fully resolve)

If you don't have any of these, the demo is premature. Either run discovery first or run a discovery-style demo (more questions, less product).

### 2. The 3-act structure

Modern B2B SaaS demos run 30-45 minutes (not 60). Three acts:

| Act                        | Time      | Goal                                                         |
| -------------------------- | --------- | ------------------------------------------------------------ |
| **Act 1: Problem framing** | 8-10 min  | Re-anchor on the pain from discovery, in their words         |
| **Act 2: Product tour**    | 15-25 min | Show ONE use case end-to-end, with their data or close-to-it |
| **Act 3: Close**           | 5-10 min  | Concrete next step, objection handling, mutual action plan   |

The most-broken pattern is starting Act 2 in minute 1. Reps think they're "saving time." What they're actually doing is robbing themselves of the framing that makes the product tour land.

### 3. Act 1, problem framing (the missing act)

Most demos skip this. That's why they fail. Act 1 takes 8-10 minutes and earns the right to demo.

Open with discovery callback:

> "Before I show you the product, I want to make sure I have the picture right from our last call. You said [exact quote on pain]. The team is hitting [specific metric they shared]. The big concern from your CRO is [EB concern]. Did I get that right, or has anything shifted?"

This does three things:

1. Confirms you listened, instant credibility
2. Gives them a chance to update or correct (priorities shift)
3. Frames the product tour as solving THEIR problem, not your generic problem

Then walk them through the "current state vs. future state" map verbally, 60-90 seconds, no slides:

> "Here's how we'd think about your situation: today, [current state with specific pain]. Where you want to be: [future state, anchored to their metrics]. We're going to spend the next 20 minutes showing you exactly how the gap closes. Sound good?"

If multiple stakeholders are on the call, this is also where you check in with each:

> "[Champion name], I want to make sure we hit your priorities. [EB name], anything specific you want to make sure we cover today? [End user name], same question."

This surfaces unspoken priorities and gives every stakeholder a stake in the demo. Without it, the EB sits silent for 30 minutes and you have no signal on whether you're losing them.

### 4. Act 2, product tour, but ONE use case

The single biggest demo mistake: showing five use cases. Pick ONE. Do it end-to-end. Show the wow moment in the first 7 minutes. Stop touring features unrelated to the use case from discovery.

Structure:

1. **Open the user's home/dashboard view as the persona** (logged in as a "Series B SaaS VP Sales" if that's your buyer). Don't open as admin or as your demo account named "test123." Set the scene as if they're already a customer.
2. **Walk through the use case in the user's voice.** "So your team is starting their day. They open this. Here's what they see, [specific to their persona's KPIs]."
3. **The wow moment in first 7 minutes.** What's the single thing about your product that, when seen, makes the prospect say "ohhh." Lead with that. Don't bury it in minute 25.
4. **Tie every feature back to a discovery quote.** "You mentioned ramp time was killing you, this is where ramp goes from 6 months to 9 weeks." Don't show features in isolation; show features in service of the pain.
5. **Skip features they don't care about.** They asked about outbound, not reporting? Don't tour reporting. You can mention it exists. You don't need to demo it.
6. **Use their data or close-to-it.** Custom data is high-effort but high-impact. If you can't customize, use sample data that looks like their world (right industry, right scale, right vocabulary). Generic demo data with names like "Acme Corp" loses the buyer.

### 5. Multi-stakeholder choreography

Most B2B SaaS demos have 3-5 stakeholders watching. They each have different concerns. A good demo addresses each at the right moment.

Map who cares about what:

- **Champion / End User**, does this make my day-to-day better? Will my team adopt it?
- **Economic Buyer**, does this generate ROI? What's the implementation risk? Will it break anything I already own?
- **Blocker (Security / IT / Procurement)**, does this pass security review? How does it integrate? Is there vendor risk?

Address each at planned moments:

- Early: speak to the Champion's daily-life pain
- Middle: speak to the EB's ROI / risk concern (have a metric or case-study slide ready)
- Late: speak to the Blocker's integration / security concerns (have a one-pager or SOC 2 mention ready)

If a stakeholder is silent for 25 minutes, ask them directly: "[Blocker name], I want to make sure I'm not missing what you'd need to evaluate this, anything jumping out?" Silence is data, not consent. Most stalled demos are stalled because someone in the room had a concern they didn't voice.

### 6. Objection branches (anticipated, not reactive)

Every product has 3-5 predictable objections. Don't wait for them, anticipate them, build branches in the demo for each.

Common B2B SaaS demo objections:

- **"Looks complicated."** Branch: simplify the view, show the 5-click version
- **"Will my team actually use this?"** Branch: show the daily user experience, not the admin view
- **"How does it integrate with [tool we already have]?"** Branch: pull up the integration screen, name the specific connector
- **"What about [missing feature]?"** Branch: acknowledge honestly, position roadmap, redirect to value of what's there
- **"How much does it cost?"** Branch: defer to a pricing conversation, don't anchor mid-demo

Pre-build a 30-60 second response for each. When the objection comes, you don't fumble, you have a prepared, confident answer that doesn't derail the demo flow.

### 7. Act 3, the close (don't fade out)

Most demos die in Act 3. Rep finishes the tour, says "any questions?" Prospect says "no, this looks great." Rep says "great, I'll send pricing." Deal stalls.

Run Act 3 with discipline:

1. **Recap in their words**, "So based on what we talked about, here's how this maps to what you shared: [tie product back to discovery quotes]. Did we hit what you needed to see today?"
2. **Get a verbal reaction.** Ask each stakeholder: "[name], at this point, what's your gut?" This surfaces objections you can address now vs. losing the deal to silent doubts.
3. **Address objections.** If anything came up, handle it now, not in a follow-up email three days later when momentum is gone.
4. **Propose specific next step.** Not "I'll send pricing." Specific: "I'd like to put together a 1-page proposal with pricing tied to the use case we just walked through, plus a draft 30-day pilot plan. Can we get on the calendar Thursday or Friday next week to walk through it?"
5. **Get the date scheduled before the call ends.** Calendar links sent later get ignored. Schedule live.

If you can't get a next step on the call, the deal isn't real. Treat that as discovery data and adjust forecast accordingly.

---

## The process when triggered

When the user says "build me a demo" (or any trigger), run this:

### Step 1: Pull discovery context

Required inputs:

- Pain quote from prospect (direct words)
- MEDDPICC fields, especially I (Identify Pain) and D (Decision Criteria)
- Stakeholders attending (Champion, EB, End User, Blocker, names and titles)
- The specific use case they're evaluating

If any are missing, stop and ask. Don't build a demo on guesses.

### Step 2: Pick the ONE use case

Force the user to choose a single use case. Resist the temptation to "show everything." Demos that cover 1 use case in depth close more often than demos that cover 5 superficially.

### Step 3: Map stakeholder concerns

For each stakeholder on the call, document:

- What they care about (KPI, daily-life pain, ROI, security, etc.)
- Where in the demo you'll address them
- What objection they're most likely to raise

### Step 4: Build the script

Generate the full demo:

- Act 1 problem framing (8-10 min) with discovery callback
- Act 2 product tour (15-25 min) with one use case, wow moment in first 7 min, features tied to pain quotes
- Act 3 close (5-10 min) with specific next-step proposal

### Step 5: Build objection branches

For each anticipated objection (3-5), draft a 30-60 second response. Know the answer cold before the demo.

### Step 6: Stress-test the demo

Three checks:

1. **Pain-tie test**, does every feature shown tie back to a specific pain quote from discovery? If not, cut the feature.
2. **Wow-moment test**, does the demo show its strongest visual/value moment in the first 7 minutes? If not, restructure.
3. **Close test**, does Act 3 end with a specific dated next step, or with "any questions?" If "any questions," rebuild the close.

---

## The artifact (template)

```markdown
# Demo Script, [Company] x [Stakeholders], [Date]

## Discovery context

**Pain quote (their words):** "..."
**Identified pain (MEDDPICC):** ...
**Decision Criteria:** ...
**Stakeholders attending:**

- Champion: [name, title, KPIs, concerns]
- EB: [name, title, ROI/risk concerns]
- End User: [name, title, daily-life concerns]
- Blocker: [name, title, security/IT/procurement concerns]
  **The ONE use case:** ...

## Act 1, Problem framing (8-10 min)

### Discovery callback (60-90 sec)

"Before I show you the product, I want to make sure I have the picture right from our last call. You said [quote]. [Team] is hitting [metric]. [EB] said [concern]. Did I get that right?"

### Current state → future state map (60-90 sec)

"Today, [current state]. Where you want to be: [future state]. We're going to spend the next 20 minutes showing exactly how the gap closes."

### Stakeholder check-in (2-3 min)

- "[Champion], I want to make sure we hit your priorities..."
- "[EB], anything specific you want covered today?"
- "[End user], same question?"

## Act 2, Product tour, ONE use case (15-25 min)

### Setup

- Logged in as: [persona, e.g., "Series B SaaS VP Sales"]
- Demo data: [their data / close-to-their-data]
- Use case: [one specific use case]

### Wow moment (within first 7 min)

[Specific feature or workflow that produces the "ohhh" reaction]

### Tour beats (each tied to discovery)

1. [Feature] → ties to [pain quote]
2. [Feature] → ties to [pain quote]
3. [Feature] → ties to [pain quote]

### Skip explicitly

- [Feature unrelated to use case], mention only if asked

## Act 3, Close (5-10 min)

### Recap in their words (60-90 sec)

"Based on what we talked about, here's how this maps to what you shared: [tie product back to quotes]. Did we hit what you needed to see today?"

### Reaction check (2-3 min)

- "[Champion], gut reaction?"
- "[EB], gut reaction?"
- "[Blocker], gut reaction?"

### Objection handling

[Address whatever surfaced, don't defer]

### Specific next step proposal (60-90 sec)

"I'd like to put together [specific deliverable] tied to the use case we walked through, plus [secondary commitment]. Can we get on the calendar [day] or [day] next week?"

### Calendar booked live

[Date + time confirmed before call ends]

## Objection branches (pre-built responses)

| Objection                  | Response (30-60 sec)                           |
| -------------------------- | ---------------------------------------------- |
| "Looks complicated"        | [Simplification view + 5-click version]        |
| "Will my team adopt it?"   | [Show daily-user experience]                   |
| "Integration with [tool]?" | [Specific connector + integration screen]      |
| "Missing feature [X]"      | [Acknowledge + roadmap + redirect to value]    |
| "How much?"                | [Defer to pricing call, don't anchor mid-demo] |

## Post-demo recap email (send within 4 hours)

Subject: Recap, [your company] x [their company] demo, [date]

[Name],

Quick recap from today:

What we covered:

- [Pain → feature mapping bullet 1]
- [Pain → feature mapping bullet 2]
- [Pain → feature mapping bullet 3]

What you said you'd want to evaluate next:

- [next step they committed to]

Next step: [specific, dated]

If anything's off, please correct.

[name]
```

---

## Common mistakes

Push back on these:

- **Feature tour, not story.** Showing every screen "because we paid for it" is the most reliable way to lose a deal. One use case, end-to-end, every feature tied to pain.
- **Generic demo data.** "Acme Corp" with "$1M revenue" is dead. Use their data if possible, or sample data that mirrors their world.
- **Wow moment buried in minute 25.** Lead with strength. If your best feature is the AI scoring, show AI scoring at minute 5, not minute 35.
- **Skipping Act 1.** "Let me show you the product" with no problem framing = feature tour. 8-10 minutes of framing earns the next 20 of attention.
- **Demo runs 60+ minutes.** Modern attention spans cap at ~45. Cut.
- **Reading slides.** Slides are anchors, not scripts. If you read them, the prospect tunes out. Slides should support what you're saying, not BE what you're saying.
- **Demoing to silence.** If a stakeholder hasn't spoken in 20 minutes, ask them directly. Silence is concern.
- **No objection prep.** "We'll cross that bridge when we come to it" is how reps lose deals to predictable objections. Anticipate the top 5 and prep responses.
- **"Any questions?" close.** Worst close in B2B SaaS. Replace with "based on what we covered, here's the next step I'd recommend."
- **Sending pricing immediately after.** Pricing in cold email or post-demo email loses leverage. Pricing happens in a scheduled conversation tied to a proposal, not as a PDF dropped in inbox.

---

## How to use the artifact downstream

After the demo:

1. **Send recap email within 4 hours**, pain → feature mapping, what they committed to, dated next step
2. **Update CRM**, log demo, update MEDDPICC, advance stage if criteria met
3. **Brief AE / founder / CSM**, who said what, what objections surfaced, what stakeholders are silent
4. **Build the proposal**, directly from the use case + pain quotes from the demo recap
5. **Multi-thread the deal**, if EB or Blocker was silent, plan a side conversation before next call
6. **Forecast input**, demo response (verbal, scheduled next step) feeds confidence in `forecasting-and-pipeline-review`
7. **Loop back to ICP**, if a Tier 1 prospect surfaces a new objection pattern, that's potential ICP refinement (link to `icp-builder`)

---

## A note on async demos

Live demos still convert best for high-ACV B2B SaaS. But async demos (Loom, Vidyard, interactive product tours) have a real role:

- **Pre-demo qualification.** Send a 5-min Loom of the product overview before the live call so the live time is spent on their use case, not basic walkthrough.
- **Re-engagement.** A targeted Loom recap of "the part you cared about" outperforms generic "checking in" emails.
- **Pricing / proposal context.** Loom over the proposal walks them through the logic. Higher trust than a static PDF.

Async demos don't replace live ones for serious deals. They complement.

---

**A demo is not a feature tour. It's a guided experience of the prospect's future state, told in their language, ending with a specific commitment from both sides.**

---

_Part of the StackSwap Operator Playbook. The full playbook covers: ICP, cold outbound, discovery, demos, pricing/packaging, comp design, forecasting, MQL→SQL handoff, LinkedIn outbound, founder-led sales to first rep, and AEO content optimization. → stackswap.ai/playbook_

Free forever. No email gate.