営業が会話の際に使っているフレームワークをご紹介します。
もしかしたら、営業以外の方にもお役に立つかも…！？
フレームワーク①：BANT（バント）
まずは、BANT（バント）です。
顧客のニーズと状況を把握するためのフレームワークです。
BANTの内訳は、以下です。
B（Budget）：予算 どのぐらいの予算を確保しているか
A（Authority）：決裁権 購入の意思決定は誰がするか
N（Needs）：需要 そもそも需要があるか
T（Time Frame）：導入時期
BANTに以下のCHを加えて、BANTCH（バントチャンネル）とすることもあります。
Ｃ（Competitor）：競合相手 ライバル企業はどこか、どんな提案をしているか
Ｈ（Human Resource）：人的資源 作業分担する人
早い段階でこれらを把握していないと、思わぬ落とし穴にハマることがあります。
例えば、Authorityを聞いていなかったことで、担当者と合意形成できたものの、決裁者の鶴の一声で全てがひっくり返る、といった具合ですね。
どのようにこれらを顧客から確認するかは、様々なコツがあります。
私はおおむね、下記の3点を意識してきました。
①一度に全てを聞こうとしない（電話＋商談など、聞く機会を分ける）
②ダイレクトに聞かない（例：「予算はいくらですか」ではなく「おおよそいくらを超過すると検討から外れますか」）
③慣れないうちはカンペを手元に置いて質問を行う
フレームワーク②：SPIN（スピン）
次に、SPIN（スピン）です。
こちらは、顧客の潜在的な需要を引き出すためのヒアリング手法です。
SPINの内訳は、下記です。
S（Situation）：顧客の状況を聞く質問
P（Problem）：顧客の問題を聞く質問
I（Implication）：課題を解決する必要性に気づいてもらうための質問
N（Need-Payoff）：解決策に導くための質問
なかなか難しいですね。
オンプレミス環境のお客様に、クラウドサービスを提案する例を考えてみましょう。
①S（Situation）：顧客の状況を聞く質問
「御社のサーバ保守や障害対応、どのような体制で行われていますでしょうか」
「インフラ環境は、オンプレミスでの運用が中心でしょうか」
②P（Problem）：顧客の問題を聞く質問
「システム更改や保守対応に、時間やコストがかかってしまうお悩みはございませんでしょうか」
「例えば、突発的なアクセス増やリソース不足に対応するのが難しいと感じられることはございますか」
③I（Implication）：課題を解決する必要性に気づいてもらうための質問
「仮にシステムトラブルが夜間や休日に発生した場合、業務やお客様対応にどのような影響が出ると思われますでしょうか」
「サーバ更改のたびにコストや工数がかかってしまうと、他のIT施策に手が回らなくなってしまう事象は考えられますでしょうか」
④N（Need-Payoff）：解決策に導くための質問
「もしスケーラブルで冗長化された環境を短期間かつ低コストで構築できれば、今の課題はどう変わりそうですか」
②で顧客が問題や課題を伝えた後、共感するコメントを出すのが成功のカギです。
慣れていないと尋問チックになるので、事前にロープレを何度か行うのがオススメです。
フレームワーク③：As Is/ To Be
最後に、As Is/ To Be（アズイズ/ トゥービー）です。
As Isが現状、To Beが目指す姿です。
これらを確認した後、As IsとTo Beのギャップ（課題）を埋めるための解決策を提示します。
先ほどご紹介したSPINより、シンプルですね。
個人的には、To Be→As Isの順序で聞くのが好きです。
As Isから聞いてしまうと、顧客から続けて聞くTo Beが、過度に現実的なものになってしまう可能性があるためです。
As Isに引っ張られることがある、ということですね。
まとめ：言われたものを出すだけでは不足
この記事では、以下の3つのフレームワークをお伝えしました。
フレームワーク①：BANT
フレームワーク②：SPIN
フレームワーク③：As Is/ To Be
顧客から言われたものだけ出すのは、営業として不足です。
ぜひこのようなフレームワークを使い、顧客の課題を正確に把握し、課題解決まで寄り添って行う営業を目指していきましょう！