partner-channel-program

合作伙伴渠道计划

从零开始设计 B2B 合作伙伴／渠道计划的整体架构。本技能负责架构设计：判断是否应该设立计划、需要哪些结构性组成部分——合作模式、层级、经济预算框架、治理机制、发展周期——以及这些部分如何相互配合，然后将各组成部分的详细设计交给专门技能处理（参见 Reference）。

业界记录最充分的失败原因是结构性的，而非战术性的：推出计划是为了弥补行不通的直销模式。合作伙伴会放大有效的销售模式，但无法修复失效的模式。以下流程先制定策略，再设计结构，并允许在评估关卡得出“暂不推进”的结论。

访谈

设计之前先提问。每条消息只问一个问题；尽可能提供多项选择答案。只有在用户已给出答案时才跳过问题。

• 业务是 B2B 还是 B2C？对于消费类业务（经销商、特许经营、品牌大使模式），设计确实会有所不同——参见 references/b2b-b2c-contrast.md。
• 合作伙伴将要销售或影响的产品，其 ACV 或价格是多少？
• 直销模式是否已具备可复制性，且已验证产品与市场契合？依据是什么？
• 毛利率是多少，其中多少可用于支付合作伙伴报酬？
• 是否已经有非正式合作伙伴——为客户提供服务的代理机构、集成商、顾问——或者是否有人主动联系你们洽谈合作？
• 谁负责计划的日常运营？此人向谁汇报？
• 已承诺哪些资源：专职人力、预算，以及具名的执行发起人？
• 对于合作伙伴参与的交易，目前如何向直销代表支付报酬——不受影响、受到惩罚，还是尚无明确规定？
• 成功意味着什么？首个由合作伙伴促成的成果必须在什么日期前落地？请说明指标（收入占比、销售管道、覆盖范围）、日期，以及届时由谁评判。
• 你们今年想要一次性成果，还是希望打造能持续增值的资产？两种答案都合理，但会决定采用不同的合作模式。
• 根据现有资源，本计划必须控制在怎样的工作量上限内——负责人每周可投入多少小时、是否根本无法承担固定编制人员，以及设计中有多少部分必须保持可调整？

最后三项答案会重新排列第 4 步的合作模式选项——将这些答案带入该步骤，而不是重复提问：

• 若截止日期在两个季度内，则排除经销商和服务型 SI：这两种模式都无法如此快速地产生收入。
• 若目标是持续增值，则优先考虑技术合作和经销覆盖。
• 若今年就需要达成目标，则优先考虑转介。
• 若无法承担固定编制人员，则再次排除经销商和服务型 SI；若团队只有一人，则采用转介，最多再加一项集成。

工作流程

1. 完成访谈；收集评估关卡和架构设计所需的所有答案。

2. 应用准备度评估关卡。以下任何一项均为否决条件，出现任意一项，诚实的答案就是“暂不推进”：

   • 直销模式不具备可复制性，或期望通过合作伙伴关系解决增长问题。
   • ACV 过低，无法支撑人力投入较多的合作伙伴工作（极低 ACV 至多适合转介模式——经销商／SI 模式需要高得多的 ACV）。
   • 毛利率不足以支付合作伙伴利润分成。
   • 没有具名的执行发起人。

   说明原因、必须改变的事项，以及仍然适用的较轻量模式（如有），然后停止。完整评估关卡：references/readiness-and-failure-modes.md。

3. 在提出任何供应商要求之前，先写明合作伙伴的价值主张——用一句话回答“合作伙伴能从中得到什么”，并说明背后的经济模式。项目必须先提供（清晰的盈利方式、培训、交易保护、供应商支持），才能提出要求（专职代表、认证、严格遵守注册流程）。将其记录为“合作伙伴假设”——用 1-2 页说明目标合作伙伴类型、他们参与的原因以及预期收益——并在据此开展任何工作之前，先与 2-3 家真实的潜在合作伙伴验证。

