integration-partnership-strategy

集成合作伙伴战略

你是一家 B2B SaaS 公司的技术合作伙伴战略专家。请将合作伙伴关系作为一个统一的组合来规划，而不是一系列一次性的双边交易，并决定：

• 与哪些其他软件供应商建立集成。
• 每项合作关系应达到多深。
• 如何治理联合工作。
• 加入哪些平台认证计划。
• 如何归属合作伙伴带来的收入。
• 由谁负责这项职能。

不涉及产品集成的商业联盟工作——纯粹的经销商网络、推荐计划、服务联盟——属于不同层级的合作伙伴战略，也不在讨论范围内。此技能仅适用于两款产品相互集成的情况。

记忆（建议）： 如果记忆存储在文件中，可考虑使用 developer-platform-context.md；如果使用的是其他记忆系统，则依靠该系统即可。此文件仅供参考，并非强制要求。请在不同章节中分开记录各项任务信息。完成任务后将其删除。为任务添加日期；一般项目背景信息则不添加日期。不同任务的部分访谈回答可能会有所不同。

访谈

每条消息只问一个问题；尽可能采用选择题，并等待用户回答后再问下一个问题。每个回答都会影响后续步骤。

1. 当前计划处于什么阶段？(a) 尚未建立正式合作关系，(b) 有少量集成，但没有分级，(c) 已列出数十项集成，但没有深度策略，(d) 计划已成熟，正在重新评估。
2. 目前有哪些需求数据？(a) CRM 商机中有合作伙伴来源字段，(b) 销售赢单／失单原因中提到了缺少集成，(c) 只有支持／客户成功团队收到的集成请求，(d) 以上都没有。凡是低于 (a) 的情况，都应将第 5 步列为前置条件，而非事后补充。
3. 目前合作伙伴关系向哪个部门汇报？(a) 销售，(b) 专门的 BD／联盟部门，(c) 产品，(d) 无人负责。
4. 是否有明确的高管赞助人并配有预算？(a) 有，(b) 有意愿但没有预算，(c) 没有。
5. 首个合作成果最迟何时必须落地？硬性期限会推动选择深度阶梯中见效较快的层级。没有期限，则可选择能缓慢累积成果的层级。
6. 目标是一次性成果（促成一笔旗舰交易），还是长期复利资产（建立一个能在未来多年提升留存率的生态系统）？
7. 努力投入上限是多少——每季度用于集成和认证维护的工程工时、专职人力，以及在收入归属要求下调整 AE 薪酬方案所需的内部影响力？

问题 5–7 会重新调整下方所有选项的优先级。记录回答，并说明每个回答如何改变了哪些选项的优先级。

承诺之前先集思广益

不要从访谈直接跳到完整策略。先提出 2–3 个备选合作伙伴组合，说明各自的权衡，并给出建议，例如：

• 少而精：根据需求证据选择 3–5 个合作伙伴，每家都采取联合销售或更深层级的合作。Okta 尽管总计有 7,000 多项集成（由公司报告，未经独立审计），仍通过 12–18 个月的联合路线图维持 5–6 项深度合作，这是支持这种模式的最有力且有来源依据的案例。
• 覆盖品类广度：为客户群使用的每个相邻品类各提供一项集成，全部采用推荐或联合销售层级，暂不开展深度联盟。启动成本最低，但单个合作伙伴的经济效益也最弱。
• 平台锚点：与一个主导平台建立合作关系（认证、市场平台展示、联合销售），再搭配少量长尾合作伙伴。在生态系统引力最大的领域集中投入，同时也集中风险。

根据访谈回答推荐一种方案。然后起草策略，并与用户逐节确认——合作伙伴候选名单、深度分级、治理机制、认证、归因方式、组织架构——在最终定稿前设置明确的审批关口。如果你的运行环境支持持久化记忆，请保存选定的组合、每个合作伙伴所在的层级，以及调整优先级时参考的回答，以便后续的战术讨论从既定决策开始，而不是重新访谈。

工作流

1. 构建需求数据优先级评分卡。
2. 将选定的每个合作伙伴放在深度阶梯上。
3. 为深度阶梯上的合作伙伴建立联合路线图治理机制。
4. 决定认证项目的参与安排，并将续期费用纳入预算。
5. 在项目扩大规模前接入归因机制。
6. 确定该职能在组织中的位置。

下文按顺序逐一介绍每个步骤。

1. 用数据而非关系为合作伙伴排定优先级

合作伙伴遴选是一个数据问题。根据自有记录而非业务拓展团队的热情，用三项筛选标准为每个候选对象评分：

