partner-ecosystem

合作伙伴生态系统梳理

梳理某一业务领域内完整的合作伙伴与渠道格局。这项工作没有唯一的标准框架。

梳理内容包括：

• 哪些类型的合作伙伴会接触你的客户。
• 哪些合作伙伴与你争夺同一市场。
• 覆盖空白和冲突区域在哪里。
• 哪些生态系统细分领域值得投入关注。

所依据的内容：

• 角色分类法：Jay McBain 对渠道的三分法。
• 重叠分析方法：由 Ecosystem-Led Growth 推广的客户账户映射。
• 梳理方法：Verna Allee 的价值网络分析、Ron Adner 的价值蓝图。
• 优先级评估：加权评分卡加 2×2 矩阵。

产出是一份用于决策的材料，而不是合作伙伴计划：

• 生态系统地图。
• 覆盖范围／空白区域视图。
• 优先级视图。
• 一份简短的生态系统战略备忘录。

计划设计、层级标准、冲突处理规则，以及针对单个合作伙伴的经济效益分析，应交由相关技能处理（参见 Reference）。

访谈

开始梳理前先提问。每条消息只问一个问题；尽可能提供多选答案。只有用户已经给出答案时，才跳过问题。

• 你的业务是 B2B、B2C，还是混合型？公司向谁（ICP）销售什么产品，价格区间如何，通过哪种销售方式（自助服务还是销售驱动）？
• 这张地图应涵盖哪个业务领域或产品线？（绝不要一次涵盖整个公司——请提供 2-3 个合理的范围供选择。）
• 地图的目标是什么：选择渠道战略、发现覆盖空白、诊断冲突、为高管诉求评估生态系统规模，还是在建设计划前梳理全貌？
• 目前的合作伙伴组合如何：现有哪些类型的合作伙伴，每类大致有多少，实际活跃的有多少？
• 有哪些数据：CRM 中的成交记录、来源／影响归因字段、与任何合作伙伴的客户账户重叠数据、客户技术栈或购买渠道信息？
• 你是其他公司构建产品所依托的平台，还是他人生态系统中的参与者？（不同业务领域的情况可能各不相同。）
• 有哪些限制：谁是发起人，谁必须批准，有多少能力可以投入执行？
• 地图必须在哪个日期前完成？有什么决策正在等待它？（如果截止日期在一周内，应优先审查已成交订单，并采用基于访谈的重叠情况估算；如果还有一个季度的准备时间，则可以开展经授权的客户账户映射，并组织研讨会。）
• 这是一次性成果，还是可持续积累的资产？（如果只是满足一次高管诉求，静态矩阵和备忘录就足够；如果目标是持续积累，就需要定义 CRM 字段、建立重叠分析基础设施，并制定定期审查节奏，让地图在会议之后继续保持更新。）
• 工作量上限是多少——你自己的可投入时间、你能协调谁的日程，以及召集相关方或向合作伙伴索取客户账户清单时可以动用多少政治资本？（如果只有你一个人能投入，就无法开展参与式研讨会，也无法共享合作伙伴数据；这两种方式都需要他人同意。）

在下方的每项排序中都纳入这三个答案。只有这些输入可以改变针对该用户的默认排序。

工作流

在以下每个步骤中，只要存在实际选择，就始终遵循同一套原则：

• 选择要纳入的业务领域。
• 选择可接受的重叠情况估算方法。
• 选择评分卡的权重。
• 选择要制作的可视化图表。
• 选择纳入哪些类别。

向用户提供 2-3 种备选方案，说明各自的权衡并给出推荐，然后等待用户回应。绝不要把单一方案说成唯一选择。绝不要让任何假设在未说明的情况下成为地图的既定前提。

以下步骤中的所有排序都是默认方案，而非硬性规定。排序依据是单位投入所能带来的价值，而不是成本由低到高；排序也会因具体情境和执行者而变化。提出建议前，应结合你对该用户的已有了解重新排序。

影响排序调整的信号：

