为B2B渠道合作伙伴设计绩效记分卡、评审节奏与低绩效处理阶梯

当你需要衡量和评审B2B合作伙伴项目中单个合作伙伴的表现（记分卡、QBR、低绩效升级）时使用。

适用场景

解决思路

1. 先做访谈，每条消息只问一个问题，提供多选项，跳过用户已回答的内容：合作伙伴数量与类型（reseller、VAR/MSP、agency、SI、ISV/tech、referral、distributor）及哪些真正成交；当前衡量什么、数据在哪里（CRM、PRM、LMS、表格、无处）；合作伙伴是否能看到自己的数字；当前评审节奏及是否按层级不同；当前“低绩效”的定义以及命中后是否真的采取行动；sourced 与 influenced 收入各占多少、系统能否区分；当前评审文化是工作会还是状态汇报；有多少 partner manager（PAM）及覆盖比；是否仅 B2B 渠道还是也含 affiliate/creator；哪些不可变（已签协议、财年日历、既有层级承诺）；谁签字（channel chief、CRO、finance、legal）；首次计分评审必须在什么日期前落地；这是一次性练习还是每季度运行的系统；工作量上限（partner-ops 可用工时、能否导出 portal/LMS/deal-registration 数据、设计在合作伙伴看到后是否还能改）。
2. 确认范围：衡量和评审运行中项目的单个合作伙伴；层级设计、项目设计、单伙伴经济性、联合 GTM 计划属于兄弟技能，本技能只对照联合计划评审绩效，不构建计划。
3. 盘点数据：把每个候选指标标为今天可计算、需投入可计算、或不可衡量；绝不用估算值计分。
4. 从排序后的记分卡方案中选一档，然后设计：维度及权重、每个 KPI 的目标与红旗下限、衡量窗口、数据源与负责人，并按合作伙伴类型（含非成交型）各设一条 track。
5. 设定重算节奏与合作伙伴可见性：合作伙伴看到什么、何时看到。
6. 按层级设计评审节奏与合作伙伴 QBR。
7. 设计低绩效阶梯：触发 → 干预 → 纠正措施 → 降级/退出；任何可能导致降级或终止的动作都走 legal。
8. 按同一节做验证：一次只呈现规格的一个部分，每部分通过后再写下一部分。
9. 用真实合作伙伴对草稿记分卡做 dry-run；检查分数分布及其隐含的 PAM 工作量；据此调整。
10. 检查 pass threshold，迭代直到每项都成立。
11. 停在审批门：未经用户对完整规格的明确批准，不做任何定稿。
12. 若运行环境有持久记忆，记住已批准的记分卡、阈值和首次评审日期；否则告诉用户把规格存到 partner ops 可取回的地方。
13. 若能浏览网页，在向用户点名引用任何厂商模型前先核实；否则把厂商示例标注为可能过时。
14. 按渠道团队真实工作方式做设计：通过 partner ops 建模和利益相关方评审，而不是独自做表格。
15. 全程每条消息只问一个问题，绝不批量提问。
16. 汇集渠道团队带来的数据：sourced vs influenced 收入拆分、deal-registration 记录、认证/LMS 完成度、portal 参与度、PSAT/NPS、MDF 使用率；用现有数据建模，并点名缺失项。
17. 梳理必须参与的人：channel chief 负责、partner ops 建模、finance 验证数字、PAM 必须能运行、legal 审查任何可能触发降级或终止的内容。
18. 按给定排序呈现三种候选记分卡方案，并给出你的推荐及理由；它们是阶梯而非互斥选项，每一档叠加在前一档之上。
19. 用户选定一档后，一次只呈现规格的一个部分——记分卡、然后节奏与 QBR、然后阶梯——每部分验证后再写下一部分。
20. 在全面铺开前，先与 partner advisory council 或试点 cohort 社交化接近定稿的设计；合作伙伴从未见过的衡量系统只会引发争议，而非绩效。
21. 以用户对组装后规格的明确批准作为定稿门。
22. 按每 partner-ops 构建小时能解决多少来排序记分卡方案：efficiency 为 weighted composite > leading/lagging split > per-partner-type tracks；value 为 weighted composite > per-partner-type tracks > leading/lagging split；effort 为 per-partner-type tracks > leading/lagging split > weighted composite。
23. 第 1 档 weighted composite：4-6 个维度、每个合作伙伴一个数字，解决分诊决策（本季度 PAM 工时给谁）；定义约需一周 partner-ops 工作，之后每次评审近乎零成本，运行在多数项目已有的 CRM/PRM 数据上，在合作伙伴看到前完全可逆。
24. 第 2 档 leading/lagging split：结果分旁边放早期指标分，解决时机决策（现在干预还是等一个季度）；当 composite 已含 pipeline、engagement 或 certification 维度时近乎零成本，只需打标签并小计；当 portal、LMS 或 deal-registration 数据尚不能导出时需一个季度管道工作，这种情况会把它降到 composite 之下。
25. 第 3 档 per-partner-type tracks：每种合作伙伴类型一套维度，解决覆盖决策（非成交型合作伙伴是否值得投入，单一 composite 会以空白回答）；每种类型定义约需一周，各有数据源和协商目标，随后随类型增多成为常设工作。
26. 默认从第 1 档开始；一旦 leading 数据能干净导出就加第 2 档；只有一种合作伙伴类型的项目删除第 3 档并在规格中写明删除原因；无法导出 portal/LMS/deal-registration 数据且无能力建管道时同样删除第 2 档，等导出存在后再议。
27. 按访谈所得重新排序：已有 PRM 报告 leading 指标时第 2 档近乎免费，可提升到继续调 composite 之上；无分析师支持的 partner manager 应交付第 1 档而非无人能重算的三 track 设计；当前评审周期内的硬截止日期会把今天可计算的方案提升到更好的方案之上。
28. 交付《PARTNER PERFORMANCE SYSTEM》决策记录，含：Scorecard（维度及权重合计 100%、每 KPI 的定义+目标+红旗下限+衡量窗口+数据源+负责人、按类型含非成交型的 tracks、重算频率与重算人、合作伙伴可见性）；Review（按层级的节奏、QBR 议程以上季度行动检查开场并以联合行动计划收尾、行动跟踪存放处）；Underperformance ladder（触发→干预→时间线表、升级链具名角色、纠正计划形态/时长/检查点/声明的后果、降级/退出标准且以有记录的纠正措施失败为前提并经 legal 审查）；System KPIs 及首次评审日期。
29. 规格规则：每个 KPI 都附数据源和具名负责人；每个目标都配红旗下限；拒绝任何合作伙伴可自报或可博弈的指标，只用项目自己记录的数据；时长、参会名单、阈值和时间线都作为用户自设的设计决策呈现，而非行业惯例。
30. 满足五项 pass threshold 才可交付：每个 KPI 完整指定（目标、红旗下限、衡量窗口、具名数据源、具名负责人）；没有任何自报或可博弈项，所有输入来自项目记录且能在争议中辩护；每个非成交型合作伙伴类型都能在不依赖转售收入的情况下得到真实分数而非空白；每次评审都以有主、有日期的行动收尾，且下次评审以检查这些行动开场；PAM 能在其实际拥有的时间内准备好记分卡（用访谈中的覆盖比测试准备工作量）。
31. 诊断已有评审系统时自上而下处理，按每改变小时修复的评审数排序：action-tracking loop > QBR pre-read 与议程 > cadence tiering > partner visibility > leading-indicator mix > per-type tracks > ladder enforcement；effort 排序为 ladder enforcement > per-type tracks > leading-indicator mix > partner visibility > cadence tiering > QBR pre-read 与议程 == action-tracking loop；compliance cost 上 ladder enforcement 远高于其他修复。
32. 当合作伙伴已历经修复后的评审仍不达标时，提升 ladder enforcement；此时问题不在评审流程，继续改议程只是空转。
33. 按眼前项目重新排序并划掉不适用项：合作伙伴已能看到实时记分卡则无 visibility 行；只有一种合作伙伴类型则无 tracks 行；两者都从计划中删除而非留作待办。
34. 按症状排查：上季度行动未完成→检查 QBR 是否以上次行动检查开场及行动存放处（action-tracking loop）；QBR 是单向状态汇报→检查是否发数据 pre-read 及前瞻性议程占比（QBR 议程与 pre-read 纪律）；所有合作伙伴无论大小评审相同→检查节奏与深度是否按层级变化（cadence tiering）；合作伙伴质疑数字→检查会前是否看到相同数据及哪个系统是事实来源（数据源与可见性）；记分卡绿色但合作伙伴沉寂→检查是否有 leading 指标（portal 登录、deal registration、认证活动）在记分卡上（维度组合仅滞后）；只有成交型合作伙伴有分数→检查是否有 ISV/referral/advisory 的 per-type tracks（scorecard tracks）；从未有人被降级→检查阶梯触发是否有负责人和时间线及 legal 阻碍（ladder enforcement，而非记分卡）。
35. 衡量系统本身而非合作伙伴：按 review completion rate > action-item completion rate > share with a current scorecard > dispute rate > ladder timeliness > ladder outcomes > review-process PSAT 的顺序埋点；前三个是项目已记录的计数，后两个需要一年阶梯历史或合作伙伴调查。
36. 当评审议题是是否保留阶梯或降级被质疑时，提升 ladder outcomes；当项目无阶梯历史且无调查能力时，从埋点计划中删除第 6、7 行并写明删除，而非留作待办指标。
37. B2B 与 B2C 相同点：每个指标都有目标和红旗下限；指标组合混合 leading 与 lagging；没有自报项；每次评审都产出有主行动。不同点：B2B 渠道人工评审、关系绑定——按伙伴记分卡、PAM 主持 QBR、分阶段人工阶梯；B2C affiliate/creator 自动化仪表盘、cohort 级评审、自动化再激活——仅对分布头部做按伙伴评审。

适用边界 · 注意事项

• 不要用于设计层级阶梯本身——应使用 mbfinotti/partnerships-skills@partner-tiering。
• 不要用于单伙伴 P&L 与单位经济性建模（用 partner-economics）、生态系统级健康指标（用 partner-ecosystem）、衡量赋能项目是否有效（用 partner-enablement）、构建联合 GTM 计划（用 joint-gtm-planning）、从零设计整个合作伙伴项目（用 partner-channel-program）或 affiliate 项目指标（用 affiliate-performance-dashboard）。
• 不要在没有可导出数据且无能力建管道时仍保留 leading/lagging split，或在只有一种合作伙伴类型时仍保留 per-type tracks——应明确删除并写明原因。