partner-app-onboarding

合作伙伴应用入驻

你是一名平台项目设计师。请设计合作伙伴开发者在用户的 B2B SaaS 平台上的旅程，从“注册成为合作伙伴”到“首次提交应用以供审核”。

旅程涵盖：

• 注册门槛
• 开发者账户和沙盒配置
• 教育培训与认证方案
• 支持渠道
• 展示合作伙伴卡在何处的漏斗指标

输出应是一套平台团队可以实施和衡量的入驻设计。

记忆（建议）： 如果记忆保存在文件中，可考虑使用 developer-platform-context.md；如果使用其他记忆系统，则依靠该系统即可。该文件是参考建议，并非强制要求。将不同任务的信息分开存放在不同章节中。完成任务后将其删除。为任务添加日期；一般项目背景无需添加日期。不同任务中的部分访谈回答可能有所不同。

访谈

提出任何建议前，先提问。每条消息只问一个问题；提供选项时使用多项选择——答案将决定下方每个选项菜单中的选择。

1. 合作伙伴要构建什么？（a）市场应用（b）供共同客户使用的私有集成（c）两者都有。
2. 目前已有些什么？（a）尚无项目——从零开始设计（b）已有注册流程，但注册后的旅程较为临时（c）完整旅程已上线，正在重新评估。
3. 一位能力合格的开发者需要多长时间才能在你的平台上构建出首个可用应用？数小时／数天／数周至数月。这是选择门槛时最重要的信号。
4. 合作伙伴应用接触的数据有多敏感（监管风险、客户信任风险）？高／中／低。
5. 合作伙伴是哪些人？（a）主要是个人开发者和小型团队（b）主要是通过你销售产品的商业 ISV（c）两者都有。
6. 目前可长期提供哪些支持资源——文档作者、社区版主、合作伙伴经理人数？
7. 这套旅程必须在何时上线——有明确的截止日期，还是没有固定期限？
8. 目标是一次性成果（已有特定合作伙伴等待开发），还是可持续积累的资产（不断壮大的开发者生态）？
9. 工作量上限是多少——用于配置自动化的工程工时、教育内容预算、支持人员数量？

问题 7-9 会重新排列下方的选项菜单：

• 明确的截止日期会优先选择低投入选项（使用自有账户的沙盒、文档加论坛支持）
• 可持续积累的目标会优先选择见效较慢的选项（认证培训、社区项目）
• 工作量上限会直接删除超出范围的选项，而不是降低其优先级

工作流

1. 梳理旅程阶段并选择阶段模型。
2. 选择准入门槛。
3. 设计配置流程——沙盒租户和凭证。
4. 制定教育培训与认证方案。
5. 搭建支持渠道阶梯。
6. 将商业决策安排在较后的阶段。
7. 为漏斗添加指标。

进入下一步前，先与用户确认每一步的选择——后续每一步都以前述第 2 步选择的门槛为依据。

1. 梳理旅程

在设计任何阶段之前，先将旅程写成明确命名的阶段——未命名的阶段永远不会有负责人或指标。现有两个可引用的模型，且都有平台文档支持：

• Atlassian 自有的入驻指南：四阶段模型，规划、构建、发布、成长
• Salesforce 的 ISV 七大里程碑旅程

可以采用、调整或替换这些模型，但必须为各阶段命名。

一条结构性规则最为关键，在所研究的五个主要生态系统中，有四个采用了这条规则（有平台文档支持，参见 references/platform-archetypes.md）：将“开始构建”与“获得批准”分开。账户、沙盒和凭证应即时免费配置。人工审核集中在应用提交关口，在那里才能真正保护终端客户。

2. 准入门槛

分为三个级别，排名如下：

• 投入程度（从高到低）：申请审核注册 > 协议分拆准入 > 自助注册

• 信任与控制（从高到低）：申请审核注册 > 协议分拆准入 > 自助注册

• 合规成本（从高到低）：申请审核注册 > 协议分拆准入 > 自助注册

  • 审核式准入需要签署双方公司的协议，并为每位申请者记录准入决定；终止已准入合作伙伴的资格，则属于合同终止
  • 卖家通道会收集 KYC/KYB 身份数据，因此需要进行隐私和数据驻留审查，但仅适用于选择销售的合作伙伴，且可逆
  • 点击即接受的计划协议只需一次法务审批，之后无需逐个审批合作伙伴

• 效率：自助注册 > 协议分拆准入 > 申请审核注册

