在现有 B2B 合作伙伴项目中设计或重构层级：资格标准…

当已有 B2B 伙伴项目需要调整注册/银/金式层级、资格标准、权益、压缩、降级规则或迁移现有伙伴基础时使用。

适用场景

解决思路

1. 明确声明：没有单一权威的层级设计方法论，不要编造一个；只呈现领域实际提供的选择。
2. 引用 Forrester 的 3-tier norm：98% 顶级 IT 合作伙伴项目使用层级，平均三层，命名 'good, better, best'（分析师断言，非原始调查数据）。
3. 引用 Alexander Group 的三种层级机制：volume、engagement 或 engagement pathways（跨多个维度累积 points）——这是设计者要做的第一个结构选择。
4. 引用 Forrester 的 Channel Partner Segmentation Matrix（Stephanie Sissler, Feb 2023）：3x3 current-performance x future-potential 网格，明确是公开层级阶梯的内部叠加，绝不替代它。
5. 引用 Jay McBain 的批评（有署名的从业者观点，非框架）：收入是滞后指标，非交易合作伙伴——tech/ISV、referral、advisory——结构上不适合收入阶梯。
6. 先访谈再设计，每条消息只问一个问题，提供多选选项，跳过用户已答的内容。
7. 问：有多少合作伙伴，哪些类型——reseller、MSP、agency、ISV/tech、referral？哪些类型实际交易？
8. 问：当前层级、其标准、当前分布——每层有多少合作伙伴？
9. 问：具体痛点是什么：顶层拥挤、无人晋升、权益被忽略、长尾被忽视、渠道冲突？
10. 问：合作伙伴来源收入的集中度——大致 top 10-20% 的合作伙伴贡献多少份额？
11. 问：每层今天的服务成本：margin give、deal-registration uplift、MDF、PAM headcount？
12. 问：当前审查节奏是什么，降级是否实际执行？
13. 问：平均销售周期长度是多少？任何作为层级权益提供的 deal-registration protection window 都按周期的 ≥75% 设定，所以从库存范围选的窗口可能只有周期所需的一半。
14. 问：新结构必须在什么日期上线，其结果必须在什么日期从层级移动中显现？
15. 问：这是一次性修复特定痛点，还是每周期都要重新评分的复合资产？
16. 问：努力上限是什么：partner-ops 小时、可用数据工作、实际执行降级的政治资本？
17. 问：仅 B2B channel，还是项目也运行 B2C 面向的 affiliate、creator 或 loyalty 层级？
18. 问：什么是不可变的：已签合作伙伴协议、财年日历、comp plans？
19. 问：谁必须签字：channel chief、CRO、finance、legal？
20. 运行 Interview，收集设计依赖的每个当前状态事实。
21. 确认范围：精炼一个已存在项目的层级层；从零构建项目或修复个体伙伴绩效属于 Reference 节中的兄弟技能。
22. 建立 baseline：每个当前层级的合作伙伴、收入贡献和 cost-to-serve。预期 power law——10-20% 合作伙伴驱动 70-80% 渠道收入是常引用的模式（PRM-vendor 经验法则，非实证数据集）。
23. 决定层级数量（默认 3；低于约 50 个合作伙伴折叠为 2）——见 references/distribution-and-cadence.md。
24. 然后选机制，选择实际在此做出：Volume——仅收入阈值。运行近零：CRM 已有数字。排名最弱，因为收入是滞后指标，每个非交易合作伙伴得零分。
25. Engagement——收入加认证、能力或留存。约四分之一搭建，之后每周期近零。标准在申诉中合作伙伴无法争议，且非转售者可爬的阶梯。
26. Points pathway——发布公式给多个动作不同权重。常设工作：公式、每类最低值、每周期欠合作伙伴的重算。排名最细，是唯一能排序单一指标无法正确排序的基础的机制。
27. 效率（最佳比例优先）：engagement > volume > points pathway。
28. 价值（排名能力）：points pathway > engagement > volume。
29. 努力（最重优先）：points pathway > engagement > volume。
30. 成本不单独成行：机制唯一成本是运行它的工作，所以成本顺序等于努力顺序。
31. 默认 engagement。当合作伙伴跨多个动作交易——sourced、assisted、managed——升级到 points pathway。没有单一指标能按渠道团队会辩护的顺序排序它们。
32. 此顺序饿死 points pathway：最高价值、最高努力，所以每轮都输。当项目已输降级争议，或每周期层级分配逐案争论时，仍要提升它。
33. 一旦基础中很大比例从不交易，直接删除 volume。Volume 阶梯根本无法排序这些合作伙伴，留在短名单会恢复把 ISV 和 referral 合作伙伴读成坏合作伙伴的阶梯。
34. 根据 Interview 答案重新排名：一个季度内的硬日期提升 volume 并本轮从短名单移除 points pathway；复合任务提升它；无 partner-ops 小时的 effort ceiling 移除它。
35. 然后给非交易合作伙伴类型符合它们的标准，或单独轨道。
36. 先定义资格和维护标准，再碰权益——标准决定谁落在哪；先设计权益会被承诺给从未建模的人群。见 references/tier-criteria.md。
37. 用现有合作伙伴基础回测提议标准：对照下面的 pass threshold 检查结果分布；调整阈值并重跑。
38. 回测产生建模的层级人数，下一步据此定价——回测前定价的 bundle 是对无人计数人群的猜测。
39. 定价每层权益包并检查交换双向平衡：该层收入覆盖其 bundle 成本，每上一级明显奖励合作伙伴攀升。见 references/tier-benefits.md。
40. 设计晋升、降级、审查节奏、测量窗口、宽限期、祖父条款、申诉路径。
41. 计划迁移和宣导：partner advisory council preview、notice period、migration comms、published decision dates。
42. 按 Brainstorming 节头脑风暴和验证：先候选结构，再逐节 spec。
43. 检查 pass threshold；迭代标准、权益或层级数量直到每个检查成立。
44. 停在 approval gate——没有用户明确批准完整 spec，不要最终确定任何东西。
45. 如果 harness 有持久内存，记住批准的结构、阈值和首次审查日期；否则告诉用户把 spec 存到 partner ops 能取回的地方。
46. 如果能浏览网页，引用任何具名 vendor 结构前先验证——主要项目在 2022-2026 反复重组。否则标记 vendor 例子可能过时。
47. 本技能及参考文件中的每个排序都是默认，不是法律。随项目背景和执行人变化。
48. 根据已知用户事实重新排名每个排序：实时认证注册表把 engagement 机制搭建降到近零，它直接赢；仓库中已有 per-motion attribution 把 points pathway 的常设工作变成查询；渠道主管今年没有降级政治资本改变节奏顺序。
49. 说明用户的哪些事实移动了哪个选项，而不是重述默认。
50. 像渠道团队实际运行那样运行设计：压缩的 90 天设计冲刺，不是单一答案。
51. 全程每条消息只问一个问题；绝不批量提问。
52. 汇总渠道专业人士带来的数据：partner P&L、sourced-revenue distribution、cost-to-serve、PSAT/NPS、portal-engagement signals。用现有数据建模；命名缺失数据。
53. 映射 RACI：channel chief accountable、partner ops runs model、partner marketing owns migration comms、finance validates margin、legal amends agreements、CRO defends program。
54. 先细分基础（partner type x size x economic potential）；内部叠加 Forrester 3x3 网格 sanity-check 关键合作伙伴落点。
55. 展示 2-3 个候选层级结构，基于 workflow step 4 的排名机制：先推荐排名建议的，然后说明每个替代要胜出需要什么为真。
56. 用户选方向后，一次一节展示 spec——criteria、benefits、cadence、migration——每个验证后再写下一个。
57. 建议在任何公开宣布前通过 partner advisory council 宣导接近最终的结构；层级变更是谈判和关系绑定，不是发布。
58. 以用户明确批准 assembled spec 作为最终化门槛。
59. 交付 Tier Structure Spec 作为决策记录，包含：Mechanic（volume | engagement | points pathway，若为 points 则含 point formula）；Tier count（N，以及为什么不是 N-1 或 N+1）；每个 tier 从下到上重复：Name（面向合作伙伴、可重复，绝不用 'Tier 2'）、Qualification（criteria + thresholds + measurement window + data source）、Maintenance（每个审查检查点保持该 tier 的条件）、Benefits（bundle，每个权益含建模单位成本）、Modelled count（回测中今天符合条件的合作伙伴数 + 占基础百分比）、Cost-to-serve（该人数下建模年度 bundle 成本）、Revenue（该 cohort 的建模贡献）；Program level：Review cadence（重算时刻 + rolling vs fixed window）、Grace period（降级生效前的长度）、Appeals（路径 + 指定决策人 + 公布决策日期）、Grandfathering（谁在迁移中保留身份，到何时）、Migration plan（notice period、advisory-council preview、comms milestones）、Validation（全面发布前的 pilot cohort 或模型检查）、KPIs（来自 KPI 节，含首次审查日期）。
60. Spec 规则：每个阈值附测量窗口和数据源——没人能计算的 criterion 不会降任何人。
61. Spec 规则：每行带理由（例如 'top tier requires 80% gross revenue retention - gates co-sell on retention quality'）；裸数字不可审查。
62. Spec 规则：拒绝任何合作伙伴可自报或博弈的标准；只用项目自己记录并能在争议中辩护的数据。
63. Spec 规则：回测人数为强制：未对真实合作伙伴基础运行的结构是猜测，不是设计。
64. Pass threshold 1：可达不拥挤。顶级层约 >=10% 合作伙伴可达（PRM-vendor 启发式，非实证基准）。如果远超，阈值落后于基础——升级。
65. Pass threshold 2：相邻步骤有可见经济差异。约 2% 折扣加更好徽章是记录失败：合作伙伴理性拒绝攀升。
66. Pass threshold 3：每层自筹资金。每层建模权益包成本低于该层建模收入贡献。
67. Pass threshold 4：无可博弈。没有自报或可操纵标准——logo 数量和自报 pipeline 是记录博弈向量。
68. 当用户已有运行结构时，在表中找症状——行按症状而非优先级。
69. 多个症状同时出现时，按效率顺序修复：criteria thresholds > benefit differentiation > cadence, grace and comms > benefit allocation to the middle > tier count。
70. 升级阈值是对项目已有数据的电子表格更改，下个审查生效。
71. 折叠层级数量是迁移、comms 计划、协议修订，所以最后付，即使用户抱怨的是臃肿。
72. 拥挤顶层和无法解释的阶梯通常是同一种病，阈值修复治两者。
73. 层级数量被这个顺序饿死——价值最高但努力最后，所以比率每周期推迟它，而阈值在没人能解释的阶梯上反复升级。当相邻层停止在 criteria 和 benefits 上都不同，或迁移已因其他原因发生且数量可搭便车无额外 comms 成本时，提升它。划掉项目约束排除的行并说被划掉，而不是留底作为无人 scope 的工作。
74. 症状：没人能解释的层级（5+，重叠标准）-> 检查相邻层是否在 criteria 和 benefits 都不同 -> 故障变量 tier count - collapse。
75. 症状：顶层拥挤（压缩）-> 检查阈值上次提升 vs 基础增长 -> 故障变量 criteria thresholds - escalate。
76. 症状：没人晋升；合作伙伴停在入口 -> 检查阈值曲线：底部太易顶部太难；层级间悬崖 -> 故障变量 threshold spacing。
77. 症状：合作伙伴忽略阶梯，不愿投资 -> 检查每步经济差异：折扣、deal-reg uplift、rebate -> 故障变量 benefit differentiation。
78. 症状：权益分配但未用（MDF 未认领）-> 检查认领摩擦和合作伙伴营销带宽 -> 故障变量 benefit design, not criteria。
79. 症状：层级指标好看，结果不好 -> 检查哪些标准自报（pipeline, logos）-> 故障变量 criteria gameability。
80. 症状：长尾休眠 -> 检查到达中低层的投资份额 -> 故障变量 benefit allocation - fix the middle before adding tiers。
81. 症状：合作伙伴之间或与直销 deal fights -> 检查 deal-registration enforcement 一致性 -> 故障变量 benefit enforcement, not structure。
82. 症状：审查日期后 churn 飙升 -> 检查降级意外：通知、宽限、申诉 -> 故障变量 cadence, grace, and comms。
83. KPI：判断层级结构本身，不是个体合作伙伴（个体记分卡属于 mbfinotti/partnerships-skills@partner-performance）。
84. KPI：跨连续审查期的层级分布形状——向压缩或空中间漂移。
85. KPI：每审查期晋升合作伙伴份额。
86. KPI：每层收入 vs 每层 cost-to-serve。
87. KPI：权益利用率，尤其 MDF 认领率：40-60% 通常未认领（常引行业数字，有来源）。
88. KPI：按层的 partner satisfaction (PSAT/NPS)。
89. KPI：降级后 churn vs baseline partner churn。
90. B2B vs B2C 相同：power-law 集中、threshold-gated qualify → status → perks → requalify 循环、层级数量规则（默认 3，低于约 50 折 2）、失败模式。
91. B2B vs B2C 不同——进展货币：B2B channel = revenue + certifications + CSAT/retention；affiliate/creator = sales or GMV on rolling window；consumer loyalty = annual qualifying spend、nights 或 miles。
92. B2B vs B2C 不同——重置节奏：B2B = rolling or annual with grace；affiliate = rolling；consumer loyalty = hard annual status clock。
93. B2B vs B2C 不同——人工接触：B2B = PAM coverage and QBRs；B2C = self-serve automation end to end。
94. B2B vs B2C 不同——可测试性：affiliate 或 consumer ladder 可在大基础 A/B 测试；B2B 层级变更是谈判、关系绑定，通过 partner advisory council 宣导——建模和试点代替。
95. 看 references/worked-examples.md 获取完整对比、2023-2026 真实 vendor 结构分解、一个完整 worked tier structure 和 B2C 对比。
96. 参考 references/tier-criteria.md 获取 criteria menu、points-model weighting、measurement windows、gameability checks、非交易合作伙伴类型标准。
97. 参考 references/tier-benefits.md 获取 benefit menu with real costs、bundle pricing、非差异化阶梯负面例子。
98. 参考 references/distribution-and-cadence.md 获取 tier count、backtesting、target distribution、cadence、promotion/demotion、grace、grandfathering、appeals、tier-inflation control。
99. 参考 mbfinotti/partnerships-skills@partner-channel-program 从零设计整个合作伙伴项目——本技能只精炼其中的层级层。
100. 参考 mbfinotti/partnerships-skills@partner-performance 获取个体合作伙伴记分卡、QBR 结构、绩效不足触发。
101. 参考 mbfinotti/partnerships-skills@affiliate-commission-structure 获取面向专业联盟的佣金支付层级——不同于渠道层级。

适用边界 · 注意事项

• 不要用于从零搭建合作伙伴项目；应使用 mbfinotti/partnerships-skills@partner-channel-program。
• 不适用于联盟佣金支付层级（affiliate commission payout tiers）；那是独立技能。
• 不适用于个体合作伙伴记分卡、QBR 结构或绩效不足触发；应使用 mbfinotti/partnerships-skills@partner-performance。