catch-img

BANTとMEDDICの違いとは? ——営業スタイルの違いによる使い分けと、パートナー営業での“再構成”の必要性


目次[非表示]

  1. 1.はじめに
  2. 2.BANTとは?——進行条件が整った商談を見極める「スクリーニング型」
  3. 3.MEDDICとは?——条件が未整備な商談を育てる「設計型」
  4. 4.BANTとMEDDICの違いを俯瞰すると
  5. 5.多くの営業組織が陥る“誤解と空回り”
  6. 6.パートナー営業では「そのまま」では使えない理由
  7. 7.一般的なSFA/MAツールでは補いきれない構造的課題
  8. 8.だからこそ必要な「Partner MEDDIC」の再構成
  9. 9.PRMONEでの再現例(構造的支援の設計)
  10. 10.おわりに


はじめに

提案が通らない理由は「判断の前提」にある
「最後の稟議で止まった」「いつの間にか優先順位が下がっていた」——
営業現場でよくある失注の背景には、価格や提案内容の優劣ではなく、そもそも“進めるべき商談だったのか”という初期判断のズレが潜んでいます。これは、商談の適格性(=Qualification)を見極める段階でのミスと言えます。
本記事では、代表的な商談評価フレームワークである「BANT」と「MEDDIC」の特徴を整理しつつ、特にパートナー営業においては従来の適用が難しい理由と、その再構成の必要性について解説します。



BANTとは?——進行条件が整った商談を見極める「スクリーニング型」

BANTは、商談の初期段階において、「進めるべきか否か」を判断するためのチェックリスト型のフレームワークです。


項目      
意味                              
Budget    
顧客に導入予算があるか            
Authority
意思決定者にアプローチできているか
Need      
解決すべき課題が明確か            
Timeframe
具体的な導入時期が決まっているか  


BANTが有効なのは、すでに導入が前提となっている商談です。
たとえば:

  • 既存システムのリプレース案件
  • 年度予算が確保された投資計画
  • 提案依頼書(RFP)が出されている選定フェーズ

このようなケースでは、営業の役割は条件を整備し、見積精度や比較資料を揃える「整備型営業」になります。
つまり、「この案件は動くか?」を判断する効率的なスクリーニングツールとしてBANTは機能します。



MEDDICとは?——条件が未整備な商談を育てる「設計型」

MEDDICは、商談条件が未確定な段階でも、構造的に案件を育てていくためのフレームワークです。


項目              
意味                                                                
Metrics          
成功の指標(ROI、KPIなど)                                          
Economic Buyer    
最終的な意思決定権を持つ人物                                        
Decision Criteria
ベンダーを選ぶ判断基準(価格、機能、実績など)                        
Decision Process  
稟議や承認プロセスの流れ                                              
Identify Pain    
顧客の本質的な課題                                                    
Champion          
社内で提案を推進してくれる協力者                                        


MEDDICが効果を発揮するのは、検討がこれから始まる商談や、不確定要素の多い初期段階の提案活動です。

たとえば:

  • 業務改革やDX推進の構想段階
  • 導入の意思が固まっていない状態
  • 多部署が関わる意思決定プロセス

営業の役割は、課題の言語化や関係者の巻き込みをリードする「仕掛け型営業」となり、MEDDICは「どう進めれば案件化するか」を論理的に設計する道具になります。



BANTとMEDDICの違いを俯瞰すると

比較軸          
BANT(スクリーニング型) 
MEDDIC(設計型)                    
適用タイミング    
条件が整っている商談                    
条件が未整備な商談                      
営業スタイル      
応札・条件整理・比較対応                
課題共創・意思決定支援                    
成果の鍵 
見積精度・RFP対応・価格調整
課題理解・伴走力・巻き込み力        
想定される業種
製造業、インフラ、基幹業務システム 
SaaS、業務変革、ITコンサルティング等
商談の深さ
表層的(条件の確認)    
構造的(誰が・なぜ・どう決めるか)



多くの営業組織が陥る“誤解と空回り”

  • ×「BANTで十分」:予算・決裁者・時期が揃わなければ外す判断が、潜在的に有望な商談を早期に切ってしまうリスクがある。
  • ×「MEDDICを記入すれば進む」:項目を埋めること自体が目的化し、Championが本当に動いているか?などの実態が置き去りになる。
  • ×「パートナー営業でも使えるはず」:直販とパートナーでは営業構造そのものが異なり、前提が成り立たない場合が多い。



パートナー営業では「そのまま」では使えない理由

パートナー営業では、顧客との接点が自社ではなく代理店や販売パートナー側にあるため、情報取得や商談管理の構造が異なります。


項目      
直販営業                            
パートナー営業                                      
顧客接点
自社営業が直接保有 
パートナー企業が保有
情報収集  
営業自身がヒアリング・更新 
パートナー経由で断片的に共有(遅延・欠落も)
進捗管理  
SFAでリアルタイム更新 
報告ベースで粒度やタイミングにばらつき
稟議確認
営業が直接確認・関与できる
稟議フローが不透明で確認困難 


このような違いがあるため、BANTやMEDDICをそのまま適用しても、正確な判断や設計ができず機能しにくいのです。



一般的なSFA/MAツールでは補いきれない構造的課題

多くの営業管理ツール(例:主要なSFAやMA製品)は、自社営業が顧客との接点を持つ直販構造を前提に設計されています。


比較軸  
一般的なSFA/MAツールの前提
パートナー営業の現実                  
顧客接点
自社営業が保有
パートナーが保有
情報入力
自社での更新が可能  
パートナーからの断片的な報告に依存
タスク管理
社内で一元管理が可能      
実行状況が見えず、進捗把握が困難
スコアリング
顧客行動ログでスコア可視化可能
顧客行動すら取得できないケースも多い 


問題はツールの機能不足ではなく、営業の構造そのものが異なるという点にあります。



だからこそ必要な「Partner MEDDIC」の再構成

パートナー営業においても、MEDDICの視点は有効です。ただし実行には、PRM(Partner Relationship Management)による構造的補完が不可欠です。


MEDDIC要素      
PRMによる支援例                                    
Pain            
提案理由をテンプレート化し、誰でも記録・共有可能に  
Metrics          
仮のKPIを共有し、共通言語化                        
Decision Criteria
類似案件の傾向を蓄積・分析し、選定基準の明文化      
Decision Process
ステージごとの稟議フローを標準化・明示              
Economic Buyer  
接点ログを記録し、決裁者との関係状況を追跡          
Champion        
関与度・エンゲージメントをスコア化し可視化          



PRMONEでの再現例(構造的支援の設計)

  • 未記入のMEDDIC項目を自動で検出・スコア化し、支援優先度を可視化
  • 商談記録をテンプレート化し、入力品質のばらつきを抑制
  • 成功パターンをテンプレートとして展開し、ナレッジを横展開
  • トレーニング・資料閲覧履歴をもとに、Champion候補の関与度を分析支援



おわりに

フレームは“考える”ために、仕組みは“再現する”ために
BANTやMEDDICは、営業活動における思考のフレームとして非常に有用です。
しかし、営業の構造が変われば、それらをどのように適用するかも再設計が必要になります。
特にパートナー営業は、顧客との接点が自社にないという構造的な違いを前提にしたアプローチが求められます。
だからこそ、Partner MEDDICの実行を支える仕組みとしてのPRM(Partner Relationship Management)が重要になるのです。





人気記事ランキング

タグ一覧