joint-gtm-planning

联合 GTM 规划

与一位特定合作伙伴规划一项联合 go-to-market 计划。合作伙伴已经选定——候选伙伴排序应由 mbfinotti/partnerships-skills@alliance-prioritization 负责。这里规划的是一项单独的联合行动：

• 面向客户的“强强联合”故事。
• 活动的形式。
• 双方各自负责什么，以及预算如何分配。
• 双方承诺的发布顺序。
• 线索共享与归因协议。
• 决定是否再次开展的复盘。

产出是一份双方公司都能签署的联合 GTM 计划——它是一份决策文件，而不是活动素材。广告文案、邮件正文、网络研讨会脚本和落地页都是这份计划之后的战术工作。请注意与生态系统中关联技能的边界：它的联合价值主张研讨会用于筛选某个合作伙伴类别能否阐明联合价值；这项技能则为一位具名合作伙伴和一项计划撰写面向客户的实际主张。

访谈

提出任何建议前先提问。每条消息只问一个问题；尽可能提供多项选择。用户已经回答过的问题可以跳过。如果你的运行环境有持久记忆，请先查看其中是否有与该合作伙伴相关、且先前已获批准的计划，并确认有哪些变化，而不是重新访谈。

• 合作伙伴是谁？双方关系处于什么阶段：刚签约、已签约但尚未开展合作、已有过往活动的活跃合作，还是拥有高管联系的战略联盟？
• 这项计划是什么？背后的业务目标是什么：生成销售管线、推出集成或产品、进入新的细分领域或市场、品牌关联，还是共同举办活动？
• 目标受众是谁？已核实的客户账户或受众重合情况如何——是有匹配的重合数据、客户访谈证据，还是仅仅基于假设？
• 双方合作能可信地宣称什么，而任何一方单独都做不到？已经有联合价值主张草案，还是尚未开始？
• 双方各自已有的资源是什么：集成、内容、客户案例、受众渠道、活动资源、现有客户名单？
• 双方各自承诺多少预算？是否有市场开发或合作营销资金可用——申请规则和截止日期是什么？
• 双方各自的投入上限是多少：可投入的工时、分配的人力、负责人可动用的审批额度，以及承诺需要保持多大的可撤回性？决定活动形式的限制不是资金，而是两家公司之间的协调成本。
• 时间安排是什么？是否有固定日期（活动、产品发布、季度结账）？结果最迟必须在哪天落地？发布日和结果截止日是两个不同的限制。
• 目标是本季度一次性的胜利，还是发布后还能持续产生收益的复利型资产？绝不要把这一点含糊带过——它会彻底改变活动形式的优先级排序。
• 双方各自的具名负责人是谁？双方各自的高管赞助人是谁？共四个名字。
• 适用哪些线索共享和数据保护限制：涉及哪些地区、适用什么同意制度、双方各自使用什么 CRM，以及是否已有数据共享协议？
• 双方各自如何定义成功？绝不要接受合并成一个“共同目标”的说法——现在隐藏的不对称，之后会在复盘中暴露出来。

工作流

始终遵守一条原则：每遇到一个真正需要选择的分叉点——活动形式、推进顺序、线索分配规则、预算结构——就提出 2-3 种备选方案，说明各自的权衡，并明确给出推荐方案，然后等待用户决定。绝不要让假设在未明示的情况下固化为计划。

1. 开展访谈。如果可以浏览网页，请阅读两家公司的官网、合作伙伴的公开合作伙伴页面，以及任何现有的联合展示页面——在据此规划前先核实实际情况。

2. 规划前先评估准备情况。若存在以下任何一项不合格情形，请说明理由并拒绝：

   • 任一方没有明确的负责人或高管级赞助人。
   • 合作伙伴没有回应或缺乏承诺。
   • 除了把两个 Logo 放在同一份材料上，无法清楚说明联合价值。
   • 双方目标完全没有交集——一方想要潜在客户，另一方只想提升品牌覆盖度，这是已知的联合营销失败模式。
   • 任一方没有预算或执行能力。
   • 正在发生的联合销售政策争议亟待处理——请先交由 mbfinotti/partnerships-skills@partner-channel-conflict 处理。

   如果未通过评估，请指出缺少的条件并停止——计划无法弥补缺乏人员投入的合作关系。

3. 为此项目撰写联合价值主张：面向客户的主张、服务对象，以及为何需要两家公司共同参与。应用“单方无法做到”测试——如果任一家公司都能独立可信地推出该项目，那它就只是贴着合作伙伴 Logo 的单方营销活动；请重新设计或取消。