• 已经包含结构化合作伙伴影响字段的 CRM，会让内部数据提取远远领先于其他方式。
• 有设计师可用，会让网络图的优先级上升。
• 受众更习惯阅读电子表格而不是图表，会让它的优先级下降。
• 已经在共享账户数据的现有合作伙伴，会让账户映射成为低成本选项，而不是高成本选项。

说明他们的哪些回答改变了哪些选项，这样重新排序才有据可查，而不是你单方面声称的偏好。

1. 开展访谈；在接触数据之前，确认范围仅限一个业务领域，并明确说明目标。

2. 梳理所有接触该领域客户的第三方，并按以下顺序处理证据来源。切勿根据收到的合作请求或团队的人脉来编制清单；这样做的团队会签下没有共同账户、没有共同 ICP，也没有联合销售渠道的合作伙伴。

   • 内部数据提取 - CRM 记录、赢单记录、支持工单、集成和产品使用情况。花一两个小时查看已有数据，而它返回的每个名称都是该参与者接触过真实客户的证据。始终从这里开始。

   • 客户访谈 - 需要一周时间安排日程和进行交流。只有这种来源能找到顾问、社群以及系统中从未记录过的影响者；这正是仅关注交易的视角会遗漏的领域。

   • 公开信息检索 - 竞争对手的合作伙伴目录、市场平台列表、评测网站上的同类产品，以及会议赞助商名单。只要能浏览网页，几乎不费力，而且能快速扩大覆盖范围；但它找到的任何内容都不能证明这些参与者接触过_你的_客户。将检索结果视为待核实的候选项，而不是清单。

   • 价值网络分析参与式工作坊 - 需要一周的日程安排，以及召集相关方所需的政治资本。它能发现无形的交流（信任、市场洞察、品牌关联），更重要的是，让合作部门以外的人员共同参与网络图的管理。请参阅 references/discovery-workshops.md。

   • 努力程度：工作坊 > 客户访谈 > 内部数据提取 == 公开信息检索

   • 价值：客户访谈 > 工作坊 > 内部数据提取 > 公开信息检索

   • 效率：内部数据提取 > 客户访谈 > 公开信息检索 > 工作坊

   内部数据提取和公开信息检索的努力程度相当：两者都只需一个人独自工作一两个小时，无需申请权限，也无需协调日程。但它们的价值完全不能相提并论：数据提取在这一维度上胜出，因为只有它的结果能提供关于_你的_客户的证据。

   如果无法浏览网页，公开信息检索就不是低成本，而是不可能：将其删除并说明原因，而不是列出无人可用的信息来源。

   • **默认：**仅进行内部数据提取。
   • **在以下情况升级到客户访谈：**赢单记录提到了你无法归类的第三方，或影响者领域结果为空。通常都会如此；这反映的是记录方式存在缺口，而不是生态系统存在缺口。
   • **这种排序会忽略什么：**工作坊。它的价值排名第二、努力程度排名第一、效率排名最后，因此按比例排序时从未被选中；而且只有它能让合作部门以外的人员共同管理网络图，而不只是接收网络图。
   • **在以下情况下优先安排工作坊：**需要由销售、产品或高管赞助人共同管理网络图，而不只是让他们阅读；网络图应在工作坊中起草，而不是在评分后起草。
   • **在以下情况下删除工作坊：**访谈确定了个人努力的上限。明确说明已将其删除：它需要其他人同意，而将它留在清单末尾，会导致一周的日程安排，而无人同意参与。

3. 从两个维度对每个参与者进行分类：

   • 在客户旅程中的角色：影响、交易或集成与交付（McBain 的三分法，Canalys）。
   • 参与深度：从上架到深度嵌入。 纳入竞争对手。竞争合作，以及你与他们共享的合作伙伴，都是信号，而非噪声。参见 references/partner-type-taxonomy.md。

