deal-desk

deal-desk

案件ごとのレビューと値引き承認のルーティング。案件の利益率とリスクをスコア化し、適切な担当者に値引き承認をルーティングし、取引条件を商業ポリシーに照らして赤入れします。自動承認は一切行いません。 すべての出力は、スコアと、氏名が指定された人間の承認者へのルーティング推奨です。

目的

Deal Desk／RevOps／営業リーダーシップは、営業チームが値引きを求める瞬間からCFO／CRO／法務が署名する瞬間までの間に対応します。このスキルは、値引き要求を数値化してルーティングします。

決定論的なツールは3つあります。

1. deal_scorer.py — 5つの評価軸（利益率、リスク、戦略的価値、商業的適合性、契約期間の構成）で案件を0～100でスコア化し、4種類の判定のいずれかを割り当てます：APPROVE / REVIEW / ESCALATE / DECLINE。各判定は、氏名が指定された承認者の承認経路に紐付いています。
2. discount_approval_router.py — 値引き率、案件規模、ティアをもとに、氏名が指定された承認者の承認経路（AE → Manager → Director → VP → CFO/CRO）と推定所要日数を割り当てます。業界に合わせて調整されたポリシー基準に従います。
3. terms_redliner.py — 取引条件に含まれる、創業者や売り手にとって不利な10種類のパターン（上限のない補償、MFN、永続的なライセンスバック、DPAの欠如、NET-60以上、広範な勧誘禁止など）を、重大度、標準的な対案、氏名が指定された法務／商務承認者とともに検出します。

使用するタイミング

次の場合にこのスキルを呼び出してください。

• 営業チームが、AEの承認権限を超える値引き要求にフラグを立てた場合。
• 顧客からMSAの赤入れ版が返送され、法務に回す前にトリアージが必要な場合。
• 案件にCFOの承認が必要で、根拠を示せる利益率の内訳が必要な場合。
• RFPへの回答に複数年の条件が含まれ、その条件の構成をスコア化する必要がある場合。
• 更新に伴う拡張に値引きが含まれ、ポリシーへの適合を確認する必要がある場合。
• 一貫したルーティングが必要な、Deal Deskの承認キューを構築する場合。

次の用途にはこのスキルを使用しないでください：提案書の作成（business-growth/contract-and-proposal-writerを使用）、値引きマトリクスの再設計（姉妹スキルのcommercial-policyを使用）、契約書全文の詳細な法的赤入れ（c-level-advisor/skills/general-counsel-advisorを使用）。

ワークフロー

1. 案件情報を受け取る — 営業／AEが、ARR、契約期間、値引き、支払条件、顧客ティア、戦略上のフラグ、顧客が指摘した取引条件の赤入れ箇所をassets/deal_intake_template.mdに記入します（記入時間は20分）。
2. 利益率とリスクをスコア化する — deal_scorer.py --input deal.json --profile {saas|enterprise-software|services|marketplace}を実行します。総合スコア、評価軸ごとの内訳、判定を確認します。
3. 値引きをルーティングする — discount_approval_router.py --input deal.json --profile <same>を実行します。氏名が指定された承認者の承認経路と推定所要日数を取得します。調整要因（エンタープライズの下限、SMBの迅速処理レーン）は明示されます。
4. 赤入れ箇所にフラグを立てる — terms_redliner.py --input deal_terms.jsonを実行します。対案の文言と、それぞれの承認に必要な承認者を含む、重要度順のCRITICAL／HIGH／MEDIUM／LOWの指摘事項を取得します。
5. パケットをまとめる — 3つの出力をまとめて、Deal Deskレビュー用パケットを作成します。必ず氏名が指定された承認者の承認経路を含めてください。このパケットは推奨であり、承認ではありません。

スクリプト

スクリプト	目的	業界プロファイル
scripts/deal_scorer.py	判定と承認経路を含む5軸スコアカード	saas, enterprise-software, services, marketplace
scripts/discount_approval_router.py	値引き率 → 氏名が指定された承認者の承認経路と所要日数	saas, enterprise-software, services, marketplace
scripts/terms_redliner.py	対案付きの10パターンの危険条項スキャナー	該当なし（取引条件に基づく）