4. 明确双方价值和受众重合度：

   • 分别说明双方的目标，并给出数字和日期。
   • 如果生态系统协作任务已有经过验证的受众重合度数据，请使用；否则根据客户证据估算，绝不可凭空假设。
   • 定义目标细分群体，并明确排除对象——是否排除双方的现有客户，还是仅排除其中一方的现有客户？

5. 选择活动形式——这是最关键的分岔点。请先阅读 references/campaign-formats-and-sequencing.md：该文档按效率——即每单位双方协作所换取的价值——对 B2B 和 B2C 形式菜单进行排序；默认情况下，B2B 选择联合网络研讨会，B2C 选择创作者合作。根据访谈答案剔除不适用的形式，再结合对这对公司的了解重新排序，从优先级最高的形式中选出 2–3 个候选方案。说明每种方案在工作量、价值和合规方面的权衡，并明确给出建议。明确指出哪些答案改变了哪些形式的选择：

   • 硬性结果日期会排除需要整个季度才能完成的形式。
   • 需要打造可持续增值资产的要求，会优先考虑研究报告和“强强联合”页面。
   • 工作量上限较低时，候选形式会缩减至只需一小时的形式。

6. 划分工作、资产和预算：

   • 根据双方各自的优势分配内容制作工作。
   • 将双方各自的支出分别列项。
   • 原文记录市场开发基金或合作基金的条款——符合条件的活动、所需的执行证明、申领截止日期。

   未申领资金是导致失败的主要原因之一。

7. 按六个阶段安排发布：商定条款、制作资产、发布前准备、在约定日期同步发布、后续跟进、复盘。时间预算大致按单方项目时间线的两倍计算——多出的时间用于另一组织的审批和反馈周期，这是常态，不是应急预留。同样，请以任何固定日期为锚点倒排时间。参见同一文档。

8. 设计潜在客户共享和归因协议：在收集信息时作出同意与否的_决定_，并确定后续执行机制。

   • 法律依据。
   • 明确列出两家公司。
   • 同意应单独呈现，不得捆绑。
   • 撤回同意的途径。
   • 哪一方负责表单——也就是控制点（见下文的数据保护部分）。
   • 数据传输机制和时间。
   • 双方共同商定的合格潜在客户定义。
   • 去重规则。
   • 各方专属的跟踪链接。
   • 本项目的“来源于”与“受影响于”归因规则。

   在此确定并记录这些参数；起草表单的具体文案属于各项资产的执行工作，应与其他资产工作一并交由下游处理。如果联合销售协作任务已有适用于整个项目的归因政策，请将其作为约束并遵循——切勿在此重新设计。请参阅 references/lead-sharing-and-attribution.md。

9. 制定计划（见下一节），并分节提交；每节都要先经用户确认，再起草下一节。如用户提出异议，则进行修改。最终定稿前，必须取得用户对整份文档的明确批准；在现实中，双方公司的负责人也必须在任何资产工作开始前签署该计划。

10. 按照通过清单为获批草案打分。说明哪些检查未通过，并迭代，直至全部通过。

11. 如果你的运行环境支持持久化记忆，请记住获批计划的关键决策——合作伙伴、倡议、活动形式、发布日期、线索共享规则、双方各自的目标——以便后续运行（执行期间的检查、复盘、与该合作伙伴开展的下一项倡议）从这些信息开始。

12. 将此技能不负责的事项——合作伙伴选择、交易登记政策、项目分级、合作关系的经济效益、持续记分卡、赋能课程——交由 Reference 中的同类技能处理。

联合 GTM 计划

每次合作都要交付这份成果——一份双方公司都能签署的单页计划：

JOINT GTM PLAN - <company> x <partner>: <initiative>, <date>
Objectives      : each side's goal separately, each with a number and a date
Joint value prop: the customer-facing claim + why it takes both companies
Audience        : target segment, overlap evidence, explicit exclusions
Campaign shape  : format chosen, where it sat in the efficiency order, what moved it there,
                  alternatives rejected and why
Assets & split  : who creates and who approves each asset; existing assets reused
Budget & funding: each side's spend as its own line; MDF/co-op terms verbatim
Sequencing      : phase dates, the one agreed launch date, approval buffer shown
Leads & tracking: consent basis + parameters, transfer mechanism + timing, qualified-lead
                  definition, dedup rule, per-party links, sourced/influenced rule
Owners          : named owner + executive sponsor on each side - four names
Measurement     : KPIs per side, reporting cadence, scheduled debrief date

每一项都要说明理由——“于 14 日发布，因为合作伙伴的大会将于 15 日开幕”这样的安排可供审核；只写一个日期则不行。

