sales-enablement v1.0.0

name: "sales-enablement" description: "Build and maintain a full sales asset system: pitch decks, one-pagers, objection-handling docs, battle cards, demo scripts, and the versioning discipline that keeps every asset current. Use when someone needs sales collateral built from scratch, an asset audit, or a demo script for a product."

Sales Enablement

Purpose

Turn product and positioning into assets a sales team can actually use in live deals: a modular pitch deck, one-pagers a champion can forward, objection docs that give reps the same accurate line every time, battle cards that survive real conversations, demo scripts with a locked click path, and a review cadence so nothing goes stale.

This is a system, not a checklist. A checklist gives you the asset names. This gives you the asset names, the structure of each one, a worked example of each one, and the maintenance discipline that keeps them trustworthy.

Workflow

1. Intake: get the five facts before building anything

Do not write a single word of collateral without these. Ask if missing:

1. Product and buyer. What is sold, and who buys it (titles, not "decision makers").
2. Stage. Which part of the deal is this asset for: discovery, evaluation, validation, close, post-sale.
3. Persona. The same deck fails for a CTO and a CFO. Name the primary reader.
4. Competitor or objection. Is this for a competitive deal, a specific recurring objection, or both.
5. Proof. Approved case studies, metrics, customer names. Anything that cannot be verified gets cut or framed as opinion. No confident unverified claims, ever.

2. Inventory the asset set

Map assets to deal stages. Build only what the stage needs.

| Stage | Buyer question | Build | |---|---|---| | Discovery | Is this worth my time? | Qualification questions, industry point-of-view one-pager | | Evaluation | How do you stack up? | Modular pitch deck, battle cards, product one-pagers, demo script | | Validation | Can I defend this internally? | Case studies, ROI model, objection-handling doc, reference stories | | Close | Is this safe to sign? | Security and procurement FAQ, contract template, mutual action plan | | Post-sale | Did we make the right call? | QBR deck, expansion one-pager, onboarding checklist |

See references/asset-map.md for the full map with rep goals per stage.

3. Build each asset from its template

• Pitch deck: 12-slide arc (title, problem, cost of the problem, the shift/why now, the big idea, product walkthrough of 3-4 workflows, proof points, one case study, ROI scenarios, pricing overview, next step). Corporate Visions progression: why change, why you, why now, why pay. See references/pitch-deck.md for the worked example.
• One-pager: problem, outcome, how it works, one proof point, CTA. Layout guidance and a worked example in references/one-pager.md.
• Objection-handling doc: categories (price, timing, authority, need, trust), each entry as objection / what they really mean / acknowledge-reframe-proof response / follow-up question / proof point. Worked entries in references/objection-handling.md.
• Battle card: honest strengths of the competitor, evidenced weaknesses, differentiator table, landmine questions, and "when you'll lose." A card a rep can scan in ten seconds. Template and worked example in references/battle-card.md.
• Demo script: lock 3-5 key moments, note every click in order, open with the outcome (tell-show-tell), time it, script the yield-and-pivot close. Worked script in references/demo-script.md.

4. Assemble the library and hand it over

Organize the library by buyer stage, not by file type. A rep in a live deal should filter to the stage they are in and see exactly the assets that fit. Include a one-page index (what lives where, who owns it, last review date). Drop the assets/asset-inventory.csv template into the project and fill it in.

5. Install the versioning discipline

Every asset gets: an owner, a review cadence (quarterly for pricing and battle cards, on-change for product facts), and a changelog entry when updated. Stale battle cards lose deals; retire or refresh anything older than its cadence. The full maintenance routine is in references/asset-versioning.md.

Output Contract

When building an asset, deliver the asset itself, fully written:

• Deck: slide-by-slide outline with headline, body copy, and speaker notes per slide.
• One-pager: full copy plus layout guidance (visual hierarchy, sections).
• Objection doc: table of objection, response, proof point, follow-up.
• Battle card: single scannable page, consistent sections.
• Demo script: scene-by-scene with timing, talk track, and click path.
• Library handoff: asset inventory CSV filled in, plus the maintenance schedule with owners and review dates.

Operating Rules

1. One asset per persona per stage. A generic deck pleases nobody.
2. Write for scannability. Short sentences, clear headers, bullets. If a rep cannot find the answer in ten seconds, the asset will go unused.
3. Be honest about the competition. Trash-talking costs credibility; acknowledging real strengths and landing real gaps wins.
4. Acknowledge every objection before answering it. "No, actually we're better because..." reads as defensive and reps will not use it.
5. Never invent proof. Every metric, customer name, and quote must come from an approved source or get cut.
6. The library is a product. Unused or outdated assets get retired on a schedule, not "whenever."