设计直销与渠道伙伴协同销售运营章程（deal…

当需要为直销与伙伴共同参与的 B2B 商机制定政策层协作模型（注册保护、信用归因、交战规则）时使用。

适用场景

解决思路

1. 先做访谈再提任何方案：每条消息只问一个问题，尽量给多选项；用户已答过的跳过；若运行环境有持久记忆，先查是否已有批准的章程，只确认变化点而非重新访谈。
2. 访谈必问：直销组织形态（覆盖 SMB/中端/企业、内勤 vs 外勤、配额结构）；在玩或计划中的伙伴类型（referral、reseller/VAR、distributor、SI/consultancy、ISV/tech、marketplace/hyperscaler）；ACV、平均销售周期长度、直销赢单率（周期长度决定注册保护窗口）；AE 上次成功协同销售是什么体验、好在哪；当前 comp plan 是否阻碍把伙伴挂到单子上；AE 今天如何找到某账户该找哪个伙伴、耗时多久；若 AE 完全无视伙伴动议会怎样；目标是伙伴来源管道、影响收入、marketplace 交易量还是触达直销够不到的分层；今天是否有可用的归因记录（带时间戳的注册，还是成交时才提信用）。
3. 最后必问三题（后续所有排序菜单都据此重排）：必须出结果的截止日期及届时必须成立的条件（一个季度内会删掉重型 JBP 轨道、提升一小时注册与锁窗修复；超过两个季度则保留 comp-plan 工作）；是一次性解锁还是复利资产（一次性提升注册政策与交战规则，下一单即回本；复利提升 comp 中立与归因共管，每季度回报但首季几乎为零）；投入上限——可用小时数、销售领导是否愿意重开 comp plan、变更必须多可逆（拒绝重开 comp 则直接删掉所有 comp 资金档；要求可逆则降级任何对伙伴公开的内容，因为已授予的折扣远比内部规则难撤回）。
4. 运行 Workflow：先跑访谈；若能浏览网页且用户有公开的伙伴或 deal-registration 页面，先读它——在空白页设计前先审计现实。
5. 设计前先做就绪度门禁，命中任一取消资格项就带理由拒绝：ICP 尚不能清晰表述；直销尚未证明能独立可靠成交；定位、定价或流程仍在变动；ACV 低于约 $3-5k（销售辅助动议的从业者下限，属通用 SaaS 共识而非 co-sell 专项研究）；把合作当作增长问题的修复手段。伙伴放大的是已跑通的直销动议，修不好坏掉的动议。门禁失败时，建议 2-3 个深度参与的 referral 伙伴、不做正式项目，然后停止。
6. 选择流程轨道，按排名呈现两者并说明各自权衡，明确推荐。各轴不一致：效率 `lightweight playbook > heavyweight JBP`；价值 `heavyweight JBP > lightweight playbook`；投入 `heavyweight JBP > lightweight playbook`。
7. 轻量 playbook 填充：每个伙伴用一份固定模板在单次 90 分钟会话内填完。换来每格一个具名负责人和共享的 deal-stage 地图——多数争议真正争的就是这两样，成本是每伙伴一次会话加一次性模板。性价比最佳，是每个伙伴的默认，直到有东西推动升级。
8. 重型联合业务规划（JBP）：双方高管启动、共享可衡量目标、数周起草、正式签署、季度评审。换来双边高管赞助和带预算的计划——这是唯一能撬动自身外勤销售背配额的伙伴的杠杆，成本是数周起草、双边签署链和常设季度评审工作。价值最高、性价比最差——仅当需要直接影响某伙伴的销售且双方都愿资助评审节奏时才升级。
9. 当伙伴方不愿指定高管赞助人时，从菜单中删除 JBP 轨道而非仅不推荐：无赞助的联合计划产出一份没人执行的文档。跑轻量版，等有赞助人再重访。
10. 把在玩的每种伙伴类型映射到其经济性实际需要的注册与信用机制：referral 伙伴需要干净的归因，不是利润保护；reseller 需要正式注册；SI 由服务管道驱动；ISV/tech 伙伴不需要任何转售机制。绝不对所有类型发一份无差别政策。
11. 按顺序逐条设计五项政策决策，一次一条。每条决策：呈现 2-3 个候选方案，按单位投入价值排名，绝不从最便宜开始；把每个选项的权衡折进它自己那行并给出明确推荐；在继续前拿到用户拍板；用 `>` 行把排序说出来，凡成本、价值、投入、效率不一致处按轴各出一行；投入用小时、会议、签署链和可逆性表达，绝不用货币金额；用户最后三题答案排除掉的选项直接删除而非降级，并说明是哪条答案删的。
12. 五项决策依次为：1) 归因分类法——partner-sourced vs partner-influenced，以及是否另发一个合并的 partner-attached 数字。2) Deal registration 政策——注册授予什么、保护窗口与延期规则、审批标准与 SLA、公开的拒绝理由。3) 信用与薪酬——comp 中立资金模型与多方分成规则。4) 交战规则——账户分类（direct-only / partner-only / shared-pursuit）、协同销售触发条件、具名账户例外、升级阶梯。5) 决策权——谁批注册（绝不让其自身配额受该决策影响的角色来批）、谁共管归因（partnerships 加 revenue operations 是可辩护的默认）、谁在什么 SLA 下裁决争议、谁拥有交战规则文档。从业者惯例把决策权放在伙伴或生态领导层，与销售、CS、RevOps、法务共同设计，但这只是一家咨询公司的陈述模式而非实测规范——把它作为起点提出，让用户为自己的组织确认，而非断言为定论。
13. 组装章程并逐节呈现，每节经用户确认后再进入下一节。未经整份文档明确批准不得定稿。
14. 把批准的草稿对照通过清单打分，说明哪些检查未通过并迭代直到全部通过。
15. 若运行环境有持久记忆，记住已批准章程的决策——后续运行（KPI 评审、新增伙伴类型、重访窗口）从这些决策出发而非重新访谈。
16. 移交本技能不做的事——解决进行中的争议单、与单个伙伴的上市规划、项目分层与经济性——给 Reference 中的兄弟技能。
17. 交付物为《Co-Sell Operating Charter》，含：Scope（覆盖的伙伴类型、分层、账户分类）；Process track（默认轻量 playbook 填充，按伙伴类型例外用重型 JBP）；Attribution（采用的分类法、所用 sourced 测试、成交创建后的锁窗）；Registration（授予什么、保护窗口+延期规则、审批标准、SLA、公开拒绝理由）；Credit & comp（中立模型及其资金来源、配额退休规则、多方分成规则）；Decision rights（注册审批人、归因共管人、争议裁决人+SLA、交战规则文档所有者）；Engagement rules（协同销售触发条件、具名账户例外、升级阶梯）；KPIs & review（跟踪指标、目标、评审节奏）。每行都带理由：“90 天窗口因为平均周期是 100 天”可评审，光一个数字不行。
18. 通过清单（每条都过才算完成，每次说明未通过项及差距）：每条决策权行都指名具体角色、尽可能指名个人（共管即无人管）；注册审批人自身配额不受审批决策影响；保护窗口至少为用户报告的平均销售周期长度的 75%；拒绝理由是公开、明确、封闭的清单——每条都能从注册记录客观验证、无自由裁量，规范集合取自 `mbfinotti/partnerships-skills@partner-channel-conflict`，要枚举而非裁剪，因为漏掉一条就是没人能辩护的拒绝；comp 模型有财务和销售领导签署，或把偏离记录为带风险说明的故意例外；AE 读一遍就能判断一个具体单子是否可注册、受保护、comp 中立——与用户走一个真实单子场景来测试；直销代表在已用的系统内就能看到注册——记录只存在于销售团队从不打开的 portal 的政策按定义就是失败的。
19. 诚实分级引用：可作规范性陈述的成熟实践——partner-sourced / partner-influenced / partner-attached 分类法、comp 中立、交战规则文档、带保护窗口的 deal registration；真实但源自厂商的词汇——“ecosystem-led growth”和“nearbound”虽被广泛采用但由厂商创造，只作共享词汇、绝不当教义；无标准存在——co-sell 就绪度与成熟度模型是相互竞争的咨询框架，作为一类选项呈现而非规范模型；至多方向性——头条伙伴提升基准（更大单、更高赢率、更快周期）源自厂商营销而非独立研究，引用时必须附此标注。
20. 诊断已有动议时按下列顺序修复（按单位投入价值最高优先，非最便宜优先），各轴不一致故呈现计划时两者都说：效率 `published rejection grounds == lock window + dispute SLA > registration visibility > tiebreaker ladder > attribution co-ownership > comp neutrality`；价值 `comp neutrality > registration visibility > published rejection grounds > lock window + dispute SLA > attribution co-ownership > tiebreaker ladder`。
21. 前端并列是挣来的不是对冲：两者都只是一段公开文字，约一小时起草、partnerships 单独签署，各自消灭一个不同的高频症状。
22. Comp 中立是此顺序饿着的：它是页面上价值最高的修复却仍排最后，因为那是对外勤的合同承诺，耗一个季度加财务与 CRO 签署链。只跟效率线走的读者会永远做便宜档，永远买不到其他修复无法替代的那一项。
23. 仅在一个症状下把它提升到第一：注册可见性、拒绝理由和锁窗都到位后，代表仍绕开或雪藏伙伴单。若访谈第 3 题说销售领导不愿重开 comp plan，则从本计划删除 comp 中立并记为已知风险——绝不留在列表底部，否则会变成没人能签的范围。按用户自身情况重排其余项——拒绝理由已公开的团队从第二档开始。
24. 症状对照表：伙伴几乎不认识的账户上投机注册泛滥——先查参与证明标准与拒绝理由是否公开，政策故障在注册审批标准，修复约一小时、partnerships 单独；代表花销售时间争信用分成——先查归因锁窗与争议 SLA，故障在归因治理，约一小时、partnerships 单独；直销 AE 被伙伴注册突袭——先查注册记录在哪（仅 portal 还是销售系统），故障在交战规则可见性，约一周 RevOps 配置；同一账户两个主张者无干净解法——先查带时间戳的系统记录与 tiebreaker 规则，故障在决策权升级阶梯，约一周加可能不存在的工具；伙伴影响收入被报告但没人信——先查是否成交时才接受主张、partnerships 是否为该数字唯一所有者，故障在归因分类法与共管，约一个季度跨两团队的流程变更；代表悄悄回避或雪藏伙伴单——先查伙伴挂上后配额信用是否缩水、marketplace 费是否打击佣金，故障在信用与薪酬中立，约一个季度、财务+CRO 签署、一旦公开即合同化。
25. KPI 分开跟踪 sourced 与 influenced（合并会掩盖伙伴是产生管道还是加速管道）。核心 KPI：伙伴来源管道占比、伙伴影响收入占比、挂载率、注册审批时长、争议率、裁决 SLA 合规。
26. 仅在用户自己的数据内比较 partner-attached 与直销单的赢率和周期长度，因为跨公司基准不可靠：商机创建标准各公司不同，且注册审批率或审批时长没有独立行业基准。季度评审。单一伙伴驱动超过约 30% 渠道收入时存在集中度风险，值得标记。
27. 少数已发布的基准数字源自厂商、仅方向性，带标注放在 references/attribution-and-compensation.md。

适用边界 · 注意事项

• 不要用于裁决进行中的争议单——改用 mbfinotti/partnerships-skills@partner-channel-conflict。
• 不适用于 B2C/消费者场景：co-selling 是 B2B 学科，预设具名账户、背配额的销售、咨询式销售周期和商机记录；消费侧对应的是 trade marketing、co-op 广告基金、货架/渠道协议，机制不同，绝不要把 deal registration 或 comp 中立硬套到零售合作上。
• 不要用于与单个伙伴的上市规划（co-marketing、发布排期，用 @joint-gtm-planning）或整体项目结构（分层、要求、权益，用 @partner-channel-program）。