通过清单——所有检查都通过后，计划才算完成；每次都要说明未通过的检查及其差距：

• 双方各自的成功标准分别说明，并给出数字。合并成一个目标不合格。
• 联合价值主张通过“双方单独行动都无法做到”这一检验。
• 明确列出四位相关人员：双方各有一位负责人和一位执行发起人。团队名称不能代替负责人。
• 双方同意一个发布日期，并在阶段日期中清楚体现审批缓冲时间。
• 线索条目须列明收集时的同意依据及其参数、传递机制和交接时间——说明参数，而不是起草表单文案。
• 每个跟踪链接都要归因到具体一方；不得存在未标记的共享链接。
• 任何 MDF/联合营销资金都必须注明执行证明要求和申领截止日期。
• 复盘日期须在发布前排定，而不是写“之后”。
• 计划中引用的每项基准数据都必须标注来源标记。

已确立的实践、供应商用语与行业标准空白

如实评估引用内容的可靠程度——这一领域混杂着真实实践与供应商营销：

• 已确立，可作为规范性建议：

  • 联合营销本身（其学术脉络可追溯至 Koichi Shimizu 于 1981 年提出的理论）。
  • 已签署的联合营销协议，涵盖主题、时间线、双方各自的目标、资产所有权、线索共享、推广和报告。
  • 配有执行证明的 MDF/联合营销资金（验证机制可追溯至 20 世纪 30 年代的联合广告）。
  • 双方各自使用独立的跟踪链接。
  • 表单层面的同意文案。
  • 执行层发起。
  • 活动后的复盘。

  借鉴的一般框架——用于明确责任的 RACI、用于设定目标的 OKR、用于审批关卡的阶段关卡——确有其用，但并非合作伙伴营销领域发明；应适度使用，切勿生搬硬套。

• 供应商创造的术语：“nearbound”和“生态系统驱动增长”源自一家供应商（Crossbeam）及其收购的媒体品牌；作为明确命名的学科，“账户映射”也由同一家供应商推广。这些术语可用作共同语言，但绝非教条。

• 不存在行业标准：

  • 不存在公认的联合业务计划或联合 GTM 计划模板——上述框架是从实践中整理而成，因此应分节确认，而非视作行业通用表格。
  • 发布等级标准（Tier 1/2/3）、联合业务评审议程、MDF 门槛以及跨公司合格线索定义，都由具体项目决定——应明确让用户作出选择。
  • 流传的“60%–70% 的联盟会失败”这一说法无法追溯来源，属于无据传闻。绝不要把某个单一联盟失败率说成确定事实：已发表的估算范围为 20%–80%，具体取决于失败的定义，因此应注明来源并呈现这一范围——mbfinotti/partnerships-skills@alliance-prioritization 负责处理这一数据。

B2B 和 B2C

两种合作的规划纪律相同：

• 分别说明双方的目标。
• 开始制作素材前签署协议。
• 筛选品牌契合度（关联本身就是风险）。
• 确定一个共同认可的发布日期。
• 指定负责人。
• 进行复盘。

真正的差异：

维度	B2B（供应商之间的联合营销）	B2C（联合品牌、品牌与创作者合作）
重心	销售管道和潜在客户机制	产品或内容本身，以及品牌契合度带来的声誉风险
常见交付物（各方自身的效率排序见格式参考）	联合网络研讨会、优势互补页面、联合撰写的报告、集成发布	创作者合作、品牌内容合作、联合品牌产品
成功衡量方式	以销售管道为核心：潜在客户、来源于合作或受合作影响的收入	品牌资产和品牌回想度；从结构上看，归因更难
监管	没有面向消费者的披露制度；风险存在于私人合同中	消费者保护披露执法（类似 FTC 的监管）适用于赞助的创作者内容
排他性	通常会同时开展多个非排他性合作	品类排他性是明确约定的合同等级
审批	上线前通过双方的营销和法务审批链完成	品牌的否决权可能延续至制作完成后，甚至覆盖已发布的内容

潜在客户共享和数据保护

在大多数司法管辖区，两家公司之间共享已收集的潜在客户信息属于受监管的个人数据处理——欧盟的制度（GDPR）是最严格的范本，但其逻辑也适用于其他地区。每次数据传输都需要有法律依据；为某一明确用途收集的潜在客户信息，不得在未告知的情况下用于另一家公司的后续跟进。

控制点在于收集信息时的同意措辞。表单必须：

• 写明两家公司的名称。
• 说明用途。
• 将对每家公司的同意分别列出，而不是捆绑在一起。
• 便于撤回同意。

