deal-desk-approval

ディールデスク承認

標準外の取引において、誰が何を承認できるかを設計します。対象は、割引、個別条件、リスクの高い契約構造です。そして、5つの譲歩レバーにまたがる承認マトリクス、禁止条件の分類、SLA クロックとエスカレーションを伴う例外申請、前例の管理を含む仕様としてまとめます。このスキルの対象はディールデスクの承認のみです。一般的な業務プロセスの承認（経費、調達、人事、エンジニアリング変更）は対象外であり、それらを求められた場合はその旨を伝えて終了してください。

ディールデスクのしきい値は標準化されていません。流通している数値はすべて、実務家のブログやコンサルティング会社に由来し、そのうち複数はコンテンツファームによるものです。そのため、このスキルの中核となる規律は出所の明示です。各しきい値の出所を示し、外部から持ち込んだ「業界」数値ではなく、ユーザー自身の取引データから実際の数値を導き出してください。

基本ルール

• 数値しきい値には、必ず出所を付記してください。ベンダーの経験則を業界共通の基準として提示してはいけません。
  • 公開されている実務家の情報源
  • 単一ベンダーのブログ（参考例に限る）
  • ユーザー自身の取引データから導出
• 次の流通している数値を、事実として述べてはいけません。いずれも、出典が明記されないまま複数のコンテンツで繰り返されています。省くか、広まっているものの未検証であると明記してください。
  • 「粗利益率の下限は75%」
  • 「ARR $40M あたりディールデスクのFTEが1人」
  • 「ミッドマーケットのディールデスク成約率は35%／エンタープライズは70%」
  • Stripe に帰属するとされる「30%超の割引で解約率が4.2倍」
  • Gartner に帰属するとされる「2028年までにB2B 購買の90%が AI を介する」
• 「顧客から依頼された」は正当化の理由になりません。申請項目の中で最も重要なのは、却下した場合の影響、つまり例外を認めなかった場合に何が変わるかです。
• 会計上および法律上の制約は、Finance、Legal、Security、または Product に振り分ける設計上の制約として扱ってください。法律や会計に関する助言は決して行わないでください。
• 該当する場合は、否定的な調査結果を明確に述べてください。市場支配的でない SaaS ベンダーの差別的な割引設定に対して、価格差別法が課す制約はごくわずかです（references/accounting-legal-constraints.md を参照）。存在しないコンプライアンスリスクを作り上げてはいけません。
• 公開されている実務家向けガイダンスが乏しい場合は、正直に伝えてください。標準的な慣行として捏造して提示するのではなく、次の項目はユーザーと明示的に設計してください。
  • 承認済み例外の更新時の扱い
  • リセラー／MSP の価格設定ガバナンス
  • 承認者不在時の手順
• このスキルとその参考資料における選択肢の優先順位はすべて、原則ではなくデフォルトとして扱ってください。状況や実行担当者によって変わるため、何かを推奨する前に、ユーザーについてすでに把握している情報に基づいて順位を見直してください。
• 具体的には、次のとおりです。
  • アナリストが1人だけのディールデスクでは、段階的な引き上げの登録簿や四半期ごとの再導出に対応できません。
  • ポリシーに対する拒否権を持つ営業リーダーがいる場合、下限の引き上げに伴う政治的コストが高まります。そのため、反論できないデータに基づいて導出された下限が優先されます。
  • 更新対象の契約がすでに既得条件で埋まっている場合、期限切れは再交渉を意味するため、現実的な第一歩は段階的な引き上げです。
• 労力は、アナリストのレビュー時間、承認チェーンの所要時間、営業が依拠するポリシーを厳格化する際の政治的資本、および可逆性で表してください。金額では表さないでください。割引率、粗利益率の下限、成約率の計算は対象そのものであるため、そのまま扱ってください。

インタビュー

何かを設計する前に質問します。1回のメッセージにつき1つだけ質問し、可能な場合は選択肢を示します。すでに回答済みの内容はスキップします。

