Skill: quochungto/bookforge-spin-discovery-question-planner (version 1.0.0)

--- name: spin-discovery-question-planner description: "Plan Situation, Problem, Implication, and Need-payoff (SPIN) questions for a specific B2B sales call. Use this skill whenever a sales rep wants to prepare discovery questions for an upcoming meeting, when someone asks 'what should I ask in this call?', when planning questions for a deal in any industry, when drafting Implication questions for a complex sale, when prepping for a discovery call with a prospect, when a seller wants to go into a meeting with a structured question bank instead of winging it, or when a rep has a call next week and needs help thinking through what to ask. This skill applies Rackham's empirically-validated SPIN methodology — specifically including the 3-step Implication question planning sub-workflow (problem → related difficulties → questions) that makes the hardest question type executable. The output is NOT a generic discovery checklist: it is a planned conversation with branches, Implication chains, and Need-payoff conversion moves tied to specific likely customer problems and product capabilities the seller can actually deliver." version: 1.0.0 homepage: https://github.com/bookforge-ai/bookforge-skills/tree/main/books/spin-selling/skills/spin-discovery-question-planner metadata: {"openclaw":{"emoji":"❓","homepage":"https://github.com/bookforge-ai/bookforge-skills"}} status: draft source-books: - id: spin-selling title: "SPIN Selling" authors: ["Neil Rackham"] chapters: [4] domain: b2b-sales tags: [sales, b2b-sales, enterprise-sales, discovery, spin-methodology, questioning-techniques, implication-questions, need-payoff, pre-call-planning] depends-on: - need-type-classifier execution: tier: 1 mode: plan-only inputs: - type: document description: "deal-brief.md — company, contact, deal stage, deal size, what is known so far" - type: document description: "product-capabilities.md — what the seller's product can and cannot do" - type: document description: "account-research.md — company background, priorities, recent news (optional but valuable)" - type: document description: "needs-log.md — Implied/Explicit needs from prior calls (if this is a follow-up call)" tools-required: [Read, Write] tools-optional: [Grep] mcps-required: [] environment: "Document set: deal-brief.md, product-capabilities.md, account-research.md (optional), needs-log.md (optional). Agent produces question-bank-{deal}-{date}.md. Human asks the questions on the actual call." discovery: goal: "Produce a pre-call question bank organized by SPIN type, with Implication chains planned in advance and Need-payoff questions ready to deploy when needs are confirmed" tasks: - "Plan Situation Questions that establish context without boring the buyer" - "Plan Problem Questions to surface 3+ specific likely problems this prospect may have" - "Apply the 3-step Implication planning sub-workflow for each problem: consequences → questions" - "Plan Need-payoff Questions keyed to capabilities the seller can actually deliver" - "Produce a sequence guide: when to move from S → P → I → N, and when to loop back" audience: roles: [account-executive, enterprise-sales-rep, sdr, solutions-consultant, founder-led-seller] experience: intermediate when_to_use: triggers: - "Rep has a discovery or follow-up call coming up and needs to plan questions" - "Seller wants to move beyond 'winging it' and into structured discovery" - "Manager is coaching a rep on how to develop Implication questions" - "Preparing for a call with a decision-maker who responds to implications, not features" prerequisites: - "Some knowledge of the prospect's business situation (even basic) — gathered from deal-brief.md, public research, or prior calls" - "Knowledge of what capabilities the seller's product offers" not_for: - "Classifying customer responses during or after the call (use need-type-classifier)" - "Drafting Benefit statements after Explicit Needs are confirmed (use benefit-statement-drafter)" - "Classifying whether a call outcome was an Advance or Continuation (use call-outcome-classifier)" environment: codebase_required: false codebase_helpful: false works_offline: true quality: scores: with_skill: 0 baseline: 0 delta: 0 tested_at: "" eval_count: 0 assertion_count: 0 iterations_needed: 0 what_skill_catches: - "Output organizes questions by SPIN type, not as a flat generic list" - "Implication questions are derived from specific problems via the 3-step sub-workflow" - "Need-payoff questions are keyed to capabilities the seller can actually deliver" - "Sequence guide tells the rep when to transition between question types" - "Anti-pattern warnings prevent over-asking Situation Questions and premature Need-payoff" what_baseline_misses: - "Produces a flat list of generic open questions with no internal structure" - "Implication questions are filler ('why does that matter?') not consequence chains" - "Need-payoff questions appear before the need has been developed" - "No guidance on sequence, branching, or when to transition between types" --- # SPIN Discovery Question Planner ## When to Use You have a B2B sales call coming up — discovery, follow-up, or executive conversation — and you want to go in with more than good intentions. This skill produces a pre-call question bank organized by SPIN type (Situation, Problem, Implication, Need-payoff) with Implication chains planned in advance and Need-payoff questions ready to deploy once a need is confirmed. Use this skill when: - Preparing for a discovery call with a new prospect or existing account - Coaching a rep to plan questions for a specific deal - Moving from a generic question list to a structured conversation with branches - Dealing with a decision-maker (Implication Questions are especially powerful with people who think in consequences and effects) **Critical prerequisite:** Before deploying Need-payoff Questions from this plan on an actual call, use `need-type-classifier` to verify that customer responses represent Implied Needs that have been sufficiently developed — or Explicit Needs that are ready for conversion. The question bank is a plan; what the customer says on the call determines where you actually go. This skill is OUT OF SCOPE for: classifying customer responses (use `need-type-classifier`), drafting Benefit statements (use `benefit-statement-drafter`), or assessing whether a call outcome was an Advance (use `call-outcome-classifier`). ## Context & Input Gathering ### Required Context (must have — ask if missing) - **Deal context:** Who is the prospect? What's the deal stage? What do we know about their situation? -> Check environment for: `deal-brief.md` -> If missing, ask: "Tell me about the deal — company, contact role, what stage you're at, and what you already know about their situation." - **Product capabilities:** What can your product solve? What can it NOT solve? -> Check environment for: `product-capabilities.md` -> If missing, ask: "What are the main problems your product solves? Are there any capabilities it definitely does not cover?" ### Observable Context (gather from environment) - **Account research:** `account-research.md` — company priorities, recent news, competitors -> If available: use to hypothesize likely problems. If unavailable: use deal-brief plus industry knowledge. - **Prior needs log:** `needs-log.md` — Implied/Explicit needs from previous calls -> If available: read it. If some Implied Needs are already identified, the Implication chain work is partially done — plan questions to develop them further or convert them. -> If unavailable: treat this as a first call; hypothesize likely problems from scratch. - **Call type:** New account (first contact) vs follow-up call -> If first contact: more Situation Questions are appropriate — you have less background -> If follow-up: reduce Situation Questions aggressively; move faster to Problem → Implication ### Default Assumptions - Default to a **large-sale context** (high value, multi-stakeholder, relationship-dependent). In large sales, Implied Needs alone do not predict success; they must be developed into Explicit Needs before presenting solutions. - Default to **not presenting solutions** in the question bank. This is a plan-only output; Benefit statements come after Explicit Needs are confirmed on the call. ### Sufficiency Threshold SUFFICIENT: Deal context + product capabilities → produce full question bank PROCEED WITH DEFAULTS: Only deal context known, no product capabilities → produce Problem + Implication plans, note that Need-payoff questions require capability mapping MUST ASK: No deal context at all (no account, no call objective, no product) ## Process ### Step 1: Establish Deal Context and Confirm the Large-Sale Gate **ACTION:** Read available deal documents or gather from the user. Confirm: is this a large sale (high value, multiple stakeholders, long cycle) or a small/transactional sale? Note the call type (new account vs follow-up) and what has already been uncovered. **WHY:** The entire SPIN question sequence is designed for large sales. If this is a small sale (low value, single decision-maker, one-call close), Implication Questions are useful but not as critical — Problem Questions alone can move the sale. In large sales, failing to develop Implied Needs into Explicit Needs before presenting solutions is the primary cause of price objections and stalled deals. Knowing the sale type calibrates how many Situation Questions to plan and how aggressively to build Implication chains. **Output:** A one-paragraph deal context summary: company, contact, stage, what is already known about problems or needs, and sale type (large/small). ### Step 2: Identify 3+ Likely Customer Problems Mapped to Your Capabilities **ACTION:** Based on the account research, deal brief, and product capabilities, write down at least three specific problems this customer is likely to have that your product or service can solve. These are hypotheses — you will surface and confirm them on the call. Do not include problems you cannot solve. **WHY:** This is the foundational planning step from the book's methodology: "Before the call, write down at least three potential problems which the buyer may have and which your products or services can solve." This step forces you to pre-qualify which problems are worth pursuing (you can solve them) and prevents two failure modes: (1) spending the call on Situation Questions that do not lead anywhere, and (2) accidentally developing a problem via Need-payoff Questions that you cannot address — which strengthens a need you cannot meet. **Format:** ``` Problem 1: [Specific problem — e.g., "Manual reporting process takes 2+ days per month"] -> Capability match: [What we can solve — e.g., "Automated report generation"] Problem 2: [...] -> Capability match: [...] Problem 3: [...] -> Capability match: [...] ``` Add additional problems if context supports them. ### Step 3: Plan Situation Questions (Limited Set) **ACTION:** For each problem identified in Step 2, plan 1-2 Situation Questions that establish the factual background needed to ask about that specific problem. Keep the total Situation Question list short (5-8 maximum for a new account call; 2-3 for a follow-up call). **WHY:** Situation Questions collect background facts. They serve the seller, not the buyer — buyers find them tedious when overused. Research on thousands of calls found that inexperienced sellers ask far more Situation Questions than experienced ones, and that excessive Situation Questions are negatively correlated with call success. The goal is to do homework before the call (reducing unnecessary fact-finding), then ask only the Situation Questions directly needed to set up a Problem Question. Think of Situation Questions as runway, not the flight. **Anti-pattern: Situation Question overload.** Detection signal: your Situation Question list has more than 8 items for a first call, or any for a follow-up where context is established. Fix: cut any Situation Question that doesn't directly enable a Problem Question you've already planned. **Format:** ``` Situation Questions for Problem 1: - "How does your team currently handle [process area]?" - "What system do you use for [relevant function]?" ``` ### Step 4: Plan Problem Questions for Each Identified Problem **ACTION:** For each problem in Step 2, write 2-3 Problem Questions that probe directly for that problem, difficulty, or dissatisfaction. These questions should invite the customer to express an Implied Need. **WHY:** Problem Questions are more strongly linked to sales success than Situation Questions, especially in smaller sales. In large sales, they provide the raw material — the Implied Needs — that Implication Questions will develop. Without Problem Questions, you have no foundation to build an Implication chain. The goal is to hear the customer say something like "Yes, that is a problem for us" — that statement is the Implied Need you will develop in the next step. **Format:** ``` Problem Questions for Problem 1: - "Are you finding [process area] takes longer than it should?" - "What difficulties do you run into when [specific situation]?" - "Is [current approach] creating any reliability or bottleneck issues?" ``` ### Step 5: Apply the 3-Step Implication Question Planning Sub-Workflow **ACTION:** For each problem identified in Step 2, apply this three-step method to generate a chain of Implication Questions: **Step 5a — Write down the problem:** State the specific Implied Need the customer might express (from your Problem Question above). Example: *"Our current system is hard for operators to use."* **Step 5b — Write down the related difficulties this problem leads to:** Ask yourself: what are the downstream consequences of this problem? Think broadly — cost, time, people, quality, risk, downstream processes, stakeholder impact. Be especially alert for implications that reveal the problem to be more severe than it initially appears. Example consequences: - Only 3 trained operators → creates bottleneck when one is absent - Bottleneck → overtime costs - Overtime → operator dissatisfaction → turnover - Turnover → retraining cost (estimate: $5,000/operator) - Sending work outside → quality risk, delivery delays **Step 5c — Write the questions each difficulty suggests:** For each consequence, write the Implication Question that surfaces it. These questions are problem-centered — they make the problem feel more serious. This is intentional: the customer must perceive the problem as large enough to justify the cost of solving it. Example questions: - "If you only have three trained operators, what happens when one is out sick or leaves?" - "How does that bottleneck affect your production schedules?" - "What does retraining a replacement operator cost you in wages and training fees?" - "When you send work outside, how does that affect your quality control?" **WHY this step is the hardest and most valuable:** Research found that only 1 in 20 questions asked in an average sales call is an Implication Question — not because sellers don't know they're useful, but because good Implication Questions require advance planning. They cannot be improvised reliably. The reason $120,000 solutions seem outrageous against a small Implied Need is that the buyer has not yet connected the Implied Need to its full cost. The Implication chain makes that connection explicit — not by manipulation, but by helping the buyer see the total size of the problem. This is also why Implication Questions are especially powerful with decision-makers: executives think in consequences and effects, not surface symptoms. **Apply Quincy's Rule to verify your Implication Questions:** Implication Questions should feel "sad" — they are problem-centered and make the problem more serious. If a question feels "happy" or solution-focused, it has drifted into Need-payoff territory. Reclassify it in the next step. **Format per problem:** ``` Problem 1 Implication Chain: Implied Need likely heard: "[Customer's words if the Problem Q works]" Related difficulties: - [Consequence A] - [Consequence B] - [Consequence C] Implication Questions: - "[Question surfacing Consequence A]" - "[Question surfacing Consequence B]" - "[Question surfacing Consequence C — if appropriate given conversation flow]" ``` ### Step 6: Plan Need-Payoff Questions Keyed to Deliverable Capabilities **ACTION:** For each problem, plan 2-3 Need-payoff Questions to ask after the Implication chain has developed the need. Each Need-payoff Question must map to a capability your product can actually deliver. **WHY:** Need-payoff Questions shift the conversation from problem-focused (which is "sad") to solution-focused (which is "happy"). They achieve two things simultaneously: (1) they focus the customer's attention on what a solution would mean for them — positive and constructive; (2) they get the customer articulating the benefits themselves. A customer who explains to you why your solution would help them is rehearsing the pitch they will later give to their internal stakeholders. This internal selling effect is a major reason Need-payoff Questions are so powerful in large, multi-stakeholder deals. **Critical restrictions:** - **Do not ask Need-payoff Questions before the need is developed.** If the Problem Question has just been asked and the customer has only given a mild Implied Need, the Implication chain must come first. Need-payoff before development produces customer defensiveness. - **Do not ask Need-payoff Questions for capabilities you cannot deliver.** If a customer raises a need you cannot meet and you ask "Why would that be important to you?" — you are strengthening a need you have no answer for. Ask Need-payoff Questions only where you have a capability match (Step 2). **Format per problem:** ``` Need-payoff Questions for Problem 1: (Ask only after Implication chain confirms the need is felt as serious) - "If you could eliminate [the core difficulty], what would that mean for your team?" - "Would it help you if [capability we offer]?" - "Is there any other way solving [problem] would benefit you?" ``` ### Step 7: Write the Sequence Guide and Branching Rules **ACTION:** Produce a one-page sequence guide for the call. This tells the seller: when to move from S → P, from P → I, from I → N, and when to loop back. **WHY:** The SPIN sequence is a guideline, not a rigid formula. Calls branch. The customer might open the call by volunteering an Explicit Need — in which case move directly to Need-payoff. They might raise a problem the seller cannot solve — in which case do NOT ask Need-payoff Questions. They might shut down after too many Implication Questions — in which case shift to Need-payoff earlier to restore positive energy. The sequence guide arms the seller with conscious decision rules rather than reactive improvisation. **Sequence guide format:** ``` CALL SEQUENCE GUIDE — [Deal Name] — [Date] Opening: [1-2 Situation Questions to establish context — see Step 3] ↓ Problem surfacing: Ask Problem Questions for Problem 1. If customer confirms → move to Implication chain. If customer denies or deflects → move to Problem Questions for Problem 2 or 3. ↓ Implication development: Work through the Implication chain for the confirmed problem. If customer language shifts from "it's a minor issue" to "actually, this is significant" → the need is developed enough. Move to Need-payoff. If customer seems uncomfortable or negative → move to Need-payoff earlier to shift energy. ↓ Need-payoff conversion: Ask Need-payoff Questions for the developed need. Get the customer talking about what a solution would mean for them. Only present a capability AFTER a Need-payoff Question has elicited a customer statement describing the value they want. That statement is the Explicit Need. ↓ If a second problem path is needed: repeat Problem → Implication → Need-payoff cycle. LOOP BACK SIGNALS: - Customer raises a new problem mid-Implication chain → finish current chain or note the new problem and return to it. Do not abandon a chain once started. - Customer raises a need you cannot meet → do NOT ask Need-payoff Questions. Acknowledge and redirect to a need you can meet. - Call is running short → compress by combining Implication Questions and moving to Need-payoff faster. Never skip the Problem Questions — they are the foundation. ``` ### Step 8: Write the Question Bank File **ACTION:** Compile all outputs from Steps 2-7 into a single file: `question-bank-{deal}-{date}.md`. The file should be readable in 5 minutes before the call starts. **WHY:** A written artifact carries the work forward. Without it, the planning exists only in this conversation. The question bank is also the input to `spin-skill-practice-coach` if the rep wants to learn from the call afterward, and to `sales-call-plan-do-review-coach` for a full Plan-Do-Review cycle. ## Key Principles - **Implication Questions require advance planning.** They are the most powerful question type in large sales — and the hardest to generate under fire. Research found only 1 in 20 questions asked in an average call is an Implication Question. The 3-step sub-workflow (problem → consequences → questions) is the only reliable way to have good Implication Questions ready before the call. Sellers who skip this step improvise generic probes that do not build a consequence chain. - **Need-payoff Questions only work when the need is developed.** A Need-payoff Question asked against a mild, undeveloped Implied Need produces price shock ("$120,000 just to make a machine easier to use?"). The same question asked after a thorough Implication chain — where the buyer has walked through $25,000 in training costs, expensive overtime, and quality failures from work sent outside — produces the opposite reaction. The problem is now large enough to make the solution feel justified. - **Situation Questions serve you, not the buyer.** Do your homework before the call. Every Situation Question you eliminate through pre-call research is a question that doesn't bore your prospect. Experienced sellers ask far fewer Situation Questions than inexperienced ones — they move faster to problems because they have prepared better. - **Never ask Need-payoff Questions for capabilities you cannot deliver.** When a customer raises a need you cannot meet, do NOT ask "Why is that important to you?" — you will strengthen a need that will become an objection you cannot answer. Redirect to a need within your capability set. - **The SPIN sequence is a map, not a script.** Customers branch. If the customer opens with an Explicit Need, go directly to Need-payoff. If a new problem surfaces mid-chain, note it and return. If the customer seems discouraged after several Implication Questions, shift to Need-payoff earlier to restore positive energy. Quincy's Rule is the reset button: Implication = sad (problem-centered); Need-payoff = happy (solution-centered). If the conversation tone needs to change, shift question types accordingly. - **For decision-makers, lean into Implication Questions.** Decision-makers respond most favorably to sellers who explore consequences and effects. The language of implications is the language of senior executives. More Implication Questions in calls with executives; more Problem Questions in calls with users and operational stakeholders. ## Examples **Scenario: First discovery call with a mid-market manufacturing prospect** Trigger: Rep asks — "I have a discovery call next Tuesday with an operations director at a 200-person manufacturer. We sell production scheduling software. Help me plan my questions." Process: 1. Deal context: large sale, first call, no prior needs data. Product capabilities: scheduling automation, bottleneck detection, operator load balancing. 2. Likely problems: (a) manual scheduling leads to production bottlenecks, (b) operator overtime from poor load distribution, (c) last-minute changes cascade into downstream delays. 3. Situation Questions (limited): "What does your current scheduling process look like?" / "How far in advance are you typically scheduling production runs?" 4. Problem Questions: "Are you finding that last-minute order changes create downstream disruptions?" / "When one line slows down, how does that ripple into the rest of the schedule?" 5. Implication chain for Problem (a): Implied Need likely heard: "Yes, we have bottlenecks when orders change." Consequences: delayed shipments → customer dissatisfaction → expediting costs → overtime. Implication Questions: "What's the downstream effect when a bottleneck forces a late shipment?" / "How much overtime do you typically absorb when you're trying to catch up?" 6. Need-payoff: "If you could catch a bottleneck forming 24 hours in advance, what would that mean for your on-time delivery rate?" Output: `question-bank-acme-mfg-2026-04-15.md` — a three-problem, three-chain question bank with sequence guide. Rep reads it the morning of the call. --- **Scenario: Follow-up call after a discovery call where Implied Needs were surfaced** Trigger: Rep shares needs-log.md showing two Implied Needs: "approval workflow is slow" and "reporting takes two days." "I'm seeing them next week — what do I ask?" Process: 1. Deal context: follow-up call, large sale, two Implied Needs already logged. Reduce Situation Questions to near zero — context is established. 2. Prior implied needs → needs to be developed into Explicit Needs via Implication chains before any solution presentation. 3. Implication chain for "approval workflow is slow": Consequences: deals slip because contracts wait in queue → salespeople lose momentum → deals lost to faster-moving competitors → revenue at risk. Implication Questions: "When a contract sits in queue, how long does the delay typically run?" / "Have you lost any deals because a competitor moved faster while your approval was pending?" 4. Need-payoff after development: "If you could cut approval time from days to hours, what would that mean for your close rate?" Output: `question-bank-deal-name-2026-04-22.md` with two Implication chains, minimal Situation Questions, and Need-payoff questions ready after each chain. --- **Scenario: Implication chain worked example (verbatim dialogue reference)** Trigger: Rep asks — "How do Implication Questions actually work in practice? Show me an example." Process: Reference the Contortomat/Easiflo dialogue in `references/contortomat-implication-dialogue.md`. The dialogue shows a seller starting from a mild Implied Need ("the machines are rather hard to use") and building it — through 7 Implication Questions — into a recognized $25,000+ annual problem, at which point a $120,000 solution no longer seems unreasonable. The worked example is the clearest illustration of how the value equation shifts through Implication questioning. ## References - Verbatim Contortomat/Easiflo Implication Question dialogue (the worked example that shows how the value equation shifts): [references/contortomat-implication-dialogue.md](references/contortomat-implication-dialogue.md) - Verbatim telephone system Need-payoff dialogue (the worked example showing buyer-stated benefits): [references/telephone-needpayoff-dialogue.md](references/telephone-needpayoff-dialogue.md) - Stock question patterns by SPIN type (template library for rapid planning): [references/spin-question-templates.md](references/spin-question-templates.md) ## License This skill is licensed under [CC-BY-SA-4.0](https://creativecommons.org/licenses/by-sa/4.0/). Source: [BookForge](https://github.com/bookforge-ai/bookforge-skills) — SPIN Selling by Neil Rackham. ## Related BookForge Skills This skill depends on: - `clawhub install bookforge-need-type-classifier` — classify customer responses as Implied or Explicit Needs during or after the call (reads `needs-log.md` that this skill uses as input) Skills that build on this one: - `clawhub install bookforge-benefit-statement-drafter` — draft Benefit statements once Explicit Needs are confirmed (Level 2, depends on this skill) - `clawhub install bookforge-commitment-and-advance-planner` — plan the specific Advance you'll seek on the call (Level 1, use alongside this skill) - `clawhub install bookforge-sales-call-plan-do-review-coach` — wrap the full Plan-Do-Review cycle around a single call (Level 2, orchestrates this skill) - `clawhub install bookforge-spin-skill-practice-coach` — build your SPIN questioning skill systematically over weeks (Level 2, depends on this skill) Or install the full SPIN Selling skill set from GitHub: [bookforge-skills](https://github.com/bookforge-ai/bookforge-skills)

