商业政策

commercial-policy
分类设计
作者Alireza Rezvani
许可MIT
评分4.70/5
使用6.5K

commercial-policy

目的

设计管理标价折扣的参与规则 (Rules of Engagement) —— 即 Deal Desk 和 AE 执行的基准文档。包含三个确定性工具：

1. discount_matrix_builder.py — 构建一个四维矩阵（ARR 档位 × 合同期限 × 付款条件 × 战略价值等级），每个单元格包含基于当前赢率 + NRR 数据的核准折扣区间，以及相应的审批层级（AE / 经理 / 总监 / VP / CFO）。
2. exception_router.py — 当折扣申请超出矩阵范围时，将其路由至指定的审批链，附加必要的补偿性承诺（多年预付 + 指定扩张路径 + 客户案例承诺 + MSA 条款收紧），生成机器可读的审计追踪元数据，并在过去一个季度出现 3 次以上类似特例时标记先例风险。
3. policy_linter.py — 对矩阵进行治理缺陷检查：审批层级反转、折扣区间反转、毛利底线违规、覆盖漏洞、断崖式差异、未定义的战略等级、不一致的毛利底线、数据支撑不足。

输出结果是政策本身（矩阵 + 特例流程 + Lint 报告），而非针对单笔交易的应用。

使用场景

  • 新任商业负责人或 Deal Desk 负责人正在起草公司的首份正式商业政策。
  • 现有矩阵已使用超过 6 个月，且毛利审查中出现了折扣漂移 (Discount Drift)。
  • 销售代表以“Maria 上季度给 Acme 批了 28%”作为先例，你需要打破这种先例循环。
  • 季度环比特例申请数量上升，你怀疑矩阵档位定价有误。
  • CFO 收紧了毛利底线，需要根据新约束重新构建矩阵。
  • 董事会/高管询问“为什么我们折扣这么多？”，你需要一份有数据支撑且可辩护的政策。

不要将此技能用于：

  • 审批特定交易 —— 请使用 commercial/skills/deal-desk。

  • 设定定价模型 + 标价 —— 请使用 commercial/skills/pricing-strategist。

  • 撰写提案 / SOW / MSA 正文 —— 请使用 business-growth/contract-and-proposal-writer。

  • 做出“何时聘请销售 VP”的战略决策 —— 请使用 c-level-advisor/cro-advisor。

工作流

1. 审计当前折扣分布。 从 CRM 中提取过去 4 个季度的 Closed-Won 和 Closed-Lost 交易。填写 assets/policy_design_template.md（约 20 分钟）。记录每笔交易的：arr（年度经常性收入）、discount_pct（折扣率）、term_months（合同月数）、payment_terms_days（付款期限天数）、strategic_value（战略价值）、win_lost（赢单/输单）、nrr_12mo（12 个月净留存率）。

2. 设计数据-
数据支撑的矩阵。运行 scripts/discount_matrix_builder.py --input policy_intake.json --profile {saas|enterprise-software|api|marketplace|services}。输出为一个四维矩阵，每个单元格包含：批准的折扣区间 + 审批层级 + 利润底线 + 观测胜率 + 观测 NRR。观测交易数 n < 5 的单元格将被标记为 THIN。

3. 设计异常处理流程。 运行 scripts/exception_router.py --sample 查看结构。针对每个异常严重程度区间（超出 0-5 分，5-10 分，10-20 分，20+ 分），路由程序将强制执行所需的补偿性承诺。在政策文档中将此流程代码化；路由程序即为实际的执行实现。

4. 对矩阵进行 Lint 检查。 运行 scripts/policy_linter.py --input matrix.json。获取一份基于 10 项 Lint 规则的排名发现报告 —— 分为 BLOCKER（阻断）/ MAJOR（主要）/ MINOR（次要）。在向 AE 发布矩阵前，必须解决所有 BLOCKER 问题。

5. 发布与季度审查。 将矩阵作为版本化产出物发布。每季度针对最新的 4 季度滚动交易语料库重新运行构建器和 Lint 检查。观测 NRR < target_nrr 的单元格将被标记为待审查。

脚本

| 脚本 | 用途 | 行业配置文件 |
|---|---|---|
| scripts/discount_matrix_builder.py | 生成包含审批层级 + 利润底线的数据支撑四维矩阵 | saas, enterprise-software, api, marketplace, services |
| scripts/exception_router.py | 处理带有补偿性承诺的异常请求并记录审计追踪 | 不适用（由矩阵驱动） |
| scripts/policy_linter.py | 对矩阵进行 10 项规则的 Lint 检查 | 不适用（跨配置文件确定性一致） |

以上三个脚本均：仅依赖标准库，支持 --help、--sample、--input <json>、--output {markdown,json}。

