Fab Statement Classifier

Classify seller statements as Features, Advantages, or true Benefits using Rackham's strict FAB definitions. Use this skill to audit a pitch deck, sales emai...

Security Scan

This is an instruction-only FAB classification skill whose requested permissions and runtime behavior match its stated purpose — it does not install code or ask for credentials — but it will need access to whatever documents you ask it to read (decks, emails, transcripts).

Purpose & Capability

The skill's name and description (classifying seller statements into Feature/Advantage/Benefit using Rackham's rules) match the SKILL.md instructions and included references. It is an audit/classification tool and does not request unrelated capabilities, binaries, or credentials.

Instruction Scope

The SKILL.md instructs the agent to read provided seller content and optional deal context (needs-log.md) to determine whether a statement meets Rackham's Explicit Need requirement for a Benefit. All referenced paths and actions (classify statements, produce counts, run a 10-item quiz) are consistent with the described purpose. Note: the skill requires the agent to read user-supplied documents (decks, transcripts, emails), which may contain sensitive customer data — the SKILL.md does not attempt to access other system state or unrelated files.

Install Mechanism

No install spec, no code files to install. This is an instruction-only skill (lowest install risk).

Credentials

The skill requires no environment variables, credentials, or config paths. It does declare a dependency on another skill (need-type-classifier) to verify Explicit Needs — that dependency is logical for the stated purpose but you should inspect that dependent skill before enabling if you want to confirm its permissions and behavior.

Persistence & Privilege

always:false and no elevated privileges are requested. The skill needs Read/Write tools to operate on documents you provide; autonomous invocation is allowed (platform default) but is not combined with any other broad privileges here.

Assessment

This skill is coherent and low-risk from a security/permissions perspective, but consider the following before installing or running it: 1) It needs access to the documents you want audited (pitch decks, emails, call transcripts). Only grant it access to files you intend to share and avoid sending sensitive PII or customer-protected data unless you are comfortable with that processing. 2) The skill depends on a separate need-type-classifier skill to detect Explicit Needs — review that dependent skill's manifest and permissions to ensure it doesn't request unexpected credentials or external network access. 3) Because the skill includes verbatim Rackham examples and references, check any licensing or IP requirements your organization enforces if you plan to redistribute the skill or its outputs. 4) If you plan to run the skill autonomously over a large document set, restrict the file scope and monitor outputs so confidential data is not inadvertently aggregated or exported.

When to Use

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:

• Before a major demo or proposal, to verify the content contains true Benefits (not just Advantages)
• After a call where you received value objections or "it's not worth it" responses — these are the customer response most correlated with Advantage-heavy selling
• When marketing reviews collateral for use in large-sale contexts
• When coaching a rep who claims their deck is "benefit-focused"

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).

Context & Input Gathering

Required Context (must have — ask if missing)

• Seller content to audit: The actual statements you want classified -> 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."

• Sale context (large vs small): Determines how strictly to apply the Benefit gate -> 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)

Observable Context (gather from environment)

• Needs log or deal brief: Explicit Needs the customer has expressed -> 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)

• Mode check: Is this an audit of existing content, or an interactive quiz? -> 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

Sufficiency Threshold

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

Process

Step 1: Establish the Classification Framework

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.

• Test: "Is this just describing what the product is or what it includes?" → Feature

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.

• This is what most sales training calls a "Benefit." It is not a Benefit in Rackham's taxonomy.
• Test: "Does this show how the product helps, but without a prior customer-expressed want?" → Advantage

Benefit (Rackham's Type B) — A statement showing how the product meets an Explicit Need that the customer has expressed. Both conditions required:

1. The customer stated a specific want, desire, or intention before this statement
2. This statement shows the product meets that specific expressed need

• Test: "Did the customer explicitly say they need/want this? AND does this statement show we can deliver it?" → Benefit

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.

Step 2: Identify Explicit Needs in the Context

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).

Step 3: Classify Each Statement

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:

1. Statement (quoted or paraphrased if long)
2. Classification: Feature / Advantage / Benefit / Unclassifiable
3. Explicit Need present: Yes (quote it) / No
4. Rationale: one sentence explaining the classification

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.

