実践セールスファネル：各段階の「次へ進める条件」を決める

仮に、オンライン講座を販売する従業員5名の会社があるとします（仮の例）。フォームからの問い合わせは月に120件ほど。営業担当は全員に同じ資料メールを送り、1週間後に電話をかけています。ある月の成約が4件だったとき、原因を問われても答えられません。120件の中には「来月から使いたい人」と「情報を集め始めた初日の人」が混ざっていて、同じ扱いを受けているからです。

この問題を解くためにファネル（漏斗）の図がよく使われます。ところが実際の図は、「認知→興味→検討→成約」と段階名が並んでいるだけで、どういう状態になったら次へ進めてよいのかが書かれていません。本稿は、段階名よりも先に「次へ進める条件」を決める方法を扱います。

段階は名前ではなく「入る条件」と「次へ進める条件」で定義する

ファネルには、性質の違う2つの軸が混在しがちです。1つ目は顧客側の状態で、認知・興味・検討・購入という購買の進み方です。コトラーとケラーのマーケティングの教科書でも、購買意思決定は段階を踏むプロセスとして整理されています※1。この軸の上で、漏斗の上・中・下に当たる施策を分けて呼ぶ言い方が TOFU（認知）・MOFU（比較）・BOFU（決定）です。これは「どんな内容を届けるか」を決めるための分類です。

2つ目は自社側の管理状態で、リード・MQL・SQL・商談・成約・アフターフォローといった呼び方になります。MQL は営業に渡す前のマーケティング側の判定、SQL は営業が個別に会う価値があると判断した状態です。HubSpot のようなCRMには「ライフサイクルステージ」という名前でこの区分を持たせる機能があります※4。名称や初期設定はツールによって異なるため、自社の定義を先に書いてから設定に写すのが順序として安全です。

二つを混ぜると、「検討段階のリードは MQL なのか SQL なのか」という議論が終わらなくなります。顧客側の軸は「何を届けるか」、自社側の軸は「誰が何をするか」を決めるために使う、と役割を分けてください。そのうえで、自社側の各段階を次の表の形で定義します。

条件を書くときの規則は1つです。第三者が見て「はい」か「いいえ」で答えられること。「関心が高い」は感想なので条件になりません。「料金ページを2回見て、かつ資料をダウンロードした」なら、記録を見れば誰でも判定できます。この規則を守るだけで、担当者が替わっても同じ判断が再現できます。

見極めの条件は「観察できる事実」で書き、差し戻しを記録する

実際の運用でもっとも揉めるのは、マーケティングから営業へ渡す境目（MQL から SQL）です。マーケティング側は「渡した」と言い、営業側は「使えない」と言います。仮の例を挙げます。営業が1か月に受け取った18件のうち、6件は時期が未定、5件は担当者ではなく、4件は情報収集のみ、3件は連絡がつかなかった、とします（仮の例）。営業は「質が悪い」と感じますが、これを理由別に数えると、直すべき箇所が見えます。

差し戻された理由を、タグとして必ず記録してください。この作業は見落とされがちですが、条件を直す材料としてはもっとも安価で確実です。上の仮の例で「時期が未定」が最多なら、フォームに「導入を考えている時期」を選択式で追加できます。「担当者ではない」が多ければ、役職や関与の度合いを聞く項目が要ります。差し戻しの記録がなければ、議論は印象の言い合いに戻ります。

見極めの材料は2種類あります。1つは行動の観察（ページ閲覧、資料のダウンロード、メールへの返信）、もう1つは相手の申告（導入時期、課題、立場）です。行動だけで判定すると、競合の調査担当や学習目的の閲覧者を拾います。申告だけに頼ると、未記入や控えめな回答で本当の見込み客を落とします。2つを組み合わせて、次のような「3つのうち2つ」の形にすると運用しやすくなります。

• 課題：解決したい課題を、相手が自分の言葉で書いたり話したりしている。
• 時期：いつまでに決めたいか、その理由や期限が確認できた。
• 権限：決める人、または決める人に話を通せる人である。

予算・決裁者・必要性・導入時期の頭文字を取った BANT という枠組みは古くから使われています。ただし、初回の接触で予算を直接聞くと尋問のようになりやすく、相手が構えて情報を出さなくなります。予算は商談が進んだ後に、選択肢を示しながら確認する方が自然です。チャットでの具体的な聞き方はLINEでのチャット営業の記事で、価格の前に見極める順序として扱っています。

最初のふるいとして、ターゲット・ペルソナ・ICPの違いと顧客定義シートで作る ICP（理想の顧客像）も使えます。ICP に当てはまらないリードを自動で除外する必要はありませんが、SQL の条件に「ICP との一致」を加点要素として入れると、見極めの基準が自社の成約実績に近づきます。

追客は「終わり方」を先に決める

SQL の条件を満たさなかったリードは、捨てるのではなく育成に回します。ここで先に決めておくのは配信内容ではなく、終わり方のルールです。追い続けるルールだけがあると、担当者は「連絡しなければ失注する」という不安に押されて回数を増やし続け、相手には負担だけが残ります。逆に何も決めなければ、放置されたリードが溜まります。