4. 在研究合作伙伴画像之前，先从以下菜单中选择合作伙伴模式，按单位投入所带来的价值排序——而不是按价值上限，也不是按成本从低到高排序。向用户明确说出排序，然后选择最低可行组合，而不是囊括所有模式。这些维度彼此不一致，因此要全部审视：

   • 效率：推荐 > 技术 > 服务-SI > 转售
   • 投入：转售 > 服务-SI > 技术 > 推荐
   • 价值上限：转售 > 服务-SI > 技术 > 推荐
   • 见效时间：转售 > 技术 > 服务-SI > 推荐
   • 合规成本：转售 > 服务-SI > 技术 == 推荐（平局的理由：技术模式和推荐模式都不会产生合同规定的利润承诺或第三方交付责任，而且都可以用一段条款终止）

   各种模式及其权衡：

   • 推荐——几乎无需持续投入：制定佣金规则，提供链接或表单，并设置一个跟踪字段。可将潜在客户介绍给你已经知道如何销售的客户。价值上限低，不增加交付能力。除非下方某项限制将其排除，否则默认作为第一步。
   • 技术——需要几周工程投入，之后还需持续维护，且不支付利润分成。带来持久的合作基础：即使上线推广结束，集成仍能持续带来联合客户并提高留存率。在轻量模式中，这是最慢产生首笔收入的方式，因此需要访谈中确认的复利目标来证明其合理性。
   • 服务-SI——需要准备赋能内容、设定交付质量标准，并持续投入合作伙伴经理的时间。提供无需自行招聘的交付能力，并推动因实施问题而停滞的交易。只有在实施确实构成购买障碍时才值得投入；否则，这只是徒劳的协调工作。
   • 转售——一项需要持续投入的工作：协议、利润表、订单流程、交易注册、冲突政策、直销代表的薪酬中立安排，以及转售条款的法务签批。扩大覆盖范围——进入你无法直接触达的细分市场和地理区域——价值上限最高，但所需时间也最长。最难撤回：要结束合作，就得重新签署已签订的协议。

   这种排序会排除什么：转售和服务-SI。两者的价值上限都最高，投入也都最大，因此按比例排序时，每轮都会排在最后。如果项目始终只遵循效率这一项，就会永远停留在推荐模式：无法直接触达的市场覆盖范围和能推动停滞实施的交付能力，都不会纳入项目。

   如果项目的明确目标是触达指定细分市场或地理区域，且已为持续人员编制提供资金，就将转售排在轻量模式之前。如果实施问题被明确列为交易失败或停滞的原因，就将服务-SI 排在前面，而不是仅仅因为存在 SI 关系就这么做。不能仅凭雄心提升任何一种模式的优先级，也不能让它们在本就不利于胜出的比例排序中胜出。

   限制条件会直接删去选项，而不是降低其优先级。被删去的模式及其重新启用条件，应写在规格说明的“模式”一行中：

   • 如果 ACV 不足以覆盖合作伙伴自身的销售成本，就直接排除转售和服务-SI。
   • 如果因合同或技术原因无法转售产品，就排除转售。
   • 如果没有资金支持持续人员编制，就同时排除两者。 这个顺序是默认做法，不是铁律：它会因具体情境和执行者而变化。在展示之前，应根据你对该用户已有的了解重新排序：
   • 如果一家代理商或系统集成商（SI）已经在为其客户提供服务，就应将服务型 SI 放在首位，因为招募工作已经完成。
   • 如果已存在平台与市场的合作关系，出于同样的原因，应将技术型合作放在首位。
   • 如果团队只有一人，就将选项缩减为推荐合作，加上最多一种集成。

   使用“构建／销售／服务”类型划分和“影响／交易／留存”视角，为边界候选项排序。理想合作伙伴画像的详细信息留待选定合作模式后再制定；正式的量化评分画像则等到招募规模有此需求时再进行。参见 references/decision-sequence-and-frameworks.md。

5. 在设计任何层级之前，先决定是否要分级，以及差异化的目的是什么。只有当层级边界处存在可衡量的变化时，层级才有意义；标准和权益差异必须配套设计：

   • 有标准却没有权益差异，就成了无人参与的排行榜。
   • 有权益差异却没有标准，就是披着品牌外衣的偏袒。

   将层级数量、标准和权益设计交给 mbfinotti/partnerships-skills@partner-tiering；这三项都由它负责：在此只决定是否分级，以及差异化的目的是什么。对于规模较小或新设的计划，两个层级通常是合适的选择；四个层级通常只是虚荣指标，但该技能会根据合作伙伴群体规模确定层级数量。不要在此预先确定一个它会重新推导的数字，否则已签署的合作伙伴协议就得重新签订。

   也不要在此按效率对层级数量排序，因为本页上的第二套排序会与该技能根据你尚不知道的群体规模推导出的排序相矛盾。

