commercial-policy

商業ポリシー

目的

リスト価格からの値引きを統制する交渉ルールを設計します。これは、Deal Desk と AE が運用する成果物です。決定論的なツールは 3 つあります。

1. discount_matrix_builder.py — 4 次元のマトリックス（ARR 帯 × 契約期間 × 支払い条件 × 戦略的価値ティア）を作成します。各セルには、最新の受注率と NRR データに裏付けられた承認済み値引き幅と、承認者のティア（AE／マネージャー／ディレクター／VP／CFO）が設定されます。
2. exception_router.py — 値引き要求がマトリックスの範囲外の場合、指定された承認者の承認フローに回し、必須の補完的コミットメント（複数年の前払い＋明示された拡張計画＋リファレンス提供の確約＋MSA 条項の厳格化）を付加します。機械可読な監査証跡のメタデータを生成し、直近の四半期に類似の例外が 3 件以上発生している場合は、前例リスクにフラグを立てます。
3. policy_linter.py — マトリックスのガバナンス上の不備を検査します。承認者の逆転、値引き幅の逆転、最低粗利益率への違反、カバレッジの欠落、段差、戦略的ティアの未定義、最低粗利益率の不整合、データの裏付け不足を検出します。

出力はポリシーそのもの（マトリックス＋例外フロー＋検査レポート）であり、個別の商談への適用ではありません。

使用する場面

• 新任の Head of Commercial または Head of Deal Desk が、会社初の正式な商業ポリシーを作成する場合
• 既存のマトリックスが 6 か月以上更新されておらず、利益率レビューで値引きの拡大が見られる場合
• 営業担当者が「前四半期、Acme で Maria が 28％を承認した」と前例を持ち出しており、その繰り返しを断ち切る必要がある場合
• 四半期ごとの例外件数が増加しており、マトリックスの値引き幅の設定に問題があると考えられる場合
• CFO が最低粗利益率を引き上げ、新たな制約に合わせてマトリックスを再構築する必要がある場合
• 取締役や経営幹部から「なぜこれほど値引きするのか」と尋ねられ、データに基づいた、正当性を説明できるポリシーが必要な場合

次の用途にはこのスキルを使用しないでください。

• 特定の商談を承認する場合 — commercial/skills/deal-desk を使用します
• 価格モデルとリスト価格を設定する場合 — commercial/skills/pricing-strategist を使用します
• 提案書／SOW／MSA の文面を作成する場合 — business-growth/contract-and-proposal-writer を使用します
• 「いつ VP Sales を採用するか」という戦略的判断を下す場合 — 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} を実行します。出力は、承認済み値引き幅、承認者ティア、最低粗利益率、観測された受注率、セルごとの観測 NRR を含む 4 次元マトリックスです。観測商談数が n < 5 のセルには THIN のフラグが付きます。

3. 例外フローを設計します。 scripts/exception_router.py --sample を実行して構造を確認します。例外の重大度別区分（超過 0～5 ポイント、5～10、10～20、20 以上）ごとに、ルーターが必須の補完的コミットメントを適用します。フローをポリシー文書に明文化します。ルーターは運用上の実装となります。

4. マトリックスを検査します。 scripts/policy_linter.py --input matrix.json を実行します。10 個の検査ルールに基づき、BLOCKER／MAJOR／MINOR の優先順位付き指摘レポートが出力されます。マトリックスを AE に公開する前に、すべての BLOCKER を解消します。

5. 公開し、四半期ごとにレビューします。 マトリックスをバージョン管理された成果物として公開します。新しい直近 4 四半期分の商談データを対象に、四半期ごとにビルダーとリンターを再実行します。観測 NRR が target_nrr を下回るセルには、レビュー用のフラグが付きます。

スクリプト

スクリプト	目的	業界プロファイル
scripts/discount_matrix_builder.py	承認者の段階とマージン下限を備えた、4 次元のデータに基づくマトリクス	saas, enterprise-software, api, marketplace, services
scripts/exception_router.py	代替コミットメントと監査証跡を伴う例外申請を振り分けます	該当なし（マトリクスに基づく）
scripts/policy_linter.py	マトリクスに対して 10 ルールのリンターチェックを実行します	該当なし（プロファイル全体で決定論的）

3 つすべて：標準ライブラリのみを使用し、--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 で設定）。商業ポリシーが定めるのは定価からの割引であり、定価は設定しません。
• min_margin_pct の制約（マージン下限）は CFO が所管します。max_discount_pct_without_exception の制約（バンド上限）は CRO／ディールデスク責任者が所管します。このスキルでは、意図的にこれらの入力を分けています（Bain の Pricing Power によると、責任の混同はポリシーの形骸化を招く最も一般的な原因です）。
• 業界プロファイルには、慣例的なバンド幅が組み込まれています。独自の経済条件を持つ企業は、入力 JSON で上書き値を指定してください。
• マトリクスはデータに基づいていますが、データ駆動ではありません。バンドは制約とプロファイルによって設定され、観測データは各セルのパフォーマンスを示す注釈です。観測 NRR が目標を下回る場合、それはバンドを見直すべき兆候であり、さらに深い割引を続けるべきではありません。
• 「戦略的価値」の段階（logo、expansion、lighthouse）が有用なのは、具体的な判定基準が定義されている場合に限られます。リンタールール L06 はこれを徹底します。
• これはポリシー設計スキルであり、ディール承認スキルではありません。「承認」と判断することはありません。マトリクスと例外フローを作成し、それをディールデスクが適用します。

