mcpField
P
partner-marketplace-strategy

partner-marketplace-strategy

github.com/mbfinotti营销与增长214.3k 次安装3 天前更新
代码仓库

关于 partner-marketplace-strategy

partner-marketplace-strategy 是供高管决定是否以及如何在第三方市场上架产品的技能。它形成决策备忘录,涵盖市场优先级、参与深度、投入、阶段门槛和退出条件,不负责执行上架。

主要功能

  1. 01评估市场准备度与需求
  2. 02梳理并筛选候选市场
  3. 03按商定的评分权重确定优先级
  4. 04比较参与深度与经济性
  5. 05依据证据和门槛安排投入
  6. 06制定投资回报衡量与下架触发条件

适用场景

  1. 01判断产品是否适合进入第三方市场
  2. 02排列云市场、应用商店或零售市场优先级
  3. 03在工程或运营资源受限时规划投入
  4. 04设定上架复审指标与退出条件

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/mbfinotti/partnerships-skills --skill partner-marketplace-strategy

安装后在 Claude Code 中输入/partner-marketplace-strategy确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

evals/
evals.json
references/
marketplace-economics.md
marketplace-taxonomy.md
prioritization-scorecard.md
roi-and-kpis.md

详细介绍

合作伙伴 Marketplace 策略

制定在第三方 Marketplace 上架的策略:选择哪些平台、投入多深、按什么顺序、投入多少资源,以及在什么条件下停止。工作方法整合了:

  • “上架 → 交易 → 联合销售 → 扩大规模”能力阶梯(B2B 从业者的广泛共识)。
  • Tackle 的 Cloud GTM 成熟度模型(由供应商编写,其业务是逐阶段销售工具)。
  • McFadyen Digital 的 Marketplace 成熟度模型(由咨询公司编写,面向 B2C)。
  • 用于了解供应商格局的资料:Canalys 全球联合销售软件领导力矩阵、IDC MarketScape Marketplace 评估、Gartner 的 PERM 市场指南(独立分析师),以及 Jay McBain 的生态系统研究——他是最值得信赖的个人声音。

该领域没有任何框架经过独立的纵向验证。每个分阶段模型都由销售这段旅程的一方编写:将其用作结构,而非证据。

最终产出是供高管拨款决策的决策文件:Marketplace 策略备忘录,而非执行工作。

  • 上架内容、商店优化和广告策略应由其他工作负责。
  • 按合作伙伴核算经济效益、对具名联盟进行排序,以及制定联合 GTM 计划,应交由相关技能处理(参见 Reference)。

访谈

制定策略前先提问。每条消息只问一个问题,并尽可能提供多项选择答案。只有当用户已经给出答案时,才跳过问题。

  • 是 B2B 软件、消费品牌,还是混合型?
  • 产品类型和部署模式是什么:SaaS、可自托管/可安装镜像、实物商品,还是服务?
  • 价格区间是多少:典型 ACV 或订单金额、毛利率是多少?平台抽成会消耗多少利润?
  • 目前通过哪些渠道销售?直接销售模式是否已能重复奏效?证据是什么?
  • 目标买家的采购目前集中在哪里:承诺的云支出(以及对应的云服务提供商)、主导性的零售平台,还是都不是?
  • 买家现在是否通过 Marketplace 采购?目标客户中是否有承诺支出合同?
  • 谁负责这项决策,哪些人必须批准(营收、财务、产品——或电商、营销、财务)?
  • B2B:目前如何处理通过 Marketplace 引入的交易的销售佣金——不受影响、受到惩罚,还是尚无规定?
  • 运营能力:计量/权益管理工程、交易服务台、B2B 税务/法务,或 B2C 库存、履约、退货、零售媒体预算?
  • 成功意味着什么、用什么指标衡量,以及必须在什么日期前取得成果?
  • 这是本期的一次性营收收益,还是能在多年间持续产生回报的采购资产?
  • 努力程度上限是什么:可投入的工程周数、交易服务台或履约团队人数、推动薪酬计划变更所需的政治资本,以及承诺必须具备多强的可逆性?

最后三个答案会重新排列此技能中的所有选项。明确说明哪个答案改变了哪些选项:

  • 严格的近期截止日期会提升仅上架和 3P 选项的优先级,并降低任何需要构建的选项的优先级。
  • 追求长期复利的目标会提升私有报价和深度平台下注方案的优先级。
  • 努力程度上限较低时,应直接从备忘录中删除渠道/多方和混合型方案,而不是将它们搁置在末尾。

工作流

