10 Claude prompts that nail the sales demo in 2026

Ten Claude prompts that fix the ten failure modes Gong Labs win/loss data, Chris Orlob's Sales Hacker analyses, and the JBarrows demo methodology flag as the biggest reasons B2B demos lose deals: shallow account research, generic hooks, problem-skipping demos, feature-bloated narratives, no value confirmation, dodged objections, single-threaded relationships, missing Mutual Action Plans, weak pre-meeting context, and recap emails that don't activate the champion. Each prompt below carries the full text, a sample buyer scenario, and the metric it moves. The demo is the asset; these prompts are how you stop wasting it.

<a href="https://www.anthropic.com/claude?utm_source=aipromptshub&utm_medium=blog&utm_campaign=sales-demo-prompts-2026" style={{display:"inline-block",padding:"10px 18px",background:"#0a66ff",color:"white",borderRadius:"6px",textDecoration:"none",fontWeight:"bold"}}> Try Claude Pro for these prompts → </a>

The structural failure has not changed in five years: reps narrate features, buyers tune out, and the recap email lands on a stakeholder who never attended. Gong Labs' demo-conversion analysis of recorded B2B calls found that demos run as a feature tour convert to next-meeting 38% less often than demos structured as problem-insight-capability-proof — the JBarrows methodology demo arc that turns capability into commitment instead of curiosity.

Chris Orlob's Sales Hacker breakdown of 67,000 recorded demos flagged three patterns that predict losses: aha-moment buried past the eighth minute, zero value-confirmation questions in the first half, and a single-threaded champion with no economic-buyer touchpoint by the close. Gong's 2025 win/loss findings put numbers on it: demos with at least three value-confirmation questions close 1.8x more often, and deals with 4+ stakeholders engaged before the recap close 2.6x more often than single-threaded ones.

Claude Sonnet 4.5 and Opus 4.7 are the right tools because demo prep, structure, and follow-up are tightly-scoped, rule-bound rewrite tasks — exactly what the Anthropic prompt engineering guide flags as highest-yield. A demo isn't a creative writing project; it's a structured artifact that either passes the buying-committee filter or doesn't.

Most reps prep for the demo by reading the buyer's homepage. The buyer is reading their own homepage too — and finding nothing new. This prompt converts a 10-K (or annual report, S-1, board deck excerpt) into a structured research brief: stated risks, capital allocation, executive priorities, named operational pain. The opening line of the demo cites something the buyer's CFO wrote, not something the marketing team posted.

**The prompt:**

``` You are a B2B account-research analyst building a demo research brief from public filings. INPUT: - Buyer's most recent 10-K, annual report, or S-1 (full text or relevant sections): <text> - Buyer's last two earnings-call transcripts (if available): <text> - The product I sell, in one sentence: <text> - The persona attending the demo (role, function, seniority): <text> OUTPUT (JSON): { "stated_risks_relevant_to_product": [<3-5 risk-factor quotes from the 10-K with page or section reference; only risks plausibly addressable by my product>], "capital_allocation_signals": [<2-3 signals: capex direction, headcount plans, M&A posture, segment investment — quoted with source>], "executive_priorities": [<3-5 priorities named by CEO/CFO in earnings calls or letters, quoted>], "named_operational_pain": [<specific operational pain the filings admit — process delays, system migrations, audit findings, segment headwinds>], "opening_line_options": [<3 demo opening lines, each citing a specific filing reference the buyer's own CFO signed off on>], "questions_only_a_prepared_rep_would_ask": [<5 questions whose framing proves the rep read the filings>], "do_not_say_list": [<3-5 generic claims that would expose homepage-tier prep>] } Rules: - Every quote must be attributable to a specific filing section or earnings-call date. - Do not invent priorities, risks, or numbers — if the filings don't support a claim, omit it. - The opening line options must reference a public filing, not a public press release. - The do_not_say list must include the generic vendor-pitch lines a competitor would use. ```

**Why it works:** The do-not-say list is the operator test — it forces the model to name the generic openers the rep should refuse. Citing a filing in the opening line is a credibility unlock; the buyer knows their press release is marketing, their 10-K is sworn.

**Sample:** For a demo to a regional bank's COO, the brief surfaces a 10-K risk factor about manual exception-handling delays in deposit operations, an earnings-call quote about a CFO-mandated cost-to-serve target, and an opening line that names both — turning a cold demo into a continuation of the buyer's own internal conversation.

