見込み顧客評価フレームワーク：BANT、MEDDIC、GPCT — 自社の営業スタイルに合うのはどれか

60日間のエンタープライズサイクルを持つSaaS営業チームがBANTを使っていました。最初のデモから契約までのクローズ率は12%でした。9か月間の失注案件の後、VP of Salesがシンプルな分析を実施しました：後半のPipelineで失った案件のうち74%が最初のコールでBANTの評価を通過していました。予算がありました。権限が主張されていました。ニーズが述べられていました。タイムラインが提示されていました。しかしそれらのどれも彼らが勝つかどうかを予測しませんでした。

MEDDICに切り替えました。12か月後、後期ステージのコンバージョンが23%改善しました。MEDDICが魔法だからではありません。複雑な案件がクローズするかどうかを実際に決定することを担当者に検証させます：実際の経済的バイヤー、組織的影響力を持つ特定のチャンピオン、チームが実際に機能させることができる意思決定プロセス。

BANTは1960年にIBMが発明したときには意味がありました。担当者は明確な予算と単独の権限を持つ調達マネージャーにメインフレームを販売しているわけではありません。案件にチャンピオン、複数のステークホルダー、技術的な勝利が必要なら、BANTは悪い案件を通過させ、時折良い案件を失格にします。このガイドでは、どのフレームワークを使用するか、そして担当者がコール後ではなく実際のコールで適用するように実装する方法を説明します。

ステップ1：各フレームワークが実際にテストしていることを理解する

フレームワークを選ぶ前に、各フレームワークが実際にどの質問に答えているかを知ってください。

BANT: Budget（予算）、Authority（権限）、Need（ニーズ）、Timeline（タイムライン）

BANTは：この見込み客はお金、意思決定権、解決すべき問題、締め切りを持っていますか？と聞きます。買い手がすでに何かが欲しいとわかっていて、あなたの仕事が本物の買い手であることを確認することであるトランザクション型の営業向けです。インサイドセールス、30日未満のSMB案件、1人が意思決定をコントロールする状況でうまく機能します。

失敗する場所：予算がまだ存在せず（正当化プロセスの一部として作成される）、権限が購買委員会に分散していて、タイムラインが「承認が取れたとき」であるような複雑な案件。

MEDDIC: Metrics（指標）、Economic Buyer（経済的バイヤー）、Decision Criteria（意思決定基準）、Decision Process（意思決定プロセス）、Identify Pain（ペインの特定）、Champion（チャンピオン）

MEDDICは：問題を定量化できますか、署名する人に会いましたか、どのように決定するかを知っていますか、プロセスをマッピングしましたか、ペインはアクションを促すのに十分リアルですか、そしてあなたが勝つことを望んでいる社内の誰かがいますか？と聞きます。長いサイクルと複数のステークホルダーを持つ複雑なエンタープライズ営業向けです。

優れている場所：3人以上のステークホルダー、60日以上のサイクル、負けるとコストのかかる大きな契約金額、正式な調達プロセスを持つ組織。

GPCT: Goals（目標）、Plans（計画）、Challenges（課題）、Timeline（タイムライン）

GPCTは：購買者が何を達成しようとしているか、すでに何を試みたか、何が邪魔しているか、いつ結果が必要か？と聞きます。担当者が既存のRFPに応えるのではなく、購買者が問題を明確にしてビジネスケースを構築するのを助けるインバウンドのコンサルティング型営業向けです。

優れている場所：購買者がまだ問題を完全に定義していないインバウンド案件、コンサルティング型の営業スタイル、ソリューションへの道を考えるのを助けることが価値であるような案件。

SPICED: Situation（状況）、Pain（ペイン）、Impact（影響）、Critical Event（クリティカルイベント）、Decision（意思決定）

SPICEDはカスタマーサクセスのアウトカムを中心に構築された新しいフレームワークです。「Impact」（定量化可能なビジネスアウトカム）と「Critical Event」（案件を緊急にする外部の期限）を追加します。保持と拡張が最初のクローズと同様に重要なSaaS企業向けです。

優れている場所：拡張とUpsellのスタイル、チャンピオンが社内でROIを正当化する必要がある案件、アップマーケットに移行するPLGの企業。

ステップ2：案件タイプにフレームワークを合わせる

この意思決定マトリクスを使用してください。

案件サイズ / サイクル ステークホルダー1人 2〜3人のステークホルダー 4人以上のステークホルダー
1000万円未満 / 30日未満 BANT BANTまたはGPCT GPCT
1000万〜5000万円 / 30〜90日 GPCT GPCTまたはSPICED MEDDIC（ライト）
5000万〜1.5億円 / 60〜120日 SPICED MEDDICまたはSPICED MEDDIC
1.5億円以上 / 90日以上 MEDDIC MEDDIC MEDDIC