アンチパターン

• データの裏付けなしに割引帯を設定すること。「VP Salesが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。）
• 定義のない包括的な「戦略的価値」を設けること。「戦略的」の定義がなければ、1四半期以内に案件の60%が戦略的とフラグ付けされ、マトリックスは機能しなくなります。具体的な判定基準を定義してください。（Lint L06。）
• **四半期ごとのレビューを行わないこと。**市場は変化します。12か月間更新されないマトリックスは、価格設定を誤っています。ビルダーとリンターを毎四半期実行してください。（アンチパターンAP-8。）
• **CFOとCROの説明責任を混同すること。**粗利益率の下限はCFOが担当し、割引帯の上限はCROが担当します。同じ担当者が両方を担うと、その報酬に結びついた指標へ予測可能な形でずれていきます（Bain Pricing Power）。
• **公開前のLintを省略すること。**BLOCKERの指摘（承認者の順序の逆転、粗利益率下限の違反、割引帯の逆転）があると、ポリシーに署名できません。Lintは公開後のレビューではなく、公開のゲートです。

次の項目との違い

関連項目	対象範囲	違い
commercial/skills/deal-desk	一度に1件の案件へポリシーを適用します	Commercial-policyはポリシー自体を設計します。Deal-deskはマトリックスを利用し、commercial-policyはマトリックスを作成します。
commercial/skills/pricing-strategist	価格設定のモデル（席数単位／使用量／価値／段階制）と定価を設定します	Commercial-policyは定価からの割引を管理します。Pricing-strategistが価格メニューを設定し、commercial-policyがそのメニューにおける割引規律を管理します。
c-level-advisor/cro-advisor	CROの戦略的判断（「いつVP Salesを採用するか？」「当社の営業モデルはプロダクト主導か、営業主導か？」）	戦略的であり、運用上のものではありません。Commercial-policyはCROが委託する成果物であり、CRO自身の判断ではありません。
c-level-advisor/cfo-advisor	粗利益率の下限とユニットエコノミクスに関する判断	CFOはmin_margin_pctをcommercial-policyへの入力として指定します。Commercial-policyはCFOの制約をセルごとの粗利益率下限として運用に落とし込みます。
business-growth/contract-and-proposal-writer	提案書／SOW／MSAの文章を作成します	Commercial-policyは構造化されたマトリックスと監査証跡のJSONを出力し、顧客向けの文章は作成しません。

問い詰める質問ライブラリ（Matt Pocock のグリル規律）

スキルの実行前に、/cs:grill-commercial または Commercial オーケストレーターが、1 問ずつ順番に質問します。各質問には、推奨回答と典拠となる引用を記載しています。決してまとめて質問しないでください。

1. 「過去 4 四半期の値引き分布は実測でどうなっていますか？ また、中央値は現在のマトリクスの内側ですか、それとも外側ですか？」 推奨：どのようなバンドを設計する場合も、まず全データを取得してください。実測中央値がマトリクスの外側なら、そのマトリクスは建前にすぎません。 典拠：OpenView SaaS Benchmarks、RevOps Co-op のプレイブック。アンチパターン 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 のディールデスク調査。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 四半期のデータを使ってマトリクスを再検証したのは、いつが最後ですか？」 推奨：四半期ごとに実施してください。年 1 回の見直しでは遅すぎます。規律ある企業群は四半期ごとに改訂します。 典拠：OpenView のベンチマーク、RevOps Co-op。アンチパターン AP-8。

8. 「前四半期の例外すべてについて、機械可読な監査証跡レコードがありますか？ それとも承認は Slack やメールに残っていますか？」 推奨：CPQ または同等のシステムに構造化レコードを残してください。Slack やメールでの承認は、2 年目の更新交渉まで証跡として残りません。 典拠：Salesforce CPQ のベストプラクティス、Forrester のディールデスク成熟度調査。アンチパターン AP-5。

深さ優先で進めてください。5〜8 に進む前に 1〜4 を確定してください。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

サンプルのマトリクスは、設計上、4 件の BLOCKER、6 件の MAJOR、2 件の MINOR が検出され、リンターの結果は FAIL になります。すべてのルールの経路を検証するためです。実際のポリシーのインテークでは、リンターの結果が PASS または PASS_WITH_WARNINGS になるはずです。サンプルの例外（$320K のロゴ案件に対する 42% の値引き）は、AE → 営業マネージャー → ディレクター → VP Sales へと回され、見返りとして 3 つのコミットメント（36 か月の複数年契約、前払い、指定された拡大計画）が必須になります。