Step 4: Produce the Count Summary and Anti-Pattern Flag

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:

• Total statements audited: N
• Features: N (N%)
• Advantages: N (N%)
• True Benefits (Rackham): N (N%)
• Unclassifiable: N (N%)

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).

Step 5: Coaching — Converting Advantages to Benefits

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.

Step 6: Write the Audit Report

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}

Optional: Interactive Practice Mode

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.

Key Principles

• A Benefit requires customer speech first. No matter how aspirational, customer-focused, or value-oriented a statement sounds, it is an Advantage unless the customer has expressed the underlying want in their own words before the statement was made. Pitch decks, by their nature, cannot contain true Benefits — they are written before the customer has spoken. They contain Features and Advantages at best.

• The naming confusion is the problem. Decades of sales training have used the word "Benefit" to mean what Rackham calls an Advantage. Sellers who were well-trained in "Feature-Benefit selling" are actually Feature-Advantage sellers. Rackham's 5,000-call study showed that what most people call Benefits have no statistical relationship to large-sale success. True Benefits — those meeting customer-expressed Explicit Needs — are strongly correlated with Orders and Advances.

• Advantages create objections in large sales. Linda Marsh's correlation study showed that Advantages are the most probable source of customer objections. When a seller presents a capability the customer hasn't asked for, the customer evaluates whether it's worth the cost — and in large sales, "not worth it" is a likely response. This is why objection-heavy calls are typically Advantage-heavy calls.

• More Features → more price sensitivity. From the 18,000-call Features study: heavy use of Features increases customer sensitivity to price. In expensive products, this works against the seller. When classified Features are high, advise shifting from description to need development.

• Development precedes Benefits. Rackham's advice: "Do a good job of developing Explicit Needs and the Benefits almost look after themselves." You cannot manufacture Benefits from content alone — you develop them from customer conversations. The audit's purpose is to show what's missing and guide what needs to be developed before the content can be benefit-loaded.

• Stay in scope. This skill classifies existing content. It does not draft new statements (use 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.

Examples

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:

• (Step 1) Load FAB definitions.
• (Step 2) Read needs-log.md — 2 Explicit Needs documented: "We need to cut monthly close from 5 days to 2" and "We need a single dashboard for all 3 regions."
• (Step 3) Classify all 15 slides' key statements. Find: 6 Features (product specs, pricing, company stats), 8 Advantages ("helps your team move faster," "gives you complete visibility," "reduces guesswork"), 1 Benefit (the single-dashboard claim meets the stated Explicit Need), 0 unclassifiable.
• (Step 4) Count: 40% Features, 53% Advantages, 7% Benefits. Flag: 8 statements the seller labeled "Benefits" in the deck are Advantages.
• (Step 5) For each of the 8 Advantages, provide a coaching note on what Explicit Need to develop.
• (Step 6) Write 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:

• (Step 1) Load definitions.
• (Step 2) No needs log — cold outreach, no prior customer speech. Note: no Explicit Needs available → no Benefits possible.
• (Step 3) Read the email. Find: 3 Features (product specs), 4 Advantages ("so you can close deals faster," "giving your team complete pipeline visibility," "cutting your reporting time by 50%"), 0 Benefits (no customer has spoken).
• (Step 4) Count: 43% Features, 57% Advantages, 0% Benefits. Flag: a cold email structurally cannot contain Benefits — the customer hasn't spoken yet. All value claims are Advantages.
• (Step 5) Coach: the email is Advantage-heavy, which in cold outreach is normal but not maximally effective. Recommend opening with a Problem Question or a specific Implied Need trigger ("If your team is finding that...") to earn a reply, then developing needs in the first call before giving Benefits.

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.

References

• fab-classification-quiz.md — Rackham's 10-item FAB classification exercise with full answer key and scoring guide
• fab-definitions-and-edge-cases.md — Complete FAB definitions, research findings, edge cases, and the FAB-to-customer-response chain (Features → price concerns; Advantages → objections; Benefits → approval)

License

This skill is licensed under CC-BY-SA-4.0. Source: BookForge — SPIN Selling by Neil Rackham.

Related BookForge Skills

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