4. 用两种机制之一确定重叠情况。这是本练习中唯一一处：成本较低的选项不仅效果较弱，而且_更安全_，因此在提出建议前先对四个维度排序：

   • 经授权的客户映射 - 与合作伙伴交换筛选后的客户列表，并将共享客户划分到四个重叠象限中。这是唯一能在客户粒度上得出重叠情况的机制，因此才能量化联合销售目标和空白市场，而不是仅用形容词描述。

   • 访谈和技术栈代理指标 - 根据客户对所用工具和购买渠道的描述推断重叠情况。只能按类别提供方向性判断，不能细化到客户。

   • 工作量：客户映射（需要合作伙伴联系人同意，并为每个合作伙伴进行筛选和评级）> 代理指标（在已有访谈中花几小时即可）

   • 合规成本：客户映射（需要数据共享协议、审查离开你方系统的数据，以及发送后无法撤回的客户列表）> 代理指标（无）

   • 价值：客户映射（可量化的象限）> 代理指标（方向性信号）

   • 效率：只有一两个合作伙伴愿意共享时，代理指标 > 客户映射；三个或更多合作伙伴愿意共享后，客户映射 > 代理指标，因为法律和筛选工作只需投入一次，之后可供每个合作伙伴复用

   • 默认选项： 首次绘制地图时使用代理指标。绝不要因为缺少客户映射而耽误练习。

   • 当答案表明这是一个可累积的资产时，并行启动客户映射的文书工作， 这样第二次绘制地图时就能得到真实的象限。

   • 当没有合作伙伴愿意共享列表，或隐私审查无法在可用时间内通过时，删除客户映射。 记录删除原因：将某种机制搁置为“第二阶段”，正是地图声称测量了客户级重叠、实际却从未测量的原因。

   • 根据证据进行估算，绝不凭假设。参见 references/overlap-and-conflict.md。

5. 开展回溯式已成交复盘：抽取近期已成交交易样本，并记录每笔交易受其影响的所有第三方。这是整个练习中成本最低、信号最强的步骤。它能证明生态系统是否已经在影响收入，而无需招募任何新伙伴。

6. 找出覆盖缺口：没有合作伙伴覆盖的细分市场、地理区域和客户旅程阶段。也要找出冲突区域：合作伙伴与合作伙伴、直销与合作伙伴、多渠道，以及面向消费者品牌的 D2C 与零售。按客户数、涉及收入和区域量化每一项。

   仅检测和衡量。制定解决规则应由 mbfinotti/partnerships-skills@partner-channel-conflict 负责。

7. 提出自我定位问题：在这张地图上，你是关键节点、他人生态系统中的利基参与者，还是无意中表现得像主导者（Iansiti & Levien，2004）？答案决定你是招募合作伙伴，还是被他人招募。

   通过三项指标判断生态系统的整体健康状况：

   • 生产力：参与是否能提升成员的效率？
   • 稳健性：生态系统能否经受冲击？
   • 利基创造：是否持续催生新的专业角色？

   这种类型学早于现代数字平台。

8. 按行业自身的形式开展类别层面的探索会议，而非泛泛的头脑风暴：

   • 为每个候选类别开展一次 IPP 定义会议。
   • 举办 JVP 工作坊，测试该类别能否清晰表达联合客户价值。

   未通过 JVP 测试的类别不得继续推进。请在评分_之前_开展测试，这样无法陈述联合价值的类别就不会得到之后还得撤回的综合评分。参见 references/discovery-workshops.md。

9. 优先考虑幸存类别。为每个维度构建加权综合评分卡，然后在优先级 2×2 矩阵中绘制各类别：战略契合度 × 执行难度（Chris Lavoie 象限）。按合作伙伴类型划分评分卡权重：推荐合作伙伴和系统集成商绝不能共用一张评分卡。

   对生态系统中已有的类别进行排序，确定它们各自的投资关注优先级。排序之外还有两项交接：

   • 对具名候选联盟进行排序，属于 mbfinotti/partnerships-skills@alliance-prioritization。
   • 对公司尚未覆盖的类别进行排序（进入顺序、准备度门槛、产能限制），属于 mbfinotti/partnerships-skills@partner-ecosystem-expansion；该技能会将此处的排序和下文的空白领域作为输入。

   请参阅 references/prioritization-scorecards.md。

