%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
BANTCHは、見込み顧客の検討状況を複数の観点から整理するヒアリングフレームワークです。質問例と判定基準をCRMに組み込み、担当者が変わっても引き継げる仕組みにすることが活用のポイントです。
BANTCHは、見込み顧客の検討状況を複数の観点から整理するヒアリングフレームワークです。質問例と判定基準をCRMに組み込み、担当者が変わっても引き継げる仕組みにすることが活用のポイントです。
「BANTに沿って質問しているのに、商談化の判断が担当者ごとに違う」「競合や導入体制を聞きそびれ、提案後に前提が変わってしまう」「ヒアリング内容が個人のExcelやメモに分散し、フィールドセールスへ十分に引き継げない」――インサイドセールスの現場では、このような課題が生じることがあります。
BANTCHとは、Budget（予算）、Authority（決裁権）、Need（ニーズ）、Timeline（導入時期）、Competitor（競合）、Human Resources（人的リソース）を確認し、見込み顧客の商談化を判断するためのフレームワークです。質問を並べるだけではなく、各回答を同じ定義でCRMへ記録し、次のアクションにつなげるところまで設計することが重要です。
この記事では、BANTCHの各要素の定義、具体的なヒアリング質問例、商談化判定への落とし込み方までを実務目線で解説します。
本記事は「インサイドセールスとは？基礎知識から導入効果まで完全ガイド」シリーズの一部です。関連するトピックを横断的にまとめたインサイドセールス実践ガイドもあわせてご覧ください。
この記事でわかること
BANTCHという言葉を知っていても、自然な質問の流れや商談化判定まで整理できているとは限りません。ここでは、ヒアリングからCRMへの記録、営業への引き継ぎまでを一連の流れとして解説します。
- BANTCHの全体像 — 従来のBANTとの違いと、それぞれの要素を確認する意味を整理します。
- 各要素のヒアリング質問例 — 予算や決裁権だけでなく、競合状況や導入後の運用体制まで聞くための質問を紹介します。
- 商談化判定の設計方法 — 回答の充足度と定性的な温度感を組み合わせ、次のアクションを決める考え方を解説します。
- CRMで仕組み化する方法 — 情報の一元管理、入力漏れの防止、フィールドセールスへの引き継ぎに使う設計を整理します。
- 運用で起こりやすい失敗への対策 — 尋問調になる、記録が続かない、スコアだけで判断するといった問題への対応を紹介します。
インサイドセールスとして日々ヒアリングを行っている方、これから型を整備したいマネージャーの方に向けて書いています。
BANTCHヒアリングの全体像
BANTCHを活用するには、各要素の名称を覚えるだけでなく、それぞれが商談化の判断にどのように関わるかを理解する必要があります。まずはBANTとの違いと、ヒアリング結果を営業プロセスへつなげる考え方を整理します。
BANTCHを構成する要素
BANTCHでは、見込み顧客の状況を次の観点から確認します。インサイドセールスとは？基礎知識から導入効果まで完全ガイドとあわせて読むと、ヒアリングが営業プロセスのどこに位置するのかを整理しやすくなります。
| 要素 | 英語 | 日本語 | 主に確認する内容 |
|---|---|---|---|
| B | Budget | 予算 | 投資に使える予算枠や申請状況 |
| A | Authority | 決裁権 | 最終決定者と社内の承認プロセス |
| N | Need | ニーズ | 現在の課題と目指したい状態 |
| T | Timeline | 導入時期 | 解決したい時期と検討のきっかけ |
| C | Competitor | 競合 | 比較対象と選定時の評価軸 |
| H | Human Resources | 人的リソース | 導入と運用を担う社内体制 |
これらは独立した質問項目ではありません。例えば、ニーズが明確でも予算申請の時期が合わなければ、すぐに提案へ進むより継続的な情報提供が適している場合があります。導入時期が近くても運用担当者が決まっていなければ、製品の提案とあわせて導入後の体制を確認する必要があります。
BANTとの違い
従来のBANTは、予算、決裁権、ニーズ、導入時期を確認する考え方です。BANTCHでは、そこへ競合状況と人的リソースの観点を加え、提案時の比較条件や導入後の運用まで確認します。
| 比較項目 | BANT | BANTCH |
|---|---|---|
| 予算・決裁権・ニーズ・導入時期 | 確認する | 確認する |
| 競合の検討状況 | 個別に確認 | 専用の観点として確認 |
| 導入・運用体制 | 個別に確認 | 専用の観点として確認 |
| 主な使い方 | 初期的な見込み度の整理 | 比較条件や運用体制を含む商談化判定 |
次の表は、本文で説明したBANTとBANTCHの使い分けを、確認したい範囲ごとに整理したものです。
| 確認したい範囲 | 適する考え方 | 確認する内容 |
|---|---|---|
| 初期的な見込み度 | BANT | 予算、決裁権、ニーズ、導入時期 |
| 比較条件を含む検討状況 | BANTCH | BANTの要素と競合状況 |
| 導入後の運用まで含む検討状況 | BANTCH | BANTの要素、競合状況、人的リソース |
ただし、すべての商材でBANTCHの全項目を同じ深さまで聞く必要があるわけではありません。確認事項が多すぎると会話が不自然になるため、自社の営業プロセスに必要な情報を見極めることがポイントになってきます。
ヒアリングを全体フローに位置づける
BANTCHは、インサイドセールスの通話だけで完結するものではありません。フォームなどから獲得したコンタクトを育成し、商談化した段階で取引へ引き継ぎ、受注後は顧客として支援する流れの中に置く必要があります。
具体的には、コンタクトの検討状況を確認する段階でBANTCH情報を蓄積し、条件が整ったら取引を作成します。その後は取引ステージに応じて不足情報を追加し、失注した場合は理由を記録してナーチャリングへ戻します。このように前後のプロセスまでつなげることで、単発のヒアリングメモではなく、次の判断に使える情報になります。
BudgetとAuthorityを自然に確認する質問例
予算と決裁権は商談の実現可能性に関わりますが、初回から金額や決裁者だけを直接聞くと、相手に警戒されることがあります。現在の取り組みや社内の検討体制から会話を始め、段階的に具体化することをおすすめします。
Budgetは現在の投資状況から聞く
Budgetでは、予算額だけでなく、予算が確保済みなのか、これから申請するのかを確認します。いきなり金額を尋ねるのではなく、現在の取り組みから入ると会話をつなげやすくなります。
| 会話の段階 | 質問例 | 確認したいこと |
|---|---|---|
| 現状確認 | 「現在、この領域にはどのような投資をされていますか？」 | 現在の取り組みと支出の有無 |
| 計画確認 | 「今期、この領域で新しい取り組みをご検討されていますか？」 | 投資計画の有無 |
| 規模確認 | 「概算で構いませんが、どのくらいの投資規模を想定されていますか？」 | 想定する予算の範囲 |
| 手続き確認 | 「予算は確保済みでしょうか。それとも、これから申請される予定でしょうか？」 | 予算確保までのプロセス |
「予算がない」という回答だけで対象外と判断するのは早い場合があります。導入時期やニーズを確認し、今後の予算化に向けて情報提供するのか、適用範囲を絞って段階的に提案するのかを検討します。
Authorityは意思決定の流れとして聞く
Authorityで確認したいのは、役職名だけではありません。誰が評価し、誰が最終判断を行い、どのような承認手続きを通るのかを整理します。商談管理の基本と実践も、ヒアリング後の商談管理を考える際の参考になります。
| 会話の段階 | 質問例 | 確認したいこと |
|---|---|---|
| 体制確認 | 「この取り組みは、社内でどのような体制で検討されていますか？」 | 関係者の全体像 |
| 判断者確認 | 「最終的な導入判断は、どなたが担当されますか？」 | 最終決定者 |
| 関係者確認 | 「ほかに評価や選定へ関わる方はいらっしゃいますか？」 | 選定に関わる部門や担当者 |
| 手続き確認 | 「社内では、どのような流れで承認されますか？」 | 承認プロセス |
| 評価軸確認 | 「関係者の方は、どのような点を重視されますか？」 | 提案で説明すべき観点 |
直接的な聞き方が適さない場合は、「類似する案件では、どのような方が提案資料をご覧になりますか」と尋ねる方法もあります。決裁者への接触自体を目的にするのではなく、社内で検討を進めるために必要な情報をそろえる姿勢が重要です。
予算と決裁権を組み合わせて判断する
予算が明確でも、承認に関わる人や手続きがわからなければ、提案後に商談が止まることがあります。一方で、決裁者が明確でも予算化の時期が合っていなければ、すぐに提案を進めるより継続フォローが適している場合があります。
BudgetとAuthorityは個別に評価するだけでなく、「誰が、どの予算を、どの手続きで判断するのか」という一連の流れとして記録します。この関係をフィールドセールスへ引き継ぐことで、提案資料の内容や次回商談の参加者を考えやすくなります。
NeedとTimelineから検討の優先度を見極める
ニーズと導入時期は、顧客が何を解決したいのか、なぜ今検討しているのかを理解するための要素です。表面的な要望だけを記録するのではなく、現状、影響、理想の状態、期限の順に整理します。
Needは現状と理想の差から整理する
顧客が最初に口にした要望が、本質的な課題とは限りません。例えば「CRMを導入したい」という要望の背景に、営業情報の分散や引き継ぎの難しさがある場合は、製品導入そのものではなく、情報を組織で共有できる仕組みが求められています。
| 確認する段階 | 質問例 | 確認したいこと |
|---|---|---|
| 現状 | 「現在はどのような方法で運用されていますか？」 | 現在の業務フロー |
| 課題 | 「運用の中で、特に困っていることは何ですか？」 | 顕在化している課題 |
| 影響 | 「その課題によって、どのような影響が出ていますか？」 | 課題の重要度 |
| 理想 | 「どのような状態になれば、改善したと判断できますか？」 | 目指す状態 |
| 優先度 | 「複数の課題の中で、優先して解決したいものはどれですか？」 | 提案の焦点 |
| 将来像 | 「現在の課題が解消した後、次に取り組みたいことはありますか？」 | 今後の構想 |
Excelや個人のメモへ情報が分散している場合、検索や更新だけでなく、担当者の変更時にも情報が抜けやすくなります。BANTCHの記録も個人管理にすると同じ問題が起こるため、顧客の課題を聞きながら、自社側の記録方法も見直すことが大切です。
Timelineは期限の背景まで聞く
Timelineでは、希望する導入時期だけでなく、その期限が設定された理由を確認します。期限の背景を理解すると、優先的に解決すべき課題や、社内で動いている別のプロジェクトも把握しやすくなります。
| 確認する段階 | 質問例 | 確認したいこと |
|---|---|---|
| 時期 | 「いつ頃までに実現したいとお考えですか？」 | 希望する時期 |
| 計画 | 「具体的なスケジュールは決まっていますか？」 | 計画の具体性 |
| 背景 | 「今回、検討を始めたきっかけは何でしょうか？」 | 検討を始めた理由 |
| 期限 | 「社内で決まっている期限はありますか？」 | 変更しにくい期日 |
| 並行業務 | 「並行して進めている取り組みはありますか？」 | 社内リソースへの影響 |
「早めに導入したい」という回答だけでは、実際の優先度を判断しにくいことがあります。いつまでに何を決める必要があるのか、その前にどの手続きや準備が必要なのかまで確認します。
NeedとTimelineで次のアクションを決める
課題が明確で期限も具体化している場合は、フィールドセールスへ引き継いで提案を進める選択肢があります。課題は明確でも時期が定まっていない場合は、関連情報を提供しながら検討状況を確認します。
一方で、期限だけが先に決まっていてニーズが曖昧な場合は、提案を急ぐ前に現状と理想の差を掘り下げる必要があります。BANTCHは商談化の合否を決めるだけではなく、不足している情報と次に聞くべき内容を明らかにするためにも使えます。
次の表は、NeedとTimelineの確認状況に応じた次のアクションを整理したものです。
| Needの状況 | Timelineの状況 | 次のアクション |
|---|---|---|
| 課題が明確 | 期限が具体化している | フィールドセールスへ引き継ぎ、提案を進める |
| 課題が明確 | 時期が定まっていない | 関連情報を提供しながら検討状況を確認する |
| ニーズが曖昧 | 期限が先に決まっている | 提案を急ぐ前に現状と理想の差を掘り下げる |
| 情報が不足している | 情報が不足している | 不足情報と次に聞くべき内容を整理する |
CompetitorとHuman Resourcesで提案後のずれを防ぐ
競合状況と人的リソースは、従来のBANTでは独立した要素として扱われていません。比較時の評価軸と導入後の運用体制を早めに確認することで、顧客の判断条件に沿った提案を組み立てやすくなります。
Competitorは選定基準を理解するために聞く
競合情報は、他社を否定するための材料ではありません。顧客がどのような選択肢を比較し、何を重視しているのかを理解するための情報です。競合分析の手法を整理しておくと、比較条件に沿った質問を考えやすくなります。
| 確認する段階 | 質問例 | 確認したいこと |
|---|---|---|
| 比較状況 | 「ほかのサービスも検討されていますか？」 | 競合の有無 |
| 比較対象 | 「差し支えなければ、どのような選択肢を比較されていますか？」 | 比較対象 |
| 評価軸 | 「比較する際に重視している点は何ですか？」 | 選定基準 |
| 現在の利用状況 | 「現在、類似するサービスを利用されていますか？」 | 既存環境 |
| 改善点 | 「現在の運用で改善したい点はありますか？」 | 切り替えを検討する背景 |
競合名だけを聞いても、提案の方向性は決まりません。機能、運用、社内体制など、顧客が何を基準に比較しているのかを確認し、自社がその条件へどう応えられるかを説明します。
Human Resourcesは導入と運用を分けて聞く
ツールの導入では、導入プロジェクトを進める人と、導入後の運用を担う人が異なる場合があります。両者を分けて確認し、設定、教育、日常運用の担当が決まっているかを整理します。
| 確認する段階 | 質問例 | 確認したいこと |
|---|---|---|
| 導入体制 | 「導入を進めるメンバーは、どのような方々ですか？」 | プロジェクトの担当者 |
| 運用体制 | 「導入後の日常運用は、どなたが担当する予定ですか？」 | 継続的な運用担当 |
| 経験 | 「社内にツールの管理経験がある方はいらっしゃいますか？」 | 管理に必要な支援 |
| 教育 | 「利用開始にあたり、研修が必要な方はいらっしゃいますか？」 | 教育の必要性 |
| 支援 | 「運用を始める際に、外部の支援が必要になりそうでしょうか？」 | 支援範囲 |
体制が未定の場合は、それだけで検討を止めるのではなく、導入までに決めるべき役割を共有します。運用担当者の不在を見落としたまま提案を進めると、導入後の定着まで見通せないためです。
競合と体制の情報を提案へつなげる
CompetitorとHuman Resourcesを組み合わせると、選ばれる条件と導入後に実行できる条件を分けて整理できます。比較上は評価されていても運用体制が整わない場合には、提案範囲や開始方法を見直す必要があります。
比較資料を作る際は、競合の弱点を強調するのではなく、顧客が挙げた評価軸に沿って情報を整理します。運用体制についても、顧客の担当者だけに負担を寄せず、社内で引き継げる役割分担を提案することがポイントです。
BANTCHを自然な会話へ組み込む方法
BANTCHの項目順に質問を読み上げると、会話が尋問のようになりやすくなります。顧客の回答を受けて次の質問を選び、複数回の接点を通じて情報を補う設計が必要です。
会話は課題から始める
初回の会話では、NeedとTimelineから入ると、顧客が検討を始めた背景を把握しやすくなります。その後、社内体制や予算、比較状況へ話題を広げます。
| 会話の流れ | 主な確認内容 | 質問の方向性 |
|---|---|---|
| 検討の背景 | Need・Timeline | なぜ検討を始めたのか |
| 現在の運用 | Need・Human Resources | 誰がどのように運用しているのか |
| 社内の進め方 | Authority・Budget | 誰が判断し、どのように予算化するのか |
| 比較条件 | Competitor | 何を基準に選ぶのか |
| 次の行動 | 各要素の不足情報 | 次回までに何を確認するのか |
会話の順番は固定しません。顧客が予算や競合について先に話した場合は、その情報を起点に深掘りします。質問票へ戻ることより、顧客の話を受け止めて背景を確認することを優先します。
一度の接点で埋めきらない
初回の会話で全項目を埋めようとすると、一問一答になりやすくなります。初回は課題と検討背景を中心に聞き、次の接点で社内体制や選定基準を確認するなど、段階的に情報を蓄積します。
不足項目は「未充足」として残し、次に確認する質問をメモします。情報がないことと、条件を満たしていないことは異なるため、未確認の項目を否定的に評価しない運用も必要です。
顧客の言葉と担当者の判断を分ける
ヒアリング内容を要約しすぎると、顧客の発言と担当者の解釈が混ざります。顧客が話した内容を記録する欄と、商談化に向けた担当者の所見を分けておくと、引き継ぎ先が判断の根拠を確認できます。
BANTCHの充足状況だけでなく、「なぜその評価にしたのか」を残します。これにより、担当者が変わった場合やマネージャーが確認する場合でも、評価結果だけを見て判断する状態を避けられます。
商談化判定を属人化させない設計
BANTCH情報がそろっても、判定方法が決まっていなければ、商談化は担当者の経験や感覚に左右されます。評価の定義と次のアクションを対応づけ、スコアと定性的な状況の両方を確認する設計が必要です。
充足度を共通の言葉で定義する
各要素は、情報が明確になっているか、一部だけ確認できているか、まだ確認できていないかに分けて評価できます。評価名だけでなく、どの状態を指すのかをチーム内で共有します。
| 評価 | 状態 | 次の対応 |
|---|---|---|
| 充足 | 判断に必要な情報が明確になっている | ほかの要素とあわせて商談化を検討 |
| 部分充足 | 情報はあるが、判断に必要な詳細が不足している | 不足点を追加で確認 |
| 未充足 | まだ情報を確認できていない | 次の接点で確認 |
| 対象外 | 自社の条件と合わないことが確認できている | 理由を記録して対応方針を決定 |
未充足と対象外を同じ扱いにすると、情報不足だけで見込み顧客を除外することがあります。評価項目の意味をそろえることが、判定品質を整えるうえで重要です。
スコアは不足情報を探す目安にする
各要素の充足度を点数に置き換えると、担当者間で状況を比較しやすくなります。ただし、合計だけを見て自動的に商談化を決めると、顧客の事情や会話の温度感を見落とすことがあります。
スコアは、どの情報が不足しているのか、追加ヒアリングが必要なのかを見つける目安として使います。最終的な商談化は、課題の具体性、導入時期、社内の進め方、担当者の所見をあわせて判断します。
パイプラインの設計と接続する
商談化後は、BANTCH情報を取引パイプラインへ引き継ぎます。パイプラインは、取引ステージ、判断の目安、各ステージの定義、ステージ移行時に入力するプロパティを組み合わせて設計すると、営業活動と記録をつなげやすくなります。
例えば、初回提案へ進む前にニーズと決裁プロセスを確認し、見積もりを提示する前に予算や比較条件を更新するという形です。ヒアリング時点ですべてを完成させるのではなく、商談の進行に合わせて情報を具体化します。
CRMで一元管理し引き継げる仕組みを作る
BANTCH情報をExcelや担当者個人のメモへ残すと、更新箇所が分散し、フィールドセールスが最新情報を探す必要が生じます。CRMのコンタクト、会社、取引を関連づけ、同じ場所で確認できる状態を作ることが重要です。
BANTCHをプロパティとして構造化する
ヒアリング結果は、自由記述だけでなく、共通の選択肢を持つプロパティとして記録します。詳細な発言はメモへ残し、充足状況は選択式で整理すると、一覧での確認と個別の深掘りを両立しやすくなります。
| プロパティ | 入力形式 | 記録する内容 |
|---|---|---|
| Budget | 選択式と補足メモ | 予算の状況と申請プロセス |
| Authority | 選択式と補足メモ | 決定者、関係者、承認の流れ |
| Need | 選択式と補足メモ | 現在の課題と目指す状態 |
| Timeline | 選択式と補足メモ | 希望時期と期限の背景 |
| Competitor | 選択式と補足メモ | 比較状況と評価軸 |
| Human Resources | 選択式と補足メモ | 導入担当と運用担当 |
| 総合評価 | 計算または選択式 | 商談化に向けた評価 |
| 次の確認事項 | テキスト | 不足情報と次回の質問 |
項目を増やしすぎると、入力に時間がかかり、使われないプロパティが残ります。最初は商談化判断と引き継ぎに必要な項目へ絞り、運用を確認しながら調整することをおすすめします。
取引パイプラインへ情報を引き継ぐ
商談化したら、コンタクトや会社で蓄積したBANTCH情報を取引へつなげます。フィールドセールスは、顧客の課題、決裁の流れ、比較条件、運用体制を確認したうえで、次の商談を準備できます。
次の画面は、HubSpotの取引をボード形式で表示し、初回訪問、見込み、見積提示、受注内示などのステージごとに取引カードを並べた例です。
BANTCH情報を取引ステージと対応づけておくと、どの段階で何を確認するのかを共有できます。入力を単なる記録作業にせず、次の営業活動を決めるための情報として扱うことがポイントです。
必須入力と通知で記録漏れを防ぐ
商談化やステージ移行の際に重要なプロパティを必須入力にすると、記録漏れを担当者の注意力だけに頼らずに済みます。通話後に未入力項目が残っている場合は、ワークフローで担当者へ確認を促す方法も考えられます。
ただし、すべての項目を一律に必須化すると、未確認の情報を推測で入力する原因になり得ます。営業プロセス上、その段階で確認できる項目だけを対象にし、「未確認」を正しく残せる設計にします。
Breezeと人の役割を分ける
通話メモの要約や情報の一次整理にはBreezeを活用する余地があります。一方、顧客の言葉の背景を理解し、商談化するか、追加ヒアリングを行うかを決めるのは人が担当します。
Breezeが作成した内容は送信や更新の前に確認し、顧客の発言と異なる要約になっていないかを見直します。判断そのものを任せるのではなく、記録や確認作業を支援する役割として組み込むと、ヒアリング品質を保ちやすくなります。
BANTCH情報をHubSpotへ落とし込む考え方は、「HubSpotのSales Hub（SFA）とは？SFAの機能一覧とAIと連携した、実務で使えるユースケースをご紹介！」でも解説しています。
BANTCH運用で起こりやすい失敗と改善策
BANTCHは考え方がわかりやすい一方で、質問票を作っただけでは定着しません。会話、記録、判定、引き継ぎのそれぞれで起こりやすい問題を把握し、仕組みとして改善します。
よくある失敗を整理する
| 失敗 | 起こる理由 | 改善の方向性 |
|---|---|---|
| 会話が尋問調になる | 項目順に質問を読み上げる | 顧客の回答に合わせて質問順を変える |
| 初回ですべて聞こうとする | 一度の接点で記録を完成させようとする | 複数の接点で段階的に情報を補う |
| CRMへ記録されない | 入力の場所やタイミングが決まっていない | 入力項目と記録のタイミングを統一する |
| 顧客の発言が変換される | 担当者が自分の解釈だけで要約する | 発言内容と担当者所見を分ける |
| スコアだけで判断する | 数値を合否基準として扱う | 定性的な状況とあわせて確認する |
| 項目が増え続ける | 必要性を確認せずプロパティを追加する | 商談判断に使う項目へ絞る |
ただし、BANTCHは商談化を自動的に決める仕組みではありません。顧客の状況を整理し、不足している情報と次の行動をチームで共有するための枠組みです。
新しいメンバーでも使える形にする
質問例、評価の定義、記録場所が統一されていれば、新しく加わったメンバーも確認すべき内容を理解しやすくなります。経験者の話し方をそのまま再現させるのではなく、顧客の回答に応じて次の質問を選べるガイドを用意します。
CRMの必須項目も、入力を強いるためだけに使うものではありません。そのステージで何を確認すべきかを示す仕組みとして設計すると、営業プロセスの教育にもつながります。
小さく始めて判定基準を調整する
導入時は、対象とする商材やチームを絞り、質問例とCRM項目が実際の会話に合うかを確認します。入力されない項目があれば、担当者の意識だけを原因にせず、その情報を聞けるタイミングや入力方法を見直します。
企業様によって最適な要素の重みづけは異なります。受注や失注の記録を振り返りながら、どの情報が判定や引き継ぎに使われているのかを確認し、使われない項目は減らします。
失注後も情報を次の活動へ戻す
失注した取引は、BANTCH情報と失注理由を残し、必要に応じてナーチャリングへ戻します。時期が合わなかったのか、予算や体制が整わなかったのかによって、次に提供する情報や再度連絡する際の確認事項が変わります。
コンタクトの獲得、ヒアリング、商談化、取引管理、失注後のフォローを分断しないことが重要です。BANTCHをこの流れの中に置くことで、過去の会話を次のアプローチに活用できます。
よくある質問
BANTCHを導入するときに生じやすい疑問を整理します。質問項目を増やすことより、自社の営業プロセスでどのように使うかを決めることが重要です。
BANTCHとは何ですか？
BANTCHとは、Budget、Authority、Need、Timeline、Competitor、Human Resourcesの観点から、見込み顧客の検討状況を整理するヒアリングフレームワークです。予算や決裁権だけでなく、比較状況と導入後の運用体制まで確認できます。
BANTとBANTCHはどちらを使えばよいですか？
初期的な見込み度を確認するだけであれば、BANTで整理できる場合があります。競合との比較や導入後の運用体制が提案に影響する商材では、CompetitorとHuman Resourcesを含むBANTCHが適しています。
BANTCHの項目は初回ですべて聞くべきですか？
初回ですべてを聞こうとすると、会話が尋問調になりやすくなります。最初は課題と検討の背景を中心に確認し、その後の接点で予算、決裁プロセス、比較条件、運用体制を補う進め方が現実的です。
BANTCHスコアだけで商談化を判断できますか？
スコアは、不足情報や追加ヒアリングの必要性を確認する目安として使えます。ただし、会話の温度感や顧客固有の事情を表しきれないため、担当者の所見や次の行動とあわせて判断します。
CRMへ記録するときの注意点は何ですか？
選択式の評価と、顧客の発言を残す補足メモを分けることがポイントです。項目を増やしすぎず、商談化判定や営業への引き継ぎで実際に使う情報へ絞ります。
まとめ
BANTCHは質問を漏れなく読み上げるためのチェックリストではなく、見込み顧客の検討状況を共通の観点で整理し、次の営業活動へ引き継ぐためのフレームワークです。自然な会話で情報を集め、CRMへ構造化して残すところまで設計することで、担当者個人の記憶やExcelに依存しない運用へ近づけます。
記事の要点
BudgetとAuthorityでは予算化と承認の流れを確認し、NeedとTimelineでは課題と検討時期を整理します。CompetitorとHuman Resourcesでは、顧客の選定基準と導入後の運用体制を確認します。
商談化判定では、各要素の充足度だけでなく、顧客の発言、担当者の所見、不足情報をあわせて確認します。商談化後は取引パイプラインへ情報を引き継ぎ、失注した場合も理由に応じてナーチャリングへ戻します。
まずは質問と記録場所の対応づけから始める
最初から大きな運用へ広げるのではなく、質問例、評価基準、CRMの入力欄を対応づけるところから始めてみることをおすすめします。
- BANTCHの各要素について、自社の商材に合う質問例と評価の定義を整理します。
- CRMのプロパティと入力タイミングを決め、対象を絞って運用します。
- 記録内容と商談化後の結果を振り返り、使われない項目や判定基準を調整します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
BANTCHの質問設計を、トークスクリプト、営業分業、KPI、営業戦略へつなげて考えるための記事です。自社で見直したいテーマからご覧ください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