参考资料

  • references/discount_governance_canon.md —— 折扣治理证据库：OpenView Partners 基准、David Skok (For Entrepreneurs) 折扣数学、Tomasz Tunguz 的折扣分布研究、Bessemer State of the Cloud、KeyBanc Capital Markets SaaS 调查、Bridge Group AE 薪酬研究、RevOps Co-op 剧本、Forrester 交易台 (Deal-desk) 研究。共 8 个来源。
  • references/policy_design_canon.md —— 政策即产出物设计：SaaStr (Jason Lemkin)、Winning by Design (Jacco van der Kooij) 的商业纪律、Forrester 交易台成熟度研究、MIT Sloan 关于激励系统博弈的研究、麦肯锡关于商业政策有效性的研究、贝恩 *Pricing Power*、Salesforce CPQ 实施指南。共 7 个来源。
  • references/policy_anti_patterns.md —— 8 个命名的反模式，包含来源研究 + 对策 + Lint 规则映射：先例决定政策 (precedent-sets-policy)、缺乏数据支撑、缺乏补偿性承诺、审批人/利润不匹配、缺乏审计追踪、断崖式区间 (cliff edges)、“战略价值”定义模糊、缺乏季度审查。共 8 个来源。

假设条件

  • 本技能假设定价模型和标价已经存在（通过 commercial/skills/pricing-strategist 设置）。商业政策管理的是标价之上的折扣，而非设定标价。
  • CFO 负责 min_margin_pct 约束（利润底线）。CRO / 交易台负责人负责 max_discount_pct_without_exception 约束（区间上限）。本技能在设计上将这些输入分开（参考贝恩 *Pricing Power* —— 责任混淆是导致政策漂移最常见的原因）。
  • 行业配置文件内置了*惯常的*区间宽度。具有特殊经济特性的公司应通过输入 JSON 传递覆盖参数。
  • 该矩阵由数据支撑，但并非由数据驱动：区间由约束条件 + 配置文件设定；观测数据仅作为注释，用于告知你...
单元格的执行情况。如果观察到 NRR < 目标值，这应当是一个重新审查折扣区间 (band) 的信号，而不是继续深化折扣。
  • “战略价值”层级（logo、expansion、lighthouse）仅在定义了具体测试标准时才有用。Lint 规则 L06 强制执行此项。
  • 这是一项策略设计能力，而非交易审批能力。它从不直接说“批准”——它生成的是矩阵 + 异常流程，随后由 deal-desk (交易管理团队) 执行。

反模式 (Anti-patterns)

  • 在缺乏数据支撑的情况下设定折扣区间。 “销售副总裁在 Slack 讨论组中主张如此”不叫数据支撑。如果你无法展示该区间的赢率 (win-rate) 和 NRR，那么该区间就只是辞令。（由每个单元格的 data_backing 和 Lint L08 捕捉。）
  • 让先例决定策略。 “Maria 上季度给 Acme 批准了 28% 的折扣”不是一个区间——而是一个没有破坏策略的特例。exception_router.py 会将 3 个及以上类似的特例标记为信号，表明矩阵本身错了，而非交易错了。（反模式 AP-1。）
  • 在没有补偿性承诺的情况下批准特例。 无偿折扣是一种流失 (Winning by Design)。每个特例严重程度区间都需要不可协商的承诺。（exception_router.COMPENSATING_LIBRARY。）
  • 在整数 ARR 阈值处设置“悬崖边”。 10 万美元的硬性阈值会在两个季度内导致交易规模的操纵 (MIT Sloan 代理理论)。应使梯度平滑化。（Lint L05。）
  • 将“战略价值”作为未定义的万能兜底项。 如果“战略”未定义，一个季度内 60% 的交易都会被标记为战略交易，导致矩阵失效。请用具体测试进行定义。（Lint L06。）
  • 缺乏季度审查。 市场在变化； 12 个月未更改的矩阵会导致定价错误。每季度重新运行构建器 (builder) 和 Linter。（反模式 AP-8。）
  • 混淆 CFO 和 CRO 的职责。 CFO 负责利润底线 (margin floor)；CRO 负责区间上限 (band cap)。如果责任人相同，定价会不可避免地向其激励目标偏移 (Bain *Pricing Power*)。
  • 在发布前跳过 Lint 检查。 BLOCKER 级别的发现（审批人反转、利润底线违规、区间反转）会导致策略无法签署。Lint 是准入关卡，而非事后回顾。

区分于

| 相关项 | 范围 | 区别 |
|---|---|---|
| commercial/skills/deal-desk | 将策略应用于单笔交易 | Commercial-policy 设计策略本身。Deal-desk 使用矩阵，commercial-policy 产出矩阵。 |
| commercial/skills/pricing-strategist | 设定定价模型（按席位/用量/价值/分级）+ 标价 | Commercial-policy 管理标价的折扣。Pricing-strategist 制定菜单，commercial-policy 管理菜单的折扣纪律。 |
| c-level-advisor/cro-advisor | CRO 的战略判断（“何时雇佣销售 VP？”、“我们的模式是产品驱动还是销售驱动？”） | 属于战略层面而非运营层面。Commercial-policy 是 CRO 委托生成的产出物，而非 CRO 的判断本身。 |
| c-level-advisor/cfo-advisor | 利润底线 + 单位经济效益判断 | CFO 向 commercial-policy 提供 min_margin_pct 作为输入。Commercial-policy 将 CFO 的约束运营化为每个单元格的利润底线。 |
| business-growth/contract-and-proposal-writer | 撰写提案/SOW/MSA 的正文 | Commercial-policy 输出结构化矩阵 + 审计追踪 JSON，而非面向客户的正文。 |

