sales-pipeline-hygiene

Pipeline Hygiene

审核当前活跃销售管道中的交易——包括长期停滞的交易、预计成交日期异常推迟，以及缺少对预测至关重要的字段——并将发现整理成异常清单：每笔被标记的交易都要有一项处置决定、一份补救与沟通计划，以及一个可衡量的达标门槛。职责分为三方，不能共享（ORM）：

• RevOps 负责定义、快照、自动化和发布前的数据包。
• 一线经理负责逐笔交易的处置决定和辅导沟通。
• 销售代表负责更新数据并提供证据。

这种职责划分能消除争议——经理带着违反具体规则的具体记录前来，而不是提出笼统的抱怨。换成其他划分方式，会议虽然能准时结束，却什么也改变不了。

审计中最关键的定义选择必须先明确：有意义的活动是阶段、预计成交日期或金额发生变化，而不是记录的电话或邮件（ORM）。在 CRM 的语境中，记录的联系行为算作活动，但并不表示交易有进展，因此，基于这些记录制定的规则可以在交易毫无进展的情况下满足条件——这正是停滞的销售管道在一次次审核后仍然存在的原因。这是从业者之间仍有分歧的问题（许多工具以最后活动日期为依据）；默认采用字段变更定义，并将最后活动日期作为第二个独立触发条件——两者应结合使用，绝不能互相替代。

范围界定

在交付物中明确以下内容，以免审计偏离范围：

• 这是对当前销售管道中交易的一次定期审计。设计用于防止交易停滞的常设自动提醒系统是另一项工作：审计可以建议自动执行定期检查，并说明检查结果交由谁处理，但不得设计提醒时间、渠道或通知疲劳策略。
• 本审计不检查或重写阶段定义或退出标准——这属于 mbfinotti/revops-skills@pipeline-stage-definition-audit。Hygiene 将现有阶段集合视为既定条件，并检查其中的交易。
• 本审计不诊断整体预测可靠性——这属于 mbfinotti/revops-skills@sales-forecast-diagnostic。Hygiene 为其提供干净的数据，但不会修正预测方法。
• 本审计不制定全组织范围的字段所有权或数据源标准政策——这属于 mbfinotti/revops-skills@crm-data-governance。Hygiene 检查现有字段是否完整。
• 本审计不追踪销售漏斗中的收入流失——这属于 mbfinotti/revops-skills@revenue-leakage。

访谈

审计前先提问。每条消息只问一个问题；尽可能使用选择题；已回答的问题跳过。

• 可以从记录系统导出或查询哪些内容：未结商机的阶段、金额、预计成交日期、负责人、最近活动日期、创建日期、下一步行动？阶段变更历史？预计成交日期变更历史？截至特定日期的快照？
• 哪些销售模式和细分市场构成这条销售管道：SMB／高频销售、中端市场、企业级、B2C／交易型、PLG 销售协助型，还是混合型？各细分市场的典型销售周期和商机金额是多少？
• 目前已有哪类固定例行会议——每周预测会议、销售管道评审、季度业务回顾（QBR）、交易评审？审计要融入这些会议，不得新增会议。
• 做出预测和销售管道决策时，实际会参考哪些字段？（完整性检查只针对这些字段，而非所有字段。）
• 是否已有关于“过时”的书面定义或任何数据规范规则？是否有人执行，由谁负责？
• 结果必须在哪一天前提交——季度业务回顾（QBR）、预测会议，还是董事会数据？如果截止日期落在本周内，应优先安排能在当天完成的整改措施（验证规则、提醒），降低任何需要集成的措施的优先级。
• 这是一次性清理（季度业务回顾前、预测前、新领导上任时），还是定期开展的工作？只有定期执行的要求，才值得承担自动采集的成本；一次性执行后不做自动化，下个季度就得再次手动完成同样的检查。
• 工作量上限是多少：销售代表每笔商机能接受多少额外操作负担、可投入多少管理员配置时间，以及每周可投入多少经理审核时间？团队若已达到操作负担上限，无论完整性差距如何，都不应再增加提醒；审核时间预算不足，则应在批量处理和沟通处理之间更多选择前者（参见 references/disposition-and-communication.md）。
• 哪位经理会和销售代表一起处理异常清单？谁负责完成处置？
• 以前是否开展过大规模清理？销售代表反应如何？是否存在已知的、仅用于“抢占”商机的记录——只是为占住客户而创建的早期阶段记录？
• 目前是否有任何薪酬与 CRM 数据规范、字段填写完整度或预测准确度挂钩？