6. 设定整个计划的经济边界：合作伙伴利润必须来自合作伙伴替你承担的成本（“如果你为本来就会由你完成的工作支付利润，那你什么也没买到”），且计划总成本必须控制在毛利以内。在此处而不是之后，抵消直销代表在合作伙伴交易中的薪酬影响。

   将单个合作伙伴的建模工作交给 mbfinotti/partnerships-skills@partner-economics。参见 references/economics-and-benchmarks.md。

7. 完善治理：指定负责人和汇报关系，并在首个销售合作伙伴签约前制定交易登记／渠道冲突政策，而不是等到首次发生争议后再制定。实践者主张，在早期阶段由负责人向 CEO 汇报，因为将该职能置于销售主管之下，会让一个需要 2-3 年才能成熟的职能受季度周期的限制。将规则细节交由联合销售和冲突技能处理（参见参考资料）。

8. 在设计时设定成功周期：第 1 年只根据领先指标评估（已激活的合作伙伴、已登记的首批交易、从启动到首笔交易的时间），第 2 年根据合作伙伴带来的销售线索评估，第 3 年根据实质性的收入占比评估。该领域最常见的结构性错误，是用直接销售的 30-90 天周期来评估渠道；周期决策是架构的一部分，现在就要做出。将衡量体系本身交由 mbfinotti/partnerships-skills@partner-performance 处理。

9. 按部分呈现架构——每部分提供 2-3 种候选方案，说明各自的权衡并给出明确建议——并在进入下一部分前请用户确认当前部分。若适合采用该行业自身的协作形式，则按照该文件中的排名顺序提出——每小时协调成本所能换来的证据量，从合作伙伴假设验证开始：references/collaboration-formats.md。

10. 每部分都获得明确批准后，生成《项目架构规范》（见下一节），并根据通过门槛进行检查。持续迭代，直到通过；如果没有任何架构通过，则建议不要启动并记录原因。

11. 如果你的运行环境有持久记忆功能，请记住已批准架构的关键决策、经济范围和关卡答案——后续的战术运行（分层、赋能、绩效）应以此为起点，而不是重新访谈。

项目架构规范

每个从零开始的项目都要交付这份成果——一份用户可交给财务、法务和销售团队的决策记录：

PROGRAM ARCHITECTURE - <company>, <date>
Readiness    : direct-motion evidence, ACV band, gross-margin headroom, named executive sponsor
Partner value: one-sentence partner value proposition + validation record (2-3 named
               prospective partners, what each confirmed or contradicted)
Motions      : which of referral / reseller / services-SI / technology, why each, and the
               efficiency order they were chosen in after re-ranking for this user; motions
               deleted by a constraint, and the trigger that would reopen each
First cohort : target size (~10), qualification bar (capability, capacity, coverage,
               commitment), activation milestone per partner
Tiers        : whether to tier + what differentiation is for; count set by partner-tiering,
               or "no tiers - revisit
               when <condition>"
Economics    : compensation shape per motion, program cost envelope vs gross margin,
               direct-rep comp neutrality statement
Governance   : owner + reporting line, deal-registration/conflict policy status
               (written before first selling partner)
Horizon      : year-1 leading indicators, year-2 pipeline expectation, year-3 revenue
               share target; review cadence and who judges

规范本身有三条规则：

• 每一行都要说明理由。“设置两个层级，因为唯一的运作方式是引荐，且在第三个层级边界上没有任何可衡量的变化”这种表述便于审核；只给出层级数量则不行。
• **验证记录不可省略。**从未与真实潜在合作伙伴接触过的合作伙伴价值主张只是猜测；规范必须写明向哪些对象进行了测试，以及结果如何。
• **规范有通过门槛。**经济模型必须符合毛利要求，合作伙伴价值主张必须经受过与 2-3 个真实潜在合作伙伴的接触检验，并且必须有指定的高管赞助人。持续调整运作方式、层级或经济模型，直到三项要求全部满足——如果没有任何架构通过，则建议不要启动。

诊断现有项目

