revenue-leakage

收入流失

追踪记录和收入在某一个具体漏斗实例中悄然流失的环节，证明每笔损失都真实存在，估算可挽回金额，并按负责人排列修复优先级。

• 生命周期视角： Winning by Design 的 Bowtie（winningbydesign.com/bowtie）。流失贯穿从获客到入职引导、续约和扩展的整个过程，而不只是销售阶段——大多数团队过度检查前半段，却从未核对后半段。
• 后期阶段流失： MEDDPICC 的“Paper Process”要素（meddicc.com/meddpicc）指出了典型的后期阶段流失——交易在口头同意和签署之间告吹。
• 工作方法： 将 Celonis 推广的流程挖掘方法应用于漏斗自身的事件日志。根据实际发生时的时间戳重建流程，绝不依据文档中的流程图。

基本规则

• 追踪，绝不重新设计。阶段集合、路由规则、评分模型和交接流程都是输入项。如果其中某项存在缺陷，用一句话指出，并将问题转交给 Reference 中对应的技能——不要在此处重建。

• 交付物是流失登记表，绝不是数据卫生检查清单。交易停滞数量、缺失字段和推进次数都是用于定位流失的输入信号；将它们作为发现结果进行报告，是另一项技能的工作（mbfinotti/revops-skills@sales-pipeline-hygiene）。流失分析要查明记录和收入在哪些环节、因何种未记录原因退出，以及这些损失值多少。

• 除非通过以下三类判定，否则任何情况都不算流失。将正常的资格审查淘汰计为流失，是这类分析中最常见的误判。把数据采集缺口误认为漏斗流失，则是第二常见的误判。

• 估算可挽回金额，绝不使用总额。将停滞交易的总管道价值说成“流失收入”，是这类报告失去财务部门信任的典型原因。

• 仅分析某一时期、某一个进入批次中的一个漏斗实例。跨团队、漏斗或季度的项目级模式不在范围内。

• 为每个数值阈值标注其依据：已发表的实践、从业者共识，或根据用户自身数据推导。绝不要将供应商的经验法则说成行业常量。

• 提醒读者不要采用下列广为流传的线索响应速度统计数据——发布这些数据的供应商页面没有引用任何来源：

  • “5 分钟内响应 = 可能性高出 100 倍”
  • “获得资格认定的可能性高出 21 倍”
  • “B2B 平均响应时间为 42 小时”
  • “38% 的线索从未回复”
  • “391% / 60 秒规则”

  HBR 2011 年的论文《The Short Life of Online Sales Leads》（Oldroyd、McElheran、Elkington）真实存在，也可作为响应延迟会产生影响的证据引用，但通常与之关联的具体倍数无法核实。应测量用户自身的响应时间与转化率曲线，并据此推导阈值。

守恒测试

进入漏斗某个步骤的每条记录，都必须通过且仅通过一种可计数的结果离开该步骤：

• 已推进
• 已关闭丢单，且记录了原因
• 已取消资格／已回收，且记录了原因
• 仍在该步骤预期的停留时间窗口内处于开放状态

按每次转化进行核对：

entered  =  advanced + lost(reason) + disqualified(reason) + still-open(in window)  +  residual

每个非零差额都必须有解释。在将其称为流失之前，先对其进行三类判定：

1. 真实流失 - 记录原本符合条件，却因流程、系统或归属原因而停止推进（从未联系、从未接受、超出时间窗口后仍停滞、从未开具发票）。只有这类流失才需要估算规模并排序。
2. 合理取消资格 - 记录因正当原因退出，且记录了退出情况。不是流失。取消资格率为零的漏斗并不健康，而是缺少筛选。
3. 数据采集缺口 - 记录实际上已推进，但系统从未记录：未追踪的步骤、在收件箱或电子表格中完成的工作、缺失的时间戳、在从不回写的系统中完成的转化。缺失发生在数据中，而非漏斗中；应修复的是监测机制，在这里“修复漏斗”毫无作用。

检测未追踪步骤是关键手段。 对每一对相邻的系统或负责人，都要询问中间发生了什么，以及是否有人手动完成。任何在收件箱、电子表格或聊天线程中执行的步骤都没有时间戳，因此无法衡量其流失情况——在完成监测或证实其只是直接通过之前，都应将这类步骤视为疑似流失点。没有产生记录的步骤就没有可衡量的流失；应将其标记为监测缺口，而不是猜测数值。

B2B 与 B2C／自助服务

• **B2B 销售驱动：**流失点是需要人工采取行动的环节——响应、分配、接受、推进、催签。存在由销售代表负责的销售管道，因此差额可以归属于具体负责人。
• **B2C／自助服务／PLG：**漏斗的大部分环节都没有由销售代表负责的管道；其作用机制不是人为行为，而是技术因素——试用和结账步骤的流失、支付失败和催缴缺口、非自愿流失、自动续订遗漏。非自愿流失占订阅总流失的 20-40%（Baremetrics 引用 Paddle 的研究）；B2B SaaS 则为 2-5%（Baremetrics 自有平台数据——供应商汇总数据，并非独立研究）。
• **两者完全相同，适用时无需修改：**守恒核对本身、三类判定、可挽回金额的估算规则，以及未追踪的步骤在完成监测之前无法衡量这一规则。不同的只有流失点目录和证据类型。