path: references/contortomat-implication-dialogue.md
content: # Contortomat / Easiflo — Verbatim Implication Question Dialogue

**Source:** SPIN Selling, Neil Rackham, Chapter 4 (The SPIN Strategy)

This dialogue is the book's central worked example of how Implication Questions transform a small Implied Need into a problem large enough to justify a large-sale solution. The value equation shifts from "$120,000 seems outrageous" to "when you put it that way, those machines are creating a very serious problem indeed."

---

## Part 1: Without Implication Questions (the failure case)

> **SELLER:** (Situation Question) Do you use Contortomat machines in this division?
>
> **BUYER:** Yes, we've got three of them.
>
> **SELLER:** (Problem Question) And are they difficult for your operators to use?
>
> **BUYER:** (Implied Need) They are rather hard, but we've learned how to get them working.
>
> **SELLER:** (jumping to solution) We could solve that operating difficulty for you with our new Easiflo system.
>
> **BUYER:** What does your system cost?
>
> **SELLER:** The basic system is about $120,000 and...
>
> **BUYER:** (amazed) $120,000!!! Just to make a machine easier to use! You must be kidding.

**What went wrong:** The buyer perceives only a small Implied Need ("they are rather hard"). The problem does not feel large enough to justify a $120,000 solution. The value equation is out of balance — cost outweighs perceived problem severity.

