partner-tiering

合作伙伴分级

制定标准和权益，用于区分现有 B2B 合作伙伴计划中的不同级别。不存在唯一公认的分级方法——应当坦率说明这一点，而不是凭空编造。行业实际上提供的内容如下：

• Forrester 的 3 级常态：98% 的顶尖 IT 合作伙伴计划采用分级，平均设有 3 个级别，分别称为“好、更好、最好”（这是分析师的判断，并非原始调查数据）。
• The Alexander Group 的三种分级机制：按业务量、参与度，或参与路径（在多个维度累积积分）分级——这是设计者首先要做的结构性选择。
• Forrester 的渠道合作伙伴细分矩阵（Stephanie Sissler，2023 年 2 月）：一个以当前业绩 × 未来潜力为维度的 3×3 网格，明确用于叠加在公开的级别体系之上，绝不能取而代之。
• Jay McBain 的批评（这是从业者的个人观点，并非框架）：收入是滞后指标，而且非交易型合作伙伴——技术／ISV、推荐、顾问——从结构上就不适合按收入分级。

访谈

在进行任何设计之前先提问，每条消息只问一个问题。提供多个选择。用户已经回答的问题则跳过。

• 合作伙伴有多少，分别属于哪些类型——经销商、MSP、代理机构、ISV／技术、推荐？哪些类型会实际促成交易？
• 当前有哪些级别、各自的标准是什么，当前分布如何——每个级别有多少合作伙伴？
• 具体痛点是什么：最高级别过于拥挤、无人晋级、权益无人使用、长尾被忽视、渠道冲突？
• 合作伙伴带来的收入集中度如何——大约有多少收入来自排名前 10%–20% 的合作伙伴？
• 当前为每个级别提供服务的成本是多少：让利幅度、交易注册加成、MDF、PAM 人力？
• 当前的审核频率如何，是否会实际执行降级？
• 平均销售周期有多长？（作为级别权益提供的任何交易注册保护期，长度都应达到平均销售周期的 ≥75%；因此，如果没有这个数字就从固定范围中选取保护期，实际期限可能只有销售周期所需时间的一半。）
• 新结构必须在哪个日期上线，其成效又必须在哪个日期前体现在级别变动中？
• 这是针对特定痛点的一次性修复，还是一项会从现在起在每个周期重新评分、不断累积价值的资产？
• 工作量上限是多少：合作伙伴运营工时、可投入的数据工作，以及实际执行降级所需的政治资本？
• 这是否仅限于 B2B 渠道，还是该计划也包含面向 B2C 的联盟、创作者或忠诚度级别？
• 哪些条件不可更改：已签署的合作伙伴协议、财年日历、薪酬计划？
• 谁必须签字批准：渠道负责人、CRO、财务、法务？

工作流

1. 进行访谈。收集设计所依赖的所有现状事实。

2. 确认范围：优化现有计划的层级体系。从零开始构建计划，或解决单个合作伙伴的绩效问题，属于 Reference 部分中的同系列技能。

3. 建立基线：统计各现有层级的合作伙伴数量、收入贡献和服务成本。预期会呈现幂律分布——通常引用的模式是，10-20% 的合作伙伴带来 70-80% 的渠道收入（这是 PRM 供应商的经验法则，并非实证数据集）。