访谈

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

• 采用哪种漏斗和销售模式：B2B 销售驱动、销售辅助型 PLG，还是纯自助式／B2C？只分析一个漏斗实例——具体是哪一个？
• 是什么触发了这次调查：某个数字下滑、董事会提出的问题、消失的交易，还是直觉？
• 漏斗的实际运作步骤是什么（而非官方图示），记录链条的各个部分分别由哪个系统保存——营销工具、销售系统、计费系统，还是电子表格？
• 实际上可以导出或查询哪些数据：带时间戳的阶段变更历史、负责人历史、成交失败和资格取消原因代码、账单／发票记录、付款失败事件？
• 目前哪些环节依赖人工操作——哪些交接是通过收件箱、电子表格或聊天消息完成的？
• 漏斗的每个环节由谁负责，各环节之间的部分由谁负责？
• 分析应涵盖哪个时期和哪批初始群组？（只选一批群组，持续跟踪其后续情况——绝不使用不同批次混合而成的快照。）
• 平均交易额或订阅金额是多少？如果已知，各步骤之间的历史转化率是多少？
• 对每次转化中尚未解释的差额，你愿意签字认可的上限是多少？通过阈值取决于这个数字，而且必须由你确定，不能由此技能设定。常见的工作基准是每次转化中进入该步骤记录数的 5%——这是从业者采用的数值，并非已发布的标准。若没有更合适的依据，只将 5% 作为占位值；一旦某次运行产生了漏斗自身的核对历史，就应据此尽快收紧阈值。
• 必须在什么日期前实际收到追回的收入——本季度结账前、董事会会议日期前，还是没有固定期限？（硬性日期会将流程再设计从本轮待办事项中剔除，并优先考虑提醒、路由备用方案，以及重新处理已经流失记录的工作。）
• 你想一次性追回已经流失的记录，还是修复问题以防再次流失？（一次性目标会优先安排重新处理；持续改善目标则会优先安排提醒、路由备用方案和追回流程。）
• 工作量上限是什么——仅限分析人员工时、可用工程资源，还是可以开展跨团队流程变更？
  • 仅限分析人员会排除埋点和再设计修复。
  • 可用工程资源会优先安排追回流程和埋点。
  • 只有获得跨团队授权，流程再设计才有资格纳入排序。

工作流

1. 进行访谈；明确漏斗、时间段和入口群组；确认范围边界（追踪，不重新设计）。
2. 按实际运作方式绘制漏斗：每个步骤、系统、负责人和交接环节——包括人工操作环节。将所有未追踪或由人工执行的步骤标记为疑似流失点。使用 references/leak-site-inventory.md 作为探查清单，确保没有遗漏。
3. 如果可以直接查询漏斗系统，请根据事件历史为每次转化构建守恒核对；否则根据导出数据和用户提供的记录样本推导，并将所有无法核对的转化标记为未测量，而不要假定它们没有问题。
4. 使用三分法测试对所有非零残差进行分类，并为每个记录组附上证据：时间戳、负责人历史、原因代码，或这些信息的缺失。无法分类的残差仍标记为“未解释”——绝不能直接认定为“流失”。
5. 根据 references/sizing-recoverable-revenue.md 计算每个已确认真实流失可追回的金额，并为每个数字标注置信度。
6. 构建流失登记表（架构见“输出格式”），按单位修复投入可追回的金额排序，而不是只按金额排序；使用 references/sizing-recoverable-revenue.md 中的修复类别排序，并根据访谈中有关截止期限、一次性与持续性、投入上限的回答重新排序。若用户的限制排除某个修复类别，则删除该类别，而不是将其降级，并说明是哪项限制将其排除。数据采集缺口应单独列出，并附上埋点修复方案，不附金额。
7. 一次输出报告的一个章节，供用户验证，并以 references/worked-examples.md 中对应的示例为依据。
8. 检查通过阈值；持续迭代，直到满足阈值，或明确列出所有剩余缺口，并为其安排修复。
9. 如果运行环境支持持久化记忆，请存储漏斗图、埋点缺口和约定的残差基线，以便重新检查时沿用；否则，将这三项全部放在报告的最后一节中，供用户粘贴到下一次运行。

输出格式

每个阈值和金额数字都必须附带来源或置信度标签。

REVENUE LEAKAGE REPORT - <funnel>, <cohort/period>, <date>
Funnel map       : steps -> systems -> owners; manual/untracked steps flagged
Reconciliation   : per transition - entered / advanced / lost(reason) /
                   disqualified(reason) / open-in-window / residual (% of entered)