---

## Part 2: With Implication Questions (the success case)

> **SELLER:** (Problem Question) And are they difficult for your operators to use?
>
> **BUYER:** (Implied Need) They are rather hard, but we've learned how to get them working.
>
> **SELLER:** (Implication Question) You say they're hard to use. What effect does this have on your output?
>
> **BUYER:** (perceiving the problem as small) Very little, because we've specially trained three people who know how to use them.
>
> **SELLER:** (Implication Question) If you've only got three people who can use them, doesn't that create work bottlenecks?
>
> **BUYER:** (still seeing the problem as unimportant) No, it's only when a Contortomat operator leaves that we have trouble while we're waiting for a replacement to be trained.
>
> **SELLER:** (Implication Question) It sounds like the difficulty of using these machines may be leading to a turnover problem with the operators you've trained. Is that right?
>
> **BUYER:** (recognizing a bigger problem) Yes, people certainly don't like using the Contortomat machines, and operators generally don't stay with us for long.
>
> **SELLER:** (Implication Question) What does this turnover mean in terms of training cost?
>
> **BUYER:** (seeing more) It takes a couple of months before an operator gets proficient, so that's maybe $4000 in wages and benefits for each operator. On top of that we pay Contortomat $500 to put new operators through off-site training in their Southampton plant. So add perhaps $1000 for travel costs. You know, that's about $5000 for each operator we train — and I guess we must have trained at least five this year already.
>
> **SELLER:** So that's more than $25,000 in training costs in less than 6 months. (Implication Question) If you've trained five people in 6 months, it sounds like you've never had three fully competent operators at any time: how much production loss has this led to?
>
> **BUYER:** Not much. Whenever there's been a bottleneck, we've persuaded the other operators to work overtime, or we've sent work outside.
>
> **SELLER:** (Implication Question) Doesn't the overtime add even more to your costs?
>
> **BUYER:** (realizing the problem is quite serious) Yes, we've been paying overtime at two and a half times the normal job rate. Even with the additional pay, the operators aren't very willing to work the extra hours — which I'm sure is one of the reasons we're getting such high turnover.
>
> **SELLER:** (Implication Question) I can see how sending the work outside must also increase your costs, but is that the only implication of sending work out? Is the quality of work affected, for example?
>
> **BUYER:** That's what I'm most unhappy about. I can control the quality of everything we produce internally, but when anything goes outside I'm at the mercy of other people.
>
> **SELLER:** (Implication Question) And presumably, being forced to send work outside also puts you at the mercy of other people's delivery schedules?
>
> **BUYER:** Don't talk about it! I've just spent 3 hours on the phone chasing a late delivery.
>
> **SELLER:** (summarizing) So from what you've said, because your Contortomat machines are so difficult to use, you've spent $25,000 in training costs this year and you're getting expensive operator turnover. You've bottlenecks in production, and these result in expensive overtime and force you to send jobs outside. But sending jobs outside isn't satisfactory, because you're losing quality and getting late deliveries.
>
> **BUYER:** When you put it that way, those Contortomat machines are creating a very serious problem indeed.