工作流

1. 开展访谈。确定审计范围：截至指定日期的所有未结交易。冻结该快照——处置决定应以此为依据，而不是以不断变化的交易簿为准。

2. 提取数据。如果可以直接查询销售管道数据，就提取未结交易、阶段变更历史、预计成交日期变更历史和活动记录；否则，请求包含这些指定列的数据导出。然后，在进行任何衡量之前清理并标准化数据（遵循 Umbrex 的审计顺序）：

   • 将自定义阶段映射到规范顺序。
   • 移除测试记录。
   • 补齐缺失的阶段进入日期。
   • 统一货币和时区。

3. 首先评估停滞层，使用四个停滞区间——距离上次有意义的变更（ORM）不到 90 天 / 90-180 天 / 180-365 天 / 超过 365 天。排除超过 365 天的区间后，重新计算覆盖率：该数值与总体覆盖率之间的差距，才是报告夸大本季度业绩的真实程度。如果超过 20-30% 的销售管道金额处于停滞状态，应在采取任何强制措施之前安排一次销售管道清理（参见 references/disposition-and-communication.md）。

4. 从过去 12-18 个月的已成交交易历史中，按细分市场计算基准值，并排除停滞层——先清理，再衡量：包含大量无效交易的交易组，其成交曲线会比其中活跃交易的实际曲线更长、更平缓（ORM），从而扭曲审计所依据的中位数。按每个细分市场、每个阶段计算阶段停留天数的中位数（取中位数，而非平均值）。

5. 按细分市场设置阈值——从 SMB / 高速交易的约 1.5x 到企业交易的 2.0x 不等——并设置数据新鲜度窗口和推迟触发条件（见下文的检测规则；推导方法和回退方案见 references/detection-rules.md）。

6. 对快照应用三类规则。每笔交易、每条触发规则输出一行，并附上触发规则的证据。

7. 将标记合并为逐笔交易的异常清单，并附上销售管道金额；再次推迟的交易和带有多个标记的交易排在最前。

8. 根据下方分类体系，为每笔标记交易提出处置建议。由 RevOps 提议；经理和销售代表负责决定——标记绝不能自动触发删除，销售代表也不能给自己的作业打分。每项已决定的处置都必须指定负责人并记录原因。

9. 在执行或自动化任何事项之前，先拟定沟通计划；并在处理异常清单的会议至少 12 小时前发布清单——任何以拉取报告开始的会议都已经失败（ORM）。详见 references/disposition-and-communication.md。

10. 按章节输出审计报告（见下文的输出格式），供用户验证。

11. 计算 KPI 并检查通过阈值；反复调整处置方案和补救措施，直到达标，否则将差距安排到下一次审计处理。

12. 将定期审计纳入已有的例行机制（见下文的频率），并建议自动化定期检查。审计移交的预防层是提醒升级系统——Jeff Ignacio（RevOps Impact）的机制可作为参考范例：

    • 对预计成交日期已过的交易，向负责人发送消息。
    • 递增提醒计数器。
    • 第三次提醒时，将经理加入通知。

    描述这项移交属于范围；设计系统则不属于范围（范围边界）。

13. 如果你的运行环境具备持久化记忆，请保存基准值、阈值、区间规模和异常数量，让下一次审计从趋势线开始，而不是重新访谈。