强制性问题库 (Matt Pocock 质询纪律)

在技能运行前，由 /cs:grill-commercial 或 Commercial 编排器逐一引导。每个问题配有推荐答案 + 权威引用。绝不敷衍。
1. “过去 4 个季度的实际折扣分布如何 —— 中位数是在当前矩阵范围内还是范围外？”
建议：在设计任何折扣区间前，先提取数据样本。如果观察到的中位数在矩阵之外，那么该矩阵就只是摆设。
权威参考：OpenView SaaS Benchmarks；RevOps Co-op 剧本。反模式 AP-2。

2. “当前‘最高折扣’区间内订单的赢单率（Win-rate）以及 12 个月净留存率（NRR）分别是多少？”
建议：两者都要看，不能只看其一。赢单率高但 NRR 低的区间意味着是在用低价买客户，但留存像漏斗一样在流失。Tunguz 基准数据显示：NRR 最高四分位数的公司，其折扣率比最低四分位数的公司低 6 个百分点。
权威参考：Tomasz Tunguz；Bessemer State of the Cloud。

3. “公司内部谁负责利润底线（Margin Floor），谁负责折扣上限（Discount-band Cap） —— 这两者是同一人吗？”
建议：CFO 负责底线；CRO 或 Deal Desk 负责人负责上限。如果由同一人负责，决策会向其考核指标倾斜。
权威参考：Bain *Pricing Power* —— 责任分离是结构性的解决方案。反模式 AP-4。

4. “当前政策中如何定义‘战略价值’ —— 是通过具体测试，还是通过形容词？”
建议：使用具体测试。“2026 年目标名单中的前 20 个指定账户”是一个测试；而“重要客户”则不是。
权威参考：SaaStr (Lemkin)；Forrester Deal-desk 研究。Lint 规则 L06。反模式 AP-7。

5. “对于超过矩阵上限的特例申请，需要哪些补偿性承诺 —— 且在审批人签字前，这些承诺是否已形成书面记录？”
建议：最低要求为多年预付 + 指定的扩容路径；更深度的特例则需要客户承诺提供案例参考 + 紧缩 MSA 条款 + 执行层赞助人。
权威参考：Winning by Design (van der Kooij)；麦肯锡 B2B 定价研究。反模式 AP-3。

6. “在过去一个季度中，同一类型的特例是否被批准了 3 次以上 —— 如果是，是否说明矩阵本身有问题？”
建议：出现 3 次以上类似特例意味着该区间定价错误。应重新构建矩阵，而不是持续批准特例。
权威参考：OpenView 折扣漂移研究；exception_router._precedent_risk。反模式 AP-1。

7. “上一次根据过去 4 个季度的数据重新校验矩阵是什么时候？”
建议：每季度一次。年度审查太慢；自律的团队会每季度修订一次。
权威参考：OpenView benchmarks；RevOps Co-op。反模式 AP-8。

8. “上季度的所有特例申请是否有机器可读的审计追踪记录 —— 还是仅存在于 Slack 和邮件中？”
建议：在 CPQ 或同等系统中保留结构化记录。Slack/邮件审批在第二年续约谈判时无法提供有效参考。
权威参考：Salesforce CPQ 最佳实践；Forrester Deal-desk 成熟度研究。反模式 AP-5。

请按深度优先顺序执行。在开启 5-8 项之前，先锁定 1-4 项。在所有 8 项均回答完毕后，依次调用 discount_matrix_builder.py → policy_linter.py → exception_router.py --sample 以生成政策交付物。

快速示例

bash
# 设计矩阵
python3 scripts/discount_matrix_builder.py --sample
python3 scripts/discount_matrix_builder.py --input policy_intake.json --profile saas --output json > matrix.json

校验矩阵

python3 scripts/policy_linter.py --sample
python3 scripts/policy_linter.py --input matrix.json

走通特例流程

python3 scripts/exception_router.py --sample
python3 scripts/exception_router.py --input request.json --output json

示例矩阵的 Lint 结果为 FAIL（包含 4 个 BLOCKER + 6 个 MAJOR + 2 个 MINOR） —— 这是特意设计的，旨在测试每一条规则。
真正的政策准入应通过 lint 检查，结果为 PASS 或 PASS_WITH_WARNINGS。示例特例（32 万美元的大客户订单，折扣 42%）的审批流为：AE → 销售经理 → 总监 → 销售副总裁，且需要 3 项补偿性承诺（36 个月多年期合同、预付款、明确的扩容路径）。