**Metric moved:** Per Gong's 2025 first-call analysis, demos opening with a filing-cited buyer-specific risk advance to next-meeting 1.7x more often than demos opening with vendor positioning.

A demo hook is the first 90 seconds. Most reps use the same hook for the CFO, the VP Ops, and the IT Director — and lose all three. This prompt generates persona-tailored hooks per attendee, each anchored in the metric that persona is measured against.

**The prompt:**

``` You are a persona-tailored demo-hook generator. INPUT: - Research brief from prompt #1 (or summary): <text> - Confirmed attendees with role, seniority, function: <list> - The product's mechanism of impact (one sentence): <text> - Known discovery-call quotes from each attendee or their proxy: <text or "none"> For each attendee, output: { "attendee": "<name and role>", "primary_kpi": "<the metric this persona is bonused or board-reviewed on>", "latent_fear": "<what this persona is privately worried about that the product touches>", "tailored_hook": "<90-second hook, written as spoken language, naming the KPI and the buyer-side specific>", "avoid_phrases": [<3 phrases this persona dismisses on contact — "strategic enabler", "single pane of glass", etc.>], "transition_to_demo": "<one-line bridge from hook to the first demo beat>" } Also output: { "shared_opening_hook": "<a 90-second hook usable when all attendees are on simultaneously; must satisfy the senior-most attendee first>", "hook_failure_modes": [<3 patterns that would lose this room within 60 seconds>] } Rules: - Each hook must name the persona's KPI in the language they use, not vendor language. - Hooks must be readable aloud in under 90 seconds (≤200 words). - Do not invent attendee quotes — if discovery is thin, mark the hook as "hypothesis, validate in first minute." ```

**Why it works:** The latent-fear input forces the model past the surface KPI to the under-the-surface concern — the thing the CFO is privately worried about that the product happens to touch. The avoid-phrases list is the negative-space half of persona work most prompts skip.

**Sample:** For the same regional-bank demo, the CFO hook leads with cost-to-serve and exception-handling overtime, the COO hook leads with cycle-time and audit re-finding rate, the IT hook leads with integration risk and identity-provider compatibility — three different 90-second opens, one ten-minute demo body.