4. 决定层级数量（默认 3 个；合作伙伴数量低于约 50 个时缩减为 2 个）——参见 references/distribution-and-cadence.md。然后在此处选择具体机制，因为真正的选择就在这里：

   • 交易量——仅设置收入门槛。运行成本几乎为零：CRM 中已有相关数字。排序能力最弱，因为收入是滞后指标，而且所有尚未产生交易的合作伙伴在这项指标上都得零分。
   • 参与度——综合收入、认证、能力或留存情况。搭建需要几周，之后每个周期的成本几乎为零。标准无可争辩，合作伙伴申诉时也难以质疑；非转售商也能沿此路径晋级。
   • 积分路径——发布一套公式，按不同权重为多种业务活动评分。这是一项持续工作：每个周期都要维护公式、各类别的最低要求，并重新计算分数。排序能力最强，而且这是唯一能正确排列无法通过单一指标排序的合作伙伴群体的机制。
   • 效率（从最高比率到最低）：engagement > volume > points pathway
   • 价值（排序能力从强到弱）：points pathway > engagement > volume
   • 工作量（从高到低）：points pathway > engagement > volume
   • 成本无需单独列出：机制唯一的成本就是运行它所需的工作，因此成本排序与工作量排序一致。
   • 默认选择参与度。如果合作伙伴通过多种业务活动开展交易——如来源、协助、管理——则升级为积分路径。没有任何单一指标能将他们排出渠道团队愿意认可的顺序。
   • 这种排序会让积分路径处于劣势：它价值最高，工作量也最大，因此每轮都会落选。即便如此，如果计划已经频繁遭遇降级争议，或每个周期的层级分配都要逐案辩论，仍应优先考虑积分路径。
   • 如果有相当一部分合作伙伴从不产生交易，就彻底排除交易量机制。交易量阶梯根本无法对这些合作伙伴排序，将它保留在候选名单中，等于重新采用会把 ISV 和推荐合作伙伴判定为劣质合作伙伴的阶梯。
   • 根据访谈答案重新排序：
     • 如果截止日期就在一个季度内，则优先选择交易量，并在本轮排除积分路径。
     • 如果有持续累积的要求，则优先选择积分路径。
     • 如果工作量有上限且没有合作伙伴运营工时，则排除该机制。
   • 然后为不产生交易的合作伙伴类型设定适合他们的标准，或为他们设置单独的路径。

5. 在考虑福利之前，先定义资格和维持层级的标准——标准决定谁进入哪个层级；如果先设计福利，承诺的对象可能是一个从未建模过的群体。参见 references/tier-criteria.md。

6. 使用现有合作伙伴群体对拟定标准进行回测：

   • 根据下方的通过门槛，检查得出的分布。
   • 调整门槛并重新运行。

   这一步会得出下一步定价所需的建模层级人数——如果在回测前就对福利组合定价，那只是对一个从未统计过的群体进行猜测。

7. 为每个层级的权益组合定价，并双向核查收益是否平衡：该层级的收入能否覆盖其权益成本，每次升级是否都能明显回报合作伙伴的晋升。请参阅 references/tier-benefits.md。

8. 设计晋升、降级、审核频率、衡量周期、宽限期、既有资格保护和申诉流程。

9. 规划迁移和沟通：预览版合作伙伴咨询委员会、通知期、迁移沟通材料、已公布的决策日期。

10. 按照下一节的流程进行构思和验证：先列出候选结构，再逐节制定规范。

11. 检查是否达到通过门槛；迭代调整标准、权益或层级数量，直到所有检查都通过。

12. 在审批关口暂停——未经用户明确批准完整规范，不得敲定任何内容。

13. 如果你的运行环境支持持久记忆，请记住已批准的结构、门槛和首次审核日期；否则请告知用户将规范保存到合作伙伴运营团队能够检索的位置。

如果你可以浏览网页，请在引用任何具名供应商的结构前进行核实——主要计划在 2022-2026 年间多次重组。否则请标明供应商示例可能已过时。

本技能及其参考文件中的所有排序——包括上述机制、参考文件中的标准、权益、频率和降级策略——都是默认做法，并非铁律。具体安排会因计划背景及执行者而异。

请结合你对用户的已有了解，重新排列每项优先级：

• 如果已有有效的认证注册系统，使参与度机制的搭建成本几乎为零，那么它就会胜出。
• 如果数据仓库已内置按活动类型归因，积分路径的日常工作就只剩一条查询。
• 如果渠道负责人今年没有降级所需的政治资本，就会改变各项审核频率的排序。

说明用户的哪些事实改变了哪些选项，不要只复述默认做法。

构思结构

按照渠道团队的实际方式开展设计——进行为期 90 天的精简设计冲刺，而不是只给出一个答案：

• 全程每条消息只问一个问题；切勿一次性罗列多个问题。
• 汇集渠道专业人士会提供的数据：合作伙伴损益表、来源收入分布、服务成本、PSAT/NPS、门户参与度信号。使用现有数据进行建模，并指出缺失的数据。
• 明确 RACI 分工：渠道负责人承担最终责任，合作伙伴运营团队运行模型，合作伙伴营销团队负责迁移沟通，财务团队验证利润率，法务团队修订协议，CRO 为计划据理力争。
• 先按类型 × 规模 × 经济潜力细分合作伙伴群体；再在内部叠加 Forrester 3x3 网格，核对重要合作伙伴会落在哪些位置。
• 根据工作流步骤 4 中排序后的机制，提出 2-3 种候选层级结构：首先推荐排序结果认为最适合当前合作伙伴群体的方案，然后说明在什么条件下每种备选方案才会胜出。
• 用户选定方向后，每次只展示规范的一个部分——先是标准，再是权益，接着是审核频率，最后是迁移——并在撰写下一部分前逐一验证。
• 建议在公开宣布前，通过合作伙伴咨询委员会向合作伙伴介绍接近最终版的结构；层级变更需要协商并考虑合作关系，不能直接推行。
• 只有在用户明确批准汇总后的规范后，才能敲定最终方案。

