# Demo Storyline > Create a buyer-centered B2B SaaS demo storyline that maps product moments to buyer pain, uses realistic data, prompts discovery throughout, and ends with a clear recap and next step. - **Type:** Skill - **Install:** `agentstack add skill-adam-lagerhausen-b2b-marketing-skills-demo-storyline` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [adam-lagerhausen](https://agentstack.voostack.com/s/adam-lagerhausen) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [adam-lagerhausen](https://github.com/adam-lagerhausen) - **Source:** https://github.com/adam-lagerhausen/b2b-marketing-skills/tree/main/skills/demo-storyline ## Install ```sh agentstack add skill-adam-lagerhausen-b2b-marketing-skills-demo-storyline ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Demo Storyline ## When to use Use this skill when you need to plan a live or recorded B2B SaaS demo that advances a sales conversation. Best fit for: - First-call product demos - Discovery-led demos after an initial qualification conversation - Founder-led demos that need to become repeatable - AE or SE demo talk tracks - Custom interactive demos for a target segment or account - Demo sections inside sales narrative decks - Demo prep for vertical, persona, or use-case-specific sales motions Do not use this skill to create a feature tour, product training script, help documentation, or generic click path. A strong demo should map to buyer pain, not inventory the product. ## Inputs Ask for or infer as much of the following as possible: - Target audience: buyer, practitioner, economic buyer, technical evaluator, industry, company size - Buyer pain: what is broken, slow, expensive, risky, confusing, or newly urgent - Current workflow: spreadsheets, legacy tools, manual process, services, internal workaround, competitor - Desired outcome: what the buyer wants to improve, avoid, prove, or make easier - Product area: the specific workflow, capability, or use case to demo - Sales stage: first call, deep discovery, technical validation, executive demo, renewal, expansion - Qualification goal: what the rep needs to learn or confirm during the demo - Demo environment: available screens, data, integrations, personas, records, and constraints - Realistic data: company names, user roles, customer records, pipeline values, dates, tasks, metrics, statuses - Proof: customer story, metric, quote, benchmark, or before/after result - Objections or likely confusion: implementation, integrations, data quality, security, adoption, ROI, differentiation - Next step: stakeholder meeting, pilot, mutual action plan, technical validation, business case, proposal If inputs are thin, produce a useful draft with explicit assumptions and gaps. Never fill the demo with generic placeholders like "Item 1," "Customer A," or "Task 2" when realistic examples can be invented or requested. ## Demo storyline workflow 1. Anchor the demo in buyer pain. - Start with what the buyer is trying to fix, not what the product can do. - Name the current workflow and why it fails. - Define the outcome the demo should prove. 2. Tell them what you are going to show. - Preview the scenario in plain English. - Explain the roles, data, and workflow they will see. - Set expectations: "I will show three moments, then we will pause and decide if this maps to your process." 3. Get to product early. - Use only enough setup to make the demo relevant. - Move into the product before the conversation becomes a lecture. - Keep slides or context brief unless the buyer needs framing. 4. Show one coherent workflow. - Build the demo around a realistic buyer scenario. - Show the before/after change in how work gets done. - Use specific data: names, accounts, dollar values, dates, segments, statuses, exceptions, owners. - Avoid showing every feature, setting, admin page, and edge case. 5. Pause after key steps. - Demos are hard to follow; slow down after important moments. - Confirm the audience follows before moving on. - If people look confused, stop and clarify instead of clicking faster. - Zoom in where needed: data, workflow step, decision logic, output, or business impact. 6. Ask discovery questions throughout. - Use each product moment to learn something about the buyer's process. - Treat conversation as a win, not an interruption. - If the buyer opens up, follow the thread before returning to the script. 7. Tell them what they saw. - Recap the workflow in terms of pain, value, proof, and next step. - Use a recap slide or summary section at the end. - Connect the product moment back to the original business problem. ## Demo script structure Return the demo as a practical script a rep or founder could use live. Include: - Demo objective - Target audience and assumed pain - Qualification goal - Scenario setup - Realistic demo data - Opening talk track: tell them what they are going to see - Step-by-step demo flow, with each step containing: - Product moment - Buyer pain it maps to - What to say - What to click or show - Discovery question - Pause/checkpoint question - Likely confusion or objection - How to address it - Recap slide or recap talk track - Qualification signals - Recommended next step - Assumptions and missing proof ## Discovery questions Use discovery questions at every major step. Good demo questions uncover fit, urgency, process, value, and buying path. Examples: - "How does your team handle this today?" - "Where does this usually break down?" - "Who owns this workflow when something goes wrong?" - "What happens if this step is delayed or missed?" - "Which system is the source of truth today?" - "What data would your team need to trust this recommendation?" - "Who needs to approve this before it becomes the standard process?" - "What would make this valuable enough to prioritize this quarter?" - "Where would you want human review versus automation?" - "Is this close to how your team works, or would your process look different?" ## Qualification signals Listen for signals that the demo is creating a real sales conversation. Strong positive signals: - Buyer describes their current process in detail - Buyer corrects the demo scenario to match their real workflow - Buyer names a cost, risk, delay, or missed revenue impact - Buyer asks how this would work with their data, systems, roles, or approval process - Buyer brings up other stakeholders who need to see it - Buyer asks about implementation, pilot scope, pricing, security, or timeline - Buyer compares the product against a real status quo or competitor - Buyer says the demo reflects a current initiative or executive priority Weak or negative signals: - Buyer only asks generic feature questions - Buyer cannot name who owns the problem - Buyer says the current workaround is good enough - Buyer engages with the category but not the workflow - Buyer wants a recording but no next conversation - Buyer is curious but has no pain, urgency, authority, or project Use qualification signals to shape the recap and next step. A custom interactive demo can also reduce unqualified tire-kicker leads by making the buyer engage with a concrete workflow before sales spends more time; Reevo used this kind of custom interactive demo motion to reduce unqualified tire-kicker leads by 50%, improving sales efficiency and pipeline quality. ## Recap output End every demo with a recap slide or spoken recap. Default recap structure: 1. Pain confirmed - "You are trying to reduce [specific pain] caused by [current workflow/status quo]." 2. What the demo showed - "We showed how [product] helps [persona] move from [old way] to [new way]." 3. Value - "The practical value is [time saved, risk reduced, revenue protected, quality improved, visibility created]." 4. Open questions - "We still need to validate [integration, data, stakeholder, security, workflow variation, ROI]." 5. Recommended next step - "The right next step is [pilot scoping, stakeholder demo, technical validation, business case, proposal]." ## Quality bar The demo storyline is good when: - The demo starts with buyer pain and current workflow, not product features. - The product appears early enough to create belief. - The scenario is specific enough to feel real. - Every step maps to a buyer pain, outcome, or qualification goal. - The demo uses realistic data instead of generic placeholders. - The talk track follows: tell them what you will show, show them, tell them what they saw. - The rep pauses after key steps and checks whether the audience follows. - Discovery questions are embedded throughout the demo, not saved for the end. - The script gives the rep permission to stop, clarify, and follow buyer conversation. - The ending recap ties the demo back to pain, value, proof, and next step. - The demo would help qualify the account, not just impress the audience. ## Anti-patterns Avoid: - Feature tours with no buyer pain - Long company or category lectures before showing product - Generic demo data like "Item 1," "Acme," "Test User," or "Task 2" - Showing every feature because it exists - Moving too fast because the rep knows the product well - Treating buyer questions as interruptions - Ignoring confused faces or vague silence - Demoing edge cases before proving the main workflow - Over-automating the story when the buyer needs trust and control - Ending with "Any questions?" instead of a recap and concrete next step - Claiming proof that is not available ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [adam-lagerhausen](https://github.com/adam-lagerhausen) - **Source:** [adam-lagerhausen/b2b-marketing-skills](https://github.com/adam-lagerhausen/b2b-marketing-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-adam-lagerhausen-b2b-marketing-skills-demo-storyline - Seller: https://agentstack.voostack.com/s/adam-lagerhausen - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.