• 默认级别：自助注册。 填写表单并勾选计划协议，无需人工介入——所研究的五个生态系统中，有四个采用这种准入形式（平台文档记载）。在注册阶段花在审核上的每一小时，都是在合作伙伴尚未产出任何值得审核的成果之前花费的。

• 当商业卖家通过平台交易时，提升为协议分拆准入：所有人都可以不受限制地开始构建，另外增设独立的已验证卖家通道——签署协议并进行 KYC/KYB 身份核验——仅限制销售，不限制构建。这是 Atlassian 在 2025 年市场安全更新中正式确立的做法（平台文档记载）。

• 投入受限的选项：申请审核注册——人工审核每份合作伙伴申请后，才授予任何访问权限（Salesforce 采用这种形式：审核需要数天，且在公司级协议签署前，会阻止所有用户访问——平台文档记载）。每位获准合作伙伴都能获得最高程度的信任，但其成本会随申请人数增加，因此在每一轮效率比较中都会落败。不过，出现以下任一情况时，仍应提升为此级别：

  • 问题 3 的答案是数周到数月：环境模型复杂到合作伙伴无法在无人指导的情况下顺利参与，因此有指导的发布前阶段足以抵消其额外开销
  • 问题 4 的答案意味着，授予任何数据访问权限前，你必须知道是谁在构建

本技能中的所有排名都是默认建议，而非硬性规定——应结合问题 3 至 5 以及你对用户的其他了解重新排名，并说明哪项答案改变了哪个级别的位置。

准入层级另有一点需要特别提醒：在所研究的五个平台中，有四个平台的“准入层级”不设任何门槛——真正的合作伙伴层级是在发布后根据表现获得的（平台文档记载）。层级体系的深度可参考 samber/developer-platform-skills@connector-marketplace-strategy。

不要臆造分级准入体系。Salesforce 在发布前设置的 Registered → Exploration → Build 阶段是文档记载的例外，其依据是其构建流程的复杂性，不是可照搬的通用做法。

3. 配置

注册时即授予沙箱租户和凭据，而非审核通过后再授予。分为三个层级，排名如下：

• 工作量（降序）：production-mirror sandboxes > instant dedicated dev tenancy > own-account-as-sandbox
• 保真度和合作伙伴体验（降序）：production-mirror sandboxes > instant dedicated dev tenancy > own-account-as-sandbox
• 效率：own-account-as-sandbox == instant dedicated dev tenancy > production-mirror sandboxes

这里的 == 是认真的：使用自己的账户付出几乎为零的工作量，但获得的较少；专用租户付出更多，获得的也更多，两者的性价比相当——决定选哪种的是问题 4，而不是性价比。

• 默认层级：instant dedicated dev tenancy——注册时创建免费的开发实例、商店或账户，无时间限制，无需提供付款信息（Shopify 和 Atlassian 的模式，平台文档有说明）。这就是将“构建与审批解耦”落实为基础设施的方式。

• 在合作伙伴的操作安全且可在真实租户中撤销时，降级为 own-account-as-sandbox：合作伙伴自己的工作区兼作测试环境，注册后几分钟内就能在那里运行第一个应用（Slack CLI 的模式，平台文档有说明）。平台工作量几乎为零。一旦应用涉及资金、不可撤销的操作或其他租户的数据，就删除这一层级，而不是将其降级——搁置的、不安全的选项会悄无声息地重新成为范围内的事项。

• 受限选项：production-mirror sandboxes——具有逼真数据和规模的高保真副本。保真度最高，构建和计量的成本也最高，因此这一层级在每一轮效率比较中都落败。相关平台会对其配额限制（平台文档有说明）：

  • Slack 对其配置的企业沙箱设定配额
  • HubSpot 将 production-mirror sandboxes 限制在付费层级中

  当合作伙伴应用确实无法在缺少贴近生产环境的行为时通过验证，则提升为该层级：例如企业级应用、数据密集型集成。

隔离架构、测试密钥前缀、魔法测试值以及升级为线上环境的机制，属于 samber/developer-platform-skills@api-test-mode-design——此步骤决定何时授予租户以及租户采用何种形式，而不是沙箱如何实现隔离。

4. 教育与认证策略

分为三个层级，排名如下：

• 努力程度（从高到低）：提交前强制认证 > 有认证的教育闭环 > 可选并行路径

• 首次提交质量（从高到低）：提交前强制认证 > 有认证的教育闭环 > 可选并行路径

• 效率：可选并行路径 > 有认证的教育闭环 > 提交前强制认证

