commercial-policy

商业政策

目的

制定管理相对于标价折扣的参与规则，作为 Deal Desk 和 AE 遵循的准则。包含三个确定性工具：

1. discount_matrix_builder.py — 构建一个 4 维矩阵（ARR 区间 × 合同期限 × 付款条款 × 战略价值等级），每个单元格都包含经批准的折扣区间，该区间由当前赢单率和 NRR 数据支持，并标注审批级别（AE / Manager / Director / VP / CFO）。
2. exception_router.py — 当折扣申请超出矩阵范围时，按指定的审批链流转，附加所需的补偿性承诺（多年预付 + 明确的扩展路径 + 客户背书承诺 + 收紧 MSA 条款），生成机器可读的审计跟踪元数据，并在过去一个季度内出现 3 个或更多类似例外情况时标记先例风险。
3. policy_linter.py — 检查矩阵中的治理缺陷：审批级别倒置、折扣区间倒置、违反利润底线、覆盖范围缺口、断层、战略等级未定义、利润底线不一致、数据支撑不足。

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

适用场景

• 新任商业负责人或 Deal Desk 负责人正在编写公司的首份正式商业政策
• 现有矩阵已有 6 个月以上，且利润审查中发现折扣不断走高
• 销售代表以“Maria 上季度批准了 Acme 的 28% 折扣”为先例，而你需要打破这种先例循环
• 季度环比例外数量不断上升，你怀疑矩阵中的折扣区间定价不当
• CFO 收紧了利润底线，矩阵需要根据新的约束重新构建
• 董事会成员 / 高管询问“我们为什么给出这么大的折扣？”，而你需要一套有数据支撑、站得住脚的政策

请勿将此技能用于：

• 批准某笔具体交易——请使用 commercial/skills/deal-desk
• 制定定价模型和标价——请使用 commercial/skills/pricing-strategist
• 编写提案 / SOW / MSA 文案——请使用 business-growth/contract-and-proposal-writer
• 做出“何时招聘销售副总裁”的战略决策——请使用 c-level-advisor/cro-advisor

工作流

1. 审查当前折扣分布。 从 CRM 中提取过去 4 个季度的已赢单和已丢单交易。填写 assets/policy_design_template.md（约 20 分钟）。逐笔交易记录：arr、discount_pct、term_months、payment_terms_days、strategic_value、win_lost、nrr_12mo。

2. 设计有数据支撑的矩阵。 运行 scripts/discount_matrix_builder.py --input policy_intake.json --profile {saas|enterprise-software|api|marketplace|services}。输出是一个 4 维矩阵，每个单元格都包含经批准的折扣区间、审批级别、利润底线、实际赢单率和实际 NRR。实际交易数 n < 5 的单元格会标记为 THIN。

3. 设计例外流程。 运行 scripts/exception_router.py --sample 查看结构。对于每个例外严重程度区间（超出 0-5 个百分点、5-10 个百分点、10-20 个百分点、20 个百分点以上），路由器会强制要求提供相应的补偿性承诺。在政策文档中明确该流程；路由器将成为实际执行环节。

4. 检查矩阵。 运行 scripts/policy_linter.py --input matrix.json。获取按优先级排序的问题报告，包含 BLOCKER / MAJOR / MINOR 三个级别，涵盖 10 条检查规则。将所有 BLOCKER 问题解决后，再向 AE 发布矩阵。

5. 发布并按季度审查。 将矩阵作为带版本号的工件发布。每季度根据最新的滚动 4 季度交易数据集重新运行构建器和检查器。实际 NRR < target_nrr 的单元格会标记为待审查。

脚本

脚本	用途	行业配置
scripts/discount_matrix_builder.py	基于数据的四维矩阵，包含审批层级和利润率下限	saas, enterprise-software, api, marketplace, services
scripts/exception_router.py	路由例外申请，并附带补偿性承诺和审计轨迹	不适用（由矩阵驱动）
scripts/policy_linter.py	对矩阵执行包含 10 条规则的检查	不适用（在各配置间保持确定性）

三个脚本均仅依赖标准库，并支持 --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 Survey、Bridge Group AE 薪酬研究、RevOps Co-op 操作手册、Forrester 关于交易桌的研究。共 8 个来源。
• references/policy_design_canon.md — 政策即工件的设计：SaaStr（Jason Lemkin）、Winning by Design（Jacco van der Kooij）关于商业纪律的内容、Forrester 关于交易桌成熟度的研究、MIT Sloan 关于激励系统博弈行为的研究、McKinsey 关于商业政策有效性的研究、Bain Pricing Power、Salesforce CPQ 实施指南。共 7 个来源。
• references/policy_anti_patterns.md — 8 种具名反模式，包含有来源的研究、应对措施和检查规则映射：先例成为政策、缺少数据依据、缺少补偿性承诺、审批者与利润率不匹配、没有审计轨迹、断崖式门槛、未定义的“战略价值”、没有季度审查。共 8 个来源。

假设

