フィールドセールス 案件化条件の設計方法｜ISからの引き継ぎ基準を実務で決める

案件化条件を言語化しないまま動くとどうなるか

フィールドセールス 案件化条件の設計が後回しになっている組織では、共通して似た症状が出ます。インサイドセールス（IS）が「いい感触だった」と言ってトスアップした商談が、フィールドセールス（FS）の担当者から「まだ早かった」と戻ってくる。あるいは逆に、受注の見込みが薄い案件をFSが何度も追い続け、パイプラインの見た目だけが膨らんでいく。

こうした状態は、ISとFSの「感覚のズレ」ではなく、案件化の定義が言語化されていないことから生まれます。「いつ案件と呼ぶか」を先に決めておけば、IS側は基準を満たしてからトスアップでき、FS側は受け取った時点で何が確認済みかを把握できます。

• 案件化条件とは「商談のどの状態になったら案件と呼ぶか」を定義したもの
• 条件が曖昧なままだと、ISとFSの間で「まだ早い」「もう遅い」の摩擦が慢性化する
• BANT・MEDDICなどのフレームは「要素の抜け漏れを防ぐ道具」であり、使い方次第で機能が変わる
• 引き継ぎ基準は一度決めたら終わりではなく、失注理由から定期的に見直す仕組みが必要
• 株式会社START WITH WHYでは300社以上の営業支援実績から、ISとFSの設計を一体で行うことを標準にしている

株式会社START WITH WHY代表の中村です。弊社では大手・上場企業からスタートアップまで300社以上のご支援を行ってきました。フィールドセールスの立ち上げ・改善支援の中で、案件化条件の言語化はほぼ必ず取り組む論点です。このページでは、実務で使える形に絞って整理します。

案件化条件を決める重要性

営業パイプラインには必ず「段階」があります。問い合わせ、初回接触、ヒアリング、提案、クロージング――こうした段階を定義すること自体は多くの企業が行っています。しかし、「どの条件が満たされたら次のステージに進むか」まで決めている組織は、思いのほか少ない。

案件化条件を決めることで得られる変化は主に3つあります。

1. 商談数ではなく案件化率で改善できるようになる
条件が言語化されていれば、「100件の商談のうち何件が案件化したか」「案件化できなかった理由は何か」が見えてきます。「案件化条件を満たしていない商談がどこで止まっているか」を特定できれば、ISのトーク・ターゲット・接触タイミングを調整する根拠が生まれます。

2. ISへのフィードバックが具体的になる
「先週の商談、あまりよくなかった」では何も変わりません。「予算確認ができていなかった」「決裁者に会えていなかった」という形で条件の充足・未充足に対応したフィードバックが返せるようになります。FSは受け取るだけの立場ではなく、上流を磨く起点になります。

3. 停滞案件を早期に識別できる
案件化の条件が明確だと、「次のアクションが決まっていない案件」「期日が未確認の案件」を機械的に抽出できます。パイプラインの実態が見えるようになり、FS個人の「感覚」に依存したヨミ管理から脱せます。

案件化条件を決める3つの効果

条件を言語化することで変わる営業の動き方

• 商談数→案件化率 改善軸が変わる（「何件商談したか」から「何件が条件を満たしたか」へKPIが変わる）
• 感覚→根拠 フィードバックが具体的になる（「よくなかった」ではなく「予算未確認」「決裁者未接触」と伝えられる）
• パイプライン 停滞案件を早期識別（次のアクションが決まっていない案件・期日未確認の案件を機械的に抽出できる）

株式会社START WITH WHYの支援実績から導いた整理。数値ではなく定性的な変化を示す。

案件化条件はFSだけが使うものではありません。ISがトスアップの基準として使い、マネージャーがパイプラインの健全性を見るために使い、営業コンサルが改善施策を設計する際の出発点にもなります。設計は一度やれば終わりではなく、失注の理由が蓄積するたびに見直す運用が前提です。

BANT・MEDDICなど主要フレームの使い分け

案件化条件を設計するとき、既存のフレームワークを参照することは有効です。ただし「どのフレームが正しいか」よりも「自社の商材とプロセスに合わせて何を聞くか」が本質です。フレームは確認すべき要素の抜け漏れを防ぐための道具として使います。

BANT：最も広く使われる基本形

BANTは Budget（予算）、Authority（決裁権限）、Need（必要性）、Timeline（導入時期）の頭文字です。シンプルで覚えやすく、ISが初回ヒアリングで確認するチェックリストとして機能します。

ただし、BANTにはいくつかの限界があります。高単価・長期検討の案件では、初回商談の段階で予算が確定していないケースがほとんどです。「予算はまだ決まっていない」という回答を案件化不可と判断すると、有望な案件を早期に切ってしまうリスクがあります。BANTは「全項目クリアを必須にする」のではなく、「何が未確認かを把握する地図」として使うのが実用的です。

MEDDIC：大型案件・複雑な組織向け

