Sales enablement managers, Account executives, Sales engineers, Sales managers, Founders
Prepare the Required Inputs listed in the Workflow Prompt. Use as much detail as necessary.
1. Copy the Workflow Prompt.
2. Paste it into your AI tool.
3. Replace the "Required Inputs"
4. Run the prompt.
Get access to this workflow and 1000+ others designed to save hours and get better results with AI.
You are a sales enablement strategist. Create a demo playbook that helps sales reps deliver relevant, buyer-focused product demonstrations instead of feature walkthroughs.
### Required Input
- Product or Solution: [What is being demonstrated. Example: "AI customer support platform"]
- Target Buyer: [Buyer roles and users. Example: "Head of Support, CX manager, support agents"]
- Demo Goal: [What the demo should achieve. Example: prove fit, secure technical validation, advance to proposal]
- Buyer Pain Points: [Problems the demo must connect to. Example: high ticket volume, slow response times]
- Key Features or Capabilities: [Main areas to show. Example: automation rules, inbox routing, analytics]
- Differentiators: [What must stand out. Example: simple setup, multilingual support, low admin burden]
- Demo Length: [Available time. Example: 30 minutes]
- Sales Context: [Stage, deal type, audience size, or known objections]
### Input Validation
Review all inputs first. If the product, buyer, pain points, demo goal, or key capabilities are unclear, ask targeted clarification questions and wait before creating the playbook.
### Instructions
Design the playbook around buyer relevance. Start by defining the demo principle: the rep should show only what supports the buyer's stated priorities and should connect every section back to business value.
Create a pre-demo preparation process. Include what the rep should review, what assumptions to validate, what success criteria to confirm, and how to tailor the demo path. Add guidance for different audiences, such as executives, technical evaluators, daily users, and procurement influencers.
Build a demo structure with timing. Include opening recap, agenda, pain confirmation, current-state framing, solution walkthrough, proof points, objection checks, stakeholder-specific pauses, and next-step alignment. Avoid creating a generic feature tour. Each demo section should state the buyer question being answered, the feature or workflow to show, the value point to emphasise, and the transition to the next section.
Include talk tracks that are useful but not over-scripted. Add example phrases for introducing a feature, tying it to pain, checking understanding, handling silence, and recovering when the demo goes off track. Provide guidance on what not to show if time is limited.
Add demo risk controls. Include common mistakes, signs the buyer is disengaged, rescue questions, and ways to handle unexpected objections or technical questions without derailing the conversation.
### Output
Provide:
- Demo Strategy
- Pre-Demo Preparation Checklist
- Buyer-Specific Demo Paths
- Recommended Demo Flow With Timing
- Section-by-Section Demo Guide
- Talk Tracks and Transition Lines
- Objection and Disengagement Recovery
- What to Skip or Defer
- Post-Demo Follow-Up Template
- Coaching Notes for Managers
Create separate demo paths for executive buyers, technical evaluators, and end users.
Product Solution: Cross-Border Customs API Hub (Automated compliance add-on module).
Target Buyer: VP of Global Logistics, Director of International Operations, and Supply Chain Team Leads.
Demo Goal: Secure technical validation from the lead systems architect and advance the opportunity directly to a formal proposal stage.
The Core Philosophy: The fundamental rule of an enterprise logistics demo is: Never give a feature-by-feature tour. An enterprise buyer does not care about the visual design of a dashboard or the layout of an settings menu. They care about processing speed, data accuracy, and workflow automation. Every screen shown must visually prove how the system eliminates a manual step, protects an operating margin, or expands freight throughput capacity.
Reps must never open a live demonstration environment without verifying these operational metrics from discovery:
Adapt the demonstration narrative based on the primary stakeholder leading the evaluation table:
The Symptom: The buyer goes on mute, stops asking clarification questions, or you hear active email typing noises in the background.
The Rescue Track: Stop clicking through the platform. Close the software window or pause the screen share entirely to break their visual pattern. Say: “Let’s step away from the software layout for a second. Usually, when a team goes quiet here, it’s because the workflow look too different from how their field dispatchers operate day-to-day. Let’s be candid—how closely does the data structure we just reviewed map to the actual day-to-day operational reality your team faces?”
The Symptom: A database architect asks an advanced, unscripted security or encryption query mid-demo.
The Rescue Track: Do not guess or overpromise functionality. Maintain absolute commercial authority: “That is an excellent architecture query regarding our webhooks data payload encryption. To give you the exact technical spec sheets rather than a high-level summary, I am going to document that exact question for our systems engineering director. We will deliver that verified documentation alongside our post-demo notes this afternoon. Let’s keep our focus here on the operational data workflow.”
If a client arrives late or an executive states they must cut the meeting 10 minutes short, immediately drop the following sections:
Get access to all workflows, across every sector, with structured systems built for better results.