• GTM の販売形態は、営業主導、営業支援付き PLG、ハイブリッド、純粋なセルフサービス／B2C のどれですか？
• 顧客セグメントの構成と ACV の範囲について、小規模、一般的、大規模な取引はそれぞれどのような規模ですか？
• 現在、誰が割引を承認し、どのような手段で行っていますか？承認者なし、マネージャーへの確認、メールのやり取り、見積もりツール、正式な承認窓口のどれですか？
• どの取引データを照会できますか？セグメント別の割引分布、割引率別の成約率、取引ごとの利益率、承認にかかる時間などです。
• 利益率の構造は、限界費用がほぼゼロ（従来型のソフトウェア）ですか、それとも利用量に応じて売上原価が増える（AI／推論、データ、インフラ負荷の高い事業）形ですか？
• 現在、価格以外にどのような譲歩がありますか？支払条件、無償サービス、契約条項の修正、カスタム SLA、セキュリティ／プライバシーに関する追加条項、ロードマップへの要望などです。
• 四半期あたりの取引件数はどれくらいで、そのうち例外対応が必要な割合はおおよそどのくらいですか？
• 課題はどこにありますか？承認待ちで取引が滞るスピードの問題ですか、それとも利益率の低下や記録されない譲歩による収益漏れですか。あるいは両方ですか？
• 振り分け先となる部門はありますか？財務、法務、セキュリティ、プロダクト／デリバリーなどです。
• 更新については誰が担当し、過去の割引が現在、気付かれないまま引き継がれていますか？
• 四半期末の数週間に割引が増えますか？
• 期限について、この仕様をいつまでに運用開始する必要がありますか？今四半期の終了前、次の四半期まで、または期限なしですか？
• 今回の一度きりの成果ですか、それとも積み上がる資産ですか？今四半期の割引を是正しますか、それとも今後のすべての更新でポリシーを適用し、新しい営業担当者がそのポリシーを根拠に交渉できるようにしますか？ここでの「積み上がる」は文字どおりです。一度認めた譲歩は、以後ずっと前例として持ち出されます。
• 工数の上限はどのくらいですか？承認窓口に週あたり何時間のアナリスト工数を割り当てられますか。ポリシーの厳格化に対する拒否権は誰が持っていますか。営業部門に対して、どれだけの政治的資本を使えますか？

最後の3つの回答に照らして参考メニューの優先順位を見直し、どの回答によってどの選択肢の優先順位が変わったのかを明言してください。

• 厳しい期限がある場合は、すぐに効果が出る選択肢の優先順位が上がります。暫定的な自動承認の下限と、更新時に割引を終了させる扱いは、どちらも1日で導入できます。一方、データ抽出が必要な施策の優先順位は下がります。
• 効果を積み上げることが目的なら、四半期の遅れを許容してでも、勝率から導き出した下限の優先順位を暫定値より上げます。暫定値は、営業担当者が期待する割引水準になってしまうためです。
• 工数の上限が低い場合、アカウントごとの追跡が継続的に必要な更新時の段階的な扱いを候補から外し、例外対応レーンのパッケージ作成を、より少数の大きなバッチにまとめます。

ワークフロー

1. インタビューを実施し、仕様が前提とする回答をすべて収集します。

2. 対象範囲の境界を確認します。このデスクが扱うのは標準外の取引です。実際の依頼が価格戦略（定価、パッケージ、階層）または取引以外の承認プロセスに関するものであれば、その旨を伝えて適切な窓口へ案内します。

3. references/approval-matrix-design.md を参照して、対象となる5つの要素を明確にします。

   • 価格／割引
   • 支払条件と請求
   • サービスとデリバリーのコミットメント
   • 契約上のリスク
   • セキュリティ／プライバシーに関するコミットメント

   価格だけを対象とする承認マトリクスでは、譲歩がほかの4つの要素に押し出されてしまいます。

4. 同じリファレンスに基づいて承認マトリクスを設計します。

   • 割引率以外の基準：取引規模、セグメント、営業形態、契約期間、製品ライン、利益率への影響。
   • 3～4段階と、最下位に自動承認の下限を設けます。
   • すべての段階の下に、ポリシー上の利益率下限を設けます。
   • 承認者にかかわらず禁止する項目：最恵国待遇（MFN）／最安値保証、期限の定めのない価格維持、例外規定を除く責任上限なし、未承認のロードマップに関するコミットメント。

5. references/exception-taxonomy.md を参照して、例外の種類ごとに担当部門とエスカレーションの条件を割り当てます。

6. references/intake-routing-and-precedent.md を参照して、受付、ルーティング経路、2つのSLA時計、SLA超過時のエスカレーション、承認者不在時の委任、四半期末の繁忙期モードを設計します。完全性基準を満たした時点でSLA時計を開始します。不完全な申請は、形式を整えて差し戻し、キューに入れることはありません。

7. 同じリファレンスに基づいて、前例の管理を設計します。

   • 例外登録簿、付与したすべての例外の有効期限、パターンからポリシーへの見直し、例外の種類ごとの更新時の扱いを定めます。
   • 既定では期限終了とします。常設の手間をほぼかけずに譲歩全体を回収でき、元に戻すこともできます。価格の再適用によって、そのセグメントですでに解約が発生している場合に限り、段階的引き上げへ移行します。
   • 暗黙の既得権化は選択肢に含めません。
   • 公開されているガイダンスはこの点で十分ではありません。ユーザーと話し合って決定し、社内ポリシーとして記録します。