MEDDICはMetrics（定量的な効果）、Economic Buyer（予算権限者）、Decision Criteria（意思決定基準）、Decision Process（意思決定プロセス）、Identify Pain（課題の特定）、Champion（社内推進者）の6要素です。複数の意思決定者が関与する大型案件や、稟議の通し方が複雑な組織に対して特に機能します。

FSがMEDDICを使う場面では、特に「Champion（社内推進者）」の存在確認が重要です。担当窓口が稟議を通せる立場にあるか、あるいは社内で推進してくれる人物が別にいるかを把握していないと、提案後に停滞する案件が増えます。

CHAMP：スタートアップ・スピード重視の商談向け

CHAMPはChallenges（課題）、Authority（決裁権限）、Money（予算）、Prioritization（優先度）の順で確認します。BANTとの違いは、「課題の深刻さ」を最初に確認する点です。相手が自分の問題を言語化できているか、今すぐ解決したいのかを先に確認し、予算は後から議論するアプローチです。意思決定が速い組織との商談では、この順序の方が会話が自然に進みます。

BANT・MEDDIC・CHAMP比較

商材・組織規模・商談スピードで選ぶ

観点	BANT	MEDDIC	CHAMP
確認要素	予算・権限・必要性・時期	定量効果・予算権限者・意思決定基準など6要素	課題・権限・予算・優先度
向いている商材	汎用（初回ヒアリング）	大型・複雑な組織向け	スタートアップ・スピード商談
確認の優先順位	Budget（予算）から	Identify Pain（課題）から	Challenges（課題）から
稟議対応のしやすさ	中	高（Decision Processを含む）	低（稟議想定が薄い）
ISでの使いやすさ	高（シンプル）	中（要素が多い）	高（課題を先に聞く）

各フレームの特性を一般化した比較。自社の商材・プロセスに合わせて要素を調整することが前提。

フレームは組み合わせてもよい

実務では「BANTで基本確認、MEDDICで深掘り」という使い方が多くなります。ISがBANTベースで初回ヒアリングを行い、案件化の判断基準を満たしたらFSにトスアップ、FSがMEDDICでより詳細な情報を収集しながら提案を組み立てる、という流れです。

フレームを選ぶより先に、「自社の商材において何が確認できれば案件と呼べるか」を自分たちの言葉で定義することが優先です。フレームはその定義を作る際の参照リストとして使います。

IS〜FS引き継ぎの実務チェックリスト

案件化条件を設計したとして、それがトスアップの現場で機能するかどうかは別の問題です。条件を満たしているかを確認するためのチェックリストが、ISとFSの共通言語になります。

以下は、弊社がフィールドセールスの立ち上げ・改善支援で実際に使ってきた確認項目の構造を一般化したものです。商材や業界によって中身は変わりますが、確認すべきカテゴリは共通しています。

IS→FS引き継ぎ確認項目

何が分かっていて何が未確認かを明示する

• 課題の言語化：相手が自社の課題を言語化できているか。「なんとなく検討」と「今すぐ解決したい」では温度が異なる
• 予算の確認状況：予算枠があるか、金額感の感触を得ているか。未確認の場合はその旨をFSに明示する
• 決裁者・決裁プロセス：窓口担当者が決裁権を持つか。複数の承認者がいる場合は稟議の流れを把握しているか
• 検討時期・導入希望時期：今すぐ検討なのか、半年先なのかで次アクションが変わる。期日のある場合は明記
• 競合状況：他社との比較検討をしているか。すでに深く検討が進んでいる競合がいるかを把握
• 次のアクションと合意：商談後に相手が何をするか合意が取れているか。日程・担当者・確認事項を明確にする

Q. チェックリストを全項目埋めることにこだわりすぎると、トスアップが遅くなりませんか？

よくある懸念です。案件化条件は「全項目クリアを必須にする厳格なゲート」ではなく、「何が分かっていて何が分かっていないかを明示する地図」として使う設計にするとうまくいきます。

たとえば「予算：未確認」「決裁者：窓口担当者のみ接触、決裁者は別にいる模様」という状態でトスアップしても構いません。ただし、その状態がFSに伝わっていることが前提です。FSは「未確認事項が何か」を把握した上で商談に入れるので、初回商談のアジェンダを適切に設計できます。

「全部分かってから渡す」よりも、「何が分かっていないかを明示して渡す」方が、IS・FSの両者にとって動きやすい引き継ぎになります。

引き継ぎフォーマットをどこに残すか

チェックリストの確認内容は、SFAやCRMのフィールドに対応させておくことが理想です。しかし、ツールの整備より先に「何を確認するか」の合意を作ることが重要です。最初はスプレッドシートや商談前の口頭確認ルーティンから始め、慣れてきたらSFAに落とし込む順序で問題ありません。