Cadence - 融入现有仪式，绝不增加会议

• 每周预测电话会议：RevOps 会列出过去 14 天内没有实质进展的已承诺交易；销售代表须提供买家参与的证据，否则该交易将移出承诺范围（ORM）。
• 每两周按销售代表进行一次 Pipeline 评审——季度最后一个月改为每周一次——根据预先发布的例外清单，处理超期、早期阶段和停滞的交易。
• 季度区域检查：在周期结束前约两周进行，以便在衡量下一季度的覆盖情况前完成清理。
• 交易评审适用于后期阶段、非标准或已标记的交易（重新划分阶段、拆分交易），不用于例行维护。
• 让高管避开按销售代表进行的 Pipeline 评审：他们的出席会让销售代表忙于为 Pipeline 辩护，而不是暴露其中的风险（ORM）。销售代表参加其经理主持的会议；领导层则查看汇总结果。

检测规则

三类规则都将按上述定义的“有意义的活动”作为依据。为每个阈值标明其来源；这些数字是从业者的起始参考值，需要根据用户自己的数据进行校准。

• 停滞交易 - 同时使用两个相互独立的触发条件：

  • 阶段停留时间：超过该细分市场阶段停留天数中位数的 1.5x-2.0x 时标记。倍数取决于细分市场，并非个人偏好：SMB/高速交易约为 1.5x，中端市场为 1.5-2.0x，企业级为 2.0x（多方结论一致：Umbrex、Outreach、DealHub）。
  • 距上次活动的时间：中期/后期阶段 14 天内没有活动（Umbrex、Outreach）。作为非活动时长的经验法则，SMB 在 14-21 天时标记，中端市场在 30-45 天时标记，企业级在 60-90 天时标记；法律和采购审核明确豁免（DealHub）。
  • 下一步的日期已过，或没有安排未来会议，也应标记。

  将每笔停滞交易归入四类。ORM 的 12 个月规则标记出真正已死的那一层——超过 52 周后，成交曲线几乎不再有有意义的预期。

• 推迟次数异常 - 将推迟次数作为字段跟踪，而不是靠记忆：根据字段历史记录每笔交易的成交日期变更次数。

  • 第二次推迟即触发升级处理（ORM：代表更改成交日期是最能预测交易延迟的单一指标，而第二次推迟就是该采取行动的时候）。此时将交易交由经理检查。
  • 跨越季度边界的推迟比季度内的小幅调整更严重：任何跨越期间边界的成交日期变更都必须注明原因。
  • 三次或更多次延期足以成为取消资格的理由（SalesOpsClub）。

  应根据证据测试区分延期与已死交易，而不是看成交日期字段。询问“在这个日期变得现实之前，还需要发生什么？”，然后综合以下信号：

  • 双方行动计划的进展情况及注明日期的负责人。
  • 多线程接触的深度。
  • 经济决策者的参与度。
  • 是否进入采购/法律流程。
  • 内部支持者的响应情况。

  单独看，下一步延迟可能无伤大雅；但若同时出现成交日期推迟、单线程跟进和预算犹豫，就构成了有理有据、需要介入的情况。一旦确认延期，立即更新成交日期，并备注相关证据——最糟糕的结果是介入了交易，却没有更新预测。

