需要评估单个合作伙伴关系的单位经济，决定签约、扩展…

对单个 B2B 渠道/联盟伙伴或 B2C 联盟客/创作者关系建模归因收入、全加载成本、伙伴 CAC 与直接 CAC 对比、爬坡回收和增量性，输出签约/扩展/重谈/削减建议。

适用场景

解决思路

1. 先声明两个结构性事实：不存在 canonical 的 partner P&L 模板；多数广泛引用的 partner 基准是 vendor marketing 而非研究。任何号称标准（包括 PARTNERNOMICS-style 认证）都是专有产品，不是行业共识。
2. 先声明：广泛引用的 80% 渠道收入来自 20% 伙伴、只有 11% 达到激励目标、多数伙伴从不交易等数字不可追溯；引用前先读 references/benchmarks-and-figure-grading.md，标注每个数字的证据类别。
3. 运行 Interview：每消息只问一个问题，提供多选选项，跳过用户已回答的内容；在计算任何东西前固定模型服务的决策和 go/no-go 阈值。
4. Interview 询问 partner type：referral/agency、reseller/VAR、distributor/two-tier、MSP、OEM/embed、ISV tech alliance/co-sell/marketplace，还是 affiliate/creator。
5. Interview 询问建模谁的经济：你方、partner 自己的 P&L（Bech 观点：partner 必须拥有自己的 P&L），还是双方；并确定三个问题决定用哪一档。
6. Interview 询问该模型服务哪个决策：签/不签、扩展、重谈、削减/退出；适用什么 go/no-go 阈值；谁签字批准。
7. Interview 询问判定必须在什么日期前落地：签名截止日、董事会或 QBR 档期；若只有几周，排除双侧 P&L 和任何 incrementality 实验，因为两者都需要 partner 披露或读出窗口。
8. Interview 询问：一次性决策，还是每次 QBR 都重跑模型？重跑授权提升双侧 P&L 和书面假设登记册；一次性提升 vendor-side contribution 模型。
9. Interview 询问 effort ceiling：可用 analyst 小时、是否分配 finance reviewer、partner 是否愿意公开自己的数字？没有 finance reviewer 或 partner 不披露，则无论决策需要什么，工作上限都是 vendor-side 模型。
10. Interview 询问当前 direct CAC，以及它买到的平均 deal size；第 6 步要与两者比较，没有它们就没有阈值可测。
11. Interview 询问产品 gross margin，以及该 segment 的 churn rate 或平均客户生命周期；LTV 按 margin 计算，猜任何一个都会悄悄决定 verdict。
12. Interview 询问收入机制：费用是首年 ACV 的百分比还是经常性、list 折扣、royalty、revenue share、CPA？
13. Interview 询问什么叠加在上面：rebates、SPIFFs、MDF commitments、deal-registration uplift、marketplace listing fee？
14. Interview 询问招募、赋能和服务成本：account-manager 时间、training/certification 交付、portal 和工具、支持负载？
15. Interview 询问合同形态：exclusivity、term、deal registration、clawback、MDF commitments、minimums？
16. Interview 询问 ramp 预期：首次收入时间，谁资助 double-cost 期间？
17. Interview 询问实际存在什么数据：带 sourced/influenced 标签的 CRM attribution、marketplace disbursement reports、财务系统，还是只有估计？
18. Interview 询问是 B2B channel/alliance 还是 B2C affiliate/creator。
19. 选择 partner-type 经济模型；不同 partner type 的资金流和 margin 数学差异很大。参见 references/partner-type-economics.md。
20. 分离 partner-sourced、partner-influenced 和 partner-attached 收入；绝不混合。
21. 对 influence credit 设上限，使归因收入永远不能超过总收入；未设上限的 influence 会立即且永久地终结与 finance 的对话。
22. 构建 fully-loaded 成本栈：discount off list、rebates/SPIFFs、MDF、marketplace fee、account-manager 时间、enablement 和 certification 交付、support、portal/tooling allocation。
23. 运行 $2M 伙伴重述：一个 $2M 伙伴扣除 $500K 折扣、$200K MDF、$150K account management、$100K training/support 后贡献 $1.05M，而不是 $2M。
24. 计算 partner-adjusted gross margin 和 annual net contribution。
25. 按 gross margin 计算 lifetime value，绝不按 revenue 计算。参见 references/metrics-and-formulas.md。
26. 计算 fully-loaded partner CAC，然后与 direct CAC 做 like-for-like 比较：按每 $1 net revenue 的 acquisition cost，绝不按每客户；当折扣降低每个 partner deal 的收入时，按客户 CAC 是在给不同商品定价。
27. 选择并声明两种内部一致的 convention 之一，绝不混用：按 gross 记收入并把折扣记入 acquisition cost；或按 net of discount 记收入并把它排除。
28. 不要给两种 convention 排序：按每 $1 net revenue 计算它们产生相同数字，排序会是虚假精确。
29. 如果 partner cost per $1 of net revenue 不低于 direct 的，渠道论点已破；在 memo 中这样说。
30. 建模 ramp 和 payback。前 6-12 个月是 double cost——同时资助 partner 的 enablement 和你自己的团队。
31. 说明 time to first revenue，以及累计贡献跨零的月份。
32. 显式测试 incrementality：多少收入本来会通过 direct 到来？Attributed 不等于 incremental（Blake, Nosko & Tadelis）。
33. 从 assumed-rate band 开始，绝不从 experiment 开始；效率顺序：assumed-rate band > matched holdout > geo split > channel pause。
34. 仅当 verdict 在 plausible range 内翻转时，才购买 experiment。
35. channel pause 会饿死顺序中的后面步骤，但它买到可用的最强证据，成本也最高；仅当 incrementality 是整个 verdict 时提升它；若协议中的 exclusivity 或 minimums 禁止暂停该 motion，直接删除它。
36. 证据强度、effort 和 compliance exposure 在 references/metrics-and-formulas.md 中分别排名。
37. 对真正影响答案的 2-3 个假设做 sensitivity：通常是 deal volume、effective discount、ramp length。报告哪些变化翻转 verdict。
38. 当建模双方时，构建 partner 自己的 3-5 年 P&L（Bech），并测试 Gomes-Casseres Third Law：价值分割是否激励 partner 继续贡献？
39. 按节呈现 memo——revenue、costs、contribution、CAC、ramp、incrementality、sensitivity、verdict——每一节先与用户验证，再起草下一节。
40. 停在 approval gate：未经用户明确批准 assembled memo，不 finalize 任何内容。
41. 检查 Pass Threshold；迭代直到每项检查成立。
42. 设置 revisit cadence 和 triggers：period start 的 joint-business-plan refresh、每季度 QBR economics review、renewal/exit gate；外加事件触发器，如 marketplace fee change、commission renegotiation、ramp-milestone slip。
43. 如果 harness 有 persistent memory，记忆 approved model、其 named assumptions 和 verdict，使 QBR 时重跑从它们开始，而不是从零开始。
44. 如果可以浏览网页，在 finalizing 前验证当前 marketplace fee rates 和 partner-type benchmark ranges——fee schedules 会变（AWS 在 2025 年 5 月限制 commit-retirement eligibility）。否则把每个数字标为 user-supplied 和 unverified。
45. 按渠道和联盟团队实际运行的方式协作运行：通过 joint business planning、deal-desk review、QBR economics reviews，绝不作为 finance-silo 计算。
46. 全程每消息只问一个问题；绝不批量提问。
47. 在双方可被召集时，把模型视为 co-created：在 joint business planning 中 vendor 和 partner 一起构建计划，partner 拥有自己的 P&L。一个 partner 从未见过的模型预测的是 partner 从未同意的合作。
48. 把建模方法排名后放在桌上，说明推荐及原因，然后等待。按每 analyst hour 买到的 decision quality 排名——四个轴不一致，都要读：efficiency：vendor-side contribution > dual-sided P&L > marketplace-mechanics-first；value（能解决多少决策）：dual-sided P&L > vendor-side contribution > marketplace-mechanics-first；effort：dual-sided P&L > vendor-side contribution > marketplace-mechanics-first；compliance cost：marketplace-mechanics-first > dual-sided P&L > vendor-side contribution。
49. Vendor-side contribution 默认：解决 sign/don't sign、scale、prune、partner CAC 对比 direct；约一个 analyst 一周，用已有 CRM attribution 和 finance 数据；一个 finance reviewer，无需 partner 披露；完全可逆。
50. Dual-sided Bech-style P&L：解决以上所有，加上 split 本身——renegotiation terms 和 Third-Law check；需要一个季度，需要 partner 披露你无法看到的成本和服务经济，并跨双方 finance 团队协调；开口询问本身是 commitment signal，很难撤回。
51. Marketplace-mechanics-first：只解决 routed-deal 成本栈——listing fee、private-offer rate、commit-drawdown eligibility、win discount；一小时即可，费率是 published primary sources；单独不能解决任何事，当 deal 通过 marketplace 路由时，它是上述两者之上的必需层，绝不是替代品。
52. 按方法列 compliance cost，最重在前：marketplace mechanics 的 eligibility 由平台更改（AWS 在 2025 年 5 月限制 commit retirement），所以 routed model 的 eligibility 要对照当前平台文档重新验证，而不是对照这里写下的任何数字。
53. Dual-sided P&L 有较小但同类的 exposure：要求 partner 打开成本基础通常意味着 mutual NDA，把另一家公司的机密数字放进你的文件，并发出你无法撤回的 commitment signal。
54. Vendor-side model 不触及公司外部任何人。
55. 默认使用 vendor-side contribution 模型。当以下任一成立时升级到 dual-sided：决策是 split 而不是 signature；partner 是 reseller-class 且必须拥有自己的 P&L（Bech）；partner disclosure 已经在桌上。
56. Dual-sided P&L 正是被这个 efficiency order 饿死的：它严格解决更多问题，但成本是一个季度对一周，所以每次 engagement 中比例都降低它，重谈总是在单方数字上跑。只要问题是如何分割价值而不是是否签约，就提升它——仅凭 vendor 的 ledger 无法诚实争论 split。
57. 删除而不是降级被用户答案排除的选项，并在 memo 中说明已删除及原因：partner 不开账本删除 dual-sided；没有分配的 finance reviewer 也删除它；deal 不通过任何 marketplace 则删除 marketplace-mechanics 层；被排到底部的 rung 会在下次 review 作为 scope 回来，来自从未听过该约束的人。
58. 在推荐前，根据你已知道的该用户重新排名：已分配 finance reviewer 会压缩 dual-sided 协调成本；过去 engagement 的 approved model 使扩展它比三者都便宜。排序是默认，不是法律——它随决策和做事的人变化。
59. 在计算前大声命名假设：哪个 volume 数字是 partner enthusiasm，哪个 benchmark 是 vendor-published，哪个 cost 是 guess。
60. 在呈现模型前，论证反对该合作的最强理由；关系投资和 logo halo 是 documented 的自欺方式。
61. 把非标准条款通过 deal-desk lens 路由：书面 discount bands，例外以书面理由。一个向背负季度数字的领导汇报的 desk 会批准能关单的条款。
62. 对于 recurring reviews，坚持双方在会前阅读同一 shared scorecard。两个 documented QBR 失败模式：status theater——会议结束没人拥有带日期的行动；no shared data going in——双方带着不同 pipeline 数字来，半场争论谁的 spreadsheet 对。
63. 在向更广领导层呈现前，一对一获得 CFO 和 CRO buy-in。
64. 按节呈现 deliverable；每节验证后再起草下一节；finalization 以用户明确批准为 gate。
65. 以该 artifact 交付 engagement：PARTNER ECONOMICS: <partner>, <date>；Decision: sign/scale/renegotiate/prune，带 agreed go/no-go threshold；Partner type: type + money-flow mechanics（fee %, discount, royalty, rev-share, CPA, marketplace）；Revenue model: sourced 和 influenced 分开预测，绝不是一个 blended number；Cost stack: discount | rebates/SPIFFs | MDF | marketplace fee | account mgmt | enablement | support | tooling；Net contribution: partner-adjusted gross margin 和 annual net contribution，按年跨 ramp；Partner CAC: fully loaded，对比 direct CAC，说明 attribution method；Ramp & payback: time to first revenue、double-cost period、累计贡献跨零月份；Incrementality: 归因收入中本来会来的份额及其 evidence class；Partner's P&L: partner 自己的 3-5 年经济及 Third-Law check（双方建模时）；Sensitivity: 2-3 个移动 verdict 的假设及各自翻转点；Verdict: 对照 stated threshold，以及什么结果会改变它；Open questions: 缺失数据、未验证数字、哪个发现会逆转 verdict。
66. Memo 规则：每个 benchmark 带 source-quality label——peer-reviewed、analyst、industry survey、vendor benchmark 或 untraceable。
67. Memo 规则：每个 input 溯源到 named source，或标记为 unverified, user-supplied——绝不发明数字，绝不从 worked example 搬运数字。如果第 5 步仍缺 direct CAC、gross margin 或 churn，停止并询问用户，而不是拿页面上最近的数字。
68. Memo 规则：open-questions section 是强制的；一个没有声明不确定性的模型已经停止提问。
69. Pass Threshold 1：partner acquisition cost per $1 of net revenue 预计低于 direct motion 的，fully loaded，按一种 stated convention。当折扣降低每个 partner deal 收入时，per-customer CAC 不是有效比较。否则渠道论点已破，memo 要说明。证据类别：practitioner consensus，锚定 2014 Pacific Crest/KeyBanc survey（$0.53 channel CAC per $1 of new ACV，是现有记录最好的 channel-CAC 数字，且已经是一个 ratio）。
70. Pass Threshold 2：sourced 和 influenced 绝不混合，一个 deal 只归因一个 partner，influence 设上限使 attributed revenue 永不超过 total revenue。
71. Pass Threshold 3：cost-to-serve fully loaded。模型要能通过 $2M 伙伴重述：headline revenue 重新表达为扣除 discount、MDF、account management、training/support 后的净值（示例 $2M → $1.05M）。
72. Pass Threshold 4：lifetime value 按 gross margin 计算，绝不按 revenue。
73. Pass Threshold 5：incrementality 显式处理，绝不假设 100%——cannibalization estimate 及其 evidence class 出现在 memo 中。
74. Pass Threshold 6：运行并报告 sensitivity；只在一个假设集下成立的 verdict 是 bet，不是 model。
75. Pass Threshold 7：每个 benchmark 按 evidence class 标注；不可追溯的著名数字（80/20 concentration、11% incentive attainment、most partners never transact）标为 untraceable 或省略。
76. 用 KPIs 在 6 到 12 个月后判断经济决策本身，而不是 partner 的持续表现（后者属于 partner-performance）：realized partner CAC 对比 modeled projection，以及同窗口的 direct CAC。
77. 用 KPIs：actual cumulative net contribution 对比 modeled ramp curve。
78. 用 KPIs：partner-sourced 客户的 retention/NRR 对比 direct-sourced；差距超过 10-15pp 表示 ICP misalignment（practitioner threshold；SaaS Capital Aug 2019 survey 发现渠道为主的公司 retention 低约 3pp）。
79. 用 KPIs：time to first partner revenue 对比 modeled ramp。
80. 用 KPIs：assumption audit——哪些 modeled inputs 被证明错误，错多少——作为下一个模型的输入。
81. 用 KPIs：verdict durability——sign/scale/prune 判断是否在前两个 quarterly reviews 中存活，而没有在模型本应抓住的事实上反转。
82. B2B 和 B2C 方法相同：归因收入减去 fully-loaded partner cost，对比 partner CAC，跨越 lifetime，按 incrementality 调整。被问时就这样说；绝不按侧重新发明。
83. 按 B2B/B2C 真正差异设计：unit of analysis——B2B 是 partner firm，少而大；B2C 是 creator/publisher，多而长尾。
84. 按差异设计：money flow——B2B 是 discount off list、rebates、MDF、marketplace fees；B2C 是按 action 支付 CPA 或 revenue share。
85. 按差异设计：ramp & enablement——B2B 6-12+ 个月 double-cost、certification；B2C 接近零、即时激活。
86. 按差异设计：attribution——B2B 是 deal registration、CRM opportunity tagging；B2C 是按 action 的 cookie/attribution window。
87. 按差异设计：concentration——B2B 少数伙伴主导；B2C 是 power-law 长尾小收入者。
88. 按差异设计：effective-rate trap——B2B 是跨层 margin stacking；B2C 是 effective rev-share 在扣除后比 stated rate 低 20-40%。
89. 按 Failure Modes 表的行顺序处理——按每小时消除的 verdict 扭曲排名，而不是按发生频率。前五行是对已有算术和标签的重跑，每行都能在一个工作日内单独逆转 verdict；其余是 term-design 和 program-hygiene 修复，以季度计，改变下一份合同而不是本周 memo 里的数字。
90. Failure Mode：double-counting influenced revenue -> 分离 sourced/influenced；一个 deal 一个 partner；cap influence at total revenue。
91. Failure Mode：ignoring cost to serve -> fully-loaded stack；对每个 headline number 运行 $2M → $1.05M restatement。
92. Failure Mode：counting cannibalized revenue as incremental -> 显式建模 incrementality；用 segmentation 和 rules of engagement，而不是希望。
93. Failure Mode：misattributed partner CAC -> 如果 partner CAC 超过 direct，按此顺序检查：double-counted influence，然后 commission against deal size，然后 lead quality。
94. Failure Mode：quoting an untraceable benchmark as fact -> 标注 evidence class；优先 named-source figures；写 unverified 而不是发明。
95. Failure Mode：margin stacking collapse across tiers -> 建模 full stack（Spengler）；考虑 two-part tariff shape 作为条款。
96. Failure Mode：over-discounting to win the partner -> 把 win discount 和 marketplace fee 一起建模——折扣经常 dwarf 3% listing fee。
97. Failure Mode：marketplace commit-drawdown surprises -> 建模 commit-retirement mechanics 和 eligibility rules，而不只是 listing fee。
98. Failure Mode：MDF that never converts -> 把 MDF 绑定到 documented plan commitments；建模 utilization，而不是 allocation。
99. Failure Mode：sunk-cost persistence and the long-tail illusion -> 100 个签约伙伴只有 12 个活跃就是 12 伙伴渠道；按 net contribution 削减，而不是按 tenure。

适用边界 · 注意事项

• 不用于对一组候选合作伙伴排序或组合优先级；那应使用 alliance-prioritization。
• 如果缺少直接 CAC、产品毛利率、流失率/客户生命周期等关键输入，或没有明确决策与 go/no-go 阈值，应先补齐数据/阈值，而不是硬建模。
• 如果目标只是合作伙伴持续绩效打分、QBR 运营回顾而非单伙伴经济决策，应使用 partner-performance。