次の表は追客ルールの雛形です。日数や手段は仮の例で、商材や相手の状況に合わせて変えてください。

7日目の連絡は、「その後いかがでしょうか」という中身のない確認になりがちです。これは相手が返信しにくい形です。「導入の時期は、来月、3か月以内、未定のどれに近いですか」のように答えを1語で返せる質問にします。返信が来れば、その内容がそのまま SQL の条件（時期）の確認になります。

終了条件と復活条件は対にして決めます。たとえば「45日目の確認に返信がなければ休眠タグを付けて配信を止める」。復活は「サイトへの再訪問、再度の問い合わせ、同意の範囲内で年に一度出す案内への反応」のいずれかがあったとき、というように書きます。連絡の頻度と手段は、相手が最初に同意した範囲に収める必要があります。個人情報保護委員会のガイドラインは、個人情報を取得する際に利用目的を特定し、本人に通知または公表することを求めています※5。メールやLINEの配信同意の考え方はチャット営業の記事で詳しく扱います。

仮の数値で読む：詰まりの場所は「定義」と「母数」で変わる

次の表は、全体が完全に仮の数値です（仮の例）。実在の企業の実績でも、業界の平均でもありません。

この表を見て「リード獲得の3％が低い」と感じても、比べる基準がありません。出典のない業界平均は基準にせず、比べる相手は自社の過去の数字にします。ファネルで有用なのは絶対値より、同じ定義で測った前月・前々月との差です。

読み方には3つの注意点があります。1つ目は母数の小ささです。SQL から商談への転換は、18件中12件が約67％でした。仮に13件が商談に進んでいたら約72％で、1件の違いが5ポイント以上の差になります（いずれも仮の例）。単月で一喜一憂せず、3か月ほど合算した数字で見るほうが誤読が減ります。

2つ目は定義の変更です。MQL の条件を緩めれば、MQL の件数は増え、MQL から SQL への転換率は下がります。これは営業の対応が悪化したのではなく、定義を変えた結果です。転換率は定義とセットで記録し、定義を変えた日付を残してください。この記録がないと、数か月後の自分や後任者が数字を誤って解釈します。

3つ目は転換率に隠れる滞留日数です。SQL になってから商談の予定が入るまでに何日かかっているか。ここが長いなら、問題は営業の提案力ではなく、日程調整の仕組みや初回連絡の速さかもしれません。段階ごとの「滞留日数の上限」を設計図に入れておくと、数字の中に潜む待ち時間が見えるようになります。

ファネルは直線ではない：限界と、1枚の設計図

ただし、ファネルは現実を単純にしすぎた図でもあります。マッキンゼーの研究者らは2009年に、消費者の購買の道のりを一方向の漏斗ではなく、検討の途中で候補が増減し、購入後の体験が次の検討に影響する循環として描きました※2。アビナッシュ・カウシックの See-Think-Do-Care という整理も、購入後（Care）までを施策の対象に含めています※3。成約を終点としてアフターフォローを最後に置いただけの図は、既存顧客からの紹介や再購入という入口を設計から落としてしまいます。設計図には、「アフターフォロー」から「リード」へ戻る矢印を1本書き足してください。

一方で、小規模な事業にとって7段階の管理は、記録の手間のほうが大きくなる場合があります。仮に月のリードが10件前後なら、リード・見込み・商談・成約の4段階で足ります。段階は多いほど正確になるわけではなく、記録を続けられる範囲でしか意味を持ちません。もっとも、後から細かく分けることはできるので、最初は粗く始めて、差し戻しの記録から「ここは分けるべきだ」と分かった段階だけを増やす進め方で十分です。

1枚のファネル設計図の作り方

設計図は、段階ごとに次の7項目を1行に書いた表です。段階名／入る条件／次へ進める条件／担当／滞留日数の上限／次の一手／記録する項目。この7列が埋まれば、そのまま CRM やスプレッドシートの設定に写せます。

1. 過去の成約顧客を5件ほどさかのぼり、問い合わせから契約までに実際に通った道筋を書き出す。理想の流れではなく、起きた順序を使う。
2. その道筋に共通する「次に進んだきっかけ」を、段階の通過条件の下書きにする。
3. 成約に至らなかった問い合わせを数件選び、どこで止まったかを同じ形式で書く。
4. 7項目を表に書く。条件は「はい」「いいえ」で答えられる文にする。
5. 営業とマーケティングの担当者が一緒に読み、解釈が割れる条件を直す。
6. 差し戻し理由のタグ（時期未定・担当者でない・情報収集のみ・連絡不通など）を決める。
7. 1か月運用して、タグの集計から条件を1つだけ直す。

ここまでできていれば十分です。各段階の条件が「はい」「いいえ」で判定でき、差し戻し理由を残す欄があり、担当者が替わっても同じ判断が再現できる状態を目安にしてください。実際のCRMでステージとスコアに落とす手順はCRMとパイプライン：ステージ・リードスコア・追客のルールに続きます。

段階の設計を、手を動かしながら学びたい場合は実践セールスファネルを含むコースの案内を参照してください。