决定在哪些第三方市场平台上架、投入多少…

当需要为B2B云市场、SaaS应用商店、集成目录或B2C零售平台制定上架策略时，用结构化访谈、准备度门槛、加权评分卡和带来源标注的ROI预期来产出可资助的决策备忘录。

适用场景

解决思路

1. 先做访谈再制定策略：每条消息只问一个问题，尽量提供多选题；仅在用户已给出答案时跳过。需问清：B2B软件/消费品牌/混合；产品类型与部署模式（SaaS、自托管/可安装镜像、实物、服务）；价格带（典型ACV或订单价值）与毛利率、平台抽成能吃掉多少利润；当前销售渠道及直销是否已可重复、证据是什么；目标买家的采购已落在哪里（承诺云支出及哪家厂商、主导零售平台、或都没有）；买家今天是否已通过市场平台采购、目标客户中是否有承诺支出合同；谁拥有此决策、谁必须批准（收入、财务、产品，或电商、市场、财务）；B2B中市场平台路由的交易在销售薪酬中如何处理（中性、惩罚、未定义）；运营能力（B2B的计量/授权工程、交易台、税务/法务，或B2C的库存、履约、退货、零售媒体预算）；成功以哪个指标衡量、必须在什么日期前达成；是一次性本季度收入还是多年复利的采购资产；努力上限（可用工程周数、交易台或履约人力、改变薪酬计划的政治资本、承诺必须可逆的程度）。最后三个答案会重新排序所有选项菜单，要明确说出哪个答案改变了哪个选项：紧迫的近期日期会提升仅上架和3P、降低任何需要构建的选项；复利使命会提升私有报价和深度平台押注层级；低努力上限会直接从备忘录中删除渠道/多方和混合层级，而不是把它们排在底部。
2. 全程保持三项纪律：先呈现选项再等待——凡存在真实选择（先上哪个平台、评分卡权重、参与深度、1P vs 3P、下架条件），都给出2-3个候选方案及权衡和推荐，然后等待，绝不只给一个选项；对引用的每个基准标注来源——几乎所有公开的市场平台ROI数字都来自因数字好看而获利的各方（平台委托研究、GTM工具厂商、代理机构），标注为运营方发布、厂商、委托研究、分析师或代理机构，并把精确度当作营销；针对用户重新排序——本技能及参考中的所有排序都是默认值而非定律，会随上下文和执行者变化，要说明哪个事实改变了哪个选项，例如已有计量和授权系统会删除大部分可交易层级的成本，已有承诺支出客户要求通过市场平台购买会把私有报价层级提升到一切之上，完全没有交易台会把它降到团队实际能运行的层级之下。
3. 使用本行业自己的协作格式而非通用头脑风暴：B2B用商业案例模板和阶段门准备度评审、与市场平台团队的QBR、季度前起草的薪酬中性政策、作为共享数据层的客户映射；B2C用渠道P&L模型、书面go/no-go标准、上线前准备度检查清单、每周节奏评审和90天复盘。
4. 运行访谈，确认范围是一个有明确目标的业务领域后再评估任何内容。
5. 应用准备度门槛，允许回答“尚未准备好”。取消资格项：直销尚不可重复（市场平台放大已运作的动势，不会创造动势）；毛利率无法吸收抽成加服务成本（先解决部署模式，因为抽成随其而定：SaaS上架为3%，但AWS Marketplace上的服务器/AMI/容器/ML镜像为20%，这一差距本身就能决定此门槛）；没有指定负责人或高管赞助人；缺少运营能力且无预算建设。若不合格，明确说明、指出必须改变什么并停止。
6. 运行需求vs采购诊断并写下答案。市场平台主要是交易和采购轨道，不是需求生成渠道，“上架然后祈祷”是B2B和B2C中最常被引用的失败。明确说明此上架被要求做什么：解锁承诺支出预算并缩短采购；捕获真正在那里搜索的需求。如果计划假设平台不会提供的需求，则计划要么资助需求生成，要么不推进。
7. 按类别盘点候选市场平台（超大规模云、SaaS应用商店、集成目录、零售市场平台、区域冠军），锚定在访谈所说买家采购和流量已所在之处。按默认效率顺序评估：每单位努力返回的价值，努力是工程周数、交易台返工和可逆性，绝不是费用。没有跨两侧的顺序：B2B为超大规模云 > 集成目录 > SaaS应用商店；B2C为主导零售市场平台 > 区域冠军。若能浏览网页，从竞争对手上架、平台合作伙伴目录和类别邻居扩展盘点。参见references/marketplace-taxonomy.md了解各轴排序及每种排序会饿死什么。
8. 评分前先筛硬门槛：范围违规、业务无法接受的平台条款、缺失的前置条件。将未解决的合规或费用问题标记为“待验证”。绝不把未知转化为拒绝或接受。
9. 对幸存者按加权优先级评分卡打分：提出权重，评分前与用户达成一致，对无支撑的维度不评分而非编造精确度。然后基于临时影响估计应用第二遍影响×努力过滤器——ROI模型要到第11步才构建，所以把该轴标为“临时”，宁可让候选未绘制也不编造影响数字。给每个候选四向结果——试点、准备、待验证、不优先——而非二元go/no-go。参见references/prioritization-scorecard.md。
10. 验证每个已排名候选的经济性。若能浏览网页，阅读运营方自己发布的费率表并注明日期。否则向用户索取，并将用户无法提供的内容标为“未验证”而非假设费率。若运营方完全不发布费率卡，将其记录为发现：费用是谈判输入而非常数。用已宣布的未来费率和补贴后费率压力测试商业案例，而不只是今天的。参见references/marketplace-economics.md。
11. 决定每个优先市场平台的参与深度。每个层级有自己的成本和能力门槛，所以按每单位努力的价值排序而非按层级顺序：B2B云为私有报价 > 可交易 > 仅上架 > 渠道报价；SaaS应用商店为可交易付费应用 > 免费上架 > 深度平台押注；零售为3P > 1P > 混合。云层级是累积的：把商业案例瞄准私有报价层级，把可交易当作到达它的通行费，因为止步于可交易的案例支付了几乎全部成本却只得到较小一半价值。从备忘录中删除用户努力上限排除的每个层级，并说明是哪些。绝不把它停在底部。参见references/marketplace-taxonomy.md了解各轴排序、并列情况及每种排序会饿死什么。
12. 排序：先做一个平台，证明动势，再扩展。定义解锁每个阶段的门槛——例如首批交易完成（续约是B2B中有记录的低风险证明路径）、薪酬政策书面化、贡献毛利为正——以及每个门槛需要的证据。
13. 设定投资包络：平台费用、真实服务成本和指定负责人的时间。B2B服务成本：集成/计量工程、交易台、法律/税务设置。B2C服务成本：履约、退货准备金、实际上强制的零售媒体。没有负责人和包络的上架是可见性，不是管道。
14. 构建ROI预期及其测量计划：上架前基线；与财务商定的来源vs影响定义；净新增vs转移收入分开；每侧KPI。仅将公开基准用作带来源标注的上限，绝不作为基准情形。然后针对完成的模型重新运行第6步的影响×努力过滤器，并记录每个象限移动的候选。这种移动是发现，不是要掩埋的更正。参见references/roi-and-kpis.md。
15. 在上线前写下下架/降级触发器：结束或降级上架的条件和评审日期（例如经过约定季度数的真实努力后运营成本无交易，或广告和退货后贡献毛利为负）。事先决定的触发器能抵御沉没成本压力。事后决定的很少触发。
16. 按以下顺序逐节呈现备忘录，并在起草下一节前与用户验证每一节。定稿前要求每节明确批准。
17. 对照通过阈值检查完成的备忘录，并迭代直到通过。若无候选通过，建议不上架并记录原因：这是有效且可资助的结果。
18. 若你的运行环境有持久记忆，记住已批准的决策（已排名市场平台、权重、深度选择、包络、门槛、下架触发器），以便后续运行从这些开始而非重新访谈。
19. 按以下结构交付决策记录：MARKETPLACE STRATEGY - <公司/业务领域>, <日期>；Scope：产品线、ICP、地域；B2B、B2C或混合；排除了什么；Diagnosis：需求vs采购——每个上架被要求做什么；Candidates：评估的市场平台、硬门槛筛选结果、待验证项；Prioritization：显示权重的评分卡结果；第二遍过滤器；每个候选的四向结果（试点/准备/待验证/不优先）；Depth：每个市场平台——仅上架/可交易/私有报价/渠道报价（B2B）或1P/3P/混合（B2C）；资助的层级、原因，以及因努力上限被删除的层级；Economics：每个已排名市场平台的抽成及来源和日期（无则写“未验证”）；包络vs毛利率；薪酬处理（B2B）或广告/退货/履约后贡献毛利（B2C），书面化；Staged plan：先一个平台；解锁每个阶段的门槛和证据；ROI expectation：预期范围和回收期；用于构建它的每个基准的来源标注；Delist trigger：降级或移除每个上架的条件和日期；Owner：指定负责人、批准人、评审日期；Open questions：无法验证的内容及如何验证。每行都带有评审者可检查的理由。开放问题部分是强制的：没有陈述不确定性的备忘录已停止提问。
20. 确保备忘录满足通过阈值：每个已排名市场平台都有带来源和日期的抽成（有运营方发布费率表则用其，无则明确“未验证”），没有静默假设的费用；商业案例能承受运营方已宣布的未来费率和补贴后费率，而不只是今天的；存在指定负责人和批准人（“已上架但无人对结果负责”是该领域最常见的隐性失败）；B2B薪酬处理或B2C广告/退货/履约后贡献毛利在上线前书面决定；每个基准带来源标注（运营方、厂商、委托研究、分析师、代理机构）；批准时写下带评审日期的下架触发器；备忘录中明确回答需求vs采购诊断。
21. B2B和B2C在五点上决策逻辑完全相同，要直接说明而非每侧重新发明：市场平台是交易机制而非线索来源（“上架然后祈祷”在两侧都失败）；渠道冲突是一等设计问题（B2B薪酬中性，B2C MAP政策和1P/3P防火墙）；先做一个平台、证明它、再扩展，扩展以运营准备度为门槛；同时衡量影响收入和来源收入；关注集中度风险和净新增vs转移收入。真正不同的是：决策负责人（B2B为联盟/云GTM负责人、首席合作伙伴或生态官；B2C为电商负责人/VP、市场平台经理）；批准人（B2B为CRO+CFO+产品；B2C为电商VP/CMO+财务）；核心购买驱动（B2B为承诺支出消耗+联合销售访问；B2C为消费者需求、搜索排名、履约承诺）；平台抽成（B2B随部署而定非常数：最大云市场上SaaS为3%但服务器/AMI/容器/ML镜像为20%，随交易规模和续约下降；B2C按类别6-45%，外加履约和广告）；主要成功变量（B2B为销售薪酬中性；B2C为广告/退货/履约后贡献毛利）；市场平台实际是（B2B为现有销售动势上的采购轨道；B2C为净新增运营业务，含上架、库存、广告、退货）。
22. 避免以下失败模式并采用对应修复：上架然后祈祷——把上架当作需求渠道，修复是书面需求vs采购诊断，单独资助需求否则不上架；薪酬计划惩罚市场平台交易、销售代表绕行（B2B），修复是季度前书面薪酬中性政策并写入备忘录；已上架但无人对结果负责，修复是备忘录中指定负责人和包络，无负责人即不上架；商业案例基于今天抽成或介绍性0%档，修复是用已宣布未来费率和补贴后费率压力测试；隐藏服务成本后期破坏案例（计量、税务、交易台；VAT、退货、广告），修复是批准前把完整服务成本纳入包络；1P/3P自我竞争或同产品价格侵蚀（B2C），修复是混合前决定防火墙和定价政策；转移收入被计为市场平台ROI，修复是上架前基线、净新增与转移分开；第一个平台未证明就加第二个，修复是带证据的阶段门、平台一上续约优先证明；下架决策推迟到沉没成本主导，修复是批准时写下触发器和日期。

适用边界 · 注意事项

• 不用于选择下一个要启动的合作伙伴类别——应使用mbfinotti/partnerships-skills@partner-ecosystem-expansion。
• 不用于上架形式内容、商店优化和广告战术。
• 不用于单个合作伙伴经济性、具名联盟排名和联合GTM计划——这些交给兄弟技能。