Leak register    : rank | site | evidence | classification | records affected |
                   recoverable $ (confidence) | owner | fix | fix class
                   (fix class carries the effort behind the rank; ranking basis
                   and any deleted fix class stated above the register)
Disqualification : volume left for recorded, legitimate reasons (not leakage)
Capture gaps     : untracked steps + records that progressed unrecorded;
                   instrumentation fix per gap, no dollar figure
Recoverable total: sum of register, by confidence band; never a gross figure
Re-check         : residual baselines agreed, re-run date, gaps scheduled

通过阈值

• 每个已核对转化中的未解释残差都低于事先与用户约定的容差——常用工作标准是每个转化中进入记录数的 5%（这是从业者的工作标准，并非已发布的标准；应根据漏斗自身的历史数据设定更严格的标准）。
• 流失登记表中的每一项都附有证据、分类、带置信度标签的可追回金额、负责人、修复方案及该修复方案所属类别。
• 每个未核对的转化和未追踪的步骤都明确标记为尚未埋点，并安排埋点修复——绝不默默省略。
• 分析恰好涵盖一个入口群组的后续流转；快照计数不得与群组流转数据混用。

持续迭代，直到四项全部满足。如果必须先建立埋点才能核对某个转化，报告应明确说明，并安排重新运行——这属于通过；猜测数字则不算通过。

常见失败模式

缺陷	后果	修正方案
混用不同批次的群组数据（快照计数与群组流量）	残差只是算术噪声；会泄漏虚构或隐藏的问题	从同一批入组对象开始跟踪；只比较相同时间段
将合理的资格取消判定为泄漏	发现的问题被夸大；销售团队不再信任报告	在将任何问题称为泄漏之前，先进行三分类
将数据采集缺口误认为漏斗流失	“修复”针对的是实际并未出问题的漏斗；毫无改善	先检查相邻系统中是否存在进展证据
对发生两次泄漏的记录重复计数	可挽回总额超过实际情况；失去公信力	每条记录只计一次，计入其首次出现无法解释的流失点
将管道总价值估算为可挽回金额	财务部门会对整份报告打折扣	可挽回金额 = 记录数 x 价值 x 从该节点开始的后续转化率
将系统缺陷归咎于销售代表	引发政治纷争，却没有修复；泄漏持续存在	将残差归到流程／系统负责人名下，而非个人，除非负责人历史记录能证明另有原因
对未跟踪步骤猜测数值	虚构的数字会影响整个排名	标明尚未设监测；先添加监测，再在下一轮测量
交付成果偏离方向，变成数据清理检查清单	与数据清理技能重复；“这值多少钱”的问题仍未得到回答	每项发现都必须说明受影响记录数及可挽回金额，或提出监测修复方案

KPI

• 每次重新运行时跟踪：
  • 各转化环节的未解释残差占比（趋势应趋近于约定的容差）
  • 每项已修复泄漏实际挽回的金额与估算可挽回金额的对比
  • 带有时间戳的漏斗步骤占比（监测覆盖率）
  • 从确认泄漏到确定修复负责人所需的时间
• 实际挽回金额与估算值的对比，是检验估算方法是否诚实的指标：如果实际挽回金额持续远低于估算值，应在下一份报告中收紧后续转化率假设。
• 绝不要将“发现的泄漏数”作为成功指标——这会鼓励夸大问题清单。

调用示例

• “我们的营销团队坚称上季度向销售团队发送了 400 条合格线索，但销售团队说他们只收到 250 条。交易在哪一步流失？这让我们损失了多少？”
• “试用注册量保持稳定，但付费转化率下降了 20%，却没人说得清漏斗中是在哪个环节发生的。追查泄漏。”
• “交易总是在口头承诺到签署合同之间消失，续约似乎也总会悄然失效。找出泄漏，并告诉我实际能挽回多少。”

参考资料

• 绘制漏斗图时，请阅读 references/leak-site-inventory.md——其中列出了从入口到非自愿流失的各个泄漏点，以及每个站点的检测信号和需提取的证据。
• 估算和排序时，请阅读 references/sizing-recoverable-revenue.md——其中介绍了可挽回收入的计算公式、后续转化估算、置信度标签和排序规则。
• 设计交付成果时，请阅读 references/worked-examples.md——其中包含一个 B2B 对账示例、一个自助式/PLG 对账示例，以及一个错误报告示例。
• 如果问题表现为预测数字错误，而不是记录消失，请参阅 mbfinotti/revops-skills@sales-forecast-diagnostic。
• 如果发现泄漏点需要重新设计分配逻辑，请参阅 mbfinotti/revops-skills@lead-routing。
• 如果发现泄漏点需要重新设计评分，请参阅 mbfinotti/revops-skills@lead-scoring。
• 如果修复交接环节的泄漏需要设计销售到 CS 的交接流程本身，请参阅 mbfinotti/revops-skills@sales-to-cs-handoff。