GTM Operations
Your Sales Methodology Is a Schema You Never Built
Twelve percent of open opportunities had a documented economic buyer despite full SPICED training. Adoption is a data-capture problem wearing a training costume. Here is the field schema and stage-gate validation that makes qualification structural.
· 14 min read
I asked a VP of Sales how his team qualified deals. SPICED, he said, without hesitating. Whole team is trained on it, certified last quarter. So I pulled a report: of 340 open opportunities, how many had a documented economic buyer? Forty-one. Twelve percent. The other 88% were being forecast on a framework the team “used” the way people use a gym membership they pay for and never visit. The training happened. The sticker was on the laptop. The framework was in nobody’s CRM.
That gap is the whole problem, and it is a data-capture failure wearing a training costume. You cannot train your way out of a schema you never built. SPICED, MEDDPICC, BANT, whatever the acronym: a sales methodology exists only to the degree it is a set of fields a rep must fill and a gate that checks they filled them. Everything else is theater with a workbook. So here is the build I run to turn a methodology into a schema, wire it to the stages, and make qualification something the system enforces instead of something a manager nags about in a one-on-one. Five rungs, bottom to top. Scroll it, then I will show you the fields, the validation rules, and the score under each one.
- L5Score completeness and put it in the pipeline review0 to 5
Compute a qualification score of zero to five per open deal, sort commit by it, and make any commit deal under three a standing agenda item. The score is the forecast input the stage label was pretending to be.
- L4Ship the stage-gate validation rulesISPICKVAL
One rule per gated stage, ISPICKVAL against StageName, a length check on the text field so one-word dodges fail. The rule blocks the save and names what is missing. This is the rung that converts training into behavior.
- L3Pick the four or five fields that gate, and only those5 gates
Gate economic buyer, quantified impact, decision process, and critical event. Leave situation and competition as encouraged context. Gating everything produces TBD in every box; gating the predictors produces qualification.
- L2Map each framework element to a typed field7 fields
Situation becomes long text, Pain becomes a checkbox, Impact becomes currency, Critical Event becomes a date. A methodology with no columns is a methodology nobody uses, because free text cannot be gated, reported, or trusted.
- L1Baseline the capture rate before you touch anything12%
Run one report: of open deals past Stage 2, what percent carry a confirmed economic buyer and a quantified impact. Write the number down. In the story above it was 12%. Every later rung is measured against this line, so capture it before you change a single field.
Locate yourself on that ladder. Most teams live below the first rung, quoting a methodology they never measured. Every rung above it turns a slogan into a mechanism. By the top rung, the framework everyone “uses” is the framework the pipeline runs on, and you can prove it with a report instead of a certification record.
Why the training never sticks
The story every enablement team tells itself is that adoption is a knowledge problem. Reps do not qualify well, so we train them harder, certify them, run reinforcement. Then attainment stays flat. In the first half of 2025, 76% of reps missed quota (Ebsta and Pavilion, 2025 B2B benchmarks), and win rates sat at 19%, down from about 29% the year before (Ebsta and Pavilion). More training did not move those numbers, because the methodology never became a thing the rep had to do to move a deal. It stayed optional. Optional qualification is no qualification.
Here is the mechanism the training theory misses. A rep under pressure inside a 6.5-month cycle (Ebsta, 2024) does the minimum the system demands. If the system demands a StageName change and a close date, that is what they enter. The SPICED elements live in the rep’s head, or worse, in a call recording nobody rewatches, and never land as structured data. When the deal slips, the manager cannot inspect what was missing, because there was nothing to inspect. Adoption is an ops problem: you get the behavior your fields and gates require, not the behavior your slides describe. That is rung L1 telling you the truth before you spend another dollar on reinforcement.
Turn the acronym into a field schema
SPICED has six elements: Situation, Pain, Impact, Critical Event, Decision, and it maps cleanly onto what MEDDPICC calls Economic Buyer, Decision Criteria, Decision Process, and Metrics. I do not care which acronym you standardize on. I care that each element becomes a typed field with a validation-friendly shape, not a free-text scratchpad. This is rung L2, and the type choice is the point: some elements are booleans (is the economic buyer confirmed, yes or no) and some are structured values with a minimum bar (what is the documented decision process, what is the dollar impact). The booleans and the numbers drive the gates. The text drives the coaching. Here is the schema I ship, mapped from framework element to CRM field:
| Framework element | CRM field | Type | Gate-relevant |
|---|---|---|---|
| Situation | Current_State__c | Long text | No, context |
| Pain | Pain_Identified__c | Checkbox | Yes, gates Stage 2 |
| Impact / Metrics | Quantified_Impact__c | Currency | Yes, gates Stage 3 |
| Economic buyer | Economic_Buyer_Confirmed__c | Checkbox | Yes, gates Stage 3 |
| Decision process | Decision_Process__c | Long text | Yes, gates Stage 4 |
| Critical event | Critical_Event_Date__c | Date | Yes, gates Stage 4 |
| Competition | Competition__c | Picklist | No, context |
The gate-relevant column is the spine of rung L3. Those are the fields a rep cannot leave empty when they try to advance the stage. The non-gated fields are still valuable for coaching, but forcing all seven as hard requirements is how you manufacture garbage: reps type “TBD” into every box to escape the wall. Gate the four or five that predict outcomes, keep the rest as encouraged context. This is the same principle behind not taxing reps with 30 required fields, which I broke down in the required fields tax. The CRM data modeling guide covers the field-type choices in more depth.
Wire the schema to the stages: the gate is the enforcement
Fields alone do nothing. A rep can create all seven fields and ignore every one of them. Enforcement is rung L4: a validation rule that fires when the rep tries to advance the stage without the fields that stage requires. You cannot enter Stage 3 until the economic buyer is confirmed and the impact is quantified, because those are the observable facts that define Stage 3.
Here is the gate as a Salesforce validation rule. Note the ISPICKVAL against StageName, never a bare operator against the picklist, and note that it blocks only forward motion into the gated stage:
AND(
ISPICKVAL(StageName, "3 - Validation"),
OR(
NOT(Economic_Buyer_Confirmed__c),
ISBLANK(Quantified_Impact__c),
Quantified_Impact__c <= 0
)
)
That reads as: if a rep is moving a deal into Stage 3 and either the economic buyer is not confirmed or the quantified impact is blank or zero, block the save with a message that names exactly what is missing. The rep cannot forecast a Stage 3 deal that has no buyer and no dollar impact, because the deal physically cannot reach Stage 3 without them. The gate turns “we use SPICED” into “you cannot advance without SPICED.”
The Stage 4 gate stacks on the same pattern for decision process and critical event:
AND(
ISPICKVAL(StageName, "4 - Proposal"),
OR(
LEN(Decision_Process__c) < 40,
ISBLANK(Critical_Event_Date__c)
)
)
The LEN check is deliberate. A rep can type “yes” into a decision-process field to escape a checkbox gate, so for the text field I require a minimum length, which forces at least a sentence of actual process. It is a crude proxy for quality, and it is enough to stop one-word dodges. Quality of the sentence is the manager’s job in the pipeline review; presence of the sentence is the gate’s job. The two jobs stay separate, and the gate never pretends to do the manager’s.
The capture rate climbs, and you can watch it
Here is that before-and-after as a table, because the number moving is the entire argument. The baseline cohort of 340 open deals stays at 12%, since the gate does not reach backward and force fields onto deals already sitting in late stages. What changes is every deal advanced after the gate goes live. Those are the deals the gate touches, and their capture rate is near total by construction.
| Cohort | Open Stage 3+ deals | With confirmed economic buyer | Capture rate |
|---|---|---|---|
| Baseline, pre-gate | 340 | 41 | 12% |
| Day 30, advanced post-gate | 58 | 55 | 95% |
| Day 60, advanced post-gate | 96 | 92 | 96% |
| Day 90, advanced post-gate | 141 | 138 | 98% |
The 12% in the top row is the same 12% on the stat tile and rung L1. The bottom row is rung L4 doing its job. Nobody trained harder between those rows. The system started requiring the field, so the field started showing up. This is what “adoption is an ops problem” looks like when you put a number on it: a capture rate that moves the week the validation rule deploys, not the quarter after the next enablement session.
The completeness score you can forecast on
Once the elements are typed fields, you can compute a qualification-completeness score per deal, and that score is a better forecast input than a rep’s gut feel. This is rung L5. A deal with confirmed buyer, quantified impact, documented process, and a critical event date is a different animal from one carrying a stage label and nothing behind it. This SQL scores every open deal on the five gate-relevant fields and buckets it:
SELECT
opportunity_id,
stage_name,
amount,
(CASE WHEN pain_identified THEN 1 ELSE 0 END) +
(CASE WHEN quantified_impact > 0 THEN 1 ELSE 0 END) +
(CASE WHEN economic_buyer_confirmed THEN 1 ELSE 0 END) +
(CASE WHEN LENGTH(decision_process) >= 40 THEN 1 ELSE 0 END) +
(CASE WHEN critical_event_date IS NOT NULL THEN 1 ELSE 0 END)
AS qual_score -- 0 to 5
FROM opportunities
WHERE is_closed = false
ORDER BY amount DESC
Now sort your commit by qual_score. Any deal in commit with a score under three is a deal your rep is betting on with more conviction than the data supports. That is the conversation the pipeline review should have, and it is the one the forecasting guide argues qualification completeness drives: economic buyer and decision process predict slips 30 to 45 days earlier than a stage label does. The completeness score is qualification made into a number you can forecast on.
The distribution shifts once the gates are live. Toggle the states below. Before gating, most open deals sit at a completeness score of one or two, because reps advanced them on stage labels alone. After the Stage 3 and Stage 4 gates, the mass moves right, because a deal cannot reach the later stages without accumulating the fields.
View as table
| Item | Value |
|---|---|
| Score 0-1 | 130 deals |
| Score 2 | 90 deals |
| Score 3 | 60 deals |
| Score 4 | 40 deals |
| Score 5 | 20 deals |
Training vs schema: what moves adoption
| Methodology as training | Methodology as schema plus gates | |
|---|---|---|
| Where it lives | A class, a workbook, a laptop sticker | Typed CRM fields wired to stages |
| What enforces it | A manager nagging in one-on-ones | A validation rule blocking the stage save |
| How you inspect a deal | Ask the rep, hope for the call recording | Filter the report on the gated fields |
| Forecast input | Rep gut feel and stage label | Qualification-completeness score 0 to 5 |
| What a rep does under pressure | Skips it, enters stage and close date | Fills it, because the deal will not advance otherwise |
| Economic-buyer capture rate | 12% (the story above) | 98% on advanced deals by day 90 |
The right column is not more disciplined people. It is the same people inside a system that makes the disciplined thing the only path forward. That is the whole trick, and it is why the capture-rate table moves in weeks rather than quarters.
The part enablement will not like
If you run enablement, this piece reads as an argument that your training does not work, and that is not quite it. The training builds the understanding. The schema and the gates build the behavior, and behavior is what shows up in the forecast. A rep can understand SPICED perfectly and still never enter an economic buyer, because understanding and doing are governed by different systems, and only one of them is a laptop sticker.
So stop measuring adoption by certification completion and start measuring it by capture rate. Certification tells you the rep sat in the room. The report that filters open pipeline to deals missing a confirmed buyer tells you whether the methodology is real. If that number is 12%, no amount of additional training fixes it, because you are treating a data-capture failure as a knowledge gap.
Build the schema, gate the stages, score the completeness, and the framework everyone “uses” finally becomes the framework the pipeline runs on. The VP whose team captured a buyer on 12% of deals did not need a better class. He needed four fields, two validation rules, and a report he could run on a Monday. That is a week of ops work standing in for a year of enablement that was never going to land, because the thing he was missing was never knowledge. It was columns.
Keep reading
One email. Every week.
One email a week: an operating problem I solved or botched, with the model, the numbers, and what I would change. No roundups, no theory, unsubscribe whenever it stops being useful.
The newsletter opens soon.
Connect a provider in src/config.ts