8. references/accounting-legal-constraints.md を参照して、会計および法務上の制約をルーティングルールとして組み込みます。どの取引構造が、どの承認段階で承認される場合でも、事前に財務または法務へ回付する必要があるのか、その理由も定めます。

9. 以下のセクションに従って、B2BとB2Cをそれぞれ明示的に扱います。見せかけの対称性ではなく、非対称に扱います。

10. 同リファレンスにある優先順位に従って、しきい値を調整します。

    • データがある場合は、割引帯ごとの受注率から自動承認の下限を導きます。
    • 受注率データが乏しい場合は、ユーザー自身の割引分布のパーセンタイルを代替として使用します。
    • 例示的な段階設定は1サイクル限りの仮置きとし、ポリシーとして適用しません。

    パターンを判断できるようになるまで、およそ2四半期分のデータが必要です（RevOps Co-op）。まだデータが存在しない場合は、成果物にその旨を記載します。

11. 仕様（以下の出力形式）をセクションごとに提示し、ユーザーの確認を受けます。references/worked-examples.md にある対応する実例を根拠として使用します。

12. KPIと以下の合格しきい値を付け、合格条件を満たすまで反復します。

13. 実行環境に永続メモリがある場合は、決定した承認段階、下限、禁止項目、更新時の扱いを記憶させます。これにより、後日の再調整では再度のインタビューではなく、これらの内容を出発点にできます。

B2B と B2C

人が対応するディールデスクは、B2B／エンタープライズ向けの仕組みです。B2B では顧客ごとに価格を設定し、見積もりと交渉を行います。一方、B2C では商品ごとに価格を設定し、公開された価格で販売します。B2C にディールデスクは存在しないため、作り出してはいけません。

• PLG、セルフサービス、および取引量の多いトランザクション型 SMB：これに相当するのは、ルールに基づく割引ポリシーです。自動プロモーションエンジン、公開された割引段階、クーポンのガバナンス、利用規約に明記された例外ルールで構成され、人による承認チェーンはありません。人が関与するのは、営業支援が始まる取引規模を超える場合のみです。
• B2C コマース：プロモーション／値下げカレンダーのガバナンス、クーポンの発行と併用のルール、公開された価格調整ポリシーが、ディールデスクの役割を果たします。
• すべてに共通して当てはまるのは、例外による価格の侵食、その根本原因としての文書化されていない前例、そして段階の定義、すべての例外の記録、拡大の監視という規律です。

この対比は、仕組みがそれぞれの販売形態にどう当てはまるかを考察するものとして示してください。文書化された業界の知見として示してはいけません。

出力形式

すべての取り組みで、この成果物を納品してください。すべてのしきい値の行に出典タグを付け、すべての承認者に指名された代理担当者を設けます。

DEAL DESK APPROVAL SPEC - <company>, <date>
Scope        : what counts as non-standard; what this desk explicitly does not govern
Levers       : how each of the five levers is governed (price, payment, services, risk, security)
Matrix       : dimensions x tiers, approver + delegate per tier, auto-approve floor,
               policy margin floor (or cost floor for usage-scaling COGS), fences per segment
Prohibited   : terms no tier approves without an explicit give-get trade
Intake       : required fields (impact-of-denial weighted highest), completeness standard,
               bounce protocol for incomplete requests
Routing      : fast / complex / exception lanes, with lane criteria and the target volume
               share per lane - bulk in fast; exception lane forced by structure, not size
SLAs         : response clock + decision clock per lane (business hours, complete-submission
               to recorded-and-communicated decision), 50/80/100 elapsed-SLA escalation,
               delegation and quarter-end peak mode
Precedent    : register fields, expiry on every exception, pattern-to-policy cadence,
               renewal treatment per exception class (sunset by default; step-up only
               where snap-back churn is evidenced; no silent grandfathering)
Constraints  : accounting/legal routing table - which structures reach Finance/Legal and why
Calibration  : data source per threshold, provenance tags, recalibration cadence
KPIs         : five-KPI scoreboard + measurement definitions

KPI

• 5 つの KPI からなるスコアボードを、単独ではなく必ず一緒に追跡してください（Umbrex）：

  • サイクルタイム
  • 受注率
  • 割引率
  • マージン
  • 価格漏れ

  スピードだけを重視すると不適切な取引をすばやく承認することになり、マージンだけを重視すると行き詰まりが生じ、営業担当者はディールデスクを迂回するようになります。

• サイクルタイムは、必要事項がすべて記入された申請の提出から、決定が記録され、関係者に伝達されるまでの営業時間で測定してください。平均ではなく、中央値と 90 パーセンタイルの両方を報告してください。迂回行動を引き起こすのは、p90 の遅延です。