このマトリクスへのいくつかのオーバーライド：

  • 経済的バイヤーではない技術的バイヤーに販売している場合、案件サイズに関係なくMEDDICを使用してください。「欲しいと思っている人」と「署名する人」を分けることがMEDDICのコアの価値です。
  • 購買者がまだ問題定義モードにある場合、案件が大きくてもGPCTを使用してください。
  • 最近カテゴリーを採用した企業（初めての購買者）に販売している場合、SPICEDは彼らが証明したいと思うアウトカムを中心に会話を固定するのに役立ちます。

ステップ3：ディスカバリーコールにフレームワークを組み込む

すべての評価フレームワークで最大の失敗パターンはこれです：担当者がトレーニングセッションで頭字語を学び、次に「MEDDICを完了する」ためにコールの終わりに5つの急ぎの質問をします。購買者はそれを嫌います。チェックリストが読み上げられているように聞こえます。

目標は尋問ではなく会話を通じて評価情報を浮上させることです。

MEDDICを自然に浮上させる5つの質問：

  1. 「今これを優先する理由は何ですか？」（特定されたペインとタイムラインを浮上させる）
  2. 「あなたの会社でこのような意思決定が通常どのように行われるか説明してください。」（意思決定プロセスと経済的バイヤーを浮上させる）
  3. 「この問題を解決するために他に誰が関与していて、彼らが最も気にしているのは何ですか？」（チャンピオンと意思決定基準を浮上させる）
  4. 「これを修正すると、6か月後の成功はどのようなものですか？どの数値が動きますか？」（指標を浮上させる）
  5. 「社内でこの問題を解決することの最大の支持者は誰かいますか？そのリーダーシップに何を言っていますか？」（チャンピオンの質を浮上させる）

これらのどれも評価のチェックリストには聞こえません。すべてがMEDDICデータを提供します。これらをディスカバリーコールガイドに書き込み、ロールプレイで練習し、次の質問に移るのではなく答えを聞くよう担当者をコーチングしてください。

ステップ4：評価フィールドをCRMに組み込む

評価はデータがマネージャーが見られる場所に住んでいる場合にのみ役立ちます。CRMフィールドとして何を作るか対コールノートに何を残すかを決める必要があります。

フィルタリングおよびレポートするものについてはCRMフィールドを作成：

HubSpotでは：経済的バイヤー（名前＋役職）、意思決定プロセス（ドロップダウン：非公式、委員会、正式な調達）、特定されたペイン（テキスト）、評価スコア（数値0〜10）のカスタム案件プロパティを作成してください。

Salesforceでは：標準のMEDDICフィールドを使用するか、MEDDICプラグインをインストールしてください。最低限、経済的バイヤー確認済み（チェックボックス）、チャンピオン名、意思決定基準（テキスト）、意思決定タイムライン（日付）のカスタムフィールドを作成してください。

Pipedriveでは：案件レコードにカスタムフィールドを使用してください。営業マネージャーがPipelineビューでフィルタリングできる「評価完全性」フィールド（パーセンテージ）を作成してください。

ノートに残す（フィールドではない）：

特定の異議。購買者がペインを説明するために使った正確な言葉。これが今緊急である理由の背景。

ルール：Pipelineでソートしたいかレポートに含めたい場合はフィールドを作成してください。特定の案件のコーチングに役立つコンテキストであれば、ノートに残せます。

ステップ5：評価を資格喪失ツールとして使う

これはほとんどの営業チームが機会を逃している場所です。評価フレームワークは取り組む価値のある案件を見つける方法として教えられます。しかし最も高いレバレッジの使用は取り組みを止めるべき案件を特定することです。

担当者が勝てない案件に費やすすべての時間は、勝てる案件に費やされていない時間です。

フレームワーク別の明確な資格喪失シグナル：

BANTの資格喪失条件：今年度に予算が存在せず、作成する道筋もない。話している人が自分は意思決定に関与していないと明示的に言う。

MEDDICの資格喪失条件：チャンピオン（組織的影響力を持ち、あなたが勝つことを積極的に望みプロセスを通じてコーチングしてくれる誰か）を特定できない。複数のリクエストの後も経済的バイヤーが一度も利用可能にされていない。6週間以上案件にいてまだ意思決定基準を知らない。

