从零设计公司营收漏斗模型时用：定阶段、分析单元…

当需要从零设计宏观营收漏斗模型（阶段集、分析单元、用途、转化假设、营销-销售-CS 交接）时使用，尤其适用于 B2B 和高考虑度 B2C。

适用场景

解决思路

1. 只做宏观设计：确定存在哪些阶段、什么单元在其中移动、谁的数字进入计划、谁拥有每个交接；不要写单个阶段退出标准措辞、lead-routing 规则或交接执行 playbook，把这些交给兄弟技能。
2. 在数阶段之前先定两个前置决策：模型用途（process/planning/forecast）和移动单元（lead、contact、buying group、opportunity、account）。
3. 不要把 process、planning、forecast 三种用途混进同一套阶段集；流程模型、计划模型、预测模型应有不同最优阶段集。
4. 转化假设以 cohort 为先：win rate 是 period 指标，close rate 是 cohort 指标，pipeline conversion rate 是 snapshot 指标；分别跟踪，不要强行让一套阶段集同时产出两者。
5. 模型中的每个 rate 必须标明 basis（cohort 或 milestone），否则不要发布。
6. 公开 benchmark 只触发调查，绝不用来设定目标；若某阶段远偏离公开范围，把它当问题调查，而不是补差距。
7. 把漏斗当作容量和资源分配工具，而不是买方心理模型；它回答需要多少 SDR、多少 demand-gen 预算、什么 quota 容量；growth loop 作为独立渠道策略工件，彼此不越界。
8. MQL 是糟糕的目标但可接受的状态；迁移到 buying-group qualification 是昂贵的数据模型变更，低于约每 deal 3-4 个 stakeholder 时不要推荐。
9. RevOps 拥有该模型的定义、instrumentation 和 change control；绝不拥有 segmentation、ICP、offer bets、pricing posture；业务漂移到这些领域时要说明。
10. 只有在真实运营需要迫使时才加阶段；早期公司主要失败是 10 阶段 pipeline 模拟尚未拥有的 enterprise 流程，每个额外阶段都是永久 admin 开销。
11. 给每个数字标注 provenance：用户自己的数据、具名公开来源及其 caveat、或明确猜测。
12. 下面排序菜单中的默认顺序不是法律；要按 Interview 答案和公司已有条件重新排序，并说明哪个答案移动了哪个选项。
13. 设计前先访谈；每条消息问一个问题，尽量 multiple-choice，已回答的跳过。
14. 问触发原因：没有 funnel model、继承的模型没人信、motion 或产品变化使旧模型失效、还是领导要 revenue plan？
15. 问模型首先要回答哪个问题：每步人们该做什么（process）、要达到数字需要多少输入（planning）、还是本季度什么会 close（forecast）？选一个 primary，其他只做派生视图，不加阶段。
16. 问 GTM motion：no-touch/PLG self-serve、low-touch assisted、mid-touch（SDR 资格确认后给 AE）、high-touch enterprise、channel/partner-led？是否同时跑多个？
17. 问收入模型：subscription、usage/consumption-based、marketplace/take-rate、one-time purchase？
18. 问典型 deal 有多少 stakeholder：1-2、3-4、5+？这决定 individual-lead 还是 buying-group 单元。
19. 问公司阶段：pre-PMF/seed、Series A-B、Series C+ 或 public？
20. 问新收入中来自现有客户（renewal、upsell、cross-sell）的大致比例；这决定 post-sale funnel 要承载多少。
21. 问数据：有多少季度 stage history，在 CRM 还是 warehouse，是否干净到能算 cohort rates？最近是否清理 stale pipeline？
22. 问现有定义：一个 MQL 定义还是按 region/team 多个？今天谁拥有定义？是否有 standing forum 可批准变更？
23. 问 B2B、B2C 还是两者；若 B2C，是 sales-assisted high-consideration（insurance、property、enrollment）还是 transactional/self-serve volume？
24. 问模型必须何时落地，是否有 planning cycle（annual plan、board meeting）依赖它；硬 deadline 会促使先用 blended rates 发布模型，把 segmentation 排为后续。
25. 问这是一次性 plan input 还是长期 operating model；一次性把治理压缩为 named owner 和 review date；复合 mandate 则 funnel council 和 re-benchmarking cadence 非可选。
26. 问 effort ceiling：analyst 做 cohort 分析的时间、admin 给新定义做 instrumentation 的容量、以及让 marketing 和 sales 接受 bilateral SLA 的政治资本；没有跨职能 sponsor 就把 SLA 层降为 paper agreement，并在交付物中说明。
27. 执行 Interview。确认范围边界：设计模型，不是审计现有阶段定义，也不是在模型内执行。
28. 确定两个前置决策和 revenue boundary。用户确认三者前不要进入阶段计数。
29. 选择 framework vocabulary。
30. 进入显式 brainstorming：给出 2-3 个候选阶段集设计，列 trade-off 和推荐。在用户选定前不要在其上构建任何东西。
31. 按 Conversion Assumptions 构建 conversion register。
32. 按 Ownership Handoffs 设计 ownership 和 handoff 层。
33. 设置 governance shell：谁批准定义变更、re-benchmarking cadence tiers、模型本身的 version control。
34. 按 Output Shape 逐个 artifact 输出供用户验证，并用匹配的 worked example 作为基础；绝不要把整个模型作为既成事实一次性呈现。
35. 检查 Pass Threshold；迭代直到满足，或每个剩余 gap 都被显式排期（如 cohort decomposition 等待数据量）。
36. 如果 harness 有 persistent memory，存储已定 purpose、unit、boundary、stage set、assumption register，让后续 planning/reporting 从已决定模型开始，而不是重新访谈。
37. 确定 model purpose：process model（rep 做什么）、planning model（多少输入达到数字）、forecast model（本季度什么 close）有不同最优阶段集。
38. 注意 starting pipeline 是过去 1-4 季度创建的 opportunities 混合，因此 cohort-based close rate 和 current-quarter conversion rate 是不同工具；分别跟踪。
39. 确定 unit of analysis：lead、contact、buying group、opportunity 或 account；这个选择决定所有下游，并且是 named frameworks 代际之间真正区别；根据 Interview 的 stakeholders-per-deal 答案决定，而不是框架时尚。
40. 确定 pre-sale 在哪里结束；三种可辩护边界：contract signature（标准、可审计、对 consumption revenue 错误）、first value delivered（经济上诚实、需要 product telemetry）、onboarding completion（方便，但交付里程碑而非买方里程碑）。
41. 默认推荐：建模两个边界——把 accounting boundary 设在 commit 给 finance，并把 time-to-first-impact 作为独立 CAC-recovery 指标；不要合并两者。
42. 框架选择按 motion 和 unit 映射，并判断 board 已经说谁的 benchmark pool 和 vocabulary；不要按效率排名。
43. mid-touch、individual-lead qualification -> 2012-era Demand Waterfall vocabulary。
44. account-based、buying-group qualification（3-4+ stakeholders）-> Demand Unit Waterfall (2017) 或，在 renewal/upsell/cross-sell mix 必须按 opportunity type 建模时，B2B Revenue Waterfall (2021+)。
45. recurring revenue 且有重大 expansion economics -> Bowtie（post-sale half 等权重；expansion 在新 ARR 中占比：$50M 以上 40%+，$50-100M 约 58%，$100M 以上约 67%）。
46. TOFU/MOFU/BOFU -> 仅用于 content 和 demand-gen planning lens；绝不要作为 pipeline 的阶段集。
47. marketplace/take-rate -> 没有已发布框架适配；构建两个 funnel（supply、demand）并在其间设置 liquidity constraint，并声明模型是 custom。
48. 整体采用一个 named framework 有一个被低估收益：标准化阶段定义让外部 peer benchmarking 有意义；在呈现选择前读 references/framework-selection.md。
49. 推荐前先 brainstorm。呈现 2-3 个候选阶段集设计。
50. 每个候选必须指定：阶段列表及每阶段 owner。
51. 每个候选必须指定：unit of analysis，以及在哪里切换（如 lead -> opportunity）。
52. 每个候选必须指定：post-sale coverage。
53. 每个候选必须指定：该设计优化什么。
54. 每个候选必须指定：其常设 admin cost。
55. 随后给 trade-off 对比和一个带理由的推荐。让用户选择或混合；在 conversion register 构建其上之前验证该选择。
56. 把候选保持在 motion 的阶段数区间内：no-touch/PLG 3-4；low-touch 4-5；mid-touch 和多数 mid-market/enterprise 5-7；high-touch enterprise 6-8。
57. 第八阶段用于长 legal/security review 是例外，不是默认。
58. 真正不同的购买流程（channel/partner）使用单独镜像 pipeline，绝不要在主 pipeline 上额外加阶段。
59. 按公司阶段调整复杂度：pre-PMF 用 4-5 阶段并把猜测标为猜测，而不是 Series-C 治理装置。
60. 按 planning accuracy per analyst-hour 排序数字来源；把 vendor 和 CRM 默认 stage probabilities 从菜单中完全删除，不是降级——它们是没人从该业务推导出的圆整数，设计上乐观，乘以乐观 deal value 时误差会复合。
61. value 排序：own segmented cohort rates > own blended cohort rates > adjusted external benchmarks。
62. effort 排序：own segmented cohort rates > own blended cohort rates > adjusted external benchmarks。
63. efficiency 排序：own blended cohort rates > own segmented cohort rates > adjusted external benchmarks。
64. 默认档：用用户自身历史的 blended cohort rates，并按 volume 能支持的两个方差最大的维度做 segmentation。
65. 只有当每个 cell 的条目仍足够大可信时，才升到更充分 segmentation（motion x segment x source x opportunity type）；样本量而非野心决定拆分。
66. 仅在 pre-PMF 或 trigger reset 抹掉可用历史时，才降到 adjusted external benchmarks，并把每个此类数字标为明确猜测。
67. 注意该顺序会饿死 full four-dimension segmentation；随着 volume 增长提升它，因为 opportunity type 对 rate 的影响比多数团队建模的更大（new-business acquisition 低个位数转化，而 renewal/expansion 高得多）。
68. 方法第 1 步：先清扫 stale pipeline；在某个 vendor 的基数中，超过 10% 的 pipeline 12+ 个月未被触碰，它会扭曲其上计算的每个 rate。
69. 方法第 2 步：在 4-8 季度窗口按阶段计算：进入该阶段的单位数，除以最终到达下一阶段的单位数；计数 entries，绝不计数 current occupancy。
70. 方法第 3 步：在 conversion register 中记录每个 rate 的 basis（cohort 或 milestone）、分子/分母定义、样本量、来源、refresh trigger。
71. 方法第 4 步：从 6-8 个 cohort 按时间分解 close rate：in-quarter、first-quarter、second-quarter shares；没有 lag decomposition，计划可能算术正确但时间错误——在 30 天周期，季度 coverage 数学几乎无意义，因为约三分之二的季度关闭 pipeline 在季度开始时不存在。
72. 方法第 5 步：把 bottom-up funnel plan 与 top-down revenue target 对账，并明确命名 gap；绝不要平均掉它——命名的 gap 能在 10% MQL 缺口变成收入 miss 前两个季度暴露它。
73. 方法第 6 步：设置 re-check cadence：weekly 运营监控、不改假设；monthly 重算 cohort 并标 drift flags；quarterly 重新批准和 versioning；trigger-based 在 ICP、pricing、segment、motion、comp-plan 或 stage-definition 变化时 full re-baseline。Trigger 会使历史失效，因此 reset 而不是 blend。
74. 处理三个跨职能交接点：marketing-to-sales（qualified lead accepted）、sales-to-CS（closed-won 到 onboarding）、CS-to-sales（renewal/expansion）。
75. 每个交接点都需要双方 owner、明确 handoff criteria 和 bilateral SLA。
76. 按 alignment gained per unit of effort 和 political capital 设置四个投资档位；value 排序：system-enforced timers > bilateral SLA > standardized definitions > paper mapping。
77. effort 排序：system-enforced timers > bilateral SLA > standardized definitions > paper mapping。
78. efficiency 排序：paper mapping > standardized definitions > bilateral SLA > system-enforced timers。
79. 档位 1 Paper mapping：每个交接的双方进同一房间，映射 funnel first touch 到 expansion，标记每个 handoff 的 owner、criteria 和 break 点；1-2 小时；从业者报告最大 alignment gaps 在前 30 分钟浮现；始终在设计 engagement 内先做。
80. 档位 2 Standardized definitions：每个 handoff trigger 一个书面定义（什么算 qualified、什么触发 handoff），基于 behavior 而不是单一 point-score threshold；需要数天起草和签核。
81. 档位 3 Bilateral SLA：双方都有 commitments、timers、consequences，目标设在当前 baseline 附近；单边 SLA 让 marketing 成被告、sales 成法官，并毒害要创造的 alignment；需要数周谈判和跨职能 sponsor。
82. 档位 4 System-enforced timers：在 CRM/automation 层内置 acceptance clocks、auto-reversion、escalation、reassignment，并在 standing joint cadence 审查 compliance；需要 admin build 加 retraining。
83. 注意 efficiency 顺序会饿死 enforcement，而 handoff 实际失败在 enforcement 而非 definition：没人系统追踪的 SLA 一个季度内退化成文档。SLA 一批准就提升到 rung 4，而不是留作后续阶段。
84. 如果 Interview 发现没有 sponsor 支持 bilateral SLA，就从设计中划掉 rungs 3-4，交付 rungs 1-2，并在交付物中记录 gap，而不是假装纸面协议能成立。
85. 机制、代表 timers、sales-to-CS data contract 见 references/handoff-sla-design.md。
86. 交付物是一组 artifact，逐个文件呈现供验证。
87. stage-definitions.md：每阶段——name、definition、entry criteria、owner、unit、system-of-record field（exit-criteria wording 由下游 stage-definition audit skill 起草）。
88. conversion-register.csv：rate、numerator/denominator、cohort-or-milestone basis、sample size、source/provenance、last refreshed、next-refresh trigger。
89. funnel-model：bottom-up plan with lagged cohort conversion，与 top-down target 对账，gap 明确命名。
90. sla.md：bilateral commitments、timers、consequences、escalation、version history——每个 handoff point 一份。
91. data-dictionary.md：object model、field ownership、allowed values、模型依赖字段的 reason codes。
92. governance-charter.md：funnel council membership、decision rights、definition change control、re-benchmarking cadence。
93. capacity-model：从 funnel model 推导的 headcount 和 budget implications，绝不独立撰写。
94. 定义放在 CRM 和 marketing automation platform；测量放在 warehouse，这样定义变更时可重述历史而不破坏过去报告。
95. 检查每个阶段都有 named owner、entry definition、unit of analysis、system-of-record field；没有阶段可以没有用户能陈述的运营需要。
96. 检查 conversion register 中每个 rate 都带 basis（cohort 或 milestone）、numerator/denominator、sample size、provenance、refresh trigger；没有未标注的默认值存活。
97. 检查 bottom-up plan 和 top-down target 已对账，gap 以数字陈述，不被平均掉。
98. 在有 4+ 季度历史处，用历史 backtest 模型；对 modeled vs actual rates 超出约定 tolerance band 的阶段标记并给假设。
99. 两个 revenue boundaries（accounting commit 和 first value）都已建模，或单边界选择在交付物中被明确论证。
100. 每个 handoff point 都有双方义务、timer、consequence、escalation path——或记录哪些 rungs 被划掉及原因。
101. 迭代直到六项全部成立；cohort decomposition 需要 6-8 个成熟 cohort 才可信；若量还不够，按可用 basis 发布、标注，并把升级排为 register 的第一个 refresh trigger。
102. 修复 definition drift across regions/teams：使用一套定义，由 council 批准并 versioned；区域差异需要 council 批准。
103. 修复 per-layer volume metrics per team：增加共享的全漏斗指标 alongside 层级指标，并联合审查转化。
104. 修复每个 transition 只有一个 blended conversion rate：按 volume 支持的最高方差两个维度做 segmentation。
105. 修复 stage set 兼任 forecast categories：用两个正交字段——stage = 流程位置，category = 置信度。
106. 修复 linear-journey assumption：设计显式 recycle/regression paths；把 backward transitions 作为一级指标测量。
107. 修复 consumption revenue 上单一 signature 收入边界：分别建模 commit 和 first-value boundaries。
108. 修复 PLG 中 PQL-only qualification：加入 product-qualified account；先分桶 PQLs、hand-raisers。
109. 修复用 attribution 解决渠道预算争斗：把 attribution 当方向性；把争斗排除在 funnel model 范围外。
110. 修复 stale pipeline 留在 baseline：在任何 rate 计算前做 hygiene sweep。
111. B2B 和 B2C 分三种情况。
112. sales-assisted、high-consideration B2C（insurance、property、solar、enrollment、automotive、mortgage）：完整模型不变地迁移，因为它们跑真实阶段 pipeline，purpose/unit/boundary 决策按原样适用；单元通常是 household 或 applicant 而非 buying group。
113. transactional/self-serve B2C：完全没有 per-deal stage state；正确工具是 lifecycle stages 和 cohort/event-funnel analytics；本技能产出的模型会是错误 artifact；说明并设计 lifecycle/cohort measurement plan，而不是强套 pipeline。
114. PLG：位于两者之间——self-serve 侧用 cohort math，从 product-qualified gate 往后用压缩阶段模型。
115. 跟踪模型是否有效，而不是是否存在：每季度每阶段 day-one plan 与 actuals 的绝对 gap。
116. Assumption drift vs register tolerance bands。
117. Backward-transition rate。
118. 每个 handoff 的 SLA compliance（response time、disposition rate）。
119. 命名的 bottom-up/top-down gap 跨 planning cycles 趋向零。
120. 治理健康：register 的 last-refreshed dates 当前，定义变更走 council 而不是绕过。
121. 只作方向性 context，绝不承诺：正式 marketing-sales SLAs 与更强报告 program ROI 相关，aligned revenue operations 与更快增长相关——都是 survey/analyst findings，不是对某公司的保证。
122. 选择 vocabulary 和 stage-count band 时读 references/framework-selection.md。
123. 构建 register 时读 references/conversion-methodology.md。
124. 设计 handoff layer 时读 references/handoff-sla-design.md。
125. 塑造交付物时读 references/worked-examples.md。
126. 审计现有阶段集 exit criteria 用 mbfinotti/revops-skills@pipeline-stage-definition-audit；本技能设计这些阶段所在的模型，那个技能起草每阶段 buyer-verifiable wording。
127. lead scoring 逻辑用 mbfinotti/revops-skills@lead-scoring。
128. lead-routing 逻辑用 mbfinotti/revops-skills@lead-routing。
129. 执行 post-close handoff 用 mbfinotti/revops-skills@sales-to-cs-handoff。
130. 在推导 rate 前必须做的 stale-deal sweep 用 mbfinotti/revops-skills@sales-pipeline-hygiene。
131. 本模型 KPI 汇入的 metric hierarchy 用 mbfinotti/revops-skills@revenue-kpi-framework。

适用边界 · 注意事项

• 不适用于审计现有 pipeline 的阶段定义；应使用 mbfinotti/revops-skills@pipeline-stage-definition-audit。
• 不适用于交易型/自助式 B2C；它没有逐 deal 阶段状态，应改用生命周期阶段与 cohort/event-funnel 分析。
• 不适用于执行层细节：不要用它写单个阶段的退出标准措辞、lead-routing 规则或交接执行 playbook。