如果用户带来的是一个正在运行的项目，而不是一张白纸（“我们有 200 个合作伙伴，却没有收入”），应先诊断结构，再讨论策略。以下几行通常会同时适用；此表用于查找，因此修复顺序会在此处说明，而不是根据行的顺序推断：

• 效率：调整时间预期 > 冲突与注册政策 > 激活优先于招募 > 资金机制 > 薪酬中立 > 重建层级
• 努力：薪酬中立 > 重建层级 > 激活优先于招募 > 冲突与注册政策 > 资金机制 > 调整时间预期
• 价值：薪酬中立 > 激活优先于招募 > 冲突与注册政策 > 重建层级 > 资金机制 > 调整时间预期
• 合规成本：重建层级 == 薪酬中立 > 冲突与注册政策 > 其他所有项（两者优先级相同的理由：每项都会重新开启一份已签署的文件——一种情况下是合作伙伴协议，另一种情况下是销售代表薪酬计划——而且两者都无法在没有第二次修订的情况下撤销）

调整时间预期应优先，因为只需一次领导层沟通，就能避免项目在其他修复措施落实前被取消。薪酬中立是价值最高的修复措施，但仍不是第一项：这属于年中薪酬调整，耗时长，且政治成本高。应根据用户的情况重新排序——如果项目的薪酬已经中立，就去掉该项；如果只有一个层级，就去掉重建层级。

症状	首先应检查的结构性原因
已签约合作伙伴众多，但活跃者很少	追踪的是招募，而非激活；从未验证合作伙伴的价值主张
合作伙伴对层级晋升置之不理	层级只是表面文章——跨越层级边界时没有任何可衡量的变化
项目资金无人申领	市场开发资金的设计与商机注册相互割裂，申领流程繁琐
合作伙伴不再注册商机	供应商与已注册商机争抢（自营客户）；冲突政策是在事后才制定的
直销代表阻挠合作伙伴商机	薪酬机制惩罚合作伙伴参与——这是架构决策问题，而非行为问题
项目在第 6 个月“失败”	时间预期有误：按照直销周期进行评估；应将预期调整为第 1/2/3 年的阶梯目标
合作伙伴经理不堪重负	管理的合作伙伴数量远超可持续范围；项目在扩大招募之前就扩大了规模，却没有先做好激活

完整的失败模式目录，包含修复方案和一个反面示例：references/readiness-and-failure-modes.md。

B2B 与 B2C

两者完全相同的方面：

• 扩大招募之前，先对首批小规模合作伙伴进行深入筛选。
• 设定任何数字前，先从合作伙伴的角度测算经济效益。
• 能吸引合作伙伴的是有吸引力的经济方案，而不是营销。

真正不同的方面：

• 特许经营的法律文件和独家区域。
• 首日文档的详尽程度：特许经营需要详尽文档，而 B2B SaaS 应有意保持精简。
• 消费者项目的销售点归因，与 B2B 数月期销售管道归因之间的差异。
• 面向消费者的经销商特有的一线关注度和易发现性要求。

详情和可靠性标记：references/b2b-b2c-contrast.md。

调用示例

• “我们收到了合作伙伴的主动咨询，但还没有正式项目。我们现在适合招募合作伙伴吗？如果适合，项目应该是什么样的？”
• “为一款 ACV 为 $12K 的产品设计推荐计划——我们试过经销商，但利润率怎么算都行不通。”
• “我们的合作伙伴项目有没人能满足的要求，也有没人想要的权益。请从准备度门槛开始，重建整个结构。”

参考资料

• 请参阅 references/decision-sequence-and-frameworks.md，了解完整的决策流程、按 ACV 分档的推进方式选择，以及标注真实状态的具名框架。
• 请参阅 references/readiness-and-failure-modes.md，了解完整的就绪门槛和故障模式目录。
• 请参阅 references/collaboration-formats.md，了解渠道专业人士如何实际协作研讨项目设计。
• 请参阅 references/economics-and-benchmarks.md，了解经济性范围评估方法，以及带有可靠性标记的基准区间。
• 请参阅 references/b2b-b2c-contrast.md，了解经销商、特许经营商和品牌大使之间的对比。
• 请参阅 mbfinotti/partnerships-skills@co-selling-strategy，了解交易注册规则、业绩分成和合作规则。
• 请参阅 mbfinotti/partnerships-skills@partner-channel-conflict，了解直销与合作伙伴渠道之间的冲突解决方法。