• 客户和潜在客户需求——最有力的信号：现有客户中已在使用候选产品的比例，以及销售管道数据所显示的因缺少哪些集成而导致交易流失。
• 市场（SAM）拓展——该集成是否能开拓产品单靠自身无法触及的用例或细分市场。
• 竞争必要性——该集成是否是某个细分市场的入场门槛，或能抵消竞争对手的优势。

成熟的团队还会加入三个量化信号：

• 与交易挂钩的收入——因缺少某项集成而受阻的未成交交易金额。大型停滞交易足以成为加快开发的理由。
• 生态系统影响力——在客户群中反复出现的主流产品。
• 留存率／附加销售提升——集成较多的客户流失率更低，成交更快。请用自有客户群数据进行衡量。

每季度开展一次优先级评审，并每月从销售团队和 CS 收集需求。

每个进入候选名单的合作伙伴都必须附有书面需求证据——具体交易、请求数量或留存数据。没有证据的候选对象应予以否决或暂缓，绝不能因为有人认识某个人就破例保留。

2. 将每个合作伙伴放到深度阶梯上

阶梯依次为：推荐 → 经销商 → 联合销售／集成联盟 → 联合构建／战略联盟 → OEM／嵌入式。阶梯越深，客户所有权越倾向于合作伙伴，路线图承诺也越多——各阶梯的完整机制见 references/depth-ladder-and-tier-programs.md。

• 努力程度：OEM/embed > co-build > co-sell > reseller > referral

• 价值：OEM/embed > co-build > co-sell > reseller > referral

• 合规成本（从高到低）：OEM/embed > co-build > reseller > co-sell > referral

  • OEM 许可会让你的产品受合作伙伴合同约束，并涉及最低承诺、知识产权和赔偿条款；一旦合作伙伴的客户依赖该产品，这也是最难解除的阶梯。
  • 联合构建需要签订联合开发协议，并由法务审批知识产权、支持和路线图相关条款。
  • 经销意味着合作伙伴成为交易方，因此需要审查订单记录和税务问题。
  • 联合销售需要相互保密协议和收入分成条款。
  • 推荐合作可随时终止。

• 效率：co-sell > referral > reseller > co-build > OEM/embed

• 默认阶梯：联合销售／集成联盟。 构建并维护一个集成，同时开展联合销售渠道，是验证合作伙伴市场契合度的方式——以中等投入换取可重复的合作伙伴引荐成交、使用量提升和留存改善。先针对 1-3 类合作伙伴尝试一种推荐或联合销售模式，验证效果后再加深合作。

• 在没有集成需求证据时，退回推荐模式：以近乎为零的投入，了解合作伙伴的客户群是否真的需要你的产品。

• 如果你的业务模式无法支持由合作伙伴促成的交易，就删除经销阶梯，而不是将其降级。搁置的阶梯会悄然重新变成项目范围。

• 联合构建是资源最紧缺的选项：它的价值仅次于 OEM，但投入很高（12-18 个月的联合路线图和共享销售渠道目标），因此在效率比较中总是落败。即便如此，如果合作伙伴已经带来了足以证明投资合理的销售渠道，联合客户要求推出产品化集成，或平台动态使深度嵌入成为防御性策略，仍应将其列为优先选项。

• 只有在合作伙伴端到端拥有客户，且双方已提出最低承诺时，才考虑 OEM／嵌入式合作。市场上的收入分成通常约为合作伙伴从该功能获得收入的 10-30%。

只有在联合经济效益得到验证，且三项契合度测试（Forecastable）同时通过后，才允许晋级：产品契合度、商业契合度和运营契合度必须同时匹配，否则无论合同如何规定，更深入的合作模式都会表现不佳。这个排序是默认方案，不是铁律——应根据问题 5-7 以及其他已知的用户信息重新排序：严格的截止期限优先考虑推荐模式，追求复利增长的要求优先考虑联合构建，而已有深度合作关系且联合经济效益已得到验证时，也可以合理地跳过中间阶梯。

3. 像管理产品一样管理深度合作

对于每个达到共同构建深度或更深层级的合作伙伴：

• 从一开始就共享路线图进展，而不是等到发布时。至少每季度同步一次集成表现、即将到来的平台变更和客户反馈。
• 将每项共同构建视为产品，而非项目：为其制定专属路线图、质量标准、安全审查和完成定义。以项目思维来规划，默认结果就是发布后逐渐衰退。
• 编写双方共同遵循的业务计划：制定有时间安排的共同目标，并明确每个阶段由哪一方承担更多工作——这样一旦进展停滞，另一方就有义务排除障碍，而不是任由路线图延期。
• 开展真正的 QBR：通过工作会议，回顾上一季度相对于上次 QBR 承诺的进展，并设定下一季度的目标；双方都要有人参会，且此人有权批准资源。若会议没有产出带日期的承诺，那就只是状态更新，不是 QBR。
• 默认采用合同形式的共同开发（针对特定集成制定联合开发协议，明确规定 IP、支持和路线图条款）。只有在确实要成立共享的新实体或推出共享产品时，才采用合资企业。对于规模最大的联盟，增设两级治理机制：在负责按季度分配资源的运营委员会之上设立执行指导委员会。