在每个步骤中坚持三项原则:

  • 先给出选项,再等待。 只要存在真实选择(先做哪个平台、评分卡权重、参与深度、1P 还是 3P、下架条件),就先给出 2–3 种备选方案,说明各自的权衡并提出建议,然后等待。绝不要把某个选项说成唯一选择。
  • 为引用的每项基准数据标注来源性质。 几乎所有已发布的 marketplace ROI 数据都来自能从漂亮数字中获利的相关方:平台委托的研究、GTM 工具供应商、代理机构。请将每项标注为运营方发布、供应商、委托研究、分析师或代理机构,并将精确数字视为营销手段。
  • 根据用户情况重新排序。 本技能及其参考资料中的所有排序都是默认建议,而非铁律:排序会随情境和执行者而变化。说明是什么事实改变了哪些选项的顺序,例如,已有计量和权益管理系统会大幅降低可交易方案的成本;已有承诺支出且主动要求通过 marketplace 采购的客户,会让私有报价方案排在其他所有方案之前;完全没有交易支持团队,则会让它排在团队实际能够执行的方案之后。

使用本专业领域的协作方式,而非泛泛的头脑风暴:

  • B2B:业务论证模板和阶段门准备度评审、与 marketplace/平台团队进行 QBR、在季度开始前起草佣金中立政策、将账户映射作为共享数据层。
  • B2C:渠道损益模型、书面的继续/停止标准、上线前准备清单、每周进度回顾和 90 天复盘。
  1. 开展访谈。在评估任何事项之前,确认范围仅涵盖一个业务领域,并明确目标。

  2. 应用准备度门槛。可以回答“尚未准备好”。淘汰条件:

    • 直销模式尚不可重复:marketplace 能放大有效的销售模式,但无法创造这种模式。
    • 利润率无法承担抽成比例及服务成本。先确定部署模式,因为抽成比例由此决定:AWS Marketplace 上,SaaS 列表为 3%,而服务器/AMI/容器/ML 镜像为 20%;仅这一差距就足以决定是否通过此门槛。
    • 没有明确指定的负责人或高管赞助人。
    • 缺乏运营能力,且没有预算来补足。

    如果未通过资格审查,请说明原因,指出需要改变什么,然后停止。

  3. 开展需求与采购诊断,并书面记录答案。marketplace 主要是交易和采购渠道,而非需求生成渠道:“上架后祈祷”是 B2B 和 B2C 中被提及最多的失败原因。

    明确说明此次上架的目标:

    • 解锁承诺支出预算并缩短采购周期。
    • 捕捉确实会在该平台上搜索的需求。

    如果计划依赖平台不会带来的需求,就为需求生成提供资金,否则就不要继续。

  4. 按类别盘点候选 marketplace(超大规模云平台/云、SaaS 应用商店、集成目录、零售 marketplace、区域领先平台),并以访谈中所述的买家采购和流量所在位置为依据。按默认效率顺序评估:单位投入所带来的价值。投入包括工程周数、交易支持团队的返工和可逆性,绝不包括费用。以下两个排序适用范围不同:

    • B2B:hyperscaler cloud > integration directory > SaaS app store
    • B2C:dominant retail marketplace > regional champion

    如果可以浏览网页,请根据竞争对手的上架情况、平台合作伙伴目录和同类产品扩展盘点范围。各个维度的排序及其会牺牲的内容,请参阅 references/marketplace-taxonomy.md。

  5. 在评分前筛除硬性门槛不满足的候选项:范围违规、企业无法接受的平台条款、缺少前置条件。未解决的合规或费用问题标记为“待核实”。绝不把未知情况判定为拒绝或接受。

  6. 按加权优先级评分表为通过筛选的候选项评分:提出权重,并在评分前与用户达成一致;对缺乏依据的维度不予评分,不要凭空制造精确度。然后根据暂定的影响力估算,应用第二轮“影响力 × 工作量”筛选——ROI 模型要到第 11 步才会构建,因此请将该轴标为“暂定”,并让尚无法绘制的候选项保持未绘制状态,不要凭空编造影响力数值。为每个候选项指定四种结果之一——试点、准备、待核实、不优先考虑,而不是简单地二选一、决定是否推进。请参阅 references/prioritization-scorecard.md。

  7. 核实每个排名候选项的经济效益。

    • 如果可以浏览网页,请查阅运营方自行发布的费率表,并注明日期。
    • 否则,请向用户索取费率表;对于用户无法提供的信息,标记为“未核实”,不要自行假设费率。

    如果运营方完全没有发布费率表,请将此记录为一项发现:费用是谈判输入,而非常量。业务案例需针对已公布的未来费率和补贴结束后的费率进行压力测试,而不仅仅是当前费率。请参阅 references/marketplace-economics.md。

  8. 确定每个优先市场的参与深度。每一级都有自身的成本和能力门槛,因此应按单位工作量的价值排序,而不是按级别顺序排列:

    • B2B 云:private offer > transactable > list-only > channel offer
    • SaaS 应用商店:transactable paid app > free listing > deep platform bet
    • 零售:3P > 1P > hybrid

    云市场的各级别是累积的:业务案例应以 private-offer 级别为目标,并将 transactable 视为抵达该级别的成本,因为止步于 transactable 的案例会付出工程成本,却让更大一半的价值白白流失。从备忘录中删去所有超出用户工作量上限的级别,并明确指出删去了哪些级别。不要把它们留在列表末尾。各轴的排序、并列项及每种排序会牺牲什么,请参阅 references/marketplace-taxonomy.md。

  9. 排定顺序:先选一个平台,证明这一做法可行,然后再扩展。为解锁每个阶段设定门槛——例如,完成首批交易(在 B2B 中,续约是有文档记录的低风险验证路径)、书面佣金政策、贡献利润为正——并明确每道门槛所需的证据。

  10. 设定投资上限:平台费用、实际服务成本,以及指定负责人的时间。

    • B2B 服务成本:集成/计量工程、交易支持、法律/税务设置。
    • B2C 服务成本:履约、退货准备金、实际上不可或缺的零售媒体费用。

    没有负责人和预算上限的上架只是提升曝光,而非建立销售渠道。

  11. 建立 ROI 预期及其衡量计划:

    • 上架前建立基线。
    • 与财务部门商定来源销售与影响销售的定义。
    • 将净新增收入与渠道迁移收入分开。
    • 为各方制定 KPI。

    仅将已发布的基准作为注明来源的上限,不要用作基准情景。然后,使用完成后的模型重新执行第 6 步的“影响力 × 工作量”筛选,并记录象限发生变化的每个候选项。这种变化是一项发现,不应掩盖或当作错误修正。请参阅 references/roi-and-kpis.md。

  12. 现在就写下下架/降低优先级的触发条件,并在上线前确定:写明会导致下架或降级的条件和审核日期(例如,在约定数量的季度内做出真正努力后仍无交易,却持续产生运营成本;或扣除广告和退货成本后的贡献利润率为负)。预先确定触发条件,才能抵御沉没成本压力。事后才决定,往往不会触发。

  13. 按下方所示顺序逐节呈现备忘录,并在起草下一节前让用户确认当前章节。每一节定稿前都必须获得明确批准。

  14. 根据通过门槛检查完成后的备忘录,并持续迭代,直至达标。如果没有候选平台达标,建议不上架并记录原因:这是有效且可获得资金支持的结果。

  15. 如果你的执行框架具有持久记忆功能,请记住已批准的决策(市场平台排名、权重、深度选择、预算范围、关卡、下架触发条件),以便后续运行能以此为起点,而不是重新访谈。

