首页/销售与商务/pipeline-stage-definition-audit
P

pipeline-stage-definition-audit

by @mbfinottiv
4.5(120)

对现有销售管道的阶段定义做审计,检验每个阶段的退出标准是否以买方可验证的里程碑(买方做过、说过或同意的事)为基础,而非销售代表的内部动作,并输出按严重度排序的问题清单、改写后的退出标准与安全的迁移方案。适用于排查阶段虚高、阶段卡顿、阶段名基于销售动作的 B2B 与 B2C 团队。

salescrmpipeline-auditb2b-salesrevopsGitHub
安装方式
npx skills add https://github.com/mbfinotti/revops-skills --skill pipeline-stage-definition-audit
compare_arrows

Before / After 效果对比

1 组
使用前

团队手动逐条翻查管道阶段定义,各人理解不同,退出标准常写成“已安排演示”“已发提案”这类销售动作,预测口径混乱,一次评审耗掉半天还难达成一致。

使用后

此技能按买方可验证里程碑逐阶段校验退出标准,输出严重度排序的问题清单、改写后的退出条件与停用不重命名的安全迁移方案,并附带阶段滞留、转化衰减等诊断,让预测口径统一可信。

SKILL.md

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.
    • High - criterion references the buyer but is unverifiable or recorded nowhere checkable.
    • Medium - verifiable but ambiguous; two managers could plausibly disagree.
    • Low - criterion sound; defect is naming, ordering, or redundancy.

    Severity is the value axis of a finding, never its queue position. A Critical defect fixed by one wording change ships before a Medium one that needs a picklist migration. Tag each finding with the rung it lands on and that rung's effort order of magnitude, then order the list by Remediation Order below.

  7. Draft rewritten exit criteria for every failing stage (wording guidance in the verifiability reference), then build the remediation and rollout plan from references/remediation-rollout.md - fixes sequenced by Remediation Order, deactivate-and-add migration, forecast-category re-mapping, automation audit, training and rollout shape.

  8. Emit the report (Output Shape below) one section at a time for user validation; ground it in the matching worked example from references/worked-examples.md.

  9. Check the Pass Threshold; iterate the criteria and plan until it holds or the remaining gaps are explicitly scheduled (e.g. metrics that need a full sales cycle of new data).

  10. If your harness has persistent memory, store the stage inventory, per-stage verdicts, and agreed thresholds so the post-rollout re-check starts from them instead of re-interviewing.

Remediation Order

Six fix types, ordered by forecast accuracy recovered per unit of effort - never by severity, and never cheapest-first. Effort here is admin configuration, retraining every rep who works the stage, historical data migration, and reversibility. Reversibility dominates this list: a stage definition changed twice in a quarter destroys the trend data the definitions exist to produce, so any fix that touches a stage value is close to one-way.

  • value (accuracy recovered, most first): full redefinition > criterion rewrite > evidence plumbing > stage add == stage cut > standing inspection
  • effort (most first): full redefinition > stage add > stage cut > evidence plumbing > standing inspection > criterion rewrite
  • efficiency (best first): criterion rewrite > standing inspection > evidence plumbing > stage cut > stage add > full redefinition

stage add == stage cut on value: pipeline type decides which one wins, and nothing else does.

  • Deal pipeline: recovers more from the add, since enterprise deals die in Validation and Consensus Creation, the jobs most often left uncovered.
  • Transaction pipeline: recovers more from the cut, since friction removal is that motion's design goal, and a stage deals skip is a stage that converts better skipped.

They do not tie on effort: the migration is identical, and only the add asks reps for evidence they have never been asked to produce.

  1. Criterion rewrite - restate a failing exit criterion as a buyer act pointing at a field or artifact the system already holds. No picklist change, no migration, no forecast re-map. Near-zero to an hour per stage, plus one walkthrough in the review meeting that already happens; the old wording is a document edit away. Retires most Critical and High findings on its own.
  2. Standing inspection - exit criteria on the recurring pipeline-review agenda, plus a quarterly inter-rater re-sample. An hour a quarter, forever. Recovers no accuracy by itself, and earns its rank by being the only rung that stops every rung above it drifting back to opinion within two quarters.
  3. Evidence plumbing - create the required field, validation rule, or evidence link a rewritten criterion names but the system does not capture. A week of admin configuration plus retraining every rep who touches that stage. Reversible in configuration, never in retraining. This is what turns a criterion that passes review into one that holds in production.
  4. Stage cut or merge - deactivate-and-add a stage that maps to no buying job or duplicates its neighbor. A week to a quarter: open-deal moves, forecast-category re-map, and the stage-keyed automation inventory. Breaks the trend series at cutover, and reversing it breaks it a second time.
  5. Stage add - a new stage for a buying job nothing covers. The same migration as the cut, plus a behavior reps have never been asked for and managers have never inspected. A quarter.
  6. Full redefinition - the stage set rebuilt as a coherent series rather than patched cell by cell. Out of scope here by Ground Rules; route it rather than attempting it.

Default rung: run every criterion rewrite in one pass, then schedule the standing inspection. Take on the next rung down only when a rewritten criterion names evidence the system does not capture - there the plumbing is not a later phase, it is what makes the rewrite true.

What this order starves is the full redefinition. It ranks first on value: the only fix that treats the stage set as a series instead of a list of separately worded cells. It ranks last on the ratio in every engagement, so a severity-and-effort ranking defers it indefinitely, and the pipeline accumulates well-written criteria on a stage model that cannot carry them.

Promote it, and route out of this skill to mbfinotti/revops-skills@revenue-funnel, when:

  • Fewer than two stages survive the audit as usable anchors.
  • Multiple motions share one stage list.
  • The pipeline type itself is misclassified.

Delete a ruled-out rung rather than demoting it: a rung parked at the bottom of the plan returns later as scope nobody budgeted.

  • No approver for a stage-definition change (per the Interview): strike the cut and the add from the plan, and say they are struck. A migration with no approver ships never.
  • No CRM admin available: strike the evidence plumbing the same way.

The order is a default, not a law: it shifts with context and with who executes it. Re-rank it against the Interview's answers.

  • CRM admin on hand: collapses the plumbing rung from a week to an hour and moves it above the standing inspection.
  • Sales team mid-quarter: strikes every migration rung until the quarter closes, because a stage change corrupts the quarter it lands in.
  • Pipeline small enough to re-stage by hand: drops the cut and add rungs by an order of magnitude and promotes both above the plumbing.

Output Shape

Every threshold line carries a provenance tag.

STAGE DEFINITION AUDIT - <pipeline>, <date>
Pipeline type    : development / deal / transaction + motion, ACV band, cycle length
Stage inventory  : count vs 5-7 consensus band; definitions documented or tribal;
                   forecast-category map present/absent
Per-stage verdict: stage -> exit criterion -> pass/fail verifiability -> severity
Buying-job map   : which Gartner job each stage covers; jobs with no stage; jobs
                   with several stages
Diagnostics      : conversion decay shape, a

...

用户评价 (0)

发表评价

效果
易用性
文档
兼容性

暂无评价

统计数据

安装量9.7K
评分4.5 / 5.0
版本
更新日期2026年10月13日
对比案例1 组

用户评分

4.5(120)
5
37%
4
43%
3
13%
2
5%
1
2%

为此 Skill 评分

0.0

兼容平台

🤖claude-code

时间线

创建2026年9月27日
最后更新2026年10月13日
🎁 Agent 知识卡片
调研问卷