---

## The Value Equation — Before and After

| | Before Implication Chain | After Implication Chain |
|---|---|---|
| Perceived problem | "They are rather hard to use" | $25,000+ training costs, overtime, quality risk, delivery delays |
| Perceived solution cost | $120,000 (outrageous) | $120,000 (now feels justifiable) |
| Buyer state | Dismissive | "When you put it that way, this is very serious" |

---

## Planning Notes (how this maps to the 3-step sub-workflow)

**Problem identified:** Contortomat machines are difficult to operate.

**Related difficulties written down (Step 5b):**
1. Only 3 trained operators → bottleneck risk
2. Hard-to-use machines → operator turnover
3. Turnover → retraining costs (~$5,000/operator × 5 = $25,000/year)
4. Bottlenecks → overtime (2.5× rate)
5. Overtime → increased turnover (circular)
6. Work sent outside → quality risk, delivery delays

**Questions each difficulty suggested (Step 5c):**
- "If you've only got three people who can use them, doesn't that create work bottlenecks?"
- "It sounds like the difficulty of using these machines may be leading to a turnover problem. Is that right?"
- "What does this turnover mean in terms of training cost?"
- "If you've trained five people in 6 months, it sounds like you've never had three fully competent operators at any time: how much production loss has this led to?"
- "Doesn't the overtime add even more to your costs?"
- "Is that the only implication of sending work out? Is the quality of work affected?"
- "Being forced to send work outside also puts you at the mercy of other people's delivery schedules?"


