partnerships-architect

partnerships-architect

目的

当潜在合作伙伴出现时，帮助合作负责人、业务拓展负责人和创始人兼 CEO 回答四个问题：

1. 这是真正的合作伙伴，还是只想获得优惠条款，却没有独立需求？
2. 我们应该将其划入哪个层级？（推荐 / 转售 / OEM / SI-咨询 / 战略联盟）
3. 怎样制定 90 天联合 GTM 计划，证明合作有效？
4. 什么样的收入分成在经济上合理？合作达到什么程度后，收益会超过直销？

此技能会给出层级判断、GTM 计划和收入分成区间，并明确列出终止标准。它不会签署合作协议。运行此技能后，由人来做决定。

适用场景

• 潜在合作伙伴主动联系，并要求获得转售 / OEM /“战略”条款
• 你正在设计新的合作伙伴计划层级结构
• 你正在评估表现不佳的现有合作关系，需要决定：调整层级、重构 GTM，还是终止合作
• 大品牌希望建立“战略联盟”，你需要验证这是否真实，而非供应商锁定的表面文章
• 咨询公司或 SI 希望通过你的产品获得服务收入分成
• 平台供应商提供 OEM / 白标方案，你需要测算相关收益
• 你怀疑所谓“合作伙伴带来的”交易，其实是从自有销售管道中抽取利润

请勿用于：

• 技术演示和 POC → business-growth/sales-engineer
• 评估现有渠道的服务成本和 ROI → 同级技能 channel-economics
• 全公司的收入战略 → c-level-advisor/cro-advisor
• 通过收购而非合作来获取公司 → c-level-advisor/ma-playbook
• 在已签署的合作伙伴合同中审批单笔交易折扣 → deal-desk

工作流程

步骤 1 — 信息收集（≈ 20 分钟）

填写 assets/partnership_intake_template.md。记录：partner_name、partner_type、独立需求的证据（他们带来的具名客户、终端客户关系、销售团队规模）、战略价值（地域 / 产品 / 品牌 / 渠道经济效益），以及他们承诺提供的资源（联合营销预算、专属人力、认证、销售目标）。

如果无法如实填写信息收集模板，说明潜在合作伙伴尚未展现足够的实质内容，无法进行评估。停止流程并联系对方。

步骤 2 — 划分层级

运行 scripts/partner_tier_classifier.py --input intake.json --profile saas --output markdown。 输出会将合作伙伴划入 5 个层级之一：推荐 / 转售 / OEM / SI-咨询 / 战略，并设有确定性门槛。划入战略层级必须满足：named_accounts ≥ 5，且承诺多年合作并提供专属资源。此技能会给出判定理由和终止标准。

步骤 3 — 制定联合 GTM 计划

运行 scripts/joint_gtm_planner.py --input gtm.json --profile saas --output markdown。 输出内容包括：90 天计划，涵盖发布前里程碑（培训、认证、材料）、启动方式（目标客户、销售方案、MDF 分配）、季度中期检查点和 90 天成功标准。验证规则：推荐层级不能制定渠道主导的 GTM 计划；非 OEM 层级不能制定白标方案。

步骤 4 — 收入分成模型

运行 scripts/revshare_modeler.py --input revshare.json --output markdown。计算每笔交易通过直销与合作伙伴销售时的利润、根据合作伙伴贡献深度（带来客户 > 影响交易 > 完成交付）推荐的收入分成比例区间、合作伙伴 ROI 的盈亏平衡点，以及长期经济效益——按照预计规模，合作伙伴模式的收益是否超过直销？

步骤 5 — 决策

将层级、GTM 计划和收入分成区间提交合作伙伴委员会。此技能不会签约——由你来签。将终止标准写入合同，以便触发条件满足时可按流程终止合作。

脚本

• scripts/partner_tier_classifier.py — 5 层级分类器，为每个层级设定确定性门槛
• scripts/joint_gtm_planner.py — 生成 90 天联合 GTM 计划，并根据层级验证合作方式
• scripts/revshare_modeler.py — 收入分成区间、盈亏平衡 ROI 和长期经济效益