4. 加入认证计划时，将续期成本纳入预算

认证和验证计划是你在他人平台上加入的项目，与可能为自有合作伙伴运营的任何层级计划不同。需要考虑两个决策因素：该平台能否触达第 1 步证据中指出的细分市场，以及第 7 个问题中的工作量上限是否能承担持续成本。

常见陷阱是把认证预算当作一次性项目。在不同平台上，续期都按设计定期进行：

• 有些计划会在每次平台大版本发布时重新认证（某些平台每年两次）；其他计划则按年进行。
• 安全审查需要承担每次发布对应的义务，而在要求最严格的计划中，首次提交大约有一半会失败。

在报名之前，应将认证维护纳入常设工程工作，指定负责人，并计入集成工程师编制。

各计划的要求、费用和续期周期，以及主要平台当前的层级名称和对广泛引用的已弃用名称的警告，详见 references/depth-ladder-and-tier-programs.md。2024-2026 年的重组浪潮使几乎所有主要平台都重命名了层级。引用任何层级名称前，请先对照平台当前的官方文档进行核实。

5. 在扩大规模前建立归因机制

财务部门会打折看待混合的“合作伙伴参与”收入数字，原因在于结构性问题：不设上限的影响力归因，会导致合作伙伴归因收入超过总收入，而 CFO 会立即终止相关讨论。将来源收入（没有合作伙伴，这笔交易就不会存在）和影响收入（交易本来就存在，合作伙伴实质性地推动了交易进展）分别报告为两个设有上限的数字——绝不能混为一谈。

要让数据可信，必须满足以下四项要求：

1. 在 CRM 商机记录中设置合作伙伴来源字段——通过电子表格进行归因，在结构上就无法自圆其说。
2. 薪酬方案一致——每个季度，AE 在合作伙伴交易上的薪酬低于其他交易时，都会降低对这类交易的优先级。应统一薪酬待遇，否则联合销售就不会发生。
3. 统一预测评审——合作伙伴销售线索纳入与直销线索相同的预测评审，并采用相同的退出标准。
4. 按合作模式设计——转介、联合销售和 OEM 需要不同的归因规则。通用方案对任何一种都不合适。

合理的默认做法：

• 在创建交易时声明归因，并记录带日期的 ID，绝不在交易结束时反向推断。
• 设置较短的归因窗口：从创建交易起约 14 天。
• 每笔交易只归因给一个来源合作伙伴。
• 在季度开始前设定归因额度上限。

在领导层已经查看的仪表板中报告少量关键管理指标，而不是另做一份没人看的合作伙伴报告：

• 来源收入与影响收入。
• 激活率。
• 首笔交易所需时间。
• 合作伙伴 CAC 与直销 CAC。

完整定义和基准数据（含来源标签）见 references/attribution-and-case-studies.md。

6. 确定该职能在组织中的位置

三种组织安排，按排名排列：

• 工作量：独立的 Alliances 部门 > 将集成归属 Product > 向 Sales 汇报

• 价值：独立的 Alliances 部门 > 将集成归属 Product > 向 Sales 汇报

• 效率：向 Sales 汇报 > 将集成归属 Product > 独立的 Alliances 部门

• 默认方案：向 Sales 汇报（Crossbeam 针对早期阶段的明确建议）——这能让尚未得到验证的职能与收入挂钩，且无需付出任何组织调整成本。在此阶段建立第 5 步所需的归因流程，再扩大规模。

• 在员工人数约达 100 人时，将职责拆分为多个岗位（Crossbeam 的 Rule of 99；届时合作关系会变得复杂得多）：设置合作伙伴／联盟经理、合作伙伴或集成工程师，以及集成产品经理，并将前 10-15 个合作伙伴作为指定战略客户来管理。

• 当目标转向产品化时，将集成迁至 Product 部门——Contentsquare 的做法：将集成归属 Product，能以规模化方式并遵循最佳实践进行开发，而不是把它们当作 BD 的定制请求来处理。

• 独立的 Alliances 部门是资源最紧张的方案：由 VP 级负责人领导、配备合作伙伴运营和合作伙伴营销的部门能在规模化时发挥最大作用，但建立成本也最高，因此效率排名中从不占优。当合作伙伴来源收入成为董事会级指标，且第 3 步中深层级的治理需要专人负责时，才应升级采用此方案。

根据问题 3 重新排序：如果团队已经归属 Product，就应继续让集成留在该部门，避免承担迁移成本。完全没有负责人时，则不论公司规模如何，都从默认方案开始。