10. 根据要解决的决策选择可视化方式，而不是看它放在演示文稿里效果如何。先对四种形式排序，再提供选项。介绍排名前 2-3 的形式及其权衡和建议，然后让用户选择，再开始制作。

    • 矩阵 - 在覆盖范围 × 能力深度的维度上排列合作伙伴。它能确定投资决策，而这正是绘制整张图的目的。几乎不需要制作：它就是一张表格，数据来自已有的综合评分卡。

    • 热力图 - 按地理区域、垂直行业或能力着色。它能一目了然地确定空白领域，并将信息浓缩在一张高管确实会记住的图中。需要一小时，而且每个参与方都需要关联一个明确维度。

    • 网络图 - 展示供应商、合作伙伴以及它们之间的连接。它能确定枢纽是谁，这是唯一能做到这一点的形式。需要一天或更久，并且需要真正的布局技能；否则图会像一团乱麻，什么问题也解决不了。

    • 分层视图 - 按战略相关性绘制同心圆或金字塔。它能区分核心与外围，但第 9 步已经完成了这种排序，因此这种形式基本只是在重述结果。

    • 工作量：网络图 > 热力图 > 分层视图 > 矩阵

    • 价值：矩阵 > 热力图 > 网络图 > 分层视图

    • 效率：矩阵 > 热力图 > 分层视图 > 网络图

    默认选择矩阵。如果访谈中明确目标是找出覆盖缺口，而非确定投资方向，则改用热力图。热力图比分层视图多花一小时，因为每个参与方都需要关联一个明确维度；而分层视图只是重新绘制第 9 步已得出的排序。

    • **这种排序忽略了什么：**网络图。它回答的问题是其他形式都无法回答的，而且它是唯一需要一天时间和团队可能不具备的技能的形式，因此按比率衡量时总会被排除，枢纽结构也就始终无人审视。
    • **在以下情况下优先考虑它：**用户当前需要决定哪个参与方是枢纽（负责路由、聚合，或是其他合作伙伴所依赖的合作伙伴），并且有人具备真正的布局技能且有空。
    • **在以下情况下删除它：**没有人具备这项技能。杂乱无章的图解决不了任何问题，还要花一天时间，因此不要把它包装成雄心勃勃的方案。
    • **一旦优先级 2×2 矩阵完成，就完全跳过分层视图：**同一排名的两种视图会让读者试图寻找并不存在的差异。

    请参阅 references/overlap-and-conflict.md。

11. 仅将生态系统层面的健康指标作为诊断参考，用来验证这张图。单个合作伙伴的评分卡和审查周期属于 mbfinotti/partnerships-skills@partner-performance。

    • 投入：来源型与影响型拆分（CRM 字段定义加书面去重政策；如果尚不存在，需要几天时间；如果已经存在，耗时近乎为零）> 激活率（只要有注册日期，就近乎零成本）== 覆盖度读数（已在第 6 步计算）
    • 价值：来源型与影响型拆分（生态系统是否能赚钱，以及招募速度是否超过赋能速度）> 激活率（可识别只收集品牌标志的情况）> 覆盖度读数（重述第 6 步的内容）
    • 效率：激活率 > 来源型与影响型拆分 > 覆盖度读数

    激活率和覆盖度读数的投入成本都是真正的零：前者是针对已有注册日期的一条查询，后者是第 6 步已经算出的一个数字。读取二者都无需额外成本。二者的价值有所不同，而激活率更胜一筹。

    • **先看：**激活率。它只需一条查询，却能推翻一整类地图。
    • **此顺序搁置了什么：**来源型与影响型拆分。只有它能说明生态系统是否能赚钱，但与之相关的 CRM 字段定义和去重政策需要花上几天时间，因此总是输给两个免费的数字。
    • **在以下情况下优先考虑它：**地图要用于投资决策，而非汇报覆盖度，因为没有高管会仅凭激活率就为生态系统拨款。如果相关 CRM 字段已经存在，它就会直接排在首位，让这里成本最高的读数变成免费项。
    • **在以下情况下删除它：**CRM 无法承载这些字段时。应明确说明盈利问题仍未得到解答：将其列为待定指标，会让之后的读者误以为已经测量过。

    参见 references/ecosystem-health-kpis.md。