3つすべて：標準ライブラリのみ、--help、--sample、--input <json>、--output {human,json}。

参考資料

• references/deal_desk_canon.md — ディールデスクの運用慣行：SaaStr のプレイブック（Jason Lemkin）、Winning by Design（van der Kooij + Reichl）、Forrester の調査、RevOps Co-op、OpenView のベンチマーク、Bridge Group の AE 報酬、Salesforce のディールデスクのベストプラクティス。
• references/discount_economics.md — 割引の計算と LTV への影響：David Skok（For Entrepreneurs）、Bessemer State of the Cloud、Tomasz Tunguz、OpenView の NRR 調査、Pacific Crest + KeyBanc の SaaS 調査、Insight Partners のレベニューオペレーション。計算例を含みます（粗利益率 80％の製品を 30％割引すると、利益率は 30％ではなく 37.5％減少します）。
• references/contract_landmines.md — 対案の文言例を含む、名称付きの注意すべき条項パターン 10 件以上：YC startup library、Robert Klingberg（Founder's Guide to SaaS Agreements）、Bowman + Brooke のレッドラインガイド、IACCM/WorldCC の商業管理に関する調査、Practical Law の契約ライブラリ、Bradley Tusk のエンタープライズ契約に関する解説、GC100 のガイダンス。

前提

• このスキルは、商業ポリシーがすでに存在すること（割引の範囲、支払条件の基準、補償責任の上限）を前提としています。ポリシーを適用するものであり、策定するものではありません。ポリシーの策定については、兄弟スキルの commercial-policy を参照してください。
• 業界プロファイルには、一般的なしきい値が組み込まれています。会社に文書化された割引マトリックスがある場合は、入力 JSON の policy_thresholds で指定して上書きしてください。
• 契約条件レッドライナーは、最も一般的な注意すべき条項を 10 件検出します。契約全体のレビューにおいて、法務顧問による確認の代わりにはなりません。
• スコアの重み（利益率 30％、リスク 20％、戦略 15％、商業条件 20％、期間 15％）は、CFO 寄りのバイアスを反映しています。RevOps 主導の会社では重みを変更するとよいでしょう。重みは score_deal() の冒頭に定数として定義されており、簡単に調整できます。

アンチパターン

• ディールを自動承認する。 このスキルが「承認済み」と判定することはありません。APPROVE を含むすべての判定で、署名が必要な担当者を明記します。出力は推奨事項です。
• スコアが高いからといってレッドラインの確認を省略する。 UNCAPPED_INDEMNITY を含む場合、合成スコアが高くても DECLINE です。重大なシグナルは合成スコアより優先されます。
• 任意の契約文を法務レビューするためにこのスキルを使用する。 このスキルが受け取るのは、構造化された条件 JSON です。文章のレッドライン確認には、c-level-advisor/skills/general-counsel-advisor/scripts/contract_risk_scanner.py を使用してください。
• 割引ルーターを割引計算ツールとして扱う。 すでに AE／顧客が提案した割引の承認経路を振り分けるものであり、適切な割引を計算するものではありません。価格設定のロジックは commercial/skills/pricing-strategist にあります。
• すべてのディールを CFO に回す。 ルーターは、ディールに署名できる最も権限の低い承認経路で止まります。過剰なエスカレーションはパイプラインの進行を遅らせ、AE が過度に割り引くよう促します。
• 承認経路を手作業で編集して、承認段階を飛ばす。 修飾条件（エンタープライズの下限、SMB の迅速対応レーン）は明示されています。隠れた段階の省略は監査証跡を損ないます。

以下とは異なります

兄弟スキル	対象範囲	違い
commercial/skills/pricing-strategist	価格設定のモデル（席単位、使用量、段階制、定価、パッケージ）を定めます	戦略レイヤーで運用され、個別のディールは扱いません
business-growth/contract-and-proposal-writer	提案書、SOW、MSA を作成します	出力は文書です。ディールデスクは署名前の審査ゲートです
commercial/skills/commercial-policy（兄弟スキル）	割引マトリックスと承認しきい値を設計します	ディールデスクは、そのポリシーを一度に 1 件のディールへ適用します
c-level-advisor/skills/general-counsel-advisor	詳細な法務レッドライン確認とタームシート分析を行います	契約文全体を対象とします。ディールデスクが使うのは構造化された条件 JSON です
c-level-advisor/skills/cfo-advisor	バーンレート、ユニットエコノミクス、資金調達モデルを扱います	戦略的ファイナンスを対象とします。ディールデスクは個別ディール単位です