当两家公司共同决定收集哪些数据及其用途时（联合举办网络研讨会就是典型案例），许多制度会将双方视为共同控制者：必须记录并披露双方的责任分工；无论内部如何划分，潜在客户都可以向任一家公司行使权利。

完整机制和协议内容：references/lead-sharing-and-attribution.md。

KPI

仅衡量本次合作计划——合作伙伴的持续评分卡归 mbfinotti/partnerships-skills@partner-performance 管理。

• 对本次计划的合作伙伴来源和合作伙伴影响分别跟踪；将两者合并会掩盖此次合作究竟带来了需求，还是只为已有需求锦上添花。
• 根据双方各自明确陈述的目标分别评估；某项活动可能对一家公司成功、对另一家公司失败，计划必须能如实说明。
• 核心指标：各方的潜在客户数（通过各方专属链接统计）、按双方共同商定的定义计算的合格潜在客户转化率、归因于此次计划的销售管道和收入、各方的受众增长、素材互动情况。定性复盘：合作是否顺畅、内容是否需要双方共同参与、任一方是否愿意再次合作。
• 计算回报时，以归因于本次计划的增量利润除以各方自己的支出；双方各自计算。合并后的数字会掩盖不对称的结果。
• 合作伙伴营销领域已发布的基准数据几乎都由供应商自行报告（即销售合作软件的平台调查自己的客户）。引用此类数据时，必须标明这一点；优先使用用户自己的历史活动数据作为基准。

失败模式

症状	解决方法
双方悄悄地在追求不同的结果	在计划中分别重申双方的目标；只有双方都接受彼此的目标后才能批准
上线日期一再推迟	在单独执行所需时间基础上加倍预留缓冲；从固定的外部日期倒推安排；通过发起人升级处理
只是互换 Logo、无人互动的活动	应用“双方单独都无法做到”的检验；围绕真正的联合能力重新设计，否则取消计划
潜在客户从未移交，或事后对移交情况产生争议	上线前将移交机制、时间安排和同意参数写入已签署的计划
MDF 或联合营销资金过期，未能申领	将符合条件的活动、执行证明和申领截止日期列为预算项目，并指定负责人
合作伙伴在计划进行期间不再回应	尽早启动高管发起人的升级处理路径；缩小范围，而不是勉强撑到既定日期
无人能说清计划是否有效	从第一天起使用各方专属链接，区分来源和影响，并在上线前安排复盘日期
合作伙伴的失误波及你的品牌	在准备度评审环节进行品牌契合度筛查；所有联合品牌素材均须经双方批准

调用示例

• “为我们与一家具名数据平台合作伙伴的集成产品发布制定联合 GTM 计划——双方都有预算，发布与对方的用户大会挂钩。”
• “我们和合作伙伴办了一场联合网络研讨会，结果一无所获。请为下一次计划不同的合作方案，并告诉我复盘时应该询问什么。”
• “起草一份潜在客户共享与归因协议，适用于面向欧盟和美国受众的联合营销活动。”

参考资料

• references/campaign-formats-and-sequencing.md - 按效率（每单位双方协作带来的价值）排序的 B2B 和 B2C 活动形式选项，并分别列出投入、价值和合规性维度、六阶段排序框架、固定日期锚定方式以及 MDF/联合营销基金机制。
• references/lead-sharing-and-attribution.md - 线索共享协议的内容、数据保护机制（法律依据、可分离的同意、共同控制者）、跟踪链接规范、合格线索标准对齐方式以及基准数据来源标记。
• references/plan-examples.md - 一份完整的联合 GTM 计划示例，以及一份带注释的反面示例（Logo 互换计划）。

同系列技能：

• mbfinotti/partnerships-skills@alliance-prioritization - 前置环节：决定投资哪些合作伙伴。本技能从该决策之后开始。
• mbfinotti/partnerships-skills@co-selling-strategy - 本计划须遵循的项目级交易注册和归因政策。
• mbfinotti/partnerships-skills@partner-ecosystem - 本计划用于制定目标的生态系统地图和客户重叠情况。
• mbfinotti/partnerships-skills@partner-performance - 本计划自身衡量工作之外的持续合作伙伴评分卡和业务评审节奏。
• mbfinotti/partnerships-skills@partner-channel-conflict - 直销人员与合作伙伴销售人员围绕某个客户发生的实际争议；制定联合行动计划前应先解决。
• mbfinotti/partnerships-skills@partner-marketplace-strategy - 如果该计划包含 Marketplace 相关行动，则参考 Marketplace 上架策略。