**Metric moved:** Demos opening with persona-tailored hooks advance to value-confirmation 1.6x more often (Chris Orlob's Sales Hacker analysis of 67,000 recorded demos, 2025).

The JBarrows demo arc is the structural fix for the feature-tour failure mode. Problem (the buyer's pain, named), insight (what the rep knows that the buyer doesn't), capability (the one thing the product does about it), proof (the named-customer evidence that it worked). This prompt builds the storyboard.

**The prompt:**

``` You are a JBarrows-style demo storyboard outliner. INPUT: - Buyer's top 1-3 pains from discovery: <text> - The product's 3-5 most relevant capabilities for this buyer: <text> - Insights the rep has that the buyer probably doesn't (industry benchmarks, peer behavior, regulatory shifts, anti-pattern data): <text> - Named customer proof (named customers, dated results, sample sizes): <text> - Demo length cap: <minutes> OUTPUT (JSON): { "storyboard": [ { "beat_number": <int>, "problem": "<the buyer's pain restated in their words>", "insight": "<the thing the rep knows that reframes the pain — surprising, dated, defensible>", "capability": "<the single capability shown in this beat — not a feature tour>", "proof": "<named customer or dated audit data anchoring the capability>", "value_confirmation_question": "<the question asked at end of beat to confirm value landed>", "time_minutes": <int> } // 3-5 beats total ], "aha_beat": <int>, "weakest_beat": {"beat_number": <int>, "why": "<the soft spot — usually missing proof or weak insight>"}, "cut_list": [<features and beats removed from the original demo plan>] } Rules: - Every beat must have all four PICP elements; a beat with no insight is a feature pitch and gets cut. - Aha must land by beat 3 in a 4-5 beat structure. - Proof must be named customer or dated audit; "customers report" is rejected. - Total time across beats must stay under the cap. ```

**Why it works:** Requiring the insight on every beat is the structural anti-pattern that kills feature-tour demos. The weakest-beat output forces honesty about which beat the rep will need to reinforce live.

**Sample:** For a payments-platform demo, beat 1 reframes "chargeback handling" as "the 4.8-day average decision lag that costs your team 18% of disputed amounts you'd otherwise win" — the insight the merchant didn't know, anchored to a 200-merchant Q1 audit.

**Metric moved:** Demos structured as PICP convert to next-meeting 1.9x more often than feature-tour demos (Gong Labs 2025 demo-arc analysis).

<a href="https://www.anthropic.com/claude?utm_source=aipromptshub&utm_medium=blog&utm_campaign=sales-demo-storyboard" style={{display:"inline-block",padding:"10px 18px",background:"#0a66ff",color:"white",borderRadius:"6px",textDecoration:"none",fontWeight:"bold",marginTop:"12px"}}> Run these prompts in Claude Pro → </a>

Every demo drifts toward longer. Reps add a slide, a feature, a contingency click-through. Buyers retain one or two beats. This prompt does the opposite: it scores every beat and recommends what to cut. The bar is high — beats survive only if they earn the next meeting.

**The prompt:**

``` You are a demo-trim recommender. Your job is to cut, not to add. INPUT: - Current demo storyboard (beat list with titles and one-line descriptions): <text> - The single decision the buyer is making after this demo: <text> - Maximum demo time: <minutes> - Attendee attention budget (slot length, time of day, attendee count): <text> For each beat, output: { "beat_number": <int>, "beat_title": "<title>", "does_it_earn_the_next_meeting": "yes | no | maybe", "who_it_serves": "<the specific attendee whose decision criterion this beat addresses>", "risk_if_kept": "<the cost of including this beat — time spent, attention drained, off-narrative drift>", "cut_or_keep": "cut | keep | merge_with_<beat>", "if_kept_what_must_change": "<the specific edit that earns this beat its slot>" } Also output: { "final_beats": [<the kept and merged beats in sequence>], "total_time_minutes": <int>, "removed_beats": [<beats cut, with one-line reason each>], "narrative_after_cuts": "<a 5-line summary the rep can read aloud as their internal demo plan>" } Rules: - Default action is cut. Beats survive only with explicit justification tied to the decision the buyer is making. - A beat that serves no specific attendee's decision criterion is cut without discussion. - Total time must be ≤80% of the slot — leave room for questions. - Do not propose new beats; cut, keep, or merge only. ```

**Why it works:** Default-cut inverts the rep's instinct to defend every beat. The "who it serves" requirement forces the rep to name a specific attendee — beats with no named beneficiary are deck-padding.

**Sample:** A 14-beat demo plan trims to 5 beats; the cut list includes platform architecture, navigation tour, admin panel, three integration logos, and a roadmap slide. The buyer asked one question all four discovery calls: can we audit who approved what. Beats 1-5 answer that. Everything else dies.

**Metric moved:** Trimmed demos with ≥80% of slot reserved for narrative + 20% for questions advance 1.5x more often than full-slot demos (Gong 2025 attention-budget data).

A demo without value-confirmation questions is a monologue. "Does that resonate?" is the worst version — it asks for permission, not commitment. This prompt generates question banks per beat: confirm value, surface objections, isolate decision criteria.

**The prompt:**

``` You are a value-confirmation question-bank generator for sales demos. INPUT: - Final demo storyboard (beat list): <text> - Attendees and their decision criteria: <text> - Known objections from prior discovery: <text> For each beat, output: { "beat_number": <int>, "value_confirmation_questions": [<3 questions: one specific ("how would this change your X workflow?"), one comparative ("how does this compare to <named alternative>?"), one consequence ("if you had this last quarter, what changes?")>], "objection_surfacing_questions": [<2 questions designed to make the unspoken objection speakable>], "decision_criteria_isolators": [<2 questions that move the buyer from interest to ranked criteria>], "banned_questions": [<phrases to never say: "does that make sense", "does that resonate", "any questions">] } Also output: { "closing_question_set": [<3 closing questions: one commitment-test, one next-step-naming, one champion-identifying>], "silence_handling": "<one line — what to say after a 6+ second silence; never break it for them>" } Rules: - Every question must be open-ended; yes/no questions are rejected. - Each beat must include at least one question that names the buyer's actual workflow or named alternative. - The banned_questions list is non-negotiable — these are demo-killers. ```

**Why it works:** Banning "does that resonate" and "any questions" is the small structural fix that recovers most demo-time loss. The silence-handling instruction protects the rep from filling the buyer's processing time with vendor noise.

**Sample:** For the audit-trail beat: (1) How would this change the Friday close ritual your team described? (2) How does this compare to the SharePoint workflow your auditor flagged? (3) If you had this in Q1, would the re-finding rate have changed? Each question converts curiosity into commitment.

**Metric moved:** Demos with ≥3 value-confirmation questions in the first half close 1.8x more often (Gong 2025 win/loss findings).

Most reps handle objections in real time, badly. A pre-built objection-handle library — tuned to the named account, the named alternatives, and the named risks — turns objection moments from threats into proof points. This prompt builds it.

**The prompt:**

``` You are an account-tuned objection-handle library generator. INPUT: - Buyer's stated or likely objections (from discovery, peer calls, lost-deal notes for this segment): <text> - Competitive alternatives the buyer is considering (including "do nothing" and "build internally"): <text> - Named customer proof (customers, dated results, time-in-production): <text> - Concessions the product genuinely warrants (real limits): <text> For each objection, output: { "objection": "<one sentence as the buyer would say it>", "underneath_concern": "<what the buyer is really worried about — usually risk, control, or career>", "weak_response": "<the common vendor reply that loses the room>", "strong_response": "<specific, evidence-led counter using named customer, dated audit, or transparent concession>", "redirect_question": "<the question that flips the objection into a value-confirmation moment>", "escalation_path": "<the artifact or person the rep offers if the objection persists>" } Also output: { "objections_to_concede": [<objections where partial agreement is the honest move; concession lines included>], "objection_priority_order": [<objections ranked by deal-killing impact, highest first>], "library_format": "<the one-page format the rep keeps on a second monitor during the demo>" } Rules: - Every strong response must cite a named customer, dated result, or transparent concession. - At least one objection must be conceded honestly — "sales-deck PR voice" loses trust faster than the original objection. - The redirect question must move the conversation forward, not deflect. ```

**Why it works:** The redirect-question requirement turns each objection into a value-confirmation moment — the highest-yield pivot in live demos. The required concession breaks vendor-PR voice; buyers reward honesty about real limits.

**Sample:** "Your AI will hallucinate." Underneath: regulatory risk. Strong response: "It does at 0.4% on the Q1 audit set; here's the evidence-capture workflow that catches them — the workflow Pacific Banc's compliance team signed off on." Redirect: "Where does your current process catch its own errors?"

**Metric moved:** Demos with pre-built objection libraries reduce lost-to-no-decision rate by 24% (Gong Labs 2025 lost-deal analysis).

Single-threaded demos lose. The rep talks to the champion; the economic buyer never engages; the deal dies in procurement. This prompt produces a multi-thread map: who's attending, who's missing, who needs to be activated, what artifact each persona needs to advance.

**The prompt:**

``` You are a multi-thread relationship-map generator for B2B deals. INPUT: - Confirmed demo attendees (names, roles, seniority): <text> - Known stakeholders not attending (named, role, why absent): <text> - Discovery-confirmed buying committee structure: <text or "partial — flag gaps"> - The decision the demo is teeing up: <text> OUTPUT (JSON): { "current_threads": [ { "person": "<name and role>", "thread_strength": "strong | warm | cold | unknown", "last_meaningful_touch": "<event and date or 'never'>", "role_in_decision": "champion | economic_buyer | technical_evaluator | end_user | blocker | influencer | unknown" } ], "missing_threads": [ { "role_unfilled": "economic_buyer | security | procurement | legal | end_user_champion | etc.", "why_it_matters": "<one line>", "activation_path": "<the specific introduction or artifact request needed, plus who can deliver it>" } ], "single_thread_risk_score": <0-10>, "per_persona_artifact_needs": [ {"persona": "<role>", "artifact": "<ROI model | security overview | reference call | contract template | etc.>", "by_date": "<date>"} ], "demo_in_room_strategy": "<one paragraph — how to use this specific room to activate the missing threads, including which attendee to ask for which introduction>" } Rules: - A thread is "strong" only with a substantive working session in the last 21 days. - Single-thread risk above 6 means the demo must end with at least one named introduction request. - Do not assume seniority equals decision authority — flag the assumption if unverified. ```

**Why it works:** Forcing the model to name an introduction-request the rep will make in-meeting is the structural fix for single-threading. Buyers respect a rep who asks for a CFO introduction by name; they ignore reps who say "we'd love to connect with more stakeholders."

**Sample:** The map shows three threads (champion + 2 ICs), zero economic-buyer touch, single-thread risk score 7. The in-room strategy: at minute 28, ask the champion which of three things — security review, ROI walkthrough, or peer call — would be most useful for her VP Finance, and request a 20-minute joint working session this week.

**Metric moved:** Deals with 4+ stakeholders engaged before the recap close 2.6x more often (Gong 2025 win/loss findings).

A Mutual Action Plan (MAP) is the sequenced commitment document — every step from demo to signature, with owners and dates on both sides. Most reps skip it because it feels presumptuous. The buyers who say "send a MAP" close 2x faster than buyers who don't.

**The prompt:**

``` You are a Mutual Action Plan (MAP) outliner. INPUT: - Today's date: <date> - Buyer's stated or inferred target go-live or fiscal-year close: <date> - Known buying gates (security review, procurement, legal, board, fiscal cycle): <text> - Champion's name and role: <text> - Economic buyer status: "identified | suspected | unknown" OUTPUT (JSON): { "target_signature_date": "<date — calculated by working backward from go-live with realistic gate durations>", "map_steps": [ { "step_number": <int>, "step_name": "<e.g. 'security review questionnaire returned', 'reference call with named peer', 'procurement intake submitted'>", "owner_buyer_side": "<role and name if known>", "owner_vendor_side": "<role>", "due_date": "<date>", "deliverable": "<the artifact or decision produced by this step>", "gate_passed": "<the buying gate this step clears>", "risk_if_slipped": "<one line — what happens to the target date if this slips a week>" } ], "critical_path_steps": [<the 2-3 steps that determine the signature date>], "map_framing_for_champion": "<a 3-sentence framing the champion can use internally — 'this is how I'm de-risking the project', not 'this is the vendor's contract pressure'>", "signature_line_request": "<the specific ask: 'can we both initial this by Friday', not 'let me know what you think'>" } Rules: - Every step must have both a buyer-side and vendor-side owner. - Critical-path steps must be flagged; non-critical steps must be cut if they pad the timeline. - The champion framing must be in champion-voice, not vendor-voice — "how I'm de-risking," not "how we're closing." - If economic buyer is "unknown," the first step must be the introduction request. ```

**Why it works:** The champion-voice framing is what makes the MAP forwardable. Most rep-written MAPs read as vendor pressure; this output reads as the champion's project plan.

**Sample:** A 9-step MAP working backward from a target October 1 go-live: security review by July 15, ROI walkthrough with VP Finance by July 22, reference call by August 5, procurement intake August 12, legal redlines September 1, signature September 15. Critical path: security and procurement.

**Metric moved:** Deals with a signed MAP close 2.0x faster and slip 41% less often than deals without one (Gong 2025 forecast-accuracy data).

The pre-meeting recap is the underrated demo asset. It primes the room, anchors the agenda, and gives the rep credibility before saying a word. This prompt writes a pre-recap that names the buyer's stated goals, the artifacts shared, and the three outcomes the meeting will hit.

**The prompt:**

``` You are a pre-meeting recap email writer for B2B sales demos. INPUT: - Prior discovery and meeting history (dates, attendees, what was discussed): <text> - Confirmed attendees for the upcoming demo: <list> - Buyer's stated goals or success criteria for this meeting: <text> - The three outcomes the meeting will produce (decisions, artifacts, commitments): <text> - Tone preference: "warm-professional | crisp-executive" OUTPUT (JSON): { "subject_line": "<subject naming the meeting purpose, not 'looking forward'>", "opening_line": "<one line that references something the buyer said by date or by name, proving prep>", "agenda_three_outcomes": [<the 3 outcomes as bullets, written in buyer-language>], "prep_links": [<each artifact attached with one-line description of what it answers>], "in_meeting_decisions": [<the 1-3 decisions the buyer will make in the meeting — named, with options>], "questions_for_buyer_to_prep": [<2-3 questions the rep wants the buyer to think about beforehand>], "closing_logistics": "<dial-in or location, attendees confirmed, owner of next step>", "full_email": "<the email, 150-250 words, in the requested tone>" } Rules: - Subject must name the meeting purpose; "looking forward" and "quick check-in" are rejected. - The opening line must reference a buyer-specific detail by date or by name — proves the rep prepped. - Agenda bullets are in buyer-language, not vendor-language; "demo our platform" is rejected. - The full email must be ≤250 words and readable on mobile. ```

**Why it works:** Pre-meeting context lifts the first-60-seconds of the demo from cold to warm. The named-decisions output signals the rep is treating the meeting as a working session, not a sales pitch.

**Sample:** Subject: "Tomorrow 2pm — audit-trail demo + 3 decisions for Pacific Banc." Opening: "Following up on the exception-handling cycle-time gap your team flagged on May 28." Agenda: see the audit trail on your actual workflow, confirm the integration shape, agree on next gate. Two prep questions, two artifacts inline.

**Metric moved:** Demos preceded by a structured pre-recap email convert 1.3x more often (Chris Orlob's Sales Hacker 2025 first-meeting analysis).

Most post-demo emails are "thanks, attaching deck." The champion archives them. This prompt writes two coordinated artifacts: a post-demo summary email for the room, and a separate champion brief — the one-pager the champion forwards internally to activate the economic buyer.

**The prompt:**

``` You are a post-demo summary and champion-brief generator. INPUT: - Demo transcript or rep's structured notes (questions asked, value-confirmations received, objections raised): <text> - Artifacts shared during the demo: <list with URLs> - The single decision the buyer agreed to make next: <text> - The next gate's date: <date> - Champion's name and role: <text> - Stakeholders who did NOT attend and must be activated: <list with roles> OUTPUT (JSON): { "summary_email": { "subject_line": "<subject naming the next gate or decision>", "decision_tee_up": "<one paragraph: the decision the buyer is making, the criteria, the date>", "aligned_points": [<3-5 things both sides agreed on, named explicitly>], "answered_open_questions": [<each question with the answer inline>], "artifacts_attached": [<each artifact with one-line description>], "gated_next_step": "<the specific commitment, with date and named owner>", "full_email": "<300-400 words, forwardable as-is to absent stakeholders>" }, "champion_brief": { "format": "one-page document the champion forwards internally", "top_of_page": "<the buyer's KPI, current baseline, target — in their language>", "decision_criteria_map": [<each criterion + whether the product meets it + the proof>], "objection_pre_handles": [<the 3 objections likely from absent stakeholders, with strong responses>], "artifacts_for_each_absent_stakeholder": [<per role: the one artifact that activates them>], "recommended_next_internal_step": "<the specific next move the champion takes — '20 min with VP Finance before June 24', not 'let's discuss'>", "full_one_pager": "<the document in champion-voice, ≤500 words, paste-ready into Slack or email>" } } Rules: - Subject line names the next gate or decision; "thanks for the time" is rejected. - Every open question must be answered inline. - The champion brief must be in champion-voice — paste-ready, no vendor-PR. - The brief must include a specific recommended internal step, not a generic "reach out." - Both artifacts must be forwardable as-is to stakeholders who didn't attend. ```

**Why it works:** Generating the champion brief alongside the summary email is the difference between a deal that stalls in absent-stakeholder review and a deal that the champion drives internally. The forwardable-as-is constraint blocks vendor-voice drift — the most common reason champion briefs sit in drafts.

**Sample:** Summary email subject: "Security review prep — 3 items before June 24." Champion brief top: KPI, baseline, target. Middle: 4 decision criteria with met/not-met + proof. Bottom: the specific 20-minute VP Finance ask and the ROI model link.

**Metric moved:** Demos with a forwardable champion brief close 1.7x more often and reduce time-to-close by 22% (Gong Labs 2025 close-rate analysis).

<a href="https://www.anthropic.com/claude?utm_source=aipromptshub&utm_medium=blog&utm_campaign=sales-demo-champion-brief" style={{display:"inline-block",padding:"10px 18px",background:"#0a66ff",color:"white",borderRadius:"6px",textDecoration:"none",fontWeight:"bold",marginTop:"12px"}}> Run these prompts in Claude Pro → </a>

The chain that takes a demo from cold prep to closed champion brief:

1. **T-72 hours.** Prompt #1 (10-K research brief). Read filings; generate the do-not-say list. 2. **T-48 hours.** Prompt #2 (persona-tailored hooks). One per attendee + a shared hook. 3. **T-48 hours.** Prompt #3 (PICP storyboard). Build the demo arc. 4. **T-24 hours.** Prompt #4 (trim recommender). Default-cut the bloat; protect the 80/20 narrative-to-question ratio. 5. **T-24 hours.** Prompt #5 (value-confirmation banks). One bank per beat + closing question set. 6. **T-24 hours.** Prompt #6 (objection-handle library). Second-monitor reference during the live demo. 7. **T-24 hours.** Prompt #7 (multi-thread map). Decide which introduction to ask for in-meeting. 8. **T-24 hours.** Prompt #8 (MAP outline). Send to champion the morning of, framed as de-risking. 9. **T-12 hours.** Prompt #9 (pre-recap email). Send the night before. 10. **T+2 hours.** Prompt #10 (post-demo summary + champion brief). Two artifacts, one cycle.

Prompts #1, #3, and #10 are the highest-ROI single fixes — if you only have an hour to prep, run those three. Sonnet 4.5 handles all ten; Opus 4.7 is worth it on prompt #1 (filings synthesis) and prompt #3 (insight generation) where depth beats speed.

<a href="https://www.anthropic.com/claude?utm_source=aipromptshub&utm_medium=blog&utm_campaign=sales-demo-prompts-chain" style={{display:"inline-block",padding:"10px 18px",background:"#0a66ff",color:"white",borderRadius:"6px",textDecoration:"none",fontWeight:"bold",marginTop:"12px"}}> Get Claude Pro for the full chain → </a>

### Which Claude model should I use for these sales-demo prompts?

Sonnet 4.5 handles prompts 2, 4, 5, 6, 7, 8, 9, 10 — structured rewrites and generation with explicit constraints. Use Opus 4.7 on prompt #1 (10-K research brief, long-context filings synthesis) and prompt #3 (PICP storyboard, insight generation benefits from depth). See Anthropic models for the current lineup.

### Can I run these prompts without uploading customer data to a third-party LLM?

Yes. Every prompt accepts redacted or summarized inputs. For sensitive accounts, replace customer names with role descriptors ("VP Finance at a top-10 US regional bank"), replace specific numbers with banded ranges, and strip identifiers before pasting. The structural outputs still work; the defensibility holds.

### How is this different from a generic demo-script generator?

Generic generators produce a script. These prompts produce ten coordinated artifacts — research brief, hooks, storyboard, trim list, question banks, objection library, thread map, MAP, pre-recap, post-recap — structured against named methodologies (JBarrows, MEDDIC-adjacent qualification, Gong-grade structural rules). The output is the demo cycle, not a single document.

### What if the buyer is private and there's no 10-K for prompt #1?

Substitute the closest public artifact: an S-1 if pre-IPO, a recent press release set, an earnings-call equivalent from a publicly-traded comparable. The prompt is structured to surface signal from any rep-supplied corpus; the rule is "every claim has a source." If no defensible source exists, prompt #1 outputs a smaller brief and flags the gap — better than fabricated context.

### How do I keep these prompts honest under sales pressure?

Three guardrails. (1) Do-not-say lists are non-negotiable. (2) Concession requirements in prompt #6 prevent the vendor-PR drift that kills credibility under quota pressure. (3) The champion-brief forwardable-as-is constraint catches vendor-voice slip — if you wouldn't paste it into your champion's email, the model rewrites.

### Are the sample buyers and numbers from real demos?

Sample scenarios are composites from common patterns; specific customer names and numbers in the samples are illustrative. The structural outputs are representative of what the prompts produce when run on Sonnet 4.5 with realistic discovery notes — the framework is real, the numbers should be replaced with the rep's verified data before use.

### Can I use these on partner-led demos where I'm not the primary presenter?

Yes — and it's the highest-yield use case for ride-along sellers. Run prompts #1, #3, and #7 to brief the partner; run prompt #10 immediately after for the coordinated follow-up. Even if the partner runs the live narrative, your post-demo champion brief is what determines whether the deal survives the next gate.

- Gong Labs sales research — recorded B2B sales calls; demo-conversion analysis, win/loss findings, attention-budget data, close-rate analysis. - Chris Orlob, Sales Hacker analyses — 67,000 recorded demos; first-call structure, value-confirmation patterns, single-threading risk. - JBarrows Sales Training methodology — problem-insight-capability-proof demo arc, value-confirmation question structure. - Anthropic prompt engineering documentation — Claude prompt best practices for structured rewrite tasks. - Anthropic model documentation — Sonnet 4.5 / Opus 4.7 selection.

---