层级结构规范

以此成果交付整个流程——这是一份决策记录，供用户提交给合作伙伴运营、财务和法务团队：

TIER STRUCTURE - <program>, <date>
Mechanic         : volume | engagement | points pathway, with the point formula if points
Tier count       : N, and why not N-1 or N+1
Per tier (repeat for each, bottom to top):
  Name           : partner-facing, repeatable (never "Tier 2")
  Qualification  : criteria + thresholds + measurement window + data source
  Maintenance    : what keeps the tier at each review checkpoint
  Benefits       : bundle, each benefit with its modelled unit cost
  Modelled count : partners qualifying today (from the backtest) + % of base
  Cost-to-serve  : modelled annual bundle cost at that headcount
  Revenue        : modelled contribution of that cohort
Program level:
  Review cadence : recalculation moment + rolling vs fixed window
  Grace period   : length before a demotion takes effect
  Appeals        : path + named decision owner + published decision dates
  Grandfathering : who keeps status through migration, until when
  Migration plan : notice period, advisory-council preview, comms milestones
  Validation     : pilot cohort or model checks before full launch
  KPIs           : from the KPI section, with the first review date

规范本身须遵守以下规则：

• 为每个门槛标注衡量周期和数据来源——无法计算的标准不会让任何人降级。
• 每一项都须说明理由（例如：“顶级层级要求总收入留存率达到 80%——以留存质量作为联合销售的门槛”）；只有数字而没有理由的内容无法审核。
• 拒绝任何合作伙伴可以自行申报或操纵的标准；只使用计划本身记录且在争议中能够举证的数据。
• 回测数量是必需项：未经真实合作伙伴群体检验的结构只是猜测，并非设计。

达标门槛

只有在以下四项全部满足后才发布；持续迭代设计，直到满足要求：

1. 可达成，而非拥挤。 大约 >=10% 的合作伙伴可以达到最高等级（这是基于 PRM 供应商的经验法则，并非实证基准）。如果达标者远不止于此，说明门槛跟不上基准——应提高门槛。
2. 每个相邻等级之间都有明显的经济收益差异。 已记录的失败案例是：折扣仅提高约 2%，再加上一枚更好看的徽章——合作伙伴理性地选择不晋级。
3. 每个等级都能自负盈亏。 每个等级的建模福利组合成本都低于该等级的建模收入贡献。
4. 不可钻空子。 没有任何标准可以自我申报或操纵——Logo 数量和自我申报的销售线索是已记录的作弊途径。

诊断现有层级结构

当用户带着正在运行的结构而非空白页面前来时，在表格中找到他们遇到的问题——表格按问题分类，而非按优先级排序。

同时出现多个问题时，按以下顺序修复。排序依据是效率，而非严重程度：

criteria thresholds > benefit differentiation > cadence, grace and comms > benefit allocation to the middle > tier count

• 提高门槛只需针对项目已有数据修改电子表格，并在下次评审时生效。
• 精简层级数量则需要迁移、沟通计划和协议修订，因此即使用户最初抱怨的是层级臃肿，这项工作也应最后进行。

顶层拥挤和层级梯度难以解释通常是同一种问题，提高门槛可以同时解决两者。

层级数量是最容易在上述顺序中被搁置的事项——它是清单上价值最高、仅按工作量排序时却排在最后的修复项，因此只要依据比例安排优先级，它就会每个周期都被推迟，而门槛却会在一套原本就无人能解释的层级梯度上不断上调。满足以下任一条件时，应提高这项工作的优先级：相邻层级在标准和权益上都不再有差异；或者因其他原因已经在进行迁移，且合并层级数量不会增加沟通成本。若项目的限制条件排除了某一行所述方案，就将其划掉并明确说明——例如，已签署的协议规定了当前权益组合，本周期就无法进行权益差异化——不要把它留在清单底部，否则它会再次变成一项无人纳入规划的工作。