path: references/spin-question-templates.md
content: # SPIN Question Templates — Stock Patterns by Type

**Source:** SPIN Selling, Neil Rackham. Chapter 4 (The SPIN Strategy).

Use these patterns as starting points when planning questions for a specific deal. Adapt to the actual context — these are structural templates, not word-for-word scripts. Specificity beats generality: "Are you finding that approval cycles are slowing your contract close times?" is far more powerful than "Are there any process challenges you're facing?"

---

## Situation Questions

**Purpose:** Establish factual background about the customer's current state. Use sparingly — they serve the seller, not the buyer. Do your homework first; ask only what you couldn't find out in advance.

| Template | Example |
|---|---|
| "What does your current [process/system] look like?" | "What does your current approval workflow look like?" |
| "How are you currently handling [area]?" | "How are you currently handling production scheduling?" |
| "How many [people/systems/locations] are involved in [function]?" | "How many operators use the system currently?" |
| "What [tool/vendor/approach] are you using for [function]?" | "What system are you using for demand forecasting?" |
| "How long have you been using [current approach]?" | "How long have you had this setup?" |
| "Who is involved in [process/decision]?" | "Who else is involved in the procurement decision?" |

**Situation Question limit:**
- New account, first call: 5-8 maximum
- Follow-up call: 2-3 maximum (context already established)
- Executive call: 1-2 maximum (they expect you to have done your homework)

