SPICED Framework Template (Winning by Design)

SPICED was created by Winning by Design, the revenue-architecture firm founded by Jacco van der Kooij, as the discovery backbone of their SaaS sales methodology. Credit where due: the framework is theirs. The field kit, question set, and agent tooling on this page are ours.

Who this is for

Use SPICED if your revenue recurs - SaaS, usage-based, subscriptions, retainers. BANT qualifies the transaction: budget and authority, right now. MEDDPICC qualifies the close: navigating an enterprise buying committee. SPICED qualifies the relationship: is there a quantified impact this customer will still be getting twelve months from now? In recurring revenue the close is not the payday - the renewal is. A deal won on discount and momentum churns; a deal won on documented impact expands.

Reach for it on first discovery calls, in deal reviews where "why will they buy?" gets mumbled answers, at sales-to-CS handoffs (SPICED is the handoff document), and in any pipeline where win rates look fine but net revenue retention does not.

The framework

Five components. The acronym splits as S-P-I-CE-D: Critical Event owns the C and E, and Decision covers both criteria and process. For each component, hold yourself to the evidence bar - a letter is not "filled" because you wrote something in the box.

Component	What it captures	Filled means
Situation	How the buyer operates today: team, stack, motion, volumes.	You could brief a colleague on their world in 60 seconds without guessing.
Pain	What breaks, in the buyer's own words, and who feels it.	A direct quote, attached to a named person or team that owns the problem.
Impact	What the pain costs the business - revenue, hours, churn, risk.	A number the buyer stated or confirmed. Your math does not count until they agree with it.
Critical Event	A dated deadline with a consequence for missing it.	Date plus consequence. "Renewal on Nov 30; if reporting is still manual, the board kills the program."
Decision	How they buy: criteria they will judge on, process they will follow, people involved.	You know every step between "we want this" and a countersigned contract, with names.

Impact-first discovery questions

The classic mistake is running SPICED top-to-bottom, spending twenty minutes on Situation questions you could have answered from their website. Invert it: open on Pain, chase Impact hard, backfill Situation only where it explains the pain. The order below is the asking order, not the acronym order.

• Pain: "What made you take this call now?" - "Walk me through the last time this went wrong." - "Who else feels it when it breaks?"
• Impact: "What does that cost you - in hours, deals, or customers?" - "If nothing changes for two more quarters, what does that number become?" If they cannot quantify, offer a range and make them correct you - a corrected estimate is buyer-confirmed; your silent spreadsheet is not.
• Critical Event: "Is there a date this has to be fixed by? What happens if it is not?" No date or no consequence: you have a project, not a deal.
• Decision: "Last time you bought something like this, how did it actually get done?" - "What will you judge the options on?" - "Who can veto this?" Criteria and process are different fields; collapsing them is how surprise procurement reviews happen.
• Situation: backfill as needed - stack, team, workflow, volume. Research before the call; verify, don't interrogate.

One hygiene rule: every letter without direct evidence goes into a spiced_gaps field, and the gap list is your next-call agenda. Two-plus gaps after a second call should score the deal down - wire gaps into your lead scoring framework.

The template: SPICED field kit

SPICED dies in a free-text notes field, because nobody can query "show me deals with no critical event." Store it as structured fields on the deal. This kit works in any CRM - in Relm you register the enum values first (POST /v1/enums), then each field (POST /v1/fields), and from then on values travel under custom_fields on every deal read and write. The whole registry is discoverable afterwards via GET /v1/schema - see the docs.

{
  "enums": [
    { "group": "deal.spiced_gap", "value": "situation", "label": "Situation" },
    { "group": "deal.spiced_gap", "value": "pain", "label": "Pain" },
    { "group": "deal.spiced_gap", "value": "impact", "label": "Impact" },
    { "group": "deal.spiced_gap", "value": "critical_event", "label": "Critical event" },
    { "group": "deal.spiced_gap", "value": "decision", "label": "Decision" }
  ],
  "fields": [
    { "object": "deal", "key": "spiced_situation", "label": "Situation", "data_type": "text" },
    { "object": "deal", "key": "spiced_pain", "label": "Pain (buyer's words)", "data_type": "text" },
    { "object": "deal", "key": "spiced_impact", "label": "Impact (quantified)", "data_type": "text" },
    { "object": "deal", "key": "spiced_critical_event", "label": "Critical event + consequence", "data_type": "text" },
    { "object": "deal", "key": "spiced_critical_event_date", "label": "Critical event date", "data_type": "date" },
    { "object": "deal", "key": "spiced_decision_criteria", "label": "Decision criteria", "data_type": "text" },
    { "object": "deal", "key": "spiced_decision_process", "label": "Decision process", "data_type": "text" },
    { "object": "deal", "key": "spiced_gaps", "label": "SPICED gaps", "data_type": "multiselect", "enum_group": "deal.spiced_gap" }
  ]
}