• 字段完整性 - 只检查影响预测的关键字段，而不是整个架构：

  • 下一步及其日期、成交日期、金额、阶段、预测类别、已关闭且失败交易的失败原因，以及预测实际读取的其他资格认定字段。
  • 金额、阶段和成交日期是价值最高的目标——它们本身就是有意义的活动字段。

  预测关键字段的完整率目标为 90-95%，最低底线为 80%。按效率顺序进行整改——阶段门控验证规则 > 负责人提醒 > 自动捕获——该顺序背后的三个维度及其具体数值见 references/detection-rules.md。

  • 验证规则优先：配置约需一小时，只在推进到后期阶段时触发，因此只会占用代表几秒钟；它能准确保护预测所读取的字段，若触发不当还可再次关闭。必填字段只检查是否填写了内容；验证规则则检查填写的内容是否合理。
  • 增加更多必填字段不在此列：它不是排名最后，而是应直接排除，因为过多的必填项会导致大规模填入虚假占位内容（如“n/a n/a n/a”），这比诚实留空更糟，因为它看起来像是有效信号。每个对象的必填字段上限应保持在 5-7 个。
  • 自动捕获是这套顺序最不优先考虑的选项：它能永久消除操作阻力，但需要一个集成项目和一次同意审查，因此按比例计算，每轮都会优先选择提醒而非自动捕获。如果已经部署了捕获工具，或代表已达到可承受阻力的上限且没有可用的提醒手段，则应提高其优先级。

  这一顺序是默认方案，并非铁律；应结合 Interview 的回答以及实际执行者重新排序。

处置方式

每笔被标记的交易在评审结束时都必须有且仅有一种处置方式、一位负责人和一条记录在案的原因。对于过时的待处理清单，只有两种可接受的处理方式：采取实际的下一步行动并验证成交日期，使其重新活跃；或者将其关闭（ORM）。

处置方式	适用情形
以真实原因代码关闭并标记为已输	没有买方侧证据表明存在活跃的采购流程；实际情况是“不会成交”
移入培育	确有未来意向，但目前没有活跃的采购流程
向后调整阶段	交易真实存在，但所处阶段夸大了买方的实际进展
提供证据并重新设定日期	日期不正确，但交易仍在推进；新日期应回答“首先需要发生什么”
保留，并记录明确的下一步行动和日期	标记原因是数据缺失，而非交易已失去机会；修正记录

此表刻意不设优先级：每一行代表一种不同的交易状态，应根据买方侧证据支持的情况来选择，而不是在通往同一结果的不同路径之间做选择——按效率对它们排序会造成虚假的精确感。

非标准的阶段回退和交易拆分应交由交易评审组处理。绝不要删除记录，而应进行分类：删除会移除下一次审计可供参考的记录，破坏历史数据和转化基准，而且典型 CRM 的回收站保留时间很短。对于回归的买方，默认新建一条记录并关联到已关闭并标记为已输的记录；重新打开原记录虽能实现相同的恢复效果，但成本更高且不可逆，只有满足两个明确条件之一时才例外——详见 references/disposition-and-communication.md。

B2B 与 B2C / 高速成交 / PLG

真正的差异不在于阈值，而在于分析单位、可接受的自动化程度，以及是否需要在 CRM 中进行资格认定：

• B2B（周期长、ACV 高、采购委员会）：在管道评审中逐笔检查交易；采用 2.0x 倍数，企业客户即使沉默 60-90 天也可接受；在 CRM 字段中深入记录资格信息（内部支持者、经济决策者、合同流程）；重点关注推进次数和跨季度节点。
• 高速成交 / B2C：采用汇总规则和基于例外的自动化，取代逐笔交易评审；采用约 1.5x 倍数和 14-21 天标记；设置 3-5 个阶段；仅对早期且已预先完成资格认定的阶段接受定时自动关闭，并参考上次活动日期以避免误报，且须获得销售领导层认可。速度和转化率阈值比推进次数更重要。
• 纯 PLG：潜在客户通过使用情况自行完成资格认定，自助成交在产品内完成——可能根本不需要传统的交易管道，也就不需要面向销售代表的卫生审计。应明确说明，而不是强行进行审计；卫生管理应转向产品信号和 PQL 路由。

所有销售模式都相同的要求：

• 有意义活动的定义（字段变更，而非已记录的接触）。
• 分类而非删除。
• 优先使用验证规则，而非必填字段。
• 以辅导而非监管为导向。