问题	优先检查	出问题的设计变量
无人能解释的层级（5 个以上，标准重叠）	相邻层级在标准和权益上是否都有差异	层级数量——合并
顶层拥挤（压缩）	上次提高门槛的时间与基础增长的关系	标准门槛——提高
无人晋级；合作伙伴停留在入门层级	门槛曲线：底部过于宽松，顶部过于严格；各级之间存在断层	门槛间距
合作伙伴忽视层级梯度，不愿投入	每一级的经济差异：折扣、交易注册提升、返利	权益差异化
已分配的权益无人使用（MDF 未申领）	申领流程的阻力和合作伙伴的营销资源	权益设计，而非标准
层级指标表现出色，实际结果却不理想	哪些标准由合作伙伴自行报告（销售线索、品牌标识）	标准可操纵性
长尾合作伙伴处于休眠状态	投入中有多少流向中低层级	权益分配——先改善中间层级，再增加层级
合作伙伴之间或合作伙伴与直销团队之间争抢交易	交易注册规则是否得到一致执行	权益执行，而非结构
评审日期后流失率激增	降级是否出乎意料：通知、宽限期、申诉	评审周期、宽限期和沟通

KPI

评估层级结构本身，而非单个合作伙伴（单个合作伙伴的记分卡请参阅 mbfinotti/partnerships-skills@partner-performance）：

• 连续各个评审周期的层级分布形态——是否趋于压缩或中间层级空缺。
• 每个评审周期晋级的合作伙伴占比。
• 各层级的营收与服务成本。
• 权益使用率，尤其是 MDF 申领率：常有 40-60% 无人申领（引用自业内反复出现的数据）。
• 各层级的合作伙伴满意度（PSAT/NPS）。
• 降级后的流失率与合作伙伴基准流失率相比如何。

B2B 与 B2C

两者相同：幂律式集中、由门槛控制的「达标 → 获得身份 → 享受权益 → 重新达标」循环、上述层级数量规则（默认 3 层，合作伙伴不足约 50 家时缩减为 2 层），以及上述失效模式。

差异之处——应据此设计：

• 晋级依据：B2B 渠道 = 营收 + 认证 + CSAT/留存；联盟营销/创作者 = 滚动周期内的销售额或 GMV；消费者忠诚度 = 年度合格消费额、住宿晚数或里程。
• 重置频率：B2B = 滚动周期或年度评估，并设宽限期；联盟营销 = 滚动周期；消费者忠诚度 = 严格按年度计算身份的周期。
• 人工服务：B2B = PAM 覆盖与 QBR；B2C = 端到端自助自动化。
• 可测试性：联盟营销或消费者层级体系可以在大规模用户群中进行 A/B 测试；B2B 层级变更需要协商、受关系影响，并通过合作伙伴顾问委员会进行沟通——应先建模并试点，而不是直接调整。

完整对比及真实供应商案例，请参阅 references/worked-examples.md。

调用示例

• “所有合作伙伴都享有统一的 20% 折扣，而顶级合作伙伴在问他们还能获得什么。请设计层级体系——共 160 家合作伙伴。”
• “我们的最高层级过于拥挤，而且从未执行过降级。请修正标准并制定迁移计划。”
• “我们有 25 家没有交易的 ISV 合作伙伴，无法达到任何层级的资格。请为他们制定合适的标准。”

参考资料

• 有关标准选项、积分模型权重、衡量周期、可操控性检查，以及非交易型合作伙伴的标准，请参阅 references/tier-criteria.md。
• 有关包含实际成本的权益选项、捆绑定价，以及缺乏差异化的层级体系反面示例，请参阅 references/tier-benefits.md。
• 有关层级数量、回测、目标分布、评估频率、晋级/降级、宽限期、祖父条款、申诉及层级通胀控制，请参阅 references/distribution-and-cadence.md。
• 有关对 2023-2026 年真实供应商结构的拆解、一个完整的层级结构案例及 B2C 对比，请参阅 references/worked-examples.md。
• 如需从头设计完整的合作伙伴计划，请参阅 mbfinotti/partnerships-skills@partner-channel-program——此技能仅用于优化计划中的层级部分。
• 有关单个合作伙伴记分卡、QBR 结构及表现不佳的触发条件，请参阅 mbfinotti/partnerships-skills@partner-performance。
• 有关面向专业联盟营销者的佣金支付层级，请参阅 mbfinotti/partnerships-skills@affiliate-commission-structure——这是与渠道分层不同的专业领域。