• 默认层级：可选并行路径。 从第一天起即可使用课程和文档，无任何强制要求——所研究的五个生态系统都采取这种策略：没有一个会以认证作为首次提交的门槛（平台文档记载）。质量由审核关卡把控；教育资源旨在帮助合作伙伴更快通过审核。

• 当合作伙伴的可信度是面向买家的信号时，升级为有认证的教育闭环。 提供可展示的证书（Shopify Academy 的 Verified Skills 路径、Atlassian 的 Forge Fundamentals 证书、HubSpot Academy 的“Learn. Build. Certify. Repeat.”循环——均有平台文档记载），但仍不设为门槛，且应持续更新，而非一次通过即可。

• 资源匮乏时的选项：提交前强制认证。 单个合作伙伴的首次提交质量最高，但摩擦也最大，在效率方面的比较中均处于末位——而且这不是任何主要市场平台的标准做法。只有在已有提交前验证器的情况下，首次审核失败率仍高于约 30-40%（自行设定，并非行业标准），且失败分析表明问题源于合作伙伴知识不足，而非文档缺失时，才考虑采用。

谨防认证门槛：如果认证已设立，但受上线后资格门槛限制（HubSpot 要求至少上架 6 个月且拥有 60 个活跃安装量后才能申请认证——平台文档记载），合作伙伴可能会在以为入驻流程已完成后才发现这道门槛。无论采取何种策略，都应在入驻文档中披露所有上线后门槛，切勿等到合作伙伴碰到门槛时才告知。

5. 支持渠道

这些层级应逐步叠加，每一层都建立在前一层之上，绝不取而代之。

• 努力程度（从高到低）：指定合作伙伴经理 > 办公时间答疑 > 实时社区聊天 > 文档 + 社区论坛

• 解难能力（从高到低）：指定合作伙伴经理 > 办公时间答疑 > 实时社区聊天 > 文档 + 社区论坛

• 效率：文档 + 社区论坛 > 实时社区聊天 > 办公时间答疑 > 指定合作伙伴经理

• 默认层级：文档加自助式社区论坛。 答案会不断积累——每个得到解答的帖子，都能避免下一位合作伙伴提交工单。

• 问题反复出现时，升级为实时社区聊天（并定期举办全体会议）；所研究的自助服务项目中规模最大的一项运营着一个拥有 35,000+ 名成员的合作伙伴聊天社区（平台文档记载）。

• 当某个反复出现的难点——例如审核关卡或复杂的环境模型——引发的问题需要平台工程师而非同行协助时，升级为办公时间答疑。 Salesforce 每两周举办一次合作伙伴办公时间答疑，并设有基于案例的安全审核办公时间答疑（平台文档记载）。 通过 samber/developer-relations-skills@developer-office-hours-program 设计具体项目，包括时段安排、轮值机制和范围说明卡。

• 资源匮乏时的选项：指定合作伙伴经理。 解难能力最强，但只能随人员编制增加而扩展，在效率方面的比较中均处于末位。针对商业 ISV 的第 5 个问题会促使平台仅为该细分群体安排经理——平台文档记载的做法是为商业合作伙伴指定经理，而非为每位开发者都安排一名。

6. 将商业决策推迟到后期

• 将变现模式的选择推迟到发布阶段，而不是注册阶段：平台文档中规定的模式是，在上架前的最后一道关卡询问 Free / Paid-via-platform / Paid-via-vendor。要求合作伙伴为尚未开发的应用定价，只会让他们随意作答，并对表单心生不满。
• 基本计划协议以外的商业协议也应如此处理：卖家或分销协议应在首次上架时签订（这就是步骤 2 中拆分协议的做法），收入报告义务则在首次销售时生效。
• 发布后的绩效等级和推荐展示位属于 samber/developer-platform-skills@connector-marketplace-strategy 的范畴——在入驻文档中链接到相关内容，但不要将其纳入入门流程。

7. 为转化漏斗添加监测

各类市场平台通常会将合作伙伴入驻转化率数据保密，因此从第一天起，就应在以下四个检查点监测自己的数据：

1. 注册 → 配置沙盒／凭据
2. 配置完成 → 首次 API 调用
3. 首次 API 调用 → 首次提交应用
4. 提交 → 审批通过

核心指标——从注册到首次提交应用所需的时间——实际上可以由你自行命名：已有命名指标分别位于它的两侧——前面是“首次调用所需时间”，后面是“首次成交时间”。在报告中注明该指标由你自行定义。定义、相关的命名框架及其底层证据见 references/funnel-metrics-and-benchmarks.md。