通用 SLA 机制：根据基准销售周期，为每个阶段设置按比例计算的最长允许时长；超出 SLA 时自动标记并交由经理审查——绝不要自动关闭，否则会滋生不信任。

输出格式

简洁框架——完整示例（包括一份错误的审计），见 references/audit-report-examples.md：

PIPELINE HYGIENE AUDIT - <pipeline>, as-of <date>
Definitions   : meaningful activity = stage/close date/amount change;
                per-segment thresholds with provenance
Stale layer   : value by bucket (<90 / 90-180 / 180-365 / >365d);
                headline coverage vs coverage excluding >365 bucket;
                amnesty recommended yes/no
Summary       : deals audited, flagged, % of pipeline value flagged
Exception list: deal | owner | flags | evidence | proposed disposition |
                decided disposition | disposition owner | reason
Field gaps    : field | % complete vs 90-95% target | decision it feeds |
                fix (validation rule / nudge - not new required fields)
Push report   : push-count distribution; second-push deals at top with
                stacked-signal evidence and "what has to happen" answers;
                quarter-boundary pushes with stated reasons
Remediation   : actions, owners, due dates
Communication : rituals the audit rides on; exception list published >=12h
                ahead; who is told what before enforcement
KPIs          : baseline vs target per KPI, pass/fail, next audit date

常见失败模式

失败情形	后果	解决方案
根据已记录的电话／邮件判断数据是否过时	无需推进即可满足规则；过时的销售管道每次评审都能蒙混过关	根据阶段／成交日期／金额变化判断；将最近活动作为第二个触发条件
所有细分市场使用同一固定阈值	对企业客户标记过多，对 SMB 标记不足	使用针对不同细分市场的中位数和倍数
清理数据前就进行测量	尾部的失效数据拉平成交曲线；基线遭到破坏	先排除过时数据层，再计算中位数和覆盖率
将 RevOps 当作“CRM 警察”／自动关闭、自动删除	引发不信任；真实活动转移到 CRM 之外；诚实反而受到惩罚	自动标记以供经理审核；执行前给予宽限期；采取辅导而非惩罚的方式
删除被标记的交易	下一次审计可供参考的记录消失；基线和销售代表指标遭到破坏	进行分类，绝不删除
执行未告知任何人的规则	销售代表通过被标记才发现规则；开始钻规则空子	先公布规则和阈值；提前 12 小时公布例外清单
通过增加必填字段来解决完整性问题	大量出现“待定”／“.”／“123”等垃圾数据	必填字段限制在 5-7 个；先设置按阶段触发的验证规则，再发送提醒
将薪酬与字段填写完整度挂钩	数据填写快速、完整，但质量低	如果薪酬确实要与数据规范挂钩，就应与预测准确率（结果）挂钩，绝不能与填写完整度（输入）挂钩
季度末填入虚假的成交日期	大量修改日期以通过审计；预测失真	任何跨越周期边界的延期都必须说明原因；调整激励机制
蓄意压低业绩	因薪酬／配额原因而压住交易或调整交易时机	EOQ 成交集中度为 20-25% 属于正常范围；若单个销售代表持续超过 35%，应讨论薪酬设计，而非合规问题（Avoma）
一厢情愿地看待交易	承诺成交的交易延期，或直到 40-60% 时才出现无决策结果，届时已来不及应对	基于证据划分预测类别；进行多信号叠加测试
将每次延期都视为失效交易	真正延期的交易遭到扼杀；法律／采购方面的延误被错误标记	进行证据核查；豁免法律／采购审核期间
“占坑”交易一直无人处理	仅有认领记录的交易逐渐失效，并阻碍营销和区域调整	为仅被认领的交易制定明确的处置规则
将数据规范评分作为虚荣指标／审计作秀	评分提高，预测却没有改善；相同问题年复一年地存在	根据与预测相关的 KPI 评分；超过 30 天仍反复出现的例外应转化为系统规则，而不是增加会议