市场平台策略备忘录

每次合作都应交付以下决策记录:

MARKETPLACE STRATEGY  - <company / business area>, <date>
Scope          : product line, ICP, geography; B2B, B2C, or hybrid; what was excluded
Diagnosis      : demand vs procurement  - what each listing is being asked to do
Candidates     : marketplaces evaluated, hard-gate screen results, holds for verification
Prioritization : scorecard result with weights shown; second-pass filter; four-way
                 outcome per candidate (pilot / prepare / hold / do not prioritize)
Depth          : per marketplace  - list-only / transactable / private offer / channel
                 offer (B2B) or 1P / 3P / hybrid (B2C); the rung funded, the reason,
                 and the rungs deleted because the effort ceiling rules them out
Economics      : take rate per ranked marketplace with source and date ("unverified"
                 stated where it is); envelope vs gross margin; comp treatment (B2B)
                 or contribution margin after ads/returns/fulfilment (B2C), in writing
Staged plan    : one platform first; the gate and evidence that unlock each stage
ROI expectation: expected range and payback horizon; provenance flag on every
                 benchmark used to build it
Delist trigger : the condition and date that deprioritizes or removes each listing
Owner          : named owner, approvers, review date
Open questions : what could not be verified, and what would verify it

每一行都必须说明审核者可以核查的理由。待解问题部分不可缺少:没有明确说明不确定性的备忘录,说明问题还没问完。

通过门槛

