You have seller content — a pitch deck, sales email, demo script, or call transcript — and you need to know: are these statements Features, Advantages, or true Benefits?
This matters because the most common error in B2B sales content is calling Advantages "Benefits." Rackham's 5,000-call study found that Advantages (what most training calls "Benefits") had no statistically significant relationship to success in large sales — but true Benefits were strongly linked to Orders and Advances. The distinction is not semantic. It predicts whether your content will close deals or generate objections.
Use this skill:
Interactive practice mode: If you want to self-test your FAB classification ability, ask the skill to run Rackham's 10-item quiz. The full quiz with answer key is in references/fab-classification-quiz.md.
Do NOT use this skill to draft new Benefit statements (use benefit-statement-drafter) or to generate questions to develop needs (use spin-discovery-question-planner).
-> Check prompt for: pasted text, file path, or slide content
-> Check environment for: pitch-deck-{deal}.md, sales-email.md, demo-script.md, call-transcript-{date}.md
-> If missing, ask: "Paste or point me to the seller statements you want me to classify."
-> Check prompt for: enterprise/SMB label, deal size, multi-stakeholder mention
-> Check environment for: deal-brief.md
-> If missing: default to large-sale context (conservative — prevents overstating Benefits)
-> Look for: needs-log.md from need-type-classifier, deal-brief.md
-> If available: use it to verify Benefit candidates — a statement meets an Explicit Need only if that need is documented as expressed by the customer
-> If unavailable: note the absence; any statement claiming to meet a need will be classified as Advantage unless the customer's Explicit Need is visible in the content itself (e.g., in a call transcript where both sides speak)
-> Audit mode: read the provided content, classify each statement, produce fab-audit-{artifact}.md
-> Quiz mode: deliver the 10-item Rackham quiz, collect answers, give scored feedback
SUFFICIENT: Seller content + sale context (or default to large)
PROCEED WITH DEFAULTS: Content present, no needs log (classify all statements without confirmed Explicit Needs as Advantages with a note)
MUST ASK: No seller content provided AND no quiz mode requested
ACTION: Before classifying any statement, confirm the three definitions below. Apply them exactly as written.
WHY: The entire value of this audit depends on using Rackham's strict definitions, not the common-usage definitions. Most sellers have been trained that "a Benefit is anything that shows how a feature can help the customer" — this is what Rackham calls an Advantage. If this step is skipped, every subsequent classification defaults to the casual definition and the audit produces no new information.
The three definitions:
Feature — A fact, data point, or characteristic about the product or service. Does not explain use or link to customer outcomes. Neutral in impact.
Advantage — A statement showing how a product feature can be used or can help the customer. More than a Feature — links capability to potential value. BUT: does not meet a customer-expressed Explicit Need.
Benefit (Rackham's Type B) — A statement showing how the product meets an Explicit Need that the customer has expressed. Both conditions required:
Unclassifiable — A statement that cannot be evaluated without more context (e.g., a question, a transition phrase, a non-product statement).
Step 1 output: Confirm the three definitions are loaded before proceeding.
ACTION: Before classifying individual statements, scan the available context (needs-log, deal brief, or transcript) for any customer-expressed Explicit Needs. List them. These are the only valid anchors for Benefit classifications.
WHY: The classification of any statement as a Benefit requires a prior customer-expressed Explicit Need. Without identifying those first, there is no reference point — every statement defaults to Feature or Advantage. This step also prevents the common error of using Implied Needs (problems, difficulties) as Benefit anchors. If you need to verify whether a specific customer statement is an Explicit Need, invoke need-type-classifier or apply its definitions directly: an Explicit Need is a statement of want, desire, or intention ("we need X," "we're looking for Y," "I'd like Z") — not a statement of problem or dissatisfaction.
IF a needs-log.md exists from a prior need-type-classifier run → read it and extract the Explicit Needs column
ELSE IF the content being audited is a call transcript (both sides visible) → scan buyer statements for Explicit Need language
ELSE → note that no confirmed Explicit Needs are available; proceed with the understanding that Benefit classifications will be rare or absent
Step 2 output: A short list of confirmed Explicit Needs available in context (may be empty).
ACTION: For each seller statement in the provided content, apply the definitions from Step 1, anchoring to the Explicit Needs from Step 2. Produce a per-statement classification table.
WHY: Showing the classification evidence per statement makes the output auditable. The seller needs to see exactly which words triggered each classification — especially for statements they labeled Benefits that are actually Advantages. Without this granularity, coaching is abstract; with it, the seller can rewrite specific statements.
For each statement, output:
The dominant pattern to flag: Statements containing phrases like "so you can," "which means you'll," "helping your team," "giving you the ability to," "enabling you to" are structural markers of Advantages. They show use or help — but unless paired with a prior customer-expressed want, they are Advantages, not Benefits. Flag these explicitly when the seller has labeled them Benefits.
Step 3 output: Classification table, one row per statement.
ACTION: Summarize the classification results. Count Features, Advantages, Benefits, and Unclassifiable. Flag the Advantage-as-Benefit anti-pattern if present.
WHY: The count summary makes the FAB distribution visible at a glance. Most sellers are surprised by how few true Benefits their content contains. A deck with 15 statements that the seller calls "benefit-focused" typically contains 0-2 true Benefits, 8-10 Advantages, and 4-5 Features. Showing this quantitatively is more persuasive than qualitative criticism.
Count summary format:
Advantage-as-Benefit flag: If any statement was labeled a "Benefit" by the seller (in the deck or script) but classified as an Advantage by this audit, call this out explicitly:
> "WARNING: N statements labeled 'Benefits' in this content are Advantages by Rackham's definition. They show how the product can help but do not meet a customer-expressed Explicit Need. In large sales (5,000-call study), Advantages have no statistically significant relationship to call success. True Benefits require a prior Explicit Need from the customer."
Step 4 output: Count summary + anti-pattern flag (if applicable).
ACTION: For each statement classified as Advantage, provide a one-line coaching note: what Explicit Need the customer would need to express before this Advantage could become a Benefit, and how to develop that need.
WHY: The audit is only useful if it tells the seller what to do next. "This is an Advantage, not a Benefit" is a diagnosis. The prescription — "here's the Explicit Need you'd need to develop before presenting this" — is what makes the content actionable. Without this step, the seller knows their deck is weak but not how to fix it.
Coaching note format (per Advantage):
> Statement: "[statement]"
> To become a Benefit, your customer would need to have said something like: "[example Explicit Need in customer's words]"
> How to develop it: Ask [Problem Question to surface Implied Need] → [Implication Question to build consequence] → [Need-payoff Question to get the customer to articulate the want]. Then present this capability as directly meeting their stated need.
Step 5 output: Per-Advantage coaching notes.
ACTION: Compile Steps 3-5 into a single structured report. Write it to fab-audit-{artifact}.md (e.g., fab-audit-q2-deck.md, fab-audit-discovery-email.md).
WHY: A written report persists across the conversation and can be shared with the team. It also feeds downstream skills: benefit-statement-drafter reads a needs log and the audit to draft Benefits for the confirmed Explicit Needs; objection-source-diagnoser reads the audit to trace objections back to FAB source.
Report structure:
# FAB Audit — {Content Name} — {Date}
## Sale Context
{Large / Small / Unknown}
## Explicit Needs Available
{List, or "None confirmed — all Benefits require Explicit Need development first"}
## Statement-by-Statement Classification
| # | Statement | Classification | Explicit Need Present | Rationale |
|---|---|---|---|---|
## FAB Distribution Summary
- Features: N (N%)
- Advantages: N (N%)
- True Benefits: N (N%)
## Advantage-as-Benefit Flag
{If applicable: which statements were miscategorized, and why it matters}
## Coaching: Converting Advantages to Benefits
{Per-Advantage coaching notes}
## Recommended Next Step
{One paragraph: what the seller should do before the next call/send}
ACTION: If the user asks to test their own FAB classification ability, deliver Rackham's 10-item quiz from references/fab-classification-quiz.md. Present all 10 statements, collect the user's answers, then score and explain each one.
WHY: The quiz uses a real selling dialogue with deliberate classification traps (especially #7 and #10, which sound like Benefits but are Advantages). Users who pass it — especially #7 — have internalized the Type A/Type B distinction. The quiz also grounds future audits in shared vocabulary.
benefit-statement-drafter), generate questions to develop needs (use spin-discovery-question-planner), or diagnose objections in depth (use objection-source-diagnoser). When the audit points to a development gap, name the right skill.Scenario: Pitch deck audit before a major enterprise demo
Trigger: AE says: "I'm presenting a 15-slide deck tomorrow. Can you check if it's benefit-focused?"
Process:
fab-audit-q2-demo-deck.md.Output: Audit report showing 1 confirmed Benefit, 8 Advantages mislabeled as Benefits, 6 Features. Recommendation: develop 1-2 more Explicit Needs on the pre-call before tomorrow — at minimum, convert the "monthly close" Advantage into a Benefit by confirming the need directly.
Scenario: Sales email review
Trigger: SDR asks: "Is this prospecting email too feature-heavy? I'm not getting replies."
Process:
Output: fab-audit-prospect-email.md. Coaching: shift the email to problem-focused language (what problem do they probably have?) rather than solution-focused language (what can our product do?). Follow up with spin-discovery-question-planner for the first call.
Scenario: Interactive quiz practice
Trigger: "I want to test my FAB classification. Give me the quiz."
Process: Present the 10-item dialogue from references/fab-classification-quiz.md. Collect answers. Score. For any misclassified items, explain the rule that applies — especially items 7 and 10, which are the traps (they sound like Benefits, but no Explicit Need was expressed).
Output: Score (X/10). Detailed feedback on any misses. Particular emphasis if the user called #7 or #10 a Benefit — these are the most common errors and map directly to the Advantage-as-Benefit anti-pattern in real sales content.
This skill is licensed under CC-BY-SA-4.0.
Source: BookForge — SPIN Selling by Neil Rackham.
This skill depends on:
clawhub install bookforge-need-type-classifier — Classify customer statements as Implied or Explicit Needs (needed to verify whether an Explicit Need exists before classifying a statement as a Benefit)Skills that build on this one:
clawhub install bookforge-benefit-statement-drafter — Draft Benefit statements that link product capabilities to customer-expressed Explicit Needs (the constructive complement to this audit skill)clawhub install bookforge-objection-source-diagnoser — Trace objections back to their FAB-behavior root cause (Feature → price concerns; Advantage → value objections)Or install the full SPIN Selling skill set from GitHub: bookforge-skills
共 1 个版本
暂无安全检测报告