KPI 与通过门槛

按每次审计进行跟踪，并观察多次审计的趋势；每项都标注来源：

• 陈旧金额占未结销售管道的比例：健康水平低于 20-30%，后期阶段的陈旧金额低于 15%（Umbrex）；按四个陈旧度区间统计分布。
• 真实覆盖率：标题所示覆盖率与排除超过 365 天区间后的覆盖率之差——跟踪差距是否缩小。
• 延期交易率（预测成交但推迟到本期之外的交易）：目标低于 20%；持续高于 30% 表明资格审查或纪律方面存在系统性问题（Revenue.io）。
• 推迟次数分布：推迟 0 次、1 次、2 次以上的交易占比；比较季度边界推迟且说明原因与未说明原因的交易。
• 预测关键字段的完整率：目标为 90-95%，底线为 80%（Saber；Komo/DAMA）。
• 有未来日期后续步骤的未结交易占比：核心指标；根据用户自己的基线设定目标，绝不采用已发布的数字。
• 预计成交日期准确率：CRM 中的预计成交日期与实际成交日期在容差范围内一致的已成交交易占比（ORM 的标准为 14 天；根据自身数据收紧标准）。
• 按销售代表统计的季末成交集中度，作为观察蓄意压低预测的指标。

通过门槛——首次审计用于建立基线；目标应根据该基线制定，而非采用已发布的数字。满足以下条件即为通过审计：

• 每笔标记的交易都已决定处置方式，并指定负责人和原因——未解决项为零。
• 审计结束时，预计成交日期已过的未结交易为零。
• 没有任何二次推迟或季度边界推迟的交易缺少记录在案的证据答复。
• 陈旧金额占比、真实覆盖率差距、完整率和后续步骤率均较基线有所改善，并朝商定目标迈进。

持续迭代，直到上述四项全部满足。在向利益相关方引用任何销售管道卫生统计数据前（包括“40-60% 的销售管道已陈旧”），请先查看其在 references/evidence-and-benchmarks.md 中的可信度标记——该领域许多数字细节都来自销售预测工具的供应商。

可选集成说明

除非用户提到以下某个平台，否则请跳过。

• Salesforce：回收站只保留已删除记录 15 天，这是删除在实际操作中不可逆的另一个原因；必须在推迟次数变得可重建之前，按字段启用字段历史跟踪。
• Pipedrive：各阶段的“腐烂”天数阈值是原生功能，可直接设置推导出的陈旧阈值。

调用示例

• “我们的销售管道在 QBR 前塞满了垃圾——这些交易有一半几个月都没动过。执行卫生审计，告诉我哪些该关闭、保留或转入培育。”
• “这是包含阶段历史和预计成交日期变更的未结交易 CSV。标记所有陈旧交易、所有反复推迟的交易，以及所有缺少后续步骤的交易。”
• “我的承诺成交名单里有三笔交易，每笔都已推迟预计成交日期两次。审计整个销售账簿，找出推迟异常，并给我一份供经理与销售代表跟进的例外清单。”

参考资料

• 计算基线并执行规则时，请阅读 references/detection-rules.md——其中包括有效活动的定义、按细分市场划分的中位数表、推导方法、缺少历史记录时的回退方案、占位内容检测以及占坑交易检测。
• 决定处置方式并起草推广方案时，请阅读 references/disposition-and-communication.md——其中包括每种处置方式的证据测试、原因代码设计、销售管道宽限期、重新开启记录与新建记录的默认做法及改变这一做法的两个条件、批量处理与逐笔沟通的区分，以及沟通计划。
• 准备交付内容时，请阅读 references/audit-report-examples.md——其中包含一次 B2B 审计、一次高频交易审计，以及一次错误的审计示例。
• 引用任何数字前，请阅读 references/evidence-and-benchmarks.md——其中列出每项阈值和统计数据的来源及可信度标记，包括供应商利益驱动方面的注意事项。