---
name: demo-script-builder
description: Build a tailored demo script that shows the buyer their outcome, not a feature tour. Use this skill whenever a user needs to plan a product demo, build a demo script or flow, tailor a demo to a prospect, or says 'help me structure this demo', 'they keep zoning out in demos', or 'build a demo script for [buyer]'. Trigger whenever a demo needs to be designed around the buyer's pain instead of a feature walkthrough.
---

# Demo Script Builder

## What this does and why it matters
The default demo is a feature tour that bores buyers and buries the point. This skill builds a demo structured around the buyer's specific pains, showing only the capabilities that resolve them, in the order that builds conviction, so the buyer sees their own outcome rather than your product's menu.

## Inputs to gather
1. The buyer, their role, and the pains uncovered in discovery.
2. The product capabilities and which ones map to those pains.
3. The desired outcome of the demo (advance to proposal, technical validation, executive buy-in).

## Method

### 1. Open with the destination
Start by stating the outcome the buyer will see by the end, tied to their pain. This gives every click a reason.

### 2. Tell it as their story, not a tour
Structure the demo as the buyer's workflow: here is the moment you feel the pain, here is what happens instead with this. Sequence by pain, not by product module.

### 3. Show the least that proves the most
Every screen must earn its place by resolving a known pain. Cut anything that does not. Depth on what matters beats breadth on what does not.

### 4. Build tension and payoff
Set up the pain, then reveal the resolution. A demo with narrative tension holds attention; a flat click-through loses it.

### 5. Plan the interaction points
Where to pause and ask a question, where to confirm resonance, where to let them drive.

### 6. Close on the next step
End with the agreed advancing action, not "any questions?"

## Output format
ALWAYS use:

# Demo Script: [Buyer / Company]
## Outcome statement (what they will see and why it matters to them)
## Flow (pain -> capability -> payoff, in order)
For each segment: setup line, what to show, the point to land, the check-in question
## Screens or features to skip (and why)
## Anticipated questions and responses
## Close and next step

## Anti-patterns to avoid
- A feature tour organized by product menu.
- Showing everything the product can do.
- No narrative tension, just clicking.
- Ending on "any questions?" instead of a next step.

## Example
For a buyer whose pain is slow reporting, the demo opens "by the end you will see this month-end report build itself in under a minute", skips unrelated modules, and lands the payoff on the automated report.