满足以下所有条件后,备忘录才算完成。持续迭代,直至全部达标:

  • 每个排名中的市场平台都列明费率,并注明来源和日期:有运营方自行发布的费率表时,注明该费率表;没有时,明确标注为“未经核实”。不得默默假定费率。
  • 商业论证经得起运营方已公布的未来费率和补贴结束后的费率考验,而不只是基于当前费率表。
  • 明确指定负责人和审批人:“已上架,但无人负责结果”是业内最常见、却鲜少被提及的失败原因。
  • 上线前以书面形式决定:B2B 的薪酬处理方式,或 B2C 扣除广告、退货和履约成本后的贡献利润率。
  • 每项基准数据都标注来源类型(运营方、供应商、委托研究、分析师、代理机构)。
  • 在审批时以书面形式确定下架触发条件和审核日期。
  • 在备忘录中明确回答需求与采购之间的判断问题。

B2B 与 B2C

这两者的决策逻辑在五个方面完全相同。应当明确指出这一点,而不是针对不同场景重新发明方法:

  • 市场平台是一种交易机制,而非潜客来源(“上架后听天由命”在两种场景中都行不通)。
  • 渠道冲突是需要优先考虑的设计问题(B2B 中要保持薪酬计划中立,B2C 中要制定 MAP 政策并设立 1P/3P 防火墙)。
  • 先选择一个平台,验证成效,然后再扩展;扩展的前提是运营已准备就绪。
  • 衡量受影响收入以及来源收入。
  • 关注集中度风险,以及新增收入与转移收入之间的区别。

真正不同之处:

维度B2B 软件 / 云B2C / 零售
决策负责人联盟 / 云 GTM 负责人、首席合作伙伴或生态系统官电商负责人 / 副总裁、市场平台经理
审批人CRO + CFO + 产品团队电商副总裁 / CMO + 财务部门
核心购买驱动因素已承诺支出的消耗 + 联合销售渠道消费者需求、搜索排名、履约承诺
平台抽成取决于部署方式,并非固定比例:SaaS 为 3%,但在最大的云市场平台上,服务器 / AMI / 容器 / ML 镜像为 20%;费率会随交易规模增加和续约而下降按品类为 6-45%,另加履约和广告费用
主要成功指标销售薪酬中立扣除广告 / 退货 / 履约成本后的贡献利润
市场平台的真正定位现有销售流程中的采购通道新增的运营业务(商品刊登、库存、广告、退货)

失败模式

失败解决方法
只管上架、听天由命——把上架当作需求渠道以书面形式分析需求与采购之间的关系;单独为需求投入资金,否则就不要上架
薪酬计划对通过市场成交的订单不利;销售代表因此绕开市场(B2B)在季度开始前,将薪酬中立政策写入备忘录
已上架,但无人负责结果在备忘录中指定负责人并明确资源额度;没有负责人就不上架
商业论证基于当前抽成比例或初始的 0% 费率档位对已公布的未来费率和补贴结束后的费率进行压力测试
隐藏的服务成本导致后期论证站不住脚(计量、税费、交易支持;增值税、退货、广告)批准前将完整的服务成本纳入资源额度
同一产品的 1P/3P 竞争或价格下滑(B2C)在转为混合模式前确定防火墙和定价政策
将转移过来的收入计入市场投资回报率上架前设定基线;区分新增收入与转移收入
第一个平台尚未得到验证就添加第二个平台设定基于证据的阶段关卡;先在第一个平台上验证续约
延迟做出下架决定,直到沉没成本占据主导地位在批准时写明触发条件和日期

调用示例

  • “我们应该在云市场上架吗?我们销售自托管容器镜像,ACV 为 $40K,以销售驱动为主,直接销售模式行之有效。”
  • “我们已在三个市场上架,但都没有成交。请告诉我该保留哪些、该降低哪些优先级,以及下架触发条件应该是什么。”
  • “请为可交易的上架方式构建商业论证,包括抽成比例和实际服务成本。”

参考资料

同系列技能:

  • mbfinotti/partnerships-skills@partner-ecosystem-expansion - 扩展市场以外的新合作伙伴类别;用于确定非市场渠道的范围。
  • mbfinotti/partnerships-skills@co-selling-strategy - 可交易的云市场上架所解锁的联合销售模式。
  • mbfinotti/partnerships-skills@joint-gtm-planning - 本策略选定一个具体合作伙伴或平台后,与其开展的联合行动。
  • mbfinotti/partnerships-skills@partner-channel-conflict - 针对市场所引发的冲突领域制定的行为准则。
  • mbfinotti/partnerships-skills@partner-performance - 上架开始运行后的持续评分卡和评审节奏。
  • mbfinotti/partnerships-skills@partner-economics - 单个合作伙伴关系的单位经济效益分析,包括单个平台关系。

评论

支持 Markdown