弊社の支援では「言葉で終わらせず、テンプレ・リスト・ログとして残す」ことを標準にしています。口頭で「こういう基準でやろう」と合意しても、時間が経てば解釈のズレが生まれます。引き継ぎフォーマットが存在することで、IS・FS双方の行動が揃いやすくなります。

案件化条件のコミュニケーションと運用の回し方

案件化条件は一度設計したら完成ではありません。運用しながら見直す仕組みとセットで設計することが、長期的な精度向上につながります。

失注理由を案件化条件の見直しに使う

失注した案件を振り返ると、「案件化の段階で何が分かっていれば早期に判断できたか」が見えてきます。「競合がすでに深く入り込んでいた」なら「競合状況の確認」を条件に加える、「意思決定者が商談に出てこなかった」なら「決裁者参加の確認」を必須化する、といった改善サイクルが回ります。

こうした振り返りを月次で行い、チェックリストと条件の定義を更新していく運用が、IS・FS双方の精度を上げる最も確実な方法です。

IS・FSの定期的な商談振り返り

案件化条件の運用が形骸化しやすいのは、ISとFSが別々に動き、互いのフィードバックが届かない状態が続くときです。週次あるいは隔週で、ISとFSが同じ場に集まり、直近のトスアップ案件の状況を確認する時間を設けることが有効です。

確認する内容は「トスアップした案件がどうなっているか」「案件化できなかった理由」「ISのヒアリングで改善できる点があるか」の3点です。30分でも定期的に回すことで、条件の解釈のズレを早期に修正できます。

案件化条件の運用サイクル

設計して終わりではなく、失注から学ぶ

1. Step 1：条件の初期設計
   BANTやMEDDICを参照しながら、自社商材で確認すべき要素を言語化する
2. Step 2：引き継ぎフォーマット化
   確認項目をスプレッドシートまたはSFAのフィールドに落とし、IS・FSで共有する
3. Step 3：運用開始・ログ蓄積
   トスアップ時の確認状況を記録。「何が未確認だったか」を商談ごとに残す
4. Step 4：月次の失注振り返り
   失注理由を案件化条件に照合し、「早期に判断できた情報は何か」を議論する
5. Step 5：条件の更新
   振り返りで得た知見をチェックリストと条件定義に反映し、次の運用に備える

Q. 案件化条件は商材ごとに変えるべきですか？

複数の商材・サービスラインを持つ企業では、商材ごとに条件を変えることが現実的です。単価の高い商材では稟議プロセスの確認が必要になり、低単価・短期検討の商材では「今すぐ検討しているか」の確認が最重要になる、という差があります。

ただし、商材ごとに条件を変えても「確認するカテゴリ（予算・決裁者・課題・時期）」は共通です。各カテゴリで「何をもって確認済みとするか」の閾値だけを商材別に調整するアプローチが、運用の複雑さを抑えながら精度を上げやすい設計です。

稟議を通すための資料設計もFSの役割

フィールドセールスの役割は「商談でクロージングする」ことだけではありません。提案後に稟議が通るかどうかも、FSが影響を与えられる領域です。

企業規模や業界によって稟議の流れは異なります。誰が・どの順番で・何を見て決めるかを商談の中で把握し、担当者が社内で通しやすい形の資料（比較表・リスク説明・導入後の体制説明など）を用意することが、商談後の停滞を防ぎます。

案件化条件の設計に「稟議フェーズで必要な情報が揃っているか」を組み込んでおくと、提案時点での準備が整いやすくなります。

トスアップ判断の2軸

課題の緊急度と確認情報の充足で判断する

課題の緊急度＼確認情報の充足度	低	高
高	緊急だが情報不足：条件を明示してトスアップ、FSが初回商談で補完	緊急かつ情報充足：即トスアップ、FSは提案設計に集中
低	緊急度低・情報不足：ナーチャリング継続、時期を変えて再接触	緊急度低・情報充足：タイミング待ち、定期フォローを設計

設計の精度は「誰に・いつ」の解像度で決まる

案件化条件の設計は、突き詰めると「誰が・どのタイミングで・何に困っているときに、最もこちらの提案を受け取りやすいか」の言語化です。これはフィールドセールスの商談設計だけでなく、ISのターゲット設計・接触タイミング・トーク設計にも直結します。

条件を決めることは「排除するルール」ではなく、「受注につながる商談に集中するための設計」です。条件が明確であるほど、ISは確信を持ってトスアップでき、FSは受け取った時点から提案の質を上げられます。

弊社では、IS・FSの設計を分けずに一体で考えることを支援の標準にしています。案件化条件の設計や引き継ぎフォーマットの整備、パイプラインの健全性診断など、営業プロセス全体の設計に関心がある方は、まず営業代行の費用相場・支援範囲の概要やアウトバウンド営業代行の選び方をご参照ください。弊社の支援範囲について確認いただけます。

また、フィールドセールスの商談改善と合わせてインサイドセールスの体制整備を検討されている方は、営業代行・IS代行サービスの比較も参考になります。