当需要为B2B合作伙伴计划编排培训、内容与认证路线图…

用于从合作伙伴首单倒推、排序并治理合作伙伴赋能路线图，而不是编写具体培训模块、销售战卡或考题。

适用场景

解决思路

1. 先声明不存在合作伙伴赋能的 canonical 方法论；不要编造一个，而是逐条说明该领域真正可用的内容。
2. 把 Kirkpatrick 四级评估（1959）和 Phillips ROI 仅当作评估用教学设计方法；把 ADDIE 和 SAM 仅当作建设流程方法；把 70-20-10 仅当作启发式规则（引用广但实证基础弱）。
3. 明确上述方法都不是渠道原生方法；把它们用于合作伙伴场景属于实践者改编，必须标注这一点。
4. 把所有自称合作伙伴赋能框架或生命周期模型的内容视为 PRM 厂商内容营销或 Forrester/Canalys 等专有分析师 IP；它们可以内部自洽且有用，但绝不是独立方法论。
5. 采用该领域证据最强的设计原则：实践者共识——从首单倒推设计；定义注册一个合格商机所需的最小可行知识，随着商机推进再提供更深培训，即对齐学习曲线与赚钱曲线。
6. 引用证据最强的分析师发现：Forrester 渠道研究显示，把直销内容原样回收给合作伙伴会导致使用率低落和 messaging 失败；这是该领域记录最充分的失败模式。
7. 在设计任何东西前先做访谈；每条消息只问一个问题，提供多选选项，跳过用户已回答的问题。
8. 问：这是 B2B 渠道赋能，还是面向消费者的网络——加盟、经销商、零售店员、大使/创作者？部分设计会真正分叉。
9. 问：计划中有哪些合作伙伴类型——referral、reseller、SI/implementation、MSP、ISV/tech——以及哪些实际成交？
10. 问：今天已有哪些赋能资产，每个资产来自哪里：为合作伙伴构建的，还是从直销赋能回收的？
11. 问：合作伙伴跑什么销售动作——refer、resell、implement、manage？每种需要不同深度。
12. 问：当前 time-to-first-deal 和激活率（已签约合作伙伴中拥有已注册商机的比例）是多少？未追踪也是一个答案。
13. 问：认证是否已经限制任何东西——tier 状态、折扣、co-sell 资格、线索流——还是独立徽章？
14. 问：合作伙伴现实能承担多少认证负担：每人小时数、考试费用、认证人数要求？较小的合作伙伴最先撞上人数墙。
15. 问：谁日常负责赋能、能力如何——内容创建是否在别处（产品营销、渠道运营）？所有权碎片化是有记录失败模式。
16. 问：合作伙伴投入时间在经济上得到什么——margin、服务收入、leads、MDF？合作伙伴会在多个供应商之间配给销售时间。
17. 问：成功意味着什么，必须在什么日期前落地——首个合作伙伴成交、一个认证 cohort、董事会幻灯片？
18. 问：你想要一次性胜利（一个停滞合作伙伴开始卖），还是复利资产（一套明年能 ramp 每个新签约合作伙伴的课程）？
19. 问：努力上限是什么——每周赋能小时数、占用谁的日历、强制认证会在内部消耗多少政治资本？
20. 在提出任何方案前先问最后三个问题，因为它们会重排本技能中每个选项菜单。近期日期会提升首单路径、deal-registration walkthrough、挖掘已有材料而非合作伙伴访谈的优先级。
21. 复利任务会提升认证、技术与交付 track、以及 trained-vs-untrained 对比背后按 partner-ID join 的优先级。
22. 硬性努力上限会推迟每个建设成本超过一周的资产。
23. 执行访谈；收集路线图依赖的所有现状事实。
24. 确认范围：在已存在的计划内部排序赋能；计划结构、tier 标准、合作伙伴 scorecard 属于兄弟技能。
25. 在构建任何东西前运行需求评估：访谈 5-10 个合作伙伴，活跃与不活跃各半；对每个赋能组件映射当前状态与期望状态；产出差距文档。见 references/needs-assessment.md。
26. 在设计前先选择排序方法；按下面排名展示三个候选方案——首先按每小时赋能建设能解锁多少成交排序；说出排名；推荐最高一档；等待用户选择。步骤 5-10 构建用户所选；之后才提供选择就不是真选择。
27. 方案一：最小可行首单路径（默认）——建设努力约一周；到首个合作伙伴成交约数周；买到的是在大部分课程仍未写时让合作伙伴先成交。
28. 方案二：认证优先发布——建设努力约一个季度，加上对认证声明内容的签核；到首个合作伙伴成交约一个季度或更久；买到的是在任何成交证明需要之前，先有可辩护的能力门槛和 tier 标准。
29. 方案三：全面前置课程——建设努力是长期工作；到首个合作伙伴成交约一个季度或更久，常常永远不到；买到完整覆盖每个角色和类型，代价是 firehose 失败模式。
30. 记住效率排序：最小可行首单 > 认证优先 > 全面前置课程。
31. 记住价值排序：全面前置课程 > 认证优先 > 最小可行首单。
32. 记住努力排序：全面前置课程 > 认证优先 > 最小可行首单。
33. 记住合规成本排序：认证优先 > 全面前置课程 > 最小可行首单。
34. 认证优先是三者中唯一有真实暴露的：供应商营销的认证是合作伙伴再销售的公开能力声明；受法律或品牌签核限制；一旦合作伙伴宣传徽章就很难撤回。
35. 只有在条件满足时才偏离默认，而不是因为计划规模大。当客户购买前检查认证，或未验证的合作伙伴可能伤害客户时，认证优先才值得。
36. 效率排序会饿死全面课程：它在价值和努力上都排第一，所以在比率上每轮都输。只计算效率的计划永远到不了完整角色覆盖——它发布首单路径后就停止。只有当代足够远、没有成交在等课程、且努力上限真的是长期工作时，才提升它。
37. 如果达不到上述条件，就以首单后 track 的形式增量购买全面覆盖，而不是直接放弃。
38. 当访谈排除某一档——例如没有认证可附着的经济门槛，或每个资产努力上限低于一周——就从菜单删掉它并说明已删掉，而不是列为后续阶段。
39. 某一档如果被放在底部且搁置，会以没人预算的范围回来。依据已知情况重新排序：已有 demo 环境、合作伙伴已具技术能力、或可直接改编的直销材料，都会降低前两行的努力，并可能让某一档上移。
40. 从首单倒推设计：定义合作伙伴注册一个合格商机所需的最小可行知识、访问权限和动作，并用合作伙伴总小时数计量。
41. 把首单路径之外的一切明确标为首单后培训，而不是前置条件；全面前置课程就是 firehose 失败模式。
42. 按合作伙伴 ROLE 拆分 track：sales rep、solutions architect、delivery consultant、partner marketer、executive sponsor。
43. 按合作伙伴 TYPE 拆分 track：referral 合作伙伴需要短概述；implementation 合作伙伴需要多日技术深度。
44. 按参考文件给出的排名顺序构建 track；基础中存在的每个面向客户角色仍然都要有 track，排名只决定哪个先存在。
45. 合作伙伴基础中不存在的角色要从 audience map 删除，并在那里命名为已删除，绝不晚点排期；只有 referral 的基础没有 delivery consultant，为它留一个 pending track 会变成没人计划的四分之一工作。见 references/curriculum-architecture.md。
46. 决定签约前赋能什么、签约后赋能什么：合作伙伴价值主张和经济性放在签约前；产品、销售、技术培训放在签约后。
47. 不要培训没有经济理由投入的合作伙伴；这是已记录的「合作伙伴没有价值主张」陷阱。
48. 决定是否认证，以及每个认证限制什么。认证可以成为 tier 标准；如果是，就写明并把标准设计交给 mbfinotti/partnerships-skills@partner-tiering。见 references/certification-design.md。
49. 为每类资产设置刷新节奏，并为每个资产指定负责人；过时内容比没有内容更安静地误导合作伙伴。
50. 规划 pilot cohort：先在一小群刻意选择的合作伙伴群体上启动路线图，收集反馈，再扩展。
51. 按下一节逐节验证 spec——audience map、first-deal path、tracks、certification、cadence、pilot——在遇到反对时先修改再继续。
52. 检查 pass threshold；迭代路线图直到每项检查都成立。
53. 在批准门停止——没有用户对完整 spec 的明确批准，不要最终定稿。
54. 如果你的运行环境有持久记忆，记住已批准的路线图、其排序决策和阈值；否则告诉用户把 spec 存到合作伙伴运营可检索的地方。
55. 如果你能浏览网页，在引用任何具名供应商认证结构前先验证——主要项目在 2022-2026 间反复重组；否则把供应商示例标记为可能过时。
56. 按渠道团队实际做法运行设计：先 discovery 再 design，先 socialized 再 shipped。
57. 全程每条消息只问一个问题；绝不批量提问。
58. 从 listening tour 开始：做需求评估中的 5-10 个合作伙伴访谈。如果用户无法访谈，就挖掘已有材料——joint business plans、QBR notes、asset-request logs、support tickets、portal search queries。
59. 在存在的地方拉取 joint-business-planning 输入：每个合作伙伴的目标、资源、障碍，以及已做出的培训/认证承诺。
60. 在第 4 步任何设计步骤运行前，按第 4 步的排名顺序展示三个排序方案，并说出推荐；本技能及参考文件中的每个排名都是默认而不是法律，它会随用户截止日期、努力上限、谁执行工作而移动，所以要基于用户已有资产和技能重新排序，而不是背诵。
61. 用户选定方向后，一次一节呈现 spec——audience map、first-deal path、tracks、certification、cadence、pilot——每节验证后再写下一节。
62. 建议在任何公开发布前通过 partner advisory council socialize 接近最终的路线图；收集合作伙伴反馈后忽略，比不问更糟。
63. 在扩展前先在 pilot cohort 上验证；预期 v1 不完美，并提前规划迭代窗口。
64. 以用户对汇编后 spec 的明确批准作为最终定稿门。
65. 交付物是这个工件——一份决策记录，供用户交给 partner ops、partner marketing 和 channel chief：ENABLEMENT ROADMAP - <program>, <date>。
66. spec 中写 Audience map：需要赋能的 partner types x roles；排除的类型/角色及原因。
67. spec 中写 Gap summary：每个赋能组件的当前状态 vs 期望状态（来自需求评估），按每单位修复努力的影响排序，而不是只按影响排序，否则持续一个季度的差距会挤掉一小时的差距。
68. spec 中写 First-deal path：注册一个合格商机所需的最小知识 + 访问 + 动作，用合作伙伴总小时数计量；其他一切都明确标为首单后。
69. spec 中写 Tracks：每个 role x partner type 的内容、深度、负责人，以及每个 track 的建设努力（hours / a week / a quarter / a standing job）对应它解锁什么，按该比率的顺序排列。
70. spec 中写 Pre-signature：协议前赋能什么（价值主张、经济性）vs 协议后赋能什么（培训、门户、deal registration）。
71. spec 中写 Certification：是否认证及原因；每级格式（exam / lab / outcome validation）、小时 + 费用的负担、限制什么、recertification 节奏；tier 标准设计交给 partner-tiering。
72. spec 中写 Refresh cadence：每类资产的负责人、复查日期、退役规则。
73. spec 中写 Pilot：cohort 规模 + 选择标准、成功标准、反馈闭环、扩展触发条件。
74. spec 中写 Ownership：单一可问责负责人；内容创建放在哪里；对供应商自身渠道团队的内部赋能计划。
75. spec 中写 KPIs：来自 KPI 部分，包括 trained-vs-untrained 对比设计和首次复查日期。
76. spec 规则：每个 track 在列出任何内容前，先用经济术语回答「对合作伙伴有什么好处」；合作伙伴是理性的经济行动者，会在多个供应商之间配给时间。
77. spec 规则：first-deal path 必须带一个强制小时数；没人计量过大小的路径就是伪装的 firehose。
78. spec 规则：每类资产都必须带负责人和刷新日期；无主内容会腐烂成误导性内容。
79. spec 规则：spec 只排序和设门；不包含培训内容、销售战卡文案或考题；那些是从本路线图构建的下游交付物。
80. pass threshold 1：first-deal path 用小时计量而不是周。如果强制售前路径超过大约一个合作伙伴工作日，就不会被消费（实践者共识，无独立数据集）。
81. pass threshold 2：计划中不能有任何未改动的直销资产。每个资产要么为合作伙伴构建，要么明确改编——回收内容失败是该领域记录最充分的。
82. pass threshold 3：每个面向客户角色都有 track。计划常在销售上过度投入而忽视技术/交付角色；不能 demo 或实施的合作伙伴不会卖。
83. pass threshold 4：认证限制某个经济性东西，否则不存在。徽章如果不绑定 tier、折扣、线索流或 co-sell 优先级，就会被忽略——完成跟着经济性走。
84. pass threshold 5：每个资产都有负责人和刷新日期，路线图要指定一个可问责的赋能负责人——即使内容创建仍然分散。
85. pass threshold 6：spec 中每个有序列表都要展示其顺序下的算术。建设顺序、track 列表、差距排名的每一行都要带建设努力，以 hours、a week、a quarter 或 a standing job 计，对应那一行解锁什么。绝不要用货币数字；它比它要证明的排序过时更快。没有比率垫底的顺序只是把品味伪装成排序。
86. 当用户带着一个运行中的计划而不是白纸到来时，匹配他们报告的症状并处理对应行。该表故意不排名：读者从不挑行——症状挑行——所以给八个没人正在选择的诊断排序是假精确。适用排序存在于每行内部，Check first 总是先命名最便宜的排除性检查，再命名昂贵的检查。
87. 症状：合作伙伴签约但从不激活。Check first：强制售前路径大小；是否曾为合作伙伴做过经济性案例。故障变量：first-deal path 太大，或招聘/计划问题——交给计划设计兄弟技能。
88. 症状：time-to-first-deal 超过约 90 天。Check first：按顺序检查三个常见原因——enablement minimum 太大；partner manager 过载；合作伙伴签约时未做资格筛选。故障变量：排序、产能或招聘——只有第一个是赋能故障。
89. 症状：已认证但不活跃的合作伙伴。Check first：认证限制什么；它测试能力还是点击。故障变量：认证与经济性的链接、评估格式。
90. 症状：内容未被使用。Check first：资产来源（回收自直销？）；然后检查门户摩擦（登录、可发现性）。故障变量：先内容契合，后分发。
91. 症状：合作伙伴拒绝认证。Check first：负担（小时、费用、认证人数）对比经济回报；小合作伙伴的人数墙。故障变量：认证负担设计。
92. 症状：合作伙伴不能展示产品。Check first：每个 track 是否存在 demo 环境和 demo 脚本。故障变量：demo enablement——最常报告的缺口。
93. 症状：过时内容丢单。Check first：刷新节奏和每个资产的所有权。故障变量：节奏和所有权，不是数量。
94. 症状：只有销售 track。Check first：技术、交付和营销角色的覆盖。故障变量：按角色拆分 track。
95. KPI：评估 enablement 计划，而不是单个合作伙伴；合作伙伴 scorecard、QBR、表现不佳触发条件属于 mbfinotti/partnerships-skills@partner-performance。
96. KPI：做 trained-vs-untrained cohort 对比，看 partner-sourced opportunities、time-to-first-deal、win rate——这是唯一能证明赋能起作用而不只是发生过的衡量。
97. KPI：按每个合作伙伴中的每个角色看认证覆盖率，而不是原始证书数量；40 个销售认证和 0 个技术认证是被健康总数掩盖的覆盖失败。
98. KPI：维护 certified-but-inactive 列表——完成培训却没有产生 pipeline 的合作伙伴；这是具名失败模式和辅导队列。
99. KPI：看 time-to-first-deal 和激活率，对照 60-90 天 / 30-50% 区间——PRM 厂商经验法则，不存在独立数据集。
100. KPI：把内容使用和门户参与当作最早预警信号——但低登录要先读成访问摩擦，其次才是冷漠。
101. KPI 注意：该领域几乎所有 benchmark 都来自 PRM 厂商且方法未披露——引用任何数字都带可靠性标记。合作伙伴学习平台默认只产出 Kirkpatrick Level 1-2；Level 3-4 需要 join 成交数据。见 references/measurement-and-benchmarks.md。
102. B2B 与 B2C 相同点：构建任何东西前按角色细分学习者。
103. B2B 与 B2C 相同点：把认证与认可和激励绑定，以推动完成。
104. B2B 与 B2C 相同点：以学习平台或品牌 academy 作为交付骨干。
105. B2B 与 B2C 相同点：快速新产品培训。
106. B2B 与 B2C 相同点：赋能站在客户面前那个人的核心逻辑。
107. B2B 与 B2C 真正不同：train-the-trainer 在加盟和经销商网络中是结构性的——品牌培训 franchisee/总经理，后者再培训自己的员工；B2B SaaS 计划很少正式化这一层，消费者网络没有它就无法运作。
108. B2B 与 B2C 真正不同：品牌标准认证在加盟中带法律/合规重量——强制跨地点一致性；B2B 合作伙伴认证没有可比法律暴露。
109. B2B 与 B2C 真正不同：消费者网络中覆盖是按站点且强制（每个地点由认证人员运营），而 B2B 是按组织的认证人数阈值。
110. B2B 与 B2C 真正不同：一线 mindshare——零售和经销商店员是小时工，必须用短促、激励性 micro-content 和竞争素养争取；B2B 合作伙伴销售代表是独立经济行动者，需要 margin case。
111. B2B 与 B2C 真正不同：大使/创作者教育更接近消费者零售而不是 B2B 渠道——短、自助、动机优先、为近乎零触达的高量设计。
112. B2B 与 B2C 真正不同：合同杠杆——加盟商可以强制完成培训；B2B 供应商只能激励。
113. 参考：见 references/vendor-examples.md 获取 2022-2026 真实供应商计划结构拆解，并带过时警告。
114. 参考：见 references/measurement-and-benchmarks.md 获取 Kirkpatrick 应用于渠道受众、KPI 定义和带可靠性标记的 benchmark 区间。
115. 参考：见 mbfinotti/partnerships-skills@partner-channel-program 获取整体计划结构——motions、tiers、economics envelope、governance；enablement 是它引用的一个组件。
116. 参考：见 mbfinotti/partnerships-skills@partner-performance 获取合作伙伴 scorecard、QBR 结构和表现不佳触发条件；本技能衡量 enablement 是否有效，而不是合作伙伴是否表现好。

适用边界 · 注意事项

• 不要用于 affiliate welcome emails（联盟会员欢迎邮件）；应改用 mbfinotti/partnerships-skills@affiliate-onboarding-sequence。
• 不要编写实际培训模块、销售战卡文案或考题；这些是本路线图的下游交付物。
• 不要负责整体合作伙伴计划结构、tier 标准、合作伙伴 scorecard、QBR 或表现不佳触发条件；分别交给 mbfinotti/partnerships-skills@partner-channel-program、@partner-tiering、@partner-performance。