最近、営業やマーケティング関連の記事の中で、「BANT（バント）」というフレームワークが度々取り上げられているのを目にします。

例えば、「営業支援システムでは、案件確度を『BANT』に当てはめて判断するといい」とか、「マーケティング部門がリードの確度を判断する際に『BANT』を活用している」といった内容です。

しかし、実際の営業現場において、「BANT」が案件確度を判断するのに本当に適しているのか疑問に思っています。
また、そもそも法人営業で活用するためのフレームワークなので、マーケティング部門で「BANT」を利用するのは無理があるのではないかとも感じています。

今回は、この理論自体の良し悪しはひとまず置いておいて、「BANT」を実務レベルで使用する際に気を付けるべきポイントについて考えていきたいと思います。

そもそも「BANT」とは？

本題に入る前に、まず、「BANT」とは何かについて簡単におさらいしておきましょう。
「BANT」とは―

上記4つの条件について見込み客にヒアリングを行い、案件やリードの確度を評価する際の指標として使用するものです。
これらの頭文字をとって「BANT」と呼ばれています。

それでは、実際に営業現場で起きていることをもとに、気を付けなければならないポイントについて一つ一つ考えていきましょう。

Budget――「予算がない」わけではない？

まずは、「Budget（予算）」についてです。
そもそも、お客様は本当に予算を決めてから検討を始めるのでしょうか。

確かに原材料や定期購買品などであれば、最初から予算が決まっていることもあるでしょう。
しかし、お客様自身に知見のないモノやサービスを購入する場合、そもそもの相場がわからないため、予算取りをせずに検討を始めることになります。
例えば、数社にコンペをさせ、最終的にどこで買うかを決めてから予算化するといったフローも決してめずらしくないはずです。

実際に私たちが担当者の方に予算を聞いても、「できるだけ安い方がうれしい」とか「本当に良いものであれば予算は取れると思う」といった回答が返ってきます。

このような予算化の実態を認識せず、単純に予算の「あり」「なし」だけでリードの確度を判断してしまうと、多くの機会損失が発生しかねません。

まずは、自社の商材/ソリューションが、お客様の中でどのようなプロセスで予算化されるのかをしっかり理解する必要があります。

Authority―—真の「決裁者」は誰？

「Authority（決裁権／決裁者）」では、「決裁者」をどう定義するかが重要になります。
持っている権限の強さを考えると、最終的に稟議を承認する人、印鑑を押す人、意思決定をする人などが「決裁者」になるでしょう。

しかし、実際の現場では意思決定がボトムアップで行われるケースがかなり多く見受けられます。

例えば、次のようなケースです。
このケースでは、事業部長が意思決定権を持っていました。
しかし、事業部長は検討事項についての詳細を理解しているわけではなく、部長が上げてきた報告を承認しただけです。
その部長も自分で検討したわけではなく、実はその分野に詳しい係長の意見をそのまま事業部長に報告していました。

さて、このケースでは「決裁者」は誰になるでしょうか？　本当におさえるべき人は誰でしょうか？

実際の現場では、このようなことが往々にして起こります。
このケースで厄介なのは、お客様自身も誰が「決裁者」なのか確信を持って答えることができないということです。

そのプロジェクトの鍵を握る真の「決裁者」は誰なのか。
私たち営業パーソンは、現場でしっかり見極めていく必要があります。

Needs――本質的な「ニーズ」は何？

「Needs（必要性）」もまた、 BtoBではかなり厄介なポイントです。
本来は「会社としてのニーズ」を捉えるべきなのですが、実態は必ずしも会社のニーズをベースとした意思決定が行われる訳ではありません。
そこには少なからず、担当者の意図が反映されます。
そのため、「担当者のニーズ」も把握しておく必要があります。
そうなった場合、先ほどの「決裁者」と同じように、「誰のニーズを把握すべきなのか」を見極めることが非常に難しいのです。

以前のコラム「部署」「役職」情報の重要性を知ろうでも触れましたが、下図のように、部署や役職を整理してみると、それぞれが認識している「課題」や「求めるもの」が大きく異なることがわかります。

	企画	管理	営業	製造	情報システム
経営層	①		③
部門長			③		②
現場			③		②

具体的に考えてみましょう。
①導入の方針を出すのが「企画担当役員」、②窓口として検討するのが「情報システム部」、③実際に使用するのが「営業部」だとします。

まず、企画担当役員から情報システム部に導入の目的と概要についての説明があり、情報システム部が検討を始めます。
しかし、情報システム部は簡単な説明を聞いただけで、目的について本質的には理解しきれていません。
また、営業部の業務についても深く理解しているわけではありません。

したがって、ベンダーから導入の背景や目的について聞かれても、言われていたことを伝えるだけの伝言ゲームになってしまいます。
また、業務に関するヒアリングをされても、情報システム部目線での要望を伝えるだけで、業務について十分な説明をすることができません。

このような回答を本当に「お客様のニーズ」と捉えていいのでしょうか？

弊社でもお客様にニーズをうかがう機会がありますが、「導入目的は何ですか？」「どの業務の、何を、どのように改善したいのですか？」と聞いても、多くの場合、明確な回答は返ってきません。
「導入の指示が出たから検討している」という回答が圧倒的に多いのです。

そのようなお客様に対しても導入後に成果が出せるように導くのが営業パーソンの仕事だと思います。
そのためにも、何がお客様の本質的な「ニーズ」なのかを考え、お客様としっかりとした議論をする必要があります。

Timeframe――信用できる「導入時期」とは？

最後は「Timeframe（導入時期）」についてです。
面白いもので、提案当初に導入時期が明確だったお客様の案件が、“計画の後ろ倒し”や“凍結”、“中止”になり、一方で「なる早」や「良いものがあれば」といった一見真面目に検討してなさそうなお客様の案件が“一気に導入まで進展”する、そんなことが頻繁に起こります。

「導入時期」は案件確度を判断するうえで特に重要な要素ですが、実際にその時期を明確にすることは簡単ではありません。

私自身、多くの企業と商談をさせていただく中で、導入時期を明確にコミットできない（社内でもベンダーに対しても）企業が多いように感じます。
また、同時にベンダー側のヒアリングのやり方にも問題があるのではないかと思います。

このようなざっくりとした聞き方では、導入時期を明確にするための有用な情報は得られないでしょう。

導入時期について唯一、明確にできるケースとしては、何かしらの理由がある場合です。
例えば、「保守サポートが切れる」や「法改正への対応のため」など、絶対にやらなければならない理由がある場合は信用できる情報だと考えることができます。

さいごに

このように、「BANT」を実務レベルで使うには、自社の環境下で機能するようにフレームワークそのものをカスタマイズする必要があります。
また、他のフレームワークでもそうですが、使うことが目的になってしまうと、メリットよりもデメリットの方が大きくなることを理解しなければなりません。

以下は余談になりますが、ある超有名戦略コンサルタントのセミナーを聞きにいったときの話です。
セミナー後の質疑応答が興味深いものでした。

質問者は「先ほどのケースの場合、具体的には○対○の比率が最適ですか？」とか「ベストなのは、平均何か月くらいでしょうか？」のように、“そのまま使える答え”を聞こうとします。

それに対するコンサルタントの回答はすべて「ケースバイケース」でした。
質問者は不満そうでしたが、私は率直に答えているなと感じました。

ビジネスの中で、すべての企業に当てはまる「解」はないということでしょう。
だからこそ、それぞれの環境下での「ベストな解」を個別に追求し続けることが重要になるのではないでしょうか。