12. 按章节逐一展示交付内容，并在起草下一章节前请用户确认当前章节：

    • 清单
    • 分类
    • 重叠发现
    • 缺口与冲突
    • 自我定位
    • 优先级排序
    • 备忘录

    根据反馈修改。最终定稿前，必须逐节获得明确批准。

13. 根据下方的通过门槛为最终地图评分。持续迭代，直到达标。如果无法达标（真实生态系统参与者不足 10 个，或没有可验证的重叠），请明确说明，并界定诚实可行的下一步，通常是客户访谈，而不是交付一份装饰性的地图。

14. 设定审查机制：地图永远不会完工。商定定期审查频率和立即更新的触发条件：

    • 合并或收购。
    • 新法规。
    • 某个类别转移象限。

    该练习本身所需的时间没有可靠的公开数据。任何时长都应视为估算，不过，创始人主导的精简首轮绘制曾在大约一天内完成。

15. 如果你的运行框架支持持久记忆，请记住已批准地图的范围、合作伙伴类别和优先级决策，以便后续运行从这些内容开始，而不是重新访谈。

通过门槛

满足以下所有条件，即表示首版地图完成。持续迭代，也就是增加访谈、复盘更多交易或缩小范围，直到满足这些条件：

• 至少对 10 个生态系统参与者进行了分类，并标明其旅程角色和参与深度。
• 每项重叠声明都有经过验证的重叠数据作为依据——可以是账户映射结果或客户访谈证据，绝不能只是推测。
• 对已关闭并赢单的交易进行了回溯影响分析，展示生态系统已经在哪些环节触及收入。
• 地图能为至少一项明确决策提供依据，并指定负责人——地图无法推动任何决策，是这套方法最常见的失败原因。
• 每项引用的基准数据都有来源标记（供应商一手数据、分析师、聚合商或咨询公司）——该领域几乎所有公开数字都来自希望数字越好看越有利的供应商。

生态系统战略备忘录

地图是证据。备忘录才是高管真正会阅读和拨款的内容。篇幅控制在约两页，并确保读者能从每一行追溯到地图中的证据：

ECOSYSTEM MAP  - <business area>, <date>
Scope          : business area, ICP, geography, and what was deliberately excluded
Inventory      : players found, by journey role × engagement depth, with data sources
Overlap        : verified overlap per partner category + the four-quadrant read
Closed-won read: what the retroactive review showed about existing ecosystem influence
Gaps           : uncovered segments/geographies/journey stages, each sized
Conflicts      : zones detected, accounts and revenue at stake (detection only)
Positioning    : keystone, niche player, or drifting toward dominator  - and why
Priorities     : categories on the 2x2, with the scorecard weights that placed them
Decisions      : what this map asks for, each with an owner and a review date
Open questions : what the data could not answer, and what would answer it

备忘录遵循两条规则：

• 每项主张都要注明来源。“8 笔已签约成交中有 3 笔提到了实施合作伙伴”可以接受审查；“系统集成商对我们很重要”则不行。
• **必须列出未解问题。**一张没有说明不确定性的地图，说明它已经停止发问；这正是装饰性的全景图被误认为证据的原因。

B2B 与 B2C

两者的核心方法完全相同：

• 识别、分析、可视化、优化这一流程。
• 只限定一个业务领域的规则。
• 根据客户数据绘制地图，而非依据入站请求的规则。
• 定期审查的纪律。
• 按战略契合度 × 执行难易度进行优先级排序的逻辑。

用户询问时，就说明这一点。不要为两者分别另创方法。

真正不同之处：

