SPICED is the protocol every go-to-market skill plugs into. This is the design decision that keeps it honest: every skill measures the deal one of two ways, and the two must never be blended into one score.
In this model SPICED is not a methodology to memorize. Each of its five elements (Situation, Pain, Impact, Critical Event, Decision) is a namespace: a fixed, shared place where skills write typed values and any agent can read them. A skill is a folder that runs on a deal's calls and CRM and writes into a namespace. An agent composes skills and reasons over what they wrote. Because the field names are shared, any skill or agent, from any vendor, knows where to read and write.
That raises one question the moment you try to score a deal: what exactly is a skill measuring?
A skill measures one of two fundamentally different things. They have different inputs, different owners, different cadence, and they answer to different people.
| Technique | Diagnosis | |
|---|---|---|
| Question it answers | How well did the rep run the play? | Is the element actually true on the deal? |
| Indicator type | Leading (execution quality) | Lagging (deal reality) |
| Unit | Per rep, per call | Per deal, continuous |
| Input | One interaction, scored against the rubric | All accumulated deal evidence |
| Typed output | A technique score | The namespace index (coverageIndex...) |
| Owned by | The rep's manager | The forecast |
| Consumer agent | coaching-agent | deal-health-agent |
A diagnosis reading is not a fair accountability signal. "This deal is single-threaded" can mean the rep executed poorly, or it can mean the deal is three days old and multi-threading is not due yet. Score a rep on the raw deal state and you punish them for deal stage. Technique asks the question a manager can fairly coach on, Diagnosis asks the question a forecast needs. Different question, different data, different owner. So they are two skills.
Each namespace carries a Diagnosis skill, because the forecast always needs one, and a Technique skill wherever the rep's execution is coachable.
| Namespace | Technique skill (to coaching) | Diagnosis skill (to forecast) |
|---|---|---|
| S · Situation | research done before the call | situation diagnosis |
| P · Pain | question-based selling | pain and risk surfacing |
| I · Impact | impact questions asked well | impact uncovered and quantified |
| CE · Critical Event | rep tested for a compelling event | urgency and critical-event read |
| D · Decision | decision-process technique | decision coverage, multi-threading |
| X · Cross-cutting | manager coaching | governance, revenue architecture |
Concretely, the Diagnosis side of Decision computes a Decision Coverage Index, with multi-threading as a module inside it (the index of record for threads):
Multi-Threading Index (0 to 100)
activeThreads = contacts touched in 30d who spoke on a call or replied to email
expected = 2 for SMB, 3 to 4 for mid-market, 5+ for enterprise
index = 100 * min(activeThreads / expected, 1)
writes into the shared record:
decision.threadCount = activeThreads
decision.singleThreadedRisk = activeThreads < 2
and feeds decision.coverageIndex (the D-namespace score)
Any agent reads decision.singleThreadedRisk without re-parsing a single call, because the field name is the contract. That is the whole point of the namespaces.
One direction, no cycles. Skills write; agents only read and compose.
raw evidence (calls, CRM, email)
|
|--> Technique skills --writes--> technique record (per-rep, per-call scores)
|
|--> Diagnosis skills --writes--> SPICED record (typed namespace indices)
|
v
Agents compose (read-only, no logic of their own):
- coaching-agent reads the technique record
- deal-health-agent reads the SPICED record
- discovery-agent reads both during a live call
The chain reads cleanly and stays precise about tense:
Downstream this gives one shared vocabulary two honest scorecards: an accountability view of how well the team is executing the recipe, and a forecast-and-health view of whether each deal will close and where the risk sits. Same namespaces underneath, so a rep sees their technique and a manager sees the forecast without two disconnected systems.
The typed fields are the contract, so the shape of the record is the standard. Two schema surfaces sit underneath this: the SPICED record (the diagnosis fields per namespace, and how they roll into a completeness score) and a parallel technique record (per-rep, per-call scores). The open questions worth working through together: the field definitions and nullability per namespace, the relationships that let one skill's output feed another, and how the whole thing maps to the Bowtie and Growth Architecture models.