所有脚本仅使用标准库。三个脚本均支持 --help 和 --sample。

快速示例

# Emits a 5-tier partner classification with deterministic floors per tier for the built-in sample partner
cd commercial/skills/partnerships-architect && python3 scripts/partner_tier_classifier.py --sample

参考资料

• references/channel_partner_canon.md — Caro 关于 HP 间接渠道的研究、Chintagunta 关于渠道经济学的研究、Hessling 关于合作伙伴计划的研究、Forrester 渠道软件技术栈、IDC 渠道研究、Tien Tzuo 订阅渠道模型、Geoffrey Moore 全产品合作伙伴关系
• references/joint_gtm_canon.md — Aaron Ross 的 Predictable Revenue（冷启动获客与合作伙伴渠道）、Winning by Design、Jay McBain 关于联合销售的研究、Microsoft Partner Network 策略手册、AWS Partner Network 研究、SiriusDecisions 合作伙伴基准、Bridge Group SaaS 合作伙伴数据
• references/partnership_anti_patterns.md — Forrester 关于合作伙伴主导销售却依赖自有商机的研究、Tom Tunguz 关于渠道冲突的研究、Hessling 失败案例分析、MIT Sloan 关于不成比例战略收益分成的研究、HP 渠道事后分析、IBM 渠道冲突案例、Salesforce AppExchange 研究

假设

• 无法提供独立需求证据（具名客户、终端客户关系、自有销售团队）的合作伙伴，寻求的是优惠条款，而非真正的合作伙伴关系。
• 行业配置（--profile）会调整默认值，但不会覆盖你的数据。
• 收益分成比例区间仅供参考；合同谈判、MDF 政策和独家条款属于技能范围之外的商业决策，应由人来决定。
• “合作伙伴来源”要求合作伙伴引入商机并负责主要客户关系。“合作伙伴影响”适用较低档位的收益分成。收益归因比演示文稿中的说法更重要。
• 本技能用于合作伙伴关系设计，而非已签约合作伙伴的商机管理——签约后，逐笔商机的商业审查应交由 deal-desk 处理。
• 必须制定终止标准。没有书面退出触发条件的合作伙伴关系，会让不良合作伙伴问题逐年加重。

反模式

• “合作伙伴 = 任何主动提出合作的人。” 没有独立需求的合作伙伴只是在寻找折扣。运行层级分类器——设立 REFERRAL 层级，正是为了接纳这类合作伙伴，同时避免让出经销商利润。
• 在利润不足以支撑服务的情况下授予 OEM／白标条款。 OEM 意味着你要为一个不归你所有的客户提供支持。如果收益分成不足以支付二线支持成本，这笔 OEM 交易就得不偿失。
• 对仅受合作伙伴影响的商机支付来源层级的收益分成。 受影响 ≠ 来源。即使没有合作伙伴介入，这笔交易也会成交。应按受影响档位支付。
• 未设定表现不佳合作伙伴的终止标准。 没有终止条款的“战略联盟”会在高管赞助人离职后变成永久义务。
• 直到销售代表辞职才处理渠道冲突。 当你的直销代表和合作伙伴同时出现在同一个客户面前时，你会失去其中一方。应事先而非事后确定协作规则。
• 把独家区域授予实力薄弱的合作伙伴。 这会挡住本来能够真正带来商机的强势合作伙伴。
• MDF 缺乏 ROI 责任机制。 没有具名销售管道、ROI 报告和季度结算的市场开发基金只是补贴，而非投资。
• 合作关系结束时没有退出计划。 客户服务连续性、数据移交、IP 清理和品牌撤除必须事先协商。关系恶化后再协商就太迟了。

与以下内容的区别

