关于 pipeline-stage-definition-audit
pipeline-stage-definition-audit 是审查现有销售管道阶段定义的技能,判断退出条件是否对应可由买方验证的里程碑,并生成按严重程度排序的发现报告。它还提供改写后的退出条件和迁移计划,审计而不重设计阶段集合。
主要功能
- 01识别管道类型
- 02检验买方可验证的退出条件
- 03按严重程度整理问题
- 04改写不合格的阶段条件
- 05规划安全迁移与发布
适用场景
- 01排查阶段定义含糊或依赖主观判断
- 02检查阶段推进与预测问题
- 03规划阶段值变更而保护历史报表
- 04为定义更新安排培训与发布
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ mbfinotti/ revops-skills --skill pipeline-stage-definition-audit安装后在 Claude Code 中输入/pipeline-stage-definition-audit确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
evals/evals.jsonreferences/audit-intake.mddiagnostic-metrics.mdremediation-rollout.mdverifiability-test.mdworked-examples.md详细介绍
阶段定义审计
评估现有销售流程的阶段定义,判断其反映的是否为买方可验证的里程碑——即买方做过、说过或同意过的事情,而非销售代表的内部活动;并提交按严重程度排序的发现报告,其中包含重写后的退出标准和安全迁移计划。
参考框架:
- Gartner 的六项 B2B 购买任务(买方侧参考结构):问题识别、方案探索、需求构建、供应商选择、验证、共识达成。
- GitLab 公开的商业销售手册(已发布阶段定义文档的实际范例):定义、参与人员、活动、系统强制要求、退出标准、交叉链接。
- MEDDPICC 式门槛判断:每项退出标准均评为红/黄/绿,全部为绿色后方可推进。
- Winning by Design 的 SPICED(买方侧诊断视角):其各项要素需与买方确认,而非由销售代表自行假定。
基本原则
- 只做审计,绝不重新设计。现有阶段集就是输入。如果问题出在销售漏斗模型本身,请明确指出,并转至销售漏斗设计的另请参阅(Reference),不要在此处重建模型。
- 为每个阈值标明其依据:已公开的公司实践、从业者共识,或根据用户自身数据推导。绝不要把供应商的经验法则说成行业通则。
- 提醒读者,不要引用广为流传的预测统计数据(“93% 的团队无法将收入预测误差控制在 5% 以内”“85% 的 B2B 公司未能达到预测目标”“CRM 数据准确率只有 40-60%”)——这些说法均无出处地流传,绝不能当作事实陈述。应改为说明其作用机制:晋级标准主观时,两名销售代表会将相同的交易置于不同阶段,从而扭曲阶段转化数据及其上的所有分析。
- 阶段记录的是买方所处的位置,绝不是资格评估记分卡。不存在“MEDDIC 第 1-6 阶段”(这是 Force Management 的警示):每个资格维度都应作为独立字段持续更新;将记分卡与阶段下拉列表混为一谈,会导致两者都失效。
- 在评判任何阶段之前,先对销售流程类型进行分类(见下文)。用交易销售流程的预期标准来评判交易管道,会得出错误结论。
- 绝不要重命名或删除现有阶段值。大多数 CRM 中,阶段历史记录不可变,历史记录会永久引用旧值——重命名或删除会永久破坏变更前后的报告。停用旧值,并添加新值。任何变更后,都要重新检查每个阶段的预测类别映射。
- 5-7 个阶段、每个阶段有 2-4 项退出标准,是从业者共识范围,并非硬性规定。每个阶段都必须有独特用途,才能保留;如果阶段内没有任何变化,就将其删去。
流水线类型
在评判任何阶段之前,先确定流水线类型——这三种类型来自 The RevOps Show(Doug Davidoff 和 Jess Cardenas):
- 开发型流水线 - 将客户从毫无意向推进到产生意向。阶段追踪的是买方兴趣信号,而非交易机制。
- 交易型流水线 - 从产生意向推进到作出决策。本审计示例默认采用的经典企业级 B2B 模型。
- 事务型流水线 - 高速、低价值,以减少摩擦为重点。阶段更少,标准更宽松,进展信号通常会自动触发。
高速度、自助服务、PLG 和 B2C 团队通常完全没有由销售代表负责的流水线:他们使用由营销或增长团队负责、面向买方的生命周期/漏斗阶段。只有当销售模式转为销售辅助或上探高端市场时,真正的流水线结构才会重新出现;此时,漏斗和流水线必须作为不同的报告结构并存,绝不能合并为一份阶段列表。
- **B2B 和 B2C 的共同点:**可验证性测试本身、阶段停留时长和转化诊断,以及停用而非重命名的迁移规则。
- **B2B 和 B2C 的差异:**阶段数量、证据类型(产品事件和付款信号,与签署文件和安全审查相比)以及归属责任。
关于 B2C 阶段定义的知名实践者文献很少,因此,三种流水线类型的框架是现有最佳依据;其余内容应从用户自身的数据中推导,并明确说明这一点。
访谈
在评判任何内容之前先提问。每条消息只问一个问题;尽可能采用选择题;已经回答的问题则跳过。
- 请粘贴当前阶段列表及每个阶段的书面定义,须与文档中的内容完全一致。如果定义只存在于人们的脑海中,请直接说明——这本身就是一项发现。
- 哪种销售模式会进入此流水线:企业级销售主导、中端市场、高速度内部销售,还是 PLG 销售辅助?有一条还是多条流水线?多种销售模式是否共用同一条流水线?
- ACV 区间和典型销售周期有多长?
- 是哪些症状触发了此次审计:交易卡在某个阶段、预测失准、经理对阶段判定意见不一、跳过阶段,还是悄无声息地推迟预计成交日期?
- 每个阶段对应哪种预测类别?
- 哪些必填字段、验证规则和自动化流程与阶段值绑定?
- 可以导出或查询哪些数据:阶段变更历史、已赢单/已输单记录、预计成交日期变更历史、按销售代表划分的数据?
- 谁负责阶段定义,谁批准变更(RevOps、销售领导层、财务)?
- 是否有两个人可以独立评估同一批交易——两位经理,或任何两位能在不商议的情况下评判交易记录的审核者?通过门槛中的评估者间一致性检查需要他们。如果只有一位审核者,现在就说明:该检查将改为针对机器记录标准的自动化事件抽查,交付成果必须说明这一替代方案,而不能声称获得了实际上从未测量过的一致率。
- 上次变更阶段是什么时候,推出过程进展如何?
- 能否提供样本:最近 20-30 笔已完成的交易,以及当前停留在各阶段的未完成交易?
- 必须在哪个日期前交付结果?该日期是否处于当前季度进行期间?阶段变更会污染其生效所在的季度,因此,季度中期的截止日期会排除补救顺序中的所有迁移步骤,只保留标准重写。
- 你需要在特定预测前进行一次性修正,还是需要一套每个季度都适用的定义?一次性需求优先只重写标准;长期累积性需求则要求完善证据基础设施,并将定期检查设为必选项。
- 工作量上限是多少:是否有 CRM 管理员可用,需要重新培训多少名销售代表,流水线的趋势序列是否可以接受在切换日期重新开始?没有管理员会排除证据基础设施步骤;无法接受趋势中断则会排除阶段拆分和新增阶段。
工作流
-
进行访谈;判断销售管线类型并确认范围边界(审计,而非重新设计)。
-
根据 references/audit-intake.md 收集材料并访谈相关利益方。先查看数据,再与任何人交谈。
-
对每个阶段应用 references/verifiability-test.md 中的可验证性测试:退出标准必须指明买方做了什么、说了什么或同意了什么;必须独立于销售代表的观点进行观察;并且必须记录在可供核查的地方。操作层面的判断方式:两位经理查看同一条交易记录时,能否各自独立地对是否满足标准得出相同结论?
-
将每个阶段映射到 Gartner 采购任务(同一参考文档中的表格)。标记无法映射到任何任务的阶段(伪装成阶段的销售代表活动),以及多个阶段挤在同一任务上的情况(阶段冗余)。
-
如果能直接查询销售管线数据,就计算 references/diagnostic-metrics.md 中的诊断指标;否则,根据交易样本和访谈中支持的信息推导,并将每项未测量的诊断指标标记为未测量。
-
按以下格式记录每项缺陷:阶段 | 当前退出标准 | 判定 + 原因 | 严重程度 | 修复级别 + 工作量 | 证据 | 映射的采购任务 | 拟议标准 | 迁移说明。严重程度分级:
- Critical - 退出标准纯属销售代表活动或未记录;阶段推进取决于主观判断。
- High - 标准提及买方,但无法验证,或未记录在可供核查的地方。
- Medium - 可以验证,但含义不明确;两位经理可能会合理地得出不同结论。
- Low - 标准合理;缺陷在于命名、顺序或冗余。
严重程度是缺陷的价值维度,绝不是其排队位置。一项只需改一处措辞即可修复的 Critical 缺陷,应先于一项需要迁移选项列表的 Medium 缺陷上线。为每项缺陷标注其所属级别及该级别的大致工作量,然后按照下文的修复顺序排列清单。
-
为每个未通过的阶段起草改写后的退出标准(措辞指南见可验证性参考文档),然后根据 references/remediation-rollout.md 制定修复和推出计划——按修复顺序安排修复、采用停用并新增的迁移方式、重新映射预测类别、审计自动化、安排培训并确定推出方式。
-
按照以下输出格式,每次输出报告的一个部分,供用户验证;内容须以 references/worked-examples.md 中对应的实例为依据。
-
检查通过阈值;反复调整标准和计划,直到达到阈值,或明确安排剩余差距的处理时间(例如,需要完整销售周期的新数据才能计算的指标)。
-
如果你的运行环境支持持久记忆,请保存阶段清单、各阶段的判定结果以及商定的阈值,以便推出后的复查可基于这些信息开始,而无需重新访谈。
修复顺序
六种修复类型,按单位工作量所恢复的预测准确性排序——绝不按严重程度排序,也不按成本从低到高排序。此处的工作量包括管理配置、对该阶段涉及的每位销售代表进行再培训、历史数据迁移以及可逆性。可逆性在此列表中占主导地位:一个季度内两次修改阶段定义会破坏这些定义旨在生成的趋势数据,因此任何触及阶段值的修复都近乎不可逆。
- 价值(恢复的准确性,从高到低):
完全重新定义 > 改写标准 > 补全证据链路 > 新增阶段 == 删除阶段 > 定期检查 - 工作量(从高到低):
完全重新定义 > 新增阶段 > 删除阶段 > 补全证据链路 > 定期检查 > 改写标准 - 效率(从高到低):
改写标准 > 定期检查 > 补全证据链路 > 删除阶段 > 新增阶段 > 完全重新定义
新增阶段和删除阶段在价值上相同:由销售管线类型决定哪一种更合适,其他因素均不影响。
- **交易管道:**新增阶段的收益更大,因为企业交易往往止步于验证和共识建立,而这些阶段最常缺乏覆盖。
- **事务管道:**删减阶段的收益更大,因为消除摩擦正是这种销售模式的设计目标,而交易跳过的阶段,跳过后转化率反而更高。
两者的投入并不相同:迁移工作量相同,而新增阶段还要求销售代表提供他们从未被要求提供过的证据。
- 重写标准——将未达标的退出标准改写为买方行为,并指向系统已有的字段或工件。不更改选项列表,不迁移数据,也不重新映射预测。每个阶段耗时从接近零到一小时不等,另需在现有评审会议中进行一次讲解;旧措辞只需修改文档即可。仅此一项就能消除大多数 Critical 和 High 级别的问题。
- 定期检查——将退出标准纳入定期管道评审议程,并每季度重新抽样进行评估者间复核。每季度一小时,长期持续。此举本身无法提高准确性;它之所以值得排在这一层级,是因为只有它能防止所有更高层级的措施在两个季度内重新退化为主观判断。
- 证据采集机制——创建重写后的标准所要求、但系统尚未采集的字段、验证规则或证据链接。需要一到两天的管理员配置时间,还要对所有涉及该阶段的销售代表重新培训。配置可逆,但培训投入无法撤回。这一步能让通过评审的标准在实际运行中真正成立。
- 删减或合并阶段——停用并新增阶段,以处理不对应任何购买任务或与相邻阶段重复的阶段。耗时从几天到一个季度不等:需要迁移尚未结束的交易、重新映射预测类别,并盘点所有以阶段为键的自动化。切换时会中断趋势序列;若要撤销,还会再次中断。
- 新增阶段——为当前没有任何阶段覆盖的购买任务新增一个阶段。迁移工作量与删减阶段相同,此外还要引入销售代表从未被要求执行、经理从未检查过的行为。耗时一个季度。
- 全面重新定义——将阶段集合重建为连贯的序列,而不是逐项修补。根据基本规则,此项不在范围内;应转交处理,不要尝试自行完成。
默认顺序:一次性重写所有标准,然后安排定期检查。只有在重写后的标准要求系统尚未采集的证据时,才进入下一层级——此时,证据采集机制并非后续阶段的工作,而是让重写后的标准真正成立的必要条件。
这种排序会将全面重新定义排除在外。它的价值排名第一:这是唯一能将阶段集合视为一个序列,而非一列各自措辞的项目来处理的修复方式。但在每次合作中,它的投入产出比都排在最后,因此按严重程度和投入排序时会被无限期推迟,最终导致管道中积累了措辞完善的标准,却仍建立在无法支撑这些标准的阶段模型上。
出现以下情况时,应将其提到优先位置,并从此技能转交至 mbfinotti/revops-skills@revenue-funnel:
- 审核后,可用作锚点的阶段少于两个。
- 多种销售模式共用同一套阶段列表。
- 管道类型本身被错误分类。
应将被判定不适用的层级从计划中删除,而不是降级:被搁置在计划底部的层级之后会再次出现,成为无人预算的范围。
- 没有人能批准阶段定义变更(根据访谈):从计划中删去阶段删减和新增,并明确说明已将它们删去。没有审批人的迁移永远无法上线。
- **没有可用的 CRM 管理员:**同样删去证据采集机制。
这个顺序是默认方案,不是铁律:它会随背景和执行者而变化。应根据访谈中的回答重新排序。
- **有 CRM 管理员可用:**将证据采集机制所需时间从一到两天缩短至一小时,并将其排在定期检查之前。
- **销售团队正值季度中期:**在季度结束前删去所有迁移层级,因为阶段变更会破坏其生效所在的季度数据。
- **管道规模小到可以手动重新划分阶段:**将删减和新增阶段所需投入降低一个数量级,并将两者都排在证据采集机制之前。
输出格式
每条门槛都带有来源标记。
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, aging outliers, skip/backward rate,
close-date push counts, per-rep variance (provenance-tagged)
Findings : records ordered by Remediation Order, severity carried per
record as its value axis (schema in Workflow step 6)
Remediation : rewritten exit criteria, rungs chosen and rungs struck with the
constraint that struck them, deactivate-and-add migration plan,
forecast-category re-map, automation/dashboard checklist,
training + rollout shape
Measurement : baseline values captured, post-change KPIs, re-check date
(>= one full sales cycle out)
通过门槛
- 每个阶段至少有一项退出标准,明确指出买方采取的行动,并关联到系统记录中的可核验字段或材料。
- 评审者间一致性检查:两位经理(或两位独立评审者)各自依据改写后的标准,对 10-20 笔未结交易进行评分,期间不得交流。至少 90% 的交易判定必须一致——这是一个工作基准,应根据用户自己的数据推导出更严格的标准,而非已发布的行业标准。分歧表明标准存在歧义;应改写该标准并重新抽样。
- 各阶段之间的转化率应沿销售漏斗逐级递减,或者对每个例外情况都应有意图明确的设计解释(例如,旨在淘汰交易的验证阶段)。
- 未结销售管道中,各阶段所占交易比例不应与其预期停留时间严重不符——应依据销售管道自身的历史数据推导预期分布,而非采用行业固定值。
持续迭代,直到上述四项全部满足。要使转化率和分布检查结果可信,需等新定义下的交易经历完整销售周期;如果尚无此类数据,应在交付成果中说明,并将复查安排为上线后的首个关卡。
常见失败模式
故意不排序:每一行都是一个诊断及对应的修复方法,而非针对同一问题的多个备选修复,因此按效率排序只会把读者遇到的症状排出先后,而非比较他们的选项。适用的行都应执行。
| 缺陷 | 后果 | 修复 |
|---|---|---|
| 直接重命名或删除阶段值 | 历史报告永久损坏;自动化流程悄然失效 | 停用旧值,添加新值;通过映射字段衔接 |
| 跳过预测类别重新映射 | 阶段名称看似正确,但预测汇总悄然失真 | 每次变更后重新检查每个阶段的映射 |
| 将资格评分卡嵌入选项列表 | 阶段不再反映买方所处位置;两种机制都会退化 | 将持续更新的资格字段分开设置;阶段 = 买方所处位置 |
| 将标准写成销售代表的活动 | 阶段膨胀;因过度乐观而推进 | 将每条标准改写为以买方行动开头 |
| 标准在纸面上可验证,但没有记录在任何地方 | 审计时合格,实际执行中却无法落实 | 将每条标准关联到必填字段或证据链接 |
| 用交易销售管道规则评判交易处理型销售管道 | 得出错误结论;给一个以消除阻力为目标的销售流程增加摩擦 | 先确定销售管道类型;根据销售流程调整标准权重 |
| 阶段超过约 7 个,或阶段彼此相似 | 相邻阶段难以区分;标准被稀释 | 合并阶段;每个阶段都必须有明确且独特的用途(从业者共识) |
| 以记录或合规率衡量成效 | 销售代表记录得更多、更快,却更差;数据质量没有改善 | 改为衡量转化率稳定性和评审者间一致性 |
| 在第二周就评估修复成效 | 没有经历完整的新交易周期,转化率指标毫无意义 | 至少等待一个销售周期;采用 30/60/90 天的采用情况检查点 |
| 让销售代表首次在实际工作中看到新标准 | 标准被忽视;阶段数据质量没有变化 | 先进行培训;将退出标准纳入定期销售管道审查 |
关键绩效指标
- 跟踪:阶段间转化率的稳定性和单调衰减、每位销售代表的转化率方差(最能单独反映主观定义的指标)、阶段停留时间中位数和异常值数量、跳过阶段和回退阶段的比率、每笔交易的预计成交日期推迟次数、定期抽样交易的评分者间一致性,以及预测准确度(按至少每季度一次计算首日预测值与本期最终结果之间的绝对百分比差异)。
- 切勿将采用率或日志合规率报告为成功指标——它们衡量的是压力,而非准确性。
- 每季度重新进行评分者间一致性抽样;一致性率下降意味着标准又开始偏向主观判断。
调用示例
- “我们的阶段是‘已安排演示’、‘已发送提案’和‘口头承诺’,每笔交易却都在‘已发送提案’阶段停留好几个月。请审查我们的阶段定义。”
- “我的两位经理对同一笔交易是否属于第 3 阶段意见不一。请审查我们的退出标准,并指出哪些阶段其实只是换了个说法的销售代表活动。”
- “我们正从 PLG 转向大客户市场,销售协助交易现在和自助注册共用一个销售管道。请审查我们的阶段是否还有实际意义,再据此进行预测。”
参考资料
- references/verifiability-test.md - 可验证性测试、合格与不合格的措辞、Gartner 购买任务映射表,以及一个反面示例。
- references/diagnostic-metrics.md - 各项指标的计算方法、其危险信号模式及来源。
- references/audit-intake.md - 工件清单、访谈指南和职责归属图。
- references/remediation-rollout.md - 迁移机制、切换与可比性、培训,以及可选的供应商专属集成说明。
- references/worked-examples.md - 一次企业审计、一次高速审计,以及一次错误的审计。
mbfinotti/revops-skills@sales-forecast-diagnostic- 整体预测可靠性mbfinotti/revops-skills@sales-pipeline-hygiene- 定期清理过时交易并保持卫生的节奏mbfinotti/revops-skills@crm-data-governance- 字段字典和选项列表治理mbfinotti/revops-skills@revenue-leakage- 追踪阶段间的收入流失