维度	B2B	B2C
合作伙伴术语	经销商／增值经销商、分销商、MSP、系统集成商、ISV、市场平台、联盟	零售／批发、创作者及联盟伙伴、授权、联合品牌
合作伙伴数量	数十到数百家；每家合作伙伴价值高	影响力范围可达数千家，但每家价值低得多
归因	在较长周期内区分来源于合作伙伴与受合作伙伴影响的销售管线	交易型、周期短：比较通过合作伙伴获取的客户与其他渠道客户的 LTV，并衡量品牌提升
典型冲突	合作伙伴之间的冲突，以及直销与合作伙伴之间的冲突	D2C 与零售合作伙伴之间的冲突

两种分类法以及 D2C 与零售之间的冲突模式详见 references/partner-type-taxonomy.md 和 references/overlap-and-conflict.md。

失败模式

这些条目没有效率排序，这是刻意为之，因为每一行都是一种不同的诊断，且各有一个对应的修复方法，而不是针对同一个问题的一组选项。对它们排序，就等于对读者的症状而非可选方案进行排序，这会造成虚假的精确感。应用所有符合情况的条目。

失败模式	修复方法
创建了地图，但从未将其用于决策	为地图附上明确的后续步骤和负责人；将地图纳入定期战略评审
将竞争对手排除在地图之外	绘制竞合关系，以及你们与竞争对手共同拥有的合作伙伴——他们是重要信号
将地图视为已完成	制定评审周期并设置事件触发条件（并购、法规变化、象限变动）
一次性绘制整个公司的地图	将范围限定在一个业务领域；之后针对其他领域重新执行
根据主动请求或个人关系网整理清单	根据客户数据和经过验证的重叠情况重新整理
只收集 Logo——将大量不活跃的合作伙伴计入覆盖范围	查看激活率；合作伙伴名单不等于渠道
所有合作伙伴类型都使用同一张评分卡	按类型调整权重；不同类型通往收入的路径各不相同
招募速度超过赋能速度	合作伙伴数量增加而引荐收入持平，就是明确信号；支持某一类别的能力应纳入其优先级评分

调用示例

• “围绕我们的中端市场产品线绘制合作伙伴生态系统地图——我需要向高管团队展示覆盖缺口。”
• “哪些合作伙伴类别真正影响了我们已赢单的交易？我们有三年的 CRM 历史记录，却没有归因字段。”
• “我们总是签下没有共同客户的合作伙伴。请构建一份本可以提前发现这一问题的重叠分析。”

参考资料

• references/partner-type-taxonomy.md - 旅程角色和深度两个维度、B2B 和 B2C 类型表、存在争议的边界及分类错误陷阱。
• references/overlap-and-conflict.md - 客户映射象限、空白市场规则、三种冲突模式以及 D2C 与零售的冲突，以及成果格式表。
• references/prioritization-scorecards.md - 加权评分卡机制、Lavoie 2×2、两者的结合方式，以及带演算过程的类别示例。
• references/ecosystem-health-kpis.md - 来源归因与影响归因、激活率、四象限框架、带来源标记的基准数据。
• references/discovery-workshops.md - 价值网络分析研讨会形式、Adner 的价值蓝图、IPP 定义会议、JVP 研讨会问题集。

关联技能（后续交接，同属一个合集）：

• mbfinotti/partnerships-skills@partner-channel-program - 设计此映射表表明有必要建立的合作伙伴计划。
• mbfinotti/partnerships-skills@partner-tiering - 现有计划中的层级标准和权益；映射表中的同心圆表示布局，而非层级。
• mbfinotti/partnerships-skills@partner-ecosystem-expansion - 规划要加入此映射表量化的空白市场的合作伙伴类别。
• mbfinotti/partnerships-skills@alliance-prioritization - 为指定的联盟候选对象排序；此技能仅为类别排序。
• mbfinotti/partnerships-skills@partner-channel-conflict - 针对此映射表检测到的冲突区域制定合作规则。
• mbfinotti/partnerships-skills@partner-performance - 针对单个合作伙伴的评分卡和评审周期，超出此映射表的生态系统级诊断范围。