GPCT/SPICEDの資格喪失条件：購買者があなたが解決する問題に結びついた定義された目標を持っていない。緊急性を促すクリティカルイベントがない。「いつか」解決したいと言う。

これらを発見したとき、購買者と直接的な会話をしてください：「議論した内容に基づいて、正直に言うと、今これを話すのが適切な時期かどうかわかりません。見えていないことはこれです...」

ステップ6：各案件の評価完全性をスコアリングする

フレームワークを選ぶ以上に、各案件がどれだけよく評価されているかを定量化する方法が必要です。これがマネージャーがPipelineレビューで会話を優先するために使うものです。

シンプルな0〜10の評価スコアはこのように機能します。各MEDDIC要素が0、1、または2ポイントを得ます：

要素 0 = 不明 1 = 部分的に確認 2 = 完全に確認
指標 不明 方向性のある目標が述べられた 具体的な数値とタイムライン
経済的バイヤー 特定されていない 名前がわかっているが関与していない 会って権限を確認した
意思決定基準 不明 一般的な基準が述べられた 特定の書面による基準
意思決定プロセス 不明 一般的なプロセスが説明された ステップ、タイムライン、委員会がマッピングされた
特定されたペイン 何も浮上していない 問題が認識された 定量化された影響が述べられた
チャンピオン 特定されていない 友好的な誰かが特定された アカウント内のアクティブなコーチ

10〜12を得た案件は十分に評価されています。7〜9は進行中だがギャップがあります。7未満なら、案件がPipelineに属するかどうかマネージャーは問うべきです。

このスコアはCRMにカスタムフィールドとして入ります。マネージャーは週次レビュー前に評価スコアでPipelineビューをフィルタリングするので、会話は状況報告よりもギャップに集中します。

ステップ7：教室セッションではなく案件レビューを通じて担当者をトレーニングする

フレームワークはトレーニングからは定着しません。マネージャーがリアルタイムでコーチングしながら実際の案件に繰り返し適用することで定着します。週次Pipelineレビューはこのコーチングが実際に起きる場所です — MEDDICチャレンジフォーマットはそれが別のイベントとして扱われるのではなく、その繰り返しのケイデンスに直接組み込まれた場合に最もうまく機能します。

最良の評価トレーニングは週次のPipelineレビューで起きます。担当者が案件を提示するとき、マネージャーは「この案件のMEDDICを説明して」と聞きます。担当者が答えます。マネージャーはギャップについて反論します：「CFOが経済的バイヤーだと言いました。実際に彼女とのミーティングにいましたか、それとも仮定ですか？」

一部のチームは「MEDDICチャレンジ」フォーマットを使います：月に1回、担当者がチーム全体に複雑な案件を提示し、チームがグループとしてMEDDICの質問をします。すべてに完全に答えられる担当者は通常その案件に勝ちます。

よくある失敗

小さな案件を過剰評価する。 14日間のサイクルを持つ30万円のSMB案件にフルMEDDICを実施するとオーバーヘッドが発生し、販売を遅らせます。フレームワークの強度を案件の複雑さに合わせてください。

会話ではなくチェックボックスとしてMEDDICを使う。 担当者がコール後にメモリーからMEDDICフィールドを埋めている場合、推測しています。情報はディスカバリーの会話で出てくる必要があり、マネージャーを満足させるために後から入力されてはなりません。

SMB案件で経済的バイヤーの特定をスキップする。 15人の会社で最終承認者を聞くのは「正式すぎる」と感じます。しかしSMB案件は、会話のどれにも参加していなかった誰かが承認する必要があるため最後に失敗します。すべての案件でサイズに関係なく経済的バイヤーを特定してください。

四半期中盤でフレームワークを切り替える。 BANTからMEDDICに四半期中盤で変更すると、Pipelineデータが一貫しなくなり、担当者はすべてを再評価しています。1つを選び、実施し、変更する前に1四半期測定してください。

次のステップ

上記の案件マトリクスに基づいて1つのフレームワークを選んでください。一部の案件でMEDDICを、他の案件でGPCTを試すパイロットをしないでください。

1四半期実施してください。1つの指標を追跡してください：後期ステージのコンバージョン率（最後から2番目のステージからクローズまで）。改善すれば、シグナルがあります。改善しなければ、担当者がフレームワークをディスカバリーコールで実際に適用しているかどうか、それともCRMフィールドを後から更新しているだけかどうかを確認してください。

フレームワークが失敗する最も一般的な理由は選定ではなく実装です。うまく実行されたBANTプロセスは、うまく実行されないMEDDICプロセスに勝ります。

関連記事