Each entry in enums is one POST /v1/enums body; each entry in fields is one POST /v1/fields body. Registration is idempotent on key, so re-running the kit is safe.

The agent prompt: fill SPICED from a transcript

The second half of the template is a prompt for a transcript-processing agent. It enforces the evidence bars, and its most important instruction is negative: an unsupported letter becomes a gap, never a guess.

You are a sales ops agent. Input: a discovery-call transcript, a deal ID,
and the call date.

Extract SPICED from the transcript only. Evidence rules:
- spiced_pain: the buyer's own words, quoted, with who owns the problem.
- spiced_impact: must contain a number the buyer stated or confirmed.
  If none exists, write "unquantified" and add "impact" to gaps.
- spiced_critical_event: date AND consequence. If either is missing,
  leave the date field null and add "critical_event" to gaps.
- spiced_decision_criteria vs spiced_decision_process: keep separate.
- spiced_situation: facts only (team, stack, volume, current workflow).
- Never infer or invent. A letter without direct evidence goes to
  spiced_gaps: any of situation, pain, impact, critical_event, decision.

Then write to the CRM:
1. PATCH /v1/deals/{deal_id} with {"custom_fields": { ...the fields above }}
2. POST /v1/activities with {"type": "note", "deal_id": "{deal_id}",
   "occurred_at": "{call date, ISO}", "body": a 5-line SPICED summary
   ending with "Gaps: ..." and the questions to ask next call.

Output: the summary plus the list of gaps.

Apply it with your agent

Relm's MCP server lets any MCP client (Claude, or your own agent stack) run this without glue code - point it at https://api.relmcrm.com/mcp with your key, as described in how to give your AI agent a CRM. Then a single message does the whole setup:

Register the SPICED field kit on the deal object in my Relm workspace:
create the deal.spiced_gap enum values (situation, pain, impact,
critical_event, decision), then the eight fields from
relmcrm.com/resources/spiced-framework-template. Use my test-mode key
first, verify with describe_schema, then repeat on live. After that,
fill SPICED for deal deal_x8f3k2m9q2 from the transcript I paste next.

Over plain REST, registering one field is a single call:

curl https://api.relmcrm.com/v1/fields \
  -H "Authorization: Bearer relm_test_..." \
  -H "Content-Type: application/json" \
  -d '{ "object": "deal", "key": "spiced_pain", "label": "Pain (buyer'"'"'s words)", "data_type": "text" }'

Once the fields exist, pair this template with the meeting notes to CRM agent prompt so every recorded call updates SPICED automatically, and gate stage moves on it - a deal should not reach proposal with impact still in spiced_gaps.

FAQ

What does SPICED stand for in sales?

Situation, Pain, Impact, Critical Event, Decision. It is a discovery and qualification framework created by Winning by Design for recurring-revenue sales. Situation is how the buyer operates today, Pain is what breaks, Impact is what that costs, the Critical Event is a dated deadline with a consequence, and Decision covers the criteria and process for buying.

How is SPICED different from BANT and MEDDPICC?

BANT gates on budget and authority, which qualifies the transaction. MEDDPICC maps enterprise deal complexity, which qualifies the close. SPICED centers on Impact - the quantified business outcome - because in recurring revenue the sale is only profitable if the customer renews, and customers renew on impact, not on whether they once had budget.

What counts as a Critical Event in SPICED?

A Critical Event needs a date and a consequence: something happens on a specific day, and missing it costs the buyer something concrete - a contract renewal, a launch, a compliance deadline, a board commitment. A vague desire to move fast is a compelling event at best. If you cannot name the date and the cost of missing it, record the deal as having a gap on Critical Event.

Can an AI agent fill in SPICED automatically?

Yes. Give the agent a discovery-call transcript and a prompt that maps quotes to the five SPICED components, then have it write the results into structured CRM fields. The prompt on this page enforces evidence rules - buyer quotes for Pain, a number for Impact, date plus consequence for Critical Event - and flags any letter it could not support as a gap instead of inventing an answer.

Do I need Relm to use this SPICED template?

No. The framework, questions, and field list work in any CRM - the field kit maps one-to-one to custom properties in HubSpot, Pipedrive, or a spreadsheet. Relm is the fastest way to apply it programmatically: one POST per field to register the kit, and an MCP server so an agent can read a transcript and fill the fields without a human clicking through a UI.