Pipeline Stage Definition Audit

Stage Definition Audit

Evaluate whether an existing pipeline's stage definitions reflect buyer-verifiable milestones - things the buyer did, said, or agreed to - rather than internal rep activity, and deliver a severity-ranked findings report with rewritten exit criteria and a safe migration plan.

Reference frameworks:

• Gartner's six B2B buying jobs (buyer-side reference structure): Problem Identification, Solution Exploration, Requirements Building, Supplier Selection, Validation, Consensus Creation.
• GitLab's public commercial sales handbook (real-world exemplar of a published stage-definition document): definition, who's involved, activities, system enforcement, exit criteria, cross-links.
• MEDDPICC-style gating: each exit-criterion element scored red/yellow/green, all-green to advance.
• Winning by Design's SPICED (buyer-side diagnostic lens): its elements are confirmed with the buyer, not assumed by the rep.

Ground Rules

• Audit, never redesign. The existing stage set is the input. If the funnel model itself is the defect, say so and route to the funnel-design see-also (Reference) instead of rebuilding it here.
• Label every threshold with its provenance: published company practice, practitioner consensus, or derived from the user's own data. Never present a vendor heuristic as an industry constant.
• Warn off the circulating forecast statistics ("93% of teams can't predict revenue within 5%", "85% of B2B companies miss forecast", "CRM data is only 40-60% accurate") - each circulates unattributed and must never be stated as fact. Cite the mechanism instead: when advancement is subjective, two reps stage identical deals differently, which corrupts stage conversion data and everything built on it.
• The stage records the buyer's position, never a qualification scorecard. There are no "MEDDIC stages 1-6" (Force Management's warning): each qualification dimension is its own continuously-updated field; conflating the scorecard with the stage picklist breaks both.
• Classify the pipeline type (below) before judging any stage. A transaction pipeline judged by deal-pipeline expectations produces false findings.
• Never rename or delete an existing stage value. In most CRMs, stage history is immutable and historical records reference old values forever - renaming or deleting corrupts before/after reporting permanently. Deactivate the old value and add a new one. After any change, re-check the forecast-category mapping for every stage.
• 5-7 stages with 2-4 exit criteria each is the practitioner-consensus band, not a law. A stage earns its place by having a distinct purpose; if nothing changes in it, cut it.

Pipeline Types

Establish the pipeline's type before judging a single stage - the three types come from The RevOps Show (Doug Davidoff and Jess Cardenas):

• Development pipeline - moves an account from no intent to intent. Stages track buyer interest signals, not deal mechanics.
• Deal pipeline - intent to decision. The classic enterprise B2B model this audit's examples assume by default.
• Transaction pipeline - high-velocity, lower-value, friction-reduction focus. Fewer stages, lighter criteria, often automated progression signals.

High-velocity, self-serve, PLG, and B2C teams frequently run no rep-owned pipeline at all: they run buyer-facing lifecycle/funnel stages owned by marketing or growth. A true pipeline construct reappears only when the motion goes sales-assisted or upmarket, and then funnel and pipeline must coexist as distinct reporting constructs, never merged into one stage list.

• Identical across B2B and B2C: the verifiability test itself, the stage-aging and conversion diagnostics, and the deactivate-don't-rename migration rule.
• Divergent across B2B and B2C: stage count, evidence type (product events and payment signals versus signed documents and security reviews), and ownership.

Named-practitioner literature on B2C stage definition is thin, so the three-pipeline-type framing is the best available anchor; derive the rest from the user's own data and say so.

Interview

Ask before judging anything. One question per message; multiple-choice where possible; skip anything already answered.

• Paste the current stage list with each stage's written definition, exactly as documented. If definitions live only in people's heads, say so - that is itself a finding.
• Which motion feeds this pipeline: enterprise sales-led, mid-market, high-velocity inside sales, PLG sales-assisted? One pipeline or several, and do multiple motions share one?
• ACV band and typical cycle length?
• What symptoms triggered this audit: deals stuck in one stage, forecast misses, managers disagreeing on staging, stage skipping, silent close-date pushes?
• What is the forecast-category mapping per stage?
• Which required fields, validation rules, and automations are keyed to stage values?
• What data can be exported or queried: stage-change history, closed-won/lost records, close-date change history, per-rep breakdowns?
• Who owns stage definitions and who approves changes (RevOps, sales leadership, finance)?
• Are two people available to score the same deals independently - two managers, or any two reviewers who can judge a deal record without conferring? The Pass Threshold's inter-rater check needs them. If only one reviewer exists, say so now: the check becomes an automated-event spot audit against machine-recorded criteria, and the deliverable must state that substitution rather than claim an agreement rate it never measured.
• When were stages last changed, and how did that rollout go?
• Can you provide samples: 20-30 recent closed deals and the open deals currently sitting in each stage?
• By what date must the result land, and does that date fall inside a live quarter? A stage change corrupts the quarter it lands in, so a mid-quarter deadline strikes every migration rung in Remediation Order and leaves criterion rewrites only.
• Do you want a one-off correction before a specific forecast, or a definition set that holds every quarter? One-off promotes the criterion rewrite alone; a compounding mandate promotes the evidence plumbing and makes the standing inspection non-optional.
• What is the effort ceiling: is a CRM admin available, how many reps must be retrained, and can the pipeline's trend series afford to restart at a cutover date? No admin strikes the evidence-plumbing rung; no tolerance for a trend break strikes the stage cut and the stage add.

Workflow

1. Run the Interview; classify the pipeline type and confirm the scope boundary (audit, not redesign).
2. Gather artifacts and run stakeholder interviews per references/audit-intake.md. Look at the data before talking to anyone.
3. Apply the verifiability test from references/verifiability-test.md to every stage: the exit criterion must name something the buyer did, said, or agreed to; be observable independently of the rep's opinion; and be recorded somewhere checkable. Operational form: could two managers, looking at the same deal record, independently reach the same verdict on whether the criterion is met?
4. Map each stage to a Gartner buying job (table in the same reference). Flag stages that map to no job (rep activity in disguise) and multiple stages crowding one job (redundant stages).
5. Compute the diagnostics in references/diagnostic-metrics.md where the pipeline's data can be queried directly; otherwise derive what the deal samples and interviews support, and mark each unmeasured diagnostic as such.
6. Record every defect as a finding with this schema: Stage | Current exit criterion | Verdict + why | Severity | Fix rung + effort | Evidence | Buying job mapped | Proposed criterion | Migration note. Severity scale:

• Critical - exit criterion is pure rep activity or undocumented; advancement is opinion.