• 併せて、以下も確認してください。

  • 種類別の例外率：パターンをポリシーに反映する判断のきっかけです。
  • 遅れて判明する割合：提案後に標準外の条件が表面化する割合であり、受付プロセスの不備を示します。
  • 価格実現率：実勢価格／定価（SBI Growth）。
  • 期末の割引急増。

合格基準

仕様は、すべての完全性条件を満たした場合にのみ合格となり、その後、調整ループを繰り返します。

完全性 - すべての項目を満たすまで仕様を反復してください。

• 5 つのレバーすべてが管理対象になっていること。禁止対象の分類があり、マージン（またはコスト）の下限が明記され、承認者に左右されないこと。
• すべての階層に承認者と代理担当者が記載されていること。両方の SLA の時間枠と、レーンごとの 50/80/100 エスカレーションが定義されていること。
• すべての数値しきい値に出典タグが付いており、警告対象となった数値が事実として記載されていないこと。
• 登録簿に有効期限があり、更新時の取り扱いが決定され、記録されていること。

調整 - 以下の両方を満たすまで、例外レビューの実施頻度に合わせてマトリックスを反復してください（RevOps Co-op のヒューリスティック）。

• 承認がほぼ即時：承認が必要な項目が多すぎます。自動承認の下限を引き上げてください。
• 意思決定に時間がかかる（p90 が例外レーンの SLA を超える）：階層が適切ではありません。階層を再編してください。
• 2 回を超えるレビューサイクルを経ても残っている、繰り返し発生する例外がないこと。割引率とマージンをスコアボードで維持しながら、標準ポリシーに昇格するか、明示的に却下してください。

よくある失敗パターン

欠陥	結果	対策
マトリックスが割引率のみを対象としている	値引きが支払条件、サービス、法務、セキュリティに移る	5つすべての要素を1つのマトリックスで管理する
最上位の承認者が1人の役員のみ	買い手側の調達が先に進む間、案件が何日も停滞する	承認者ごとに代理人を指名し、50／80／100でエスカレーションする
承認ロジックがチャットスレッドやスプレッドシートに存在する	背景情報が引き継がれず、四半期末に機能しなくなり、監査証跡も残らない	記録システム上で申請を回付して記録し、すべての決定をログに残す
申請の完全性を確認するゲートがない	不完全な申請に時間を費やし、手戻りが繰り返される	必須項目がそろうまでSLAの計測を開始せず、構造化された差し戻しを行う
期限のない「一度限りの例外」	顧客が翌年に前例として持ち出す	すべての例外に期限を設定して登録し、更新時の扱いを決める
四半期末のプレッシャーの下でルールを緩める	期末に割引が急増し、最悪のタイミングで前例が作られる	ピークモードでは対応能力と締切を追加し、ルールは決して緩めない
平均処理時間を報告する	処理の遅い案件が隠れ、営業担当者がデスクを迂回する	完全な申請の提出から決定の通知までの中央値とp90を報告する
コスト下限を拘束力のある下限として扱う	ソフトウェアの売上原価がほぼゼロの場合は意味をなさず、それを上回る水準で利益率が低下する	ポリシー上の利益率下限を適用する。ただし、使用量に応じて売上原価が変動する製品ではコストを下限とする
値引きを正当化するため、すべての案件を「戦略的」と分類する	案件の40％が戦略的なら、戦略的案件など存在しない	戦略的案件（役員承認済み、記録済み）と戦術的な区分を分ける

呼び出し例

• 「当社のAEは必要なだけ値引きし、すべての案件をメールでCFOに回付しています。階層とSLAを備えた実効性のある値引き承認フローを設計してください。」
• 「ACVの中央値が30,000ドルの当社は、ディールデスクを正式に設置しようとしています。非標準条件（net-90、カスタムSLA、セキュリティ補遺）の承認マトリックスと例外プロセスを作成してください。」
• 「四半期末のたびに値引きが急増し、昨年の『一度限り』の例外がすべて更新時に再び持ち出されます。例外対応と前例の管理を見直してください。」

参考資料

• references/approval-matrix-design.md - マトリックスの要素、階層、下限、禁止区分、しきい値の調整
• references/exception-taxonomy.md - 例外の種類と担当部門への回付
• references/intake-routing-and-precedent.md - 申請項目、処理経路、SLA、エスカレーション、例外登録簿
• references/accounting-legal-constraints.md - 収益認識と法務への回付ルール
• references/worked-examples.md - B2Bの仕様、PLG／B2Cの相当例、否定的な例
• 利益率の低下を検出するには、mbfinotti/revops-skills@revenue-leakage を参照してください
• ステージ管理とパイプライン連携については、mbfinotti/revops-skills@sales-pipeline-hygiene を参照してください
• 期末の案件遅延については、mbfinotti/revops-skills@sales-forecast-diagnostic を参照してください