• business-growth/sales-engineer — 技术销售：演示、POC、集成范围界定。 在合作决策做出且交易已启动后开展工作。
• channel-economics（同级技能）— 对现有渠道的服务成本和 ROI 计算。 量化已签约合作伙伴是否盈利。partnerships-architect 决定是否签约以及签约级别。
• c-level-advisor/cro-advisor — 战略层面的 CRO 判断（何时聘用渠道副总裁、 全公司的收入组合决策）。partnerships-architect 针对单个合作关系。
• c-level-advisor/ma-playbook — 当答案是“收购对方”而非“与对方合作”时使用。触发条件：合作伙伴拥有你无法复制的独立护城河，或合作需要通过股权来协调激励。转交给 ma-playbook。
• deal-desk — 对已签署的合作伙伴合同逐笔审批折扣。

强制提问库（Matt Pocock 的拷问准则）

由 /cs:grill-commercial 或编排器逐个提问。每个问题都附有建议答复和权威引用。绝不打包提问。先敲定 1-3，再开始 4-6。

1. “说出这家合作伙伴在过去 12 个月内已经卖给的 5 个终端客户——这些客户所在的公司也正是你自己会瞄准的目标。” 建议：如果他们说不出来，就说明他们没有独立需求。最多只能签约为 REFERRAL 级别。转售商／OEM／战略级别的门槛要求已证实的终端客户关系。 权威引用：Joe Hessling——合作伙伴计划失败案例分析指出，“没有独立需求”是合作伙伴级别失效的首要根本原因。

2. “这家合作伙伴是在要求优先商业条款，还是在询问如何为你带来客户？” 建议：折扣猎手会先谈条款；真正的合作伙伴会先谈客户。仔细听第一次会议的前 30 分钟。 权威引用：Forrester 渠道研究——早期 SaaS 企业收到的“合作伙伴咨询”中，超过 60% 是为了寻求折扣，而非投入渠道建设。

3. “用一句话说出双方的联合价值主张，它服务于哪位具名终端客户？” 建议：如果没有区别于双方各自独立产品的联合价值主张，那就称不上合作伙伴关系——顶多是联合营销。 权威引用：Geoffrey Moore（《跨越鸿沟》）——只有当任一方单独都无法为客户带来预期成果时，才需要通过合作伙伴关系提供完整产品。

4. “这项合作要达到多少折扣／收入分成比例，以及多大规模，才能优于直销的经济效益？” 建议：建模计算盈亏平衡所需的销售线索量。如果合作伙伴带来的交易量必须超过渠道总交易量的 30% 才能胜过直销，而合作伙伴很可能只能带来 5%，那你建立的就是一个亏损计划。 权威引用：Pradeep Chintagunta（Chicago Booth）关于渠道经济效益的研究——没有最低交易量门槛的渠道合作，理论上可以达到盈亏平衡，实际中却会亏损。

5. “终止这项合作的明确条件是什么？是否已写入合同？” 建议：设定每季度最低销售线索量、最低认证人员数量、最低联合成交数，以及 90 天补救期。若没有预先商定的条件，终止合作就会演变成一场持续 2 年的法律纠纷。 权威引用：IBM 渠道冲突案例研究（1990 年代剥离业务后）——未记录在案的终止条件，使糟糕的合作伙伴变成了永久义务。

6. “如果这家合作伙伴向你自己的某个直销客户销售，谁能胜出——你的销售代表还是他们？” 建议：在启动会议前，以书面形式制定并签署《合作规则》（ROE）。按具名客户、细分市场或地理区域划分范围。由指定人员解决冲突，而不是交给委员会。 权威引用：Jay McBain（Canalys）——渠道冲突是合作伙伴计划失败的首要原因；在合作伙伴签约前发布书面 ROE，可避免 80% 的争议。

7. “这是一项合作，还是应该收购？” 建议：如果这家合作伙伴拥有你无法复制的独立护城河、合作要求多年独家经营，而且还要求类似股权的利益协同，那你描述的其实是一次收购。改走 ma-playbook 流程。 权威引用：HP 渠道事后分析（Indigo、EDS 的部分整合）——以无股权收购方式构建的合作关系，比纯粹采用任一模式造成的价值损失都更大。

按深度优先顺序推进。先敲定 1-3（这是否是真正的合作伙伴？），再开始 4-7（结构是否合适？）。全部 7 个问题都得到回答后，依次调用 partner_tier_classifier.py → joint_gtm_planner.py → revshare_modeler.py。