• 此技能假设定价模型和标价已存在（通过 commercial/skills/pricing-strategist 设定）。商业政策管理的是相对于标价的折扣，而非设定标价。
• CFO 负责 min_margin_pct 约束（利润率下限）。CRO / 交易桌负责人负责 max_discount_pct_without_exception 约束（折扣上限）。根据 Bain Pricing Power，此技能有意将这两项输入分开（混淆职责是政策偏移最常见的原因）。
• 行业配置内置了惯常的档位宽度。经济状况特殊的公司应通过输入 JSON 传入覆盖值。
• 该矩阵有数据依据，但并非由数据驱动：档位由约束条件和配置决定；观测数据仅作为注释，用于说明该单元格的表现。如果观测到的 NRR 低于目标，这是审查档位的信号，而不是继续加大折扣。
• 只有在以具体标准定义后，“战略价值”层级（logo、expansion、lighthouse）才有用。检查规则 L06 会对此进行强制检查。
• 这是一项政策设计技能，而非交易审批技能。它从不表示“批准”，而是生成矩阵和例外处理流程，供交易桌据此执行。

反模式

• 在缺乏数据支撑的情况下设定折扣区间。“销售副总裁在 Slack 讨论串里主张这样做”不算数据支撑。如果无法展示该区间的赢单率和 NRR，这个区间就只是空谈。（通过每个单元格的 data_backing 和 lint L08 捕获。）
• 让先例决定政策。“Maria 上季度批准了 Acme 的 28% 折扣”不是一个区间，而是一次没有破坏政策的例外。exception_router.py 会将 3 次或更多相似例外标记为一个信号，说明矩阵有问题，而不是交易有问题。（反模式 AP-1。）
• **批准例外时不要求相应承诺。**无条件折扣就是收入流失（Winning by Design）。每个例外严重程度区间都必须有不可协商的承诺。（exception_router.COMPENSATING_LIBRARY。）
• **在整数 ARR 阈值处设置断崖式边界。**硬性的 $100K 阈值会在 2 个季度内导致围绕交易规模进行操纵（MIT Sloan 委托代理理论）。让梯度平滑过渡。（Lint L05。）
• **把“战略价值”当作定义不明的万能说法。**如果“战略”没有明确界定，一个季度内就会有 60% 的交易被标记为战略交易，矩阵也就形同虚设。用具体标准加以定义。（Lint L06。）
• **不进行季度审查。**市场会变化；12 个月不更新的矩阵会导致定价失准。每季度重新运行构建器和 linter。（反模式 AP-8。）
• **混淆 CFO 和 CRO 的职责。**CFO 负责利润率底线；CRO 负责折扣区间上限。由同一个负责人承担问责，会导致可预见的偏移，朝着其薪酬所挂钩的指标发展（Bain 定价权）。
• **发布前跳过 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 的战略判断（“什么时候招聘销售副总裁？”“我们的销售模式是产品驱动还是销售驱动？”）	属于战略层面，而非运营层面。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 playbooks。反模式 AP-2。

2. “当前‘最高折扣’档位的成交，赢单率和 12 个月 NRR 分别是多少？” 建议：两项都要看，不能只看其中一项。赢单率高但 NRR 低的档位，意味着用留存漏洞来换取客户标杆。Tunguz 基准数据：NRR 位于最高四分位的公司，折扣比最低四分位的公司少 6 个百分点。 权威引用：Tomasz Tunguz；Bessemer State of the Cloud。

3. “公司里谁负责毛利底线，谁负责折扣档位上限——这两项职责由同一个人承担吗？” 建议：CFO 负责底线；CRO/Head of 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）；McKinsey B2B 定价研究。反模式 AP-3。

6. “过去一个季度内，同类例外是否已获批 3 次或以上——如果是，矩阵是否有误？” 建议：3 次或以上的类似例外，说明档位定价不合理。应重建矩阵，而不是继续批准例外。 权威引用：OpenView 折扣漂移研究；exception_router._precedent_risk。反模式 AP-1。

7. “上一次用前 4 个季度的数据重新评估矩阵是什么时候？” 建议：每季度一次。年度审查太慢；严谨的团队会按季度修订。 权威引用：OpenView 基准数据；RevOps Co-op。反模式 AP-8。

8. “过去一个季度中的每个例外，是否都有机器可读的审计跟踪记录——还是审批信息只留在 Slack 和电子邮件里？” 建议：在 CPQ 或同等系统中创建结构化记录。到了第 2 年续约谈判时，Slack 和电子邮件里的审批记录无法留存。 权威引用：Salesforce CPQ 最佳实践；Forrester deal-desk 成熟度研究。反模式 AP-5。

按深度优先的顺序提问。先敲定 1-4，再开始 5-8。全部 8 个问题回答完后，依次运行 discount_matrix_builder.py → policy_linter.py → exception_router.py --sample，生成政策工件。

快速示例

# Design the matrix
python3 scripts/discount_matrix_builder.py --sample
python3 scripts/discount_matrix_builder.py --input policy_intake.json --profile saas --output json > matrix.json

# Lint the matrix
python3 scripts/policy_linter.py --sample
python3 scripts/policy_linter.py --input matrix.json

# Walk the exception flow
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。示例例外（价值 $320K 的客户交易，折扣 42%）将按 AE → Sales Manager → Director → VP Sales 的顺序审批，并要求 3 项补偿承诺（36 个月多年合同、预付、明确扩展路径）。