---

## Problem Questions

**Purpose:** Probe for problems, difficulties, and dissatisfactions. Invite the customer to express Implied Needs. More effective than Situation Questions. In large sales, they provide the raw material for Implication chains.

| Template | Example |
|---|---|
| "Are you finding [situation] creates [difficulty]?" | "Are you finding that manual reporting creates delays for your team?" |
| "What difficulties do you run into when [situation]?" | "What difficulties do you run into when scheduling around last-minute orders?" |
| "Is it difficult to [task] with your current [system/approach]?" | "Is it difficult to track accountability with your current phone system?" |
| "How satisfied are you with [current approach]?" | "How satisfied are you with the speed of your current approval process?" |
| "Does [current situation] give you any [reliability/quality/cost] problems?" | "Does your current setup give you any visibility problems across regions?" |
| "Are there any bottlenecks or slowdowns in [process]?" | "Are there any bottlenecks in how work gets assigned to operators?" |
| "What would you change about your current [approach], if you could?" | "What would you change about your scheduling process if you could?" |

---

## Implication Questions

**Purpose:** Develop the seriousness of an Implied Need. Make the problem feel larger — not by exaggerating, but by helping the customer connect the problem to its downstream consequences. Problem-centered ("sad" per Quincy's Rule).

**Best used with:** Decision-makers (who think in consequences); high-value, multi-stakeholder deals; any situation where the cost of the solution needs to feel justified.

**Planning requirement:** Do NOT improvise these. Use the 3-step sub-workflow (Step 5 of the skill body) to generate them from specific consequences before the call.

| Template | Example |
|---|---|
| "What effect does [problem] have on [downstream area]?" | "What effect does the bottleneck have on your production schedule?" |
| "If [problem] occurs, what happens to [related process]?" | "If an operator leaves, how long before a replacement is fully trained?" |
| "[Problem] seems to lead to [consequence A]. Does it also affect [consequence B]?" | "Turnover leads to retraining costs. Does it also cause bottlenecks during the gap?" |
| "What does [problem] mean in terms of [cost/time/quality/risk]?" | "What does the overtime situation mean in terms of your annual labor costs?" |
| "When [problem occurs], how does that affect [stakeholder/team]?" | "When a shipment is late, how does that affect your relationship with the customer?" |
| "Is [problem] also affecting [adjacent area you've noticed]?" | "Is the turnover also making it harder to maintain quality on specialized jobs?" |
| "Does [problem] put you at risk of [specific negative outcome]?" | "Does sending work outside put you at the mercy of other people's delivery schedules?" |

---

## Need-Payoff Questions

**Purpose:** Shift the conversation from problem-centered to solution-centered. Get the buyer articulating benefits. "Happy" per Quincy's Rule. Only deploy these after the need has been developed.

**Critical constraint:** Only ask Need-payoff Questions for capabilities you can deliver. Asking "why would that be important?" for a need you cannot meet strengthens a need that becomes an objection.

| Template | Example |
|---|---|
| "Why is [solving this problem] important to you?" | "Why is controlling unauthorized long-distance calls important to you?" |
| "How would [capability] help you?" | "How would automated scheduling help your team?" |
| "Would it be useful if you could [specific capability]?" | "Would it help if you could restrict long-distance calling to authorized users?" |
| "Is there any other way [solving this] could help you?" | "Is there any other way having faster reports would help your team?" |
| "If you could [solve the problem], what would that mean for [outcome]?" | "If you could cut approval time from days to hours, what would that mean for your close rate?" |
| "How significant would it be if [positive change occurred]?" | "How significant would it be if you could catch a bottleneck 24 hours in advance?" |
| "Would [solving this] also help with [related area]?" | "Would better cost tracking also help you with your department accountability reporting?" |
| "What would be the value to you of [specific improvement]?" | "What would be the value to you of having operators up to speed in weeks rather than months?" |

---

## Sequence and Balance Notes

**Top performer benchmarks (from Rackham's research):**
- Top performers ask approximately **10× more Need-payoff Questions** than average performers
- Only **1 in 20 questions** in an average call is an Implication Question — despite being the most powerful type
- In failed calls: more Situation Questions, far fewer Implication and Need-payoff Questions

**Practical balance for a 45-minute discovery call:**
- Situation Questions: 4-6 (or fewer if you've done homework)
- Problem Questions: 6-10 (primary exploration phase)
- Implication Questions: 4-8 per confirmed problem (the chain)
- Need-payoff Questions: 3-5 per confirmed Implication chain (conversion phase)

**Transition signals — when to move to the next type:**
- S → P: Once you have the background context you need (don't wait until you have everything)
- P → I: Once the customer confirms a problem ("yes, that is a difficulty for us")
- I → N: Once the customer's language shifts from "it's minor" to "actually, this is significant" OR once you have 3+ consequences developed
- N → present: Once the buyer has expressed a specific want or desire (Explicit Need) in their own words


path: references/telephone-needpayoff-dialogue.md
content: # Telephone System — Verbatim Need-Payoff Question Dialogue

**Source:** SPIN Selling, Neil Rackham, Chapter 4 (The SPIN Strategy)

This dialogue shows a seller using Need-payoff Questions to get the buyer talking about benefits — shifting the conversation from problem-focused to solution-focused, and rehearsing the buyer to sell internally.

---

## The Dialogue

> **SELLER:** (Need-payoff Question) ...so would you be interested in a way to control long-distance calls?
>
> **BUYER:** Well... yes, of course... but that's only one of the problems I have at the moment.
>
> **SELLER:** (Need-payoff Question) I'd like to consider those other problems in a minute. But first, you say you would like to control long-distance calling. Why is that important to you?
>
> **BUYER:** Well, right now I'm receiving a lot of pressure from the controller to contain my network costs. If I could reduce long-distance charges, it would sure help.
>
> **SELLER:** (Need-payoff Question) Would it help if you could restrict long-distance calling to authorized persons?
>
> **BUYER:** Well, yes... it would certainly prevent some of the excessive long-distance usage we're getting. Most of it's coming from unauthorized long-distance use.
>
> **SELLER:** Can we go back to issues you raised about preparing phone-system management reports? (Need-payoff Question) May I assume you'd like improvement there also?
>
> **BUYER:** Yes, it would be a big help.
>
> **SELLER:** (Need-payoff Question) Is that because it would provide you with a better method for telephone cost accounting?
>
> **BUYER:** Yes. You see, if we can identify departments that make calls, we can hold them accountable for their telephone charges.
>
> **SELLER:** (Need-payoff Question) I see... is there any other way it might help?
>
> **BUYER:** Umm... No. I think accountability is the main thing.
>
> **SELLER:** (Need-payoff Question) Well that's certainly important... but don't you think it might also be important to know how long it takes to answer incoming calls and the total number of calls that go through each extension?
>
> **BUYER:** That could be really useful.
>
> **SELLER:** (Need-payoff Question) Useful for cost reasons, or is there something else?
>
> **BUYER:** No, I wasn't thinking of costs. Where it would really help us is in improving customer service, and in this business that's important! Can you help us there?
>
> **SELLER:** Yes, we can. Let me explain how our equipment will help to...

---

## What These Need-Payoff Questions Achieved

1. **Shifted attention from problems to solutions.** Each question prompted the buyer to think about what a solution would mean, not what was wrong with the current state.

2. **Got the buyer articulating the benefits.** The buyer said "where it would really help us is in improving customer service" — the seller did not say this; the buyer did. Rackham's research showed that calls where buyers state benefits (rather than sellers) produce better outcomes.

3. **Rehearsed the buyer for internal selling.** The buyer now understands the value in their own terms — cost containment, accountability, customer service. When they go back to the controller or executive team, they can articulate the benefits in business language, not product language.

4. **Reduced objections.** Because the seller did not claim "our system will improve your customer service," the buyer discovered it themselves through the question sequence. Self-discovered benefits face far less internal resistance than seller-stated ones.

---

## Quincy's Rule Applied to This Dialogue

Quincy's Rule (from the book): *"Implication Questions are always sad. Need-payoff Questions are always happy."*

Every question in this dialogue is "happy" — it points toward solutions, value, and benefits. Compare the tone to an Implication Question like "What happens when unauthorized long-distance calls aren't controlled?" — that question is "sad" (it makes the problem feel worse). The Need-payoff Questions in this dialogue do the opposite: they make the solution feel better.

**Sequence signal:** If the buyer sounds discouraged or weighed down by Implication Questions, shift to Need-payoff Questions to restore positive energy. Need-payoff Questions are also the signal that you are close to an Explicit Need — when the buyer says "yes, I'd want that" or "that would be important," they are expressing an Explicit Need you can link a Benefit to.

---

## Stock Need-Payoff Question Patterns

These questions work across industries and deal types:
- "Why is that important to you?"
- "How would that help?"
- "Would it be useful if you could [capability]?"
- "Is there any other way this could help you?"
- "If you could [solve the problem], what would that mean for [business outcome]?"
- "Would [solving this] also help with [related area]?"
- "How significant would it be if [positive change]?"


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)