簡単な例

# Score a deal
python3 scripts/deal_scorer.py --sample
python3 scripts/deal_scorer.py --input my_deal.json --profile enterprise-software

# Route the discount
python3 scripts/discount_approval_router.py --sample
python3 scripts/discount_approval_router.py --input my_deal.json --profile saas

# Flag the redlines
python3 scripts/terms_redliner.py --sample
python3 scripts/terms_redliner.py --input my_deal_terms.json --output json

サンプル（補償責任の上限なし + MFN 条項を含む、割引率 28％のエンタープライズ SaaS ディール）は、複合スコア 100 点中 52.7 点で正しく DECLINE と判定されます。固定 COGS の下では、28％の割引によってディールの利益額が 35.9％減少します。承認経路は AE → Deal Desk → VP Sales → CFO → CRO → General Counsel です。

強制質問ライブラリ（Matt Pocock のグリル・ディシプリン）

/cs:grill-commercial または Commercial オーケストレーターが、一度に1問ずつ確認します。各質問には推奨回答と根拠となる出典が付いています。まとめて質問することはありません。

1. 「最大割引を適用した場合の粗利益率はいくらですか？　また、同じ条件で来四半期のパイプラインはどうなりますか？」 推奨：両方をモデル化します。AE が前例によるリスクを説明できるまでは承認しません。 根拠：David Skok（For Entrepreneurs — 割引の計算）、Tomasz Tunguz のベンチマーク。アンチパターン：40％の割引を一度認めた前例によって、3四半期分のパイプラインが変わってしまいます。

2. 「この割引は標準割引マトリックスの範囲内ですか、それとも範囲外ですか？」 推奨：範囲外の場合は、ポリシー例外であることを明示し、指名された例外承認者に回します。 根拠：OpenView の割引ベンチマーク、RevOps Co-op のプレイブック。

3. 「ARR 以外に、ロゴ、リファレンス、拡大への道筋などの戦略的価値はありますか？」 推奨：指名され、検証可能な拡大またはリファレンスの確約を、書面で求めます。 根拠：ロゴ獲得を目的とする割引についての SaaStr（Jason Lemkin）の見解、確約の表現に関する Winning by Design。

4. 「顧客は補償上限、責任上限、DPA（EU のデータを扱う場合）に署名していますか？」 推奨：必須です。上限のない補償は重大なシグナルとなるため、利益率にかかわらず承認を阻止します。 根拠：WorldCC（旧 IACCM）のコマーシャルマネジメント調査、GC100 の契約ガイダンス。

5. 「支払い条件は NET-30、NET-45、NET-60 以上のどれですか？」 推奨：NET-30 を優先します。NET-45 以上はキャッシュフローを圧迫するため、定量化する価値があります。 根拠：KeyBanc SaaS Survey、Pacific Crest のデータ — 支払い条件が15日延びるごとに、取引の実質価値が約2％低下します。

6. 「契約期間は複数年で年払い前払いですか、それとも年次の自動更新ですか？」 推奨：複数年の前払い ＞ 年払いの前払い ＞ 年次の自動更新、の順に優先します。60日前の通知なしの自動更新は、絶対に譲れない条件です。 根拠：Salesforce Deal Desk のベストプラクティス、OpenView の NRR 調査。

7. 「割引承認の各段階で、承認者となる人の氏名は誰ですか？」 推奨：役職だけでなく氏名を明示します。「営業担当副社長」では承認者になりませんが、「営業担当副社長の Maria Singh」なら承認者です。 根拠：Bridge Group の SaaS AE 報酬調査 — 承認者を氏名で指定すると、前例の逸脱を50％以上抑制できます。

深さ優先で進めます。5〜7に進む前に、1〜4を確定します。7問すべてに回答したら、deal_scorer.py → discount_approval_router.py → terms_redliner.py の順に呼び出します。