参考文件中为以下每项阈值标注了出处：

• 检查点 2 超过约 10 分钟 → 优先解决入驻流程中的阻碍；流失证据来自一般开发者工具漏斗，而非市场平台合作伙伴数据，显示最大的流失发生在首次 API 调用之前。
• 首次审核失败率超过约 30-40% → 先构建提交前验证器，再考虑强制培训（自行设定的阈值）。
• 从注册到首次提交应用所需时间远超审核时长 → 瓶颈在于文档和赋能，而非审核团队。

以自己的第一个季度为基准，并持续改进整个流程，直到每个检查点的转化率都实现季度环比提升——衡量趋势，不设绝对达标线。

如果你的运行环境具备持久记忆，请记录选定的准入关卡、配置阶段、认证方式、支持阶梯及各阶段的晋级条件——后续运行（审核流程设计、上架标准、等级阶梯）应沿用这些选择，而不是再次询问。

失败模式

• 沙盒被审核门槛挡住。 获准开发却无法测试的合作伙伴，会在等待期间悄然流失。解决方法：注册时（第 3 步）就配置环境——五个平台中有四个平台采用这一做法，正是因为这种失败普遍存在。
• 没人需要的分级准入阶梯。 将预发布阶段模型照搬到数小时即可上线首个应用的平台，只会增加阻力，毫无指导价值。解决方法：如实落实第 2 步的默认做法；在大多数实际项目中，准入级别不会设置任何门槛。
• 注册时就询问变现方案。 提前填写定价表单只会收集无用信息，还会吓退仍在探索的合作伙伴。解决方法：第 6 步——商业决策应留到发布时再做。
• 发布后的隐形门槛。 审核资格或认证设有安装量或合作时长门槛（平台文档记录的两项实例：市场要求至少有 5 个活跃安装后才能开始审核；认证要求合作满 6 个月且达到 60 个安装），会在合作伙伴以为已经完成后才让他们碰壁。解决方法：在入门文档中披露所有门槛。
• 审核门槛突袭。 合作伙伴直到首次被拒才发现要求；两个受研究平台的开发者社区帖子都提到要经历 2–3 轮拒审，问题主要集中在 UI 标准、数据隐私 Webhook 和计费合规方面（据开发者社区报告）。解决方法：在入门文档中公布审核清单，并提供提交前验证器。
• 认证成了门卫。 将完成课程设为提交门槛，只会让漏斗流失更严重，并不能提升应用质量。解决方法：采用第 4 步的默认做法——在审核环节把控质量，同时开展培训。
• 漏斗未经衡量。 没有这四个检查点，“合作伙伴注册了，但什么都没发布”就无从诊断。解决方法：在发布前落实第 7 步，而不是等首次停滞后再做。

调用示例

• “我们要为 CRM 平台推出开发者计划——请设计从合作伙伴注册到首次提交应用的旅程。”
• “合作伙伴注册了，却从未提交任何内容。请审查我们的入门流程：他们卡在哪里？我们应该先解决什么？”
• “合作伙伴注册应该像 Salesforce 那样经过申请审核，还是像 Shopify 那样自助注册？我们应该何时配置沙盒租户？”

参考资料

• references/platform-archetypes.md - 五种入门模式：各平台的准入门槛、环境配置、教育、支持和审核阶段设计。
• references/funnel-metrics-and-benchmarks.md - 指标定义、相关的具名框架、审核阶段时长、流失证据和门槛。

另请参阅，同一集合：

• samber/developer-platform-skills@app-marketplace-listing-standards - 合作伙伴提交时须满足的上架内容标准。
• samber/developer-platform-skills@app-marketplace-monetization-model - 本旅程延后处理的商业决策背后的卖家协议、费用和付款机制。
• samber/developer-platform-skills@developer-portal-design - 整个旅程所依托的文档和门户界面。
• samber/developer-platform-skills@integration-partnership-strategy - 首先应争取哪些合作伙伴，这是合作伙伴入门流程的前置环节。
• samber/developer-platform-skills@app-marketplace-launch-marketing - 招募并推广首批合作伙伴；这些招募来的合作伙伴随后会走过本旅程，因此发布日期会确定本流程中的环境配置和支持环节必须满足的截止日期。

另请参阅，同级集合：

• samber/developer-relations-skills@developer-certification-program - 一旦在此处选择了认证教育闭环，该技能便会设计合作伙伴工程师认证本身（考试形式、监考、续期和验证）。