收入漏斗泄漏追踪与可回收金额量化：当交易/收入在单一漏斗中无…

在单一漏斗实例、单一周期和入口 cohort 中，追踪记录与收入无声流出的位置，区分真实泄漏、健康淘汰和数据采集缺口，并量化可回收金额。

适用场景

解决思路

1. 使用 Winning by Design 的 Bowtie 生命周期视角：泄漏覆盖从获客、onboarding、续约到扩张，不止销售阶段；避免只检查漏斗顶部而不对账后半段。
2. 使用 MEDDPICC 的 “Paper Process” 元素检查晚期泄漏：交易可能在 verbal yes 与 signature 之间死亡。
3. 使用 process mining 方法：从漏斗自己的 event log 和 timestamps 重建实际运行流程，绝不从文档化流程图重建。
4. 只追踪，不重设计：stage set、routing rules、scoring model、handoff processes 都是输入；若其中一项是缺陷，用一行说明并路由到匹配技能，不在本技能重建。
5. 交付物必须是 leak register，不是 hygiene checklist；stale-deal counts、missing fields、push counts 只作为定位泄漏的输入信号，报告这些不是本技能发现。
6. 任何项在通过三向分类前都不算 leak；不要把健康淘汰算作泄漏（最常见假发现），也不要把数据采集缺口误认为漏斗下降（第二常见）。
7. 只量化 recoverable amount，绝不量化 gross；不要把 stalled deals 的 gross pipeline value 称作 leaked revenue。
8. 每次只处理一个漏斗实例、一个 period、一个 entry cohort；跨团队、跨漏斗、跨季度的项目级模式不在范围内。
9. 给每个数值阈值标注 provenance：published practice、practitioner consensus 或 derived from the user's own data；绝不把 vendor heuristic 当作 industry constant。
10. 不要使用流传的 speed-to-lead 统计：“respond in 5 minutes = 100x more likely”、“21x more likely to qualify”、“average B2B response time is 42 hours”、“38% of leads never reply”、“391% / 60-second rule”；HBR 2011 论文 “The Short Life of Online Sales Leads”（Oldroyd, McElheran, Elkington）可作为 response latency 重要的证据，但常见倍数不可验证；测量用户自己的 response-time-vs-conversion curve 并据此推导阈值。
11. 执行 Conservation Test：每个进入漏斗步骤的 record 必须通过恰好一个可计数 outcome 离开：advanced；closed-lost with a recorded reason；disqualified/recycled with a recorded reason；still open inside that step's expected dwell window。
12. 对每个 transition 建立 reconciliation：`entered = advanced + lost(reason) + disqualified(reason) + still-open(in window) + residual`。
13. 每个非零 residual 都要求解释；在称为 leak 前运行三向分类。
14. 三向分类：Real leak — record 本来可行但因 process、system 或 ownership 原因停止移动（never contacted、never accepted、stalled past window、never invoiced）；只有这些进入量化和排序。
15. 三向分类：Healthy disqualification — record 因合法原因离开且 exit 被记录；不是 leak；零淘汰的漏斗不健康，是未过滤。
16. 三向分类：Data-capture gap — record 实际前进但系统未记录：untracked step、工作存在于 inbox 或 spreadsheet、missing timestamp、conversion 完成在不会写回的系统中；下降在数据而非漏斗，修复是 instrumentation。
17. Untracked-step detection 是标志性动作：对每一对相邻 systems 或 owners，询问中间发生什么、是否人工完成；任何在 inbox、spreadsheet 或 chat thread 中执行的步骤都没有 timestamp，因此没有可测量 drop-off；在 instrumented 或证明 pass-through 前，将其视为 suspected leak site。
18. 一个不产生 records 的步骤没有可测量 leak；将其命名为 instrumentation gap，不要猜数字。
19. B2B sales-led：leak sites 是 human action points — respond、route、accept、advance、chase signature；存在 rep-owned pipeline，因此 residuals 归属到 owners。
20. B2C/self-serve/PLG：漏斗大部分没有 rep-owned pipeline；机制是技术性而非人工 — trial 和 checkout step drops、payment failure 和 dunning gaps、involuntary churn、auto-renewal misses；involuntary churn 占 subscription churn 的 20-40%（Baremetrics 引用 Paddle research），B2B SaaS 具体为 2-5%（Baremetrics 自身平台数据，vendor-aggregated，非独立研究）。
21. 两种模式都必须应用：conservation reconciliation、三向分类、recoverable-dollar sizing rule，以及“未 instrumented 的 untracked step 不能测量”的规则；只有 leak-site catalog 和 evidence types 不同。
22. 分析前先 Interview；每条消息只问一个问题；尽可能 multiple-choice；跳过已回答内容。
23. Interview 问题：哪个 funnel 和 motion：B2B sales-led、sales-assisted PLG、pure self-serve/B2C？只选一个 funnel instance — 哪一个？
24. Interview 问题：这次调查由什么触发：一个数字下降、board question、交易消失、直觉？
25. Interview 问题：漏斗按实际运行（不是官方图）有哪些步骤，每段 record trail 存在哪个系统 — marketing tool、sales system、billing system、spreadsheets？
26. Interview 问题：实际可 export 或 query 什么：带 timestamps 的 stage-change history、owner history、closed-lost 和 disqualification reason codes、billing/invoice records、payment-failure events？
27. Interview 问题：manual steps 目前在哪里 — 哪些 handoffs 通过 inbox、spreadsheet 或 chat message 发生？
28. Interview 问题：谁拥有每个 funnel segment，以及谁拥有 segments 之间的空隙？
29. Interview 问题：分析应覆盖哪个 period 和 entry cohort？（一个 cohort 向前跟踪，绝不用 mixed-vintage snapshot。）
30. Interview 问题：平均 deal 或 subscription value，以及已知的历史 step-to-step conversion rates？
31. Interview 问题：每个 transition 你愿意签核的 unexplained residual 是多少？Pass Threshold 以此数为门槛，必须由用户给出，不是本技能给。常见工作标准是 entering records 的 5% 每 transition — practitioner figure，非 published standard。没有更好依据时才把 5% 当 placeholder，一旦 funnel 自身 reconciliation history 产生，就收紧它。
32. Interview 问题：recovered revenue 必须在什么日期前到账 — 本季度 close、board date、无固定 deadline？硬日期会从本轮 register 删除 process redesign，并优先 alerts、routing fallbacks、rework 已泄漏 records。
33. Interview 问题：你要对已泄漏 records 做一次性 recovery，还是要阻止 leak recurring？One-off 促进 rework；compounding 促进 alerts、routing fallbacks、recovery sequences。
34. Interview 问题：effort ceiling 是什么 — 只有 analyst hours、有 engineering capacity，还是可以跨团队 process change？Analyst-only 删除 instrumentation 和 redesign fixes；Engineering capacity 促进 recovery sequences 和 instrumentation；Cross-team mandate 才使 process redesign 可排序。
35. Workflow 1：运行 Interview；固定 funnel、period、entry cohort；确认 scope boundary（trace, not redesign）。
36. Workflow 2：按实际运行绘制 funnel：每个 step、system、owner、handoff — 包括 manual ones；将每个 untracked 或 hand-performed step 标记为 suspected leak site；使用 [references/leak-site-inventory.md] 作为要探查的 sites 清单，以免跳过任何 site。
37. Workflow 3：如果可以直接 query 漏斗系统，从 event history 构建 per-transition conservation reconciliation；否则从用户提供的 exports 和 record samples 推导，并将每个无法 reconcile 的 transition 标记为 unmeasured，而不是假设干净。
38. Workflow 4：用三向测试分类每个非零 residual，并按 record group 附证据：timestamps、owner history、reason codes 或其缺失；无法分类的 residual 保持 “unexplained” — 绝不得直接提升为 “leak”。
39. Workflow 5：按 [references/sizing-recoverable-revenue.md] 将每个确认的 real leak 量化为 recoverable dollars，并对每个数字加 confidence tag。
40. Workflow 6：构建 leak register（schema 在 Output Shape），按 recoverable dollars per unit of fix effort 排序 — 绝不只按 dollars — 使用 [references/sizing-recoverable-revenue.md] 中的 fix-class ordering，并根据 Interview 中的 deadline、one-off-vs-compounding、effort-ceiling 答案重新排序；删掉用户约束排除的 fix class，而不是降级，并说明哪个约束删除了它；Data-capture gaps 单独一节，给 instrumentation fix，不给 dollar figure。
41. Workflow 7：一次一个 section 地输出报告供用户验证，并以 [references/worked-examples.md] 中匹配的示例为依据。
42. Workflow 8：检查 Pass Threshold；迭代直到成立，或每个剩余 gap 都被明确命名为 uninstrumented 且有 scheduled fix。
43. Workflow 9：如果 harness 有 persistent memory，存储 funnel map、instrumentation gaps、agreed residual baselines，使 re-check 从它们开始；否则将三者放入报告最后一节，供用户粘贴到下一次运行。
44. 输出时每个 threshold 和 dollar figure 都带 provenance 或 confidence tag。
45. 使用 Output Shape 模板：REVENUE LEAKAGE REPORT - <funnel>, <cohort/period>, <date>；包含 Funnel map、Reconciliation、Leak register、Disqualification、Capture gaps、Recoverable total、Re-check。
46. Pass Threshold 条件 1：每个 reconciled transition 的 unexplained residual 低于用户 upfront 同意的 tolerance — 常见工作标准为 entering records 的 5% 每 transition（practitioner working bar，非 published standard；从 funnel 自身 history 推导更严格值）。
47. Pass Threshold 条件 2：每个 leak register entry 都带 evidence、classification、recoverable figure with confidence tag、owner、fix 和 fix 的 class。
48. Pass Threshold 条件 3：每个 unreconciled transition 和 untracked step 都明确命名为 uninstrumented 且有 scheduled instrumentation fix — 绝不静默省略。
49. Pass Threshold 条件 4：分析恰好覆盖一个 entry cohort 并向前跟踪；不混合 snapshot counts 与 cohort flows。
50. 迭代直到四个条件全部成立；若某 transition 必须先建设 instrumentation 才能 reconcile，报告说明并安排 re-run — 这是通过结果；猜数字不是。
51. 避免混合 cohort vintage（snapshot counts vs cohort flows）：residuals 会成为算术噪声，发明或隐藏 leaks；修复：一个 entry cohort 向前跟踪，只比较 like periods。
52. 避免把 healthy disqualification 算作 leakage：findings 膨胀，sales 不再信任报告；修复：在称为 leak 前做三向分类。
53. 避免把 capture gap 误认为 funnel drop：会去“修复”没坏的漏斗，什么也不改善；修复：先在相邻系统检查 progression evidence。
54. 避免对 leak 两次的 record 重复计数：recoverable total 超过现实，可信度丧失；修复：每个 record 只在其 first unexplained exit 计一次。
55. 避免把 gross pipeline value 量化为 recoverable：finance 会折损整个报告；修复：Recoverable = records x value x onward conversion from that point。
56. 避免因 systems defect 责怪 reps：政治争斗、无修复、leak 持续；修复：residuals 归因到 process/system owners，除非 owner history 证明否则不归因个人。
57. 避免为 untracked step 猜数字：虚构数字会锚定整个排序；修复：命名 uninstrumented；先 instrument，下一轮再测量。
58. 避免交付物漂移成 hygiene checklist：会重复 hygiene skill，且“值多少钱”问题未答；修复：每个 finding 必须说明 records affected 和 recoverable dollars，或给 instrumentation fix。
59. 每次 re-run 跟踪 KPI：per transition 的 unexplained residual share（趋近 agreed tolerance）；每个 fixed leak 的 recovered dollars 对 sized recoverable figure；有 timestamps 的 funnel steps 占比（instrumentation coverage）；从 leak confirmation 到 fix ownership 的时间。
60. 用 Recovered-vs-sized 作为 sizing method 的诚实检查：如果实际 recovery 持续远低于 sized figure，下一次报告前收紧 onward-conversion assumptions。
61. 绝不报告 “leaks found” 作为成功指标 — 那会奖励夸大 register。
62. 当 presenting symptom 是错误 forecast number 而非记录消失，转 `mbfinotti/revops-skills@sales-forecast-diagnostic`。
63. 当 leak site 需要重设计 assignment logic，转 `mbfinotti/revops-skills@lead-routing`。
64. 当 leak site 需要重设计 score，转 `mbfinotti/revops-skills@lead-scoring`。
65. 当 handoff leak 的修复是设计 sales-to-CS handoff 本身，转 `mbfinotti/revops-skills@sales-to-cs-handoff`。
66. 当需要审计 stage definitions，使用 `mbfinotti/revops-skills@pipeline-stage-definition-audit`，本技能以 stage definitions 为给定输入。
67. 当只是 pipeline hygiene（stale-deal counts、missing fields、push counts）报告，使用 `mbfinotti/revops-skills@sales-pipeline-hygiene`。

适用边界 · 注意事项

• 不适用于单纯的 pipeline hygiene 问题（stale-deal counts、missing fields、push counts）；那属于 sales-pipeline-hygiene。
• 不适用于审计或重设计 stage definitions、routing rules、scoring model、handoff processes 本身；若要改这些，转 pipeline-stage-definition-audit、lead-routing、lead-scoring、sales-to-cs-handoff。
• 不适用于跨团队、跨漏斗、跨季度的项目级模式，或症状是错误 forecast number 而非记录消失；本技能只覆盖单一漏斗实例、单一 period、单一 entry cohort。