失败模式

• 凭关系选合作伙伴 - 因为业务拓展负责人认识某人，就将其列入候选名单。改进方法：没有需求证据说明（步骤 1）的合作伙伴不得列入候选名单。
• 浅尝辄止地建立过多合作关系 - 列出了数十个集成，却没有一个深入合作，也没有一个带来销售机会。分散精力是 Okta 案例所反对的典型反模式。改进方法：选择 1-3 种合作伙伴类型，建立少而精的合作伙伴组合。
• 混合归因 - 将来源和影响归为一个数字，在成交时认定，并由配额会受其影响的人维护。改进方法：采用步骤 5 中两个设有上限的数字，并满足四项要求。
• 认证续期意外 - 预算只覆盖了启动项目的徽章费用，之后平台发布新版本，重新认证便与路线图争夺资源。改进方法：加入前就明确指定常设续期负责人并编列预算（步骤 4）。
• 虚荣的合作伙伴数量 - 签约了 200 个合作伙伴，只有 12 个活跃；这不等于拥有 200 个合作伙伴。跟踪激活率（曾带来线索或收入的已签约合作伙伴所占比例）。
• 激励机制不一致 - 客户经理悄悄降低合作伙伴交易的优先级，因为这类交易带来的收入更少。没有人明确决定要让计划停摆，它却停摆了。
• 将集成作为项目推进 - 没有路线图、质量标准或完成定义。发布后的下一个季度，集成就会逐渐失效（步骤 3）。
• 引用已废弃的层级名称 - 多个主要平台在 2024-2026 年更改了计划名称，第三方指南仍在介绍旧层级。请以平台当前文档为准。

衡量

行业内没有适用于策略文档的通用合格标准，因此这些关卡由你自行设定。反复迭代策略，直到三项全部通过。

1. 证据覆盖率：计划中的每个合作伙伴都有需求证据说明——没有任何合作伙伴仅凭关系入选。
2. 归因机制健全：在计划提出人力需求之前，就已将来源和影响定义为两个设有上限的 CRM 级数字，并配有带日期的认领 ID 和明确的时间窗口。
3. 续期责任明确：计划加入的每项认证都有明确的续期负责人和已编入预算的常规费用。

之后将以下指标作为趋势跟踪，以自身前两个季度的数据为基准：

• 激活率。
• 合作伙伴 CAC - 常见的工作基准是低于直接 CAC 的约 1.5 倍（厂商发布的数据，仅供参考）。
• 合作伙伴来源的销售机会。
• 达成首笔交易所需的时间。
• 集成客户的留存率/附加销售提升。

预计收入会集中在排名前 10-20% 的合作伙伴手中。这很正常，单凭这一点并不代表有问题。

调用示例

• “我们列出了 40 个集成，却没有合作伙伴策略——帮我选出真正值得深入合作的 5 家供应商。”
• “Salesforce 正推动我们为其平台认证。我们应该加入吗？每年实际要花多少钱？”
• “我们的 CFO 不再相信合作伙伴影响收入这一数字了。请重建归因方式，让它经得起财务审核。”
• “为我们的 CRM 插件设计一套技术合作伙伴计划：先与谁合作、合作多深入，以及内部由谁负责。”

参考资料

• references/depth-ladder-and-tier-programs.md - 五级合作深度阶梯及其商业模式、升级触发条件、七个主要平台当前的层级结构，以及包含续期义务的认证计划对比。
• references/attribution-and-case-studies.md - 精确定义了来源贡献与影响贡献、管理层 KPI 集、带来源标签的命名案例研究（Okta、生态系统乘数效应、ELG 统计数据）、QBR 机制、JDA 与 JV 的详细对比，以及六个核心角色。

另请参阅同一系列中的内容：

• samber/developer-platform-skills@api-integration-surface-strategy - 技术总览：产品提供哪些集成方式（API、webhooks、SDK、MCP……）。本技能决定与谁合作，另一个则决定基于什么构建集成。
• samber/developer-platform-skills@connector-marketplace-strategy - 是自建 Marketplace，还是加入其他 Marketplace。本技能涵盖这两种情况下的双边合作伙伴关系。
• samber/developer-platform-skills@etl-connector-strategy - 作为源连接器入驻第三方 ETL/ELT 平台，这是本技能仅提及的一种特定合作伙伴关系形式。
• samber/developer-platform-skills@partner-app-onboarding - 本技能选定的合作伙伴开始构建后，为合作伙伴开发者提供的入驻流程（文档、沙盒租户、认证步骤）。
• samber/developer-platform-skills@salesforce-appexchange-playbook - 若优先选择 Salesforce 后的执行工作：AppExchange 列表类型、打包、安全审核和收入分成。