セールスファネルとは？BtoBの基本構造と営業×マーケ接続の設計方法を解説

この記事の要点

• セールスファネルは、見込み客が認知から受注に至る行動プロセスを段階的に可視化した「漏斗」状のモデルです
• マーケファネルとの違いは対象範囲と責任部門。マーケはリード獲得まで、セールスは商談以降を担います
• BtoBで最大のボトルネックは、マーケと営業の接続点であるMQL→SQLのハンドオフ不全です
• 各段階のKPIと転換率の目安（例：MQL→SQL 30〜50%、SQL→受注 20〜30%）を持つことで改善対象が明確になります
• 改善は「最も漏れが大きい段階」をベンチマーク比較で特定し、ピンポイントに対策するのが鉄則です

「マーケが集めたリードを営業が追わない」「ファネルを設計したいが、どこから手をつければいいかわからない」。BtoB企業のCMOや営業企画担当者からよく聞く悩みです。セールスファネルは単なるフレームワークではなく、営業とマーケの共通言語であり、経営アジェンダそのもの。本記事ではBtoBのCMO視点で、ファネルの基本構造から営業×マーケの接続設計、KPI、改善方法までを実務レベルで解説します。

この記事の監修者

麻生 諒也株式会社ウォーカンド 代表取締役

学生時代よりSEO・SNS事業を立ち上げ、個人事業主としてマーケティング領域に従事。個人と並行し、新卒でWEB広告代理店に入社。ブランド領域の広告プランナーとして、提案から運用まで一気通貫で担当する。同領域にて準MVP、MVPを受賞し、独立。2025年、株式会社ウォーカンドを設立。

セールスファネルとは？意味と基本構造をわかりやすく解説

セールスファネルとは、見込み客が認知から購買に至るまでの行動プロセスを段階的に可視化したモデルです。上から下に進むほど人数が絞られる「漏斗（じょうご）」状の構造を持ちます。各段階での離脱率を把握し、ボトルネックを特定して改善することで、効率的な受注最大化を実現するための土台になります。

セールスファネルの語源と『漏斗』に例えられる理由

funnelとは英語で「漏斗」のこと。広い口から液体を注ぐと、下に向かって細く絞られていく形状を指します。営業・マーケの世界では、見込み客の数が段階を経るごとに減っていく様子をこの形に重ねて表現しているのです。

具体例で見てみましょう。あるBtoB SaaSでサイト認知1,000人を獲得したとします。そこからフォーム登録に進むリードは100人、商談化するのは20件、最終的な受注は3件。この指数関数的な絞り込みこそ、ファネル思考の本質です。

つまり、上流の母数を増やすか、各段階の通過率を上げるか。打ち手はこの2軸に集約されます。

セールスファネルの4〜5段階モデル（TOFU/MOFU/BOFU）

一般的にはTOFU（Top of Funnel＝認知）、MOFU（Middle＝興味・検討）、BOFU（Bottom＝比較・購買）の3層で整理されます。BtoBでは精度を上げるため、「リード→MQL→SQL→商談→受注」の5段階に細分化するのが実務的です。

なぜ今セールスファネルの再設計が必要なのか

購買プロセスのデジタル化が進み、BtoBの買い手は営業に接触する前に意思決定の6〜7割を済ませているといわれています。比較サイト、口コミ、ホワイトペーパー、ウェビナーで情報収集を終えてから、初めて問い合わせが入る時代です。

つまり、営業が動き出すよりずっと前に勝負はついている。だからこそマーケがファネル上流を設計し、営業へ滑らかに引き渡す全体設計が不可欠なのです。従来の「営業がすべて」のモデルでは、もはや受注は積み上がりません。

セールスファネルとマーケティングファネル・パーチェスファネルの違い

マーケティングファネルは「認知〜リード獲得」までを対象にマーケ部門が責任を持ちます。セールスファネルは「商談〜受注」までを営業が担います。パーチェスファネルは顧客の購買心理に焦点を当てたモデルで、AIDAやAISASがこれに該当します。3つは対象範囲と責任部門が異なるのです。

マーケティングファネルとの違い（責任範囲と指標）

マーケファネルのKPIはMQL数、CPL（リード獲得単価）、コンテンツ経由のリード数など、「リードを供給するまで」が責任範囲です。一方セールスファネルは商談化率、受注率、ACV（年間契約金額）といった「受注に直結する指標」を追います。

両者の接続点が「MQL→SQL」のハンドオフ。ここが最大の分断ポイントになります。マーケは「質の高いリードを渡したつもり」、営業は「使えるリードが少ない」。この食い違いを放置すると、ファネル全体が機能不全に陥ります。

パーチェスファネル・AIDA/AISASとの違い

AIDA（Attention→Interest→Desire→Action）やAISAS（Attention→Interest→Search→Action→Share）は消費者の購買心理を表したモデルで、主にBtoCマーケで使われます。買い手の頭の中の動きを捉える視点です。

対してセールスファネルは「社内の誰が、どの段階で、何をするか」を設計するオペレーションの図。心理モデルと業務モデル。混同しがちですが、目的がまったく違います。

ダブルファネル・砂時計モデル（受注後も含めた拡張）

近年のBtoB SaaSでは、受注で終わらず、オンボーディング→活用→アップセル→紹介までを含めた「砂時計型」モデルが主流です。受注後にもう一度ファネルが開いていく形をイメージしてください。

LTV最大化が経営テーマである以上、カスタマーサクセス（CS）部門との連携設計まで含めて「ファネル」と捉えるべき。アップセル・紹介経由のリードは、新規獲得より圧倒的にCACが低くなります。

BtoBにおける営業とマーケのファネル接続──最大のボトルネックはどこか

BtoBファネルの最大の失敗要因は、「マーケが渡したリードを営業が追わない／質が低いと評価する」というMQL→SQLのハンドオフ不全です。これを解決するには、両部門で「SQLの定義」「対応SLA（時間）」「フィードバックループ」の3点を合意することが必須になります。

リード→商談→受注の3つの分断ポイント

BtoBファネルには典型的に3つの分断が起こります。第一に、マーケとインサイドセールスの間でリードが放置されるパターン。MAから通知が飛んでも、誰がいつ対応するか決まっていないと、数日後には熱が冷めます。

第二に、インサイドからフィールドセールスへの引き渡しで「商談化基準」が曖昧なケース。「とりあえずアポを取れたら渡す」では、フィールドが嫌気を起こします。第三に、フィールドからCSへの受注後ハンドオフで顧客情報が引き継がれず、オンボーディングが滞るパターン。どれも組織設計の問題です。

MQLとSQLの定義をどう揃えるか

MQL（Marketing Qualified Lead）は属性データ（業種・規模・役職）とエンゲージメントスコア（資料DL・メール開封・ウェビナー参加）で定義します。SQL（Sales Qualified Lead）はBANT（Budget予算・Authority決裁権・Need必要性・Timeframe導入時期）で定義するのが基本です。

重要なのは、両部門が同じテーブルで定義を合意するプロセス。営業とマーケのリーダーが集まり、過去の受注顧客データを見ながら「どんなリードが受注に至ったか」を逆算してMQL/SQLを言語化するワークショップを月1で開くのが効果的です。

SLA（サービスレベル合意）で営業とマーケを接続する

SLAとは部門間の「約束事」を明文化したもの。マーケは「月次MQL〇件、品質基準（業種・役職）クリア率〇%」を保証し、営業は「MQL受領後24時間以内のアプローチ、対応結果のフィードバック」を保証します。

この双方向SLAがないと、責任の押し付け合いが起こります。SLAがあれば、未達は数字で議論できる。曖昧な「印象論」を排除するための装置として機能するのです。

The Model型組織でファネルを回す（SDR/BDR/AE/CSの役割分担）

Salesforce発祥のThe Modelは、SDR（インバウンド対応）、BDR（アウトバウンド開拓）、AE（商談・受注）、CS（活用・継続）の4ロールで分業する組織モデルです。各ロール間にハンドオフ基準と引き継ぎフォーマットを定めます。

中小・スタートアップで4ロールすべてを置くのは過剰。最小構成は「マーケ＋IS（SDR兼BDR）＋AE＋CS」の1名ずつでも回ります。重要なのはロール数ではなく、「ファネルのどこを誰が担うかが明確である」こと。

セールスファネルのKPI設計と各段階の転換率の目安

各段階で追うべきKPIは、認知=サイト訪問数、興味=リード数（CVR）、検討=MQL数、商談=SQL／商談化率、受注=受注率・ACVです。BtoB SaaSの一般的な目安として、訪問→リード化2〜5%、リード→MQL 20〜30%、MQL→SQL 30〜50%、SQL→受注 20〜30%を基準に持つと現状診断が容易になります。

ファネル段階別のKPI一覧（TOFU/MOFU/BOFU）

マーケ・営業のどちらが責任を持つかをセットで決めておくこと。これだけで「数字を誰に聞けばいいか」が明確になります。

BtoB SaaSにおける各段階の転換率ベンチマーク

あくまで一般的な目安ですが、自社診断の出発点として活用できます。

• Webサイト訪問→リード化：2〜5%（コンテンツやLP次第で大きく変動）
• リード→MQL：20〜30%
• MQL→SQL：30〜50%
• SQL→商談実施：50〜70%
• 商談→受注：20〜30%（商材単価・業界による幅あり）

高単価（ACV1,000万円超）の商材ほど受注率は下がり、リードタイムは伸びる傾向があります。自社数値とベンチマークを比較し、最も乖離が大きい段階が優先改善対象です。

CAC・LTV・パイプラインカバレッジで全体を評価する

個別KPIに加え、ファネル全体の健全性は3つの経営指標で評価します。CAC（顧客獲得コスト）、LTV（顧客生涯価値）、そしてLTV/CAC比です。SaaSでは「LTV/CAC≧3」が健全水準とされています。

もう一つ重要なのがパイプラインカバレッジ。目標売上に対し、現在のパイプライン総額が「3倍以上」あることが目安です。1倍しかなければ、まず確実に未達。CMOはこの3指標を経営会議で持つべきです。

セールスファネルの作り方──4ステップで設計する実践フロー

セールスファネルの設計は4ステップで進めます。①ペルソナとカスタマージャーニーの設計、②ファネル各段階の定義とKPI設定、③段階別コンテンツ・施策のマッピング、④CRM/MAでの計測環境構築。最初から完璧を目指さず、最小限のファネルから運用しながら改善するのが成功のコツです。

STEP1：ペルソナとカスタマージャーニーを言語化する

受注顧客の共通属性と購買プロセスを分析し、ペルソナと購買ジャーニーを1枚にまとめます。BtoBで忘れてはならないのが、意思決定関与者が複数いるという事実。経営者、現場担当、情報システム、購買、それぞれの関心事は異なります。

「導入の起案者は誰か」「決裁者は誰か」「現場の抵抗勢力は誰か」。この3者を分けて設計するだけで、コンテンツの精度は飛躍的に上がります。

STEP2：各ファネル段階の定義とKPI・目標数値を決める

年間受注目標から逆算して各段階の必要数を算出します。具体例を見てみましょう。

• 年間受注目標：100件
• SQL→受注率：25% → 必要商談数 400件
• MQL→SQL率：33% → 必要MQL 約1,200件
• リード→MQL率：30% → 必要リード 4,000件
• 訪問→リード率：3% → 必要セッション 約13万

この逆算ができていない組織は、施策のスケール感が合いません。「とにかく記事を増やす」では目標は達成できないのです。

STEP3：段階別の施策・コンテンツをマッピングする

段階を無視して「導入事例を広告で配信」しても刺さりません。顧客の検討度合いとコンテンツの粒度を合わせること。これがファネル設計の肝です。

STEP4：CRM/MAでファネルを可視化・計測する

HubSpot、Salesforce、Marketo、Pardotなどのツールで各段階のデータを統合し、ダッシュボードで可視化します。最低限取得すべきデータは、リードソース・ステータス（MQL/SQL/商談/受注）・商談金額・受注日・失注理由の5項目です。

ツール選びより、データ項目の標準化が先。Excelでもいいので、まずは「全リードが同じ項目で記録されている状態」を作りましょう。

セールスファネルの改善方法──ボトルネック特定と対策

ファネル改善の鉄則は「最も漏れが大きい段階」を特定し、ピンポイントで対策すること。全段階を一度に改善しようとしても効果が薄まります。転換率を業界ベンチマークと比較し、最も乖離が大きい段階から着手する診断フローを持つことが、限られたリソースで成果を出す近道です。

ボトルネック診断の3ステップ（数値で漏れを特定する）

診断手順はシンプルです。まず各段階の転換率を計算（例：MQL→SQL 15%）。次に業界ベンチマーク（30〜50%）と比較。最後に最も乖離が大きい段階を特定し、そこを最優先で改善する。

このとき注意したいのが、「絶対数」ではなく「率」で見ること。リード数が多くてもMQL化率が低ければ、上流でのターゲティングがズレている証拠です。

TOFU（認知・集客）の改善施策

訪問→リード化率が低い場合の対策です。SEOキーワードがターゲット外（情報収集層ばかり）ではないか、広告ターゲティングが広すぎないか、LPのファーストビューが訴求と合っているか、フォーム項目が多すぎないか。順に点検していきます。

特にBtoBのフォーム項目数は要注意。10項目を超えると離脱率が跳ね上がります。必要最小限まで削れないか、再検討する価値があるでしょう。

MOFU（リード育成）の改善施策

MQL化率が低い場合は、リードナーチャリングの仕組みを見直します。獲得直後のサンクスメール、3日後の関連資料、1週間後の事例紹介、というように、時系列でコンテンツを当てるシナリオを組みましょう。

リードスコアリングを導入し、行動（資料DL2回以上＋料金ページ閲覧など）で「ホット」と判定されたリードを自動で営業に渡す仕組みも有効です。手動運用では必ず取りこぼしが発生します。

BOFU（商談・受注）の改善施策

商談化率・受注率が低いときは、営業側のオペレーションに踏み込みます。具体的には、トークスクリプトの統一、ヒアリング項目の標準化、導入事例の業界別整備、提案書テンプレートの作成、失注理由の分類と改善ループの構築。

失注分析は特に軽視されがちですが、宝の山。「なぜ負けたか」を月次で営業会議の議題にするだけで、提案精度は確実に上がっていきます。

まとめ：セールスファネルは『営業×マーケの共通言語』として設計する

本記事の要点を整理します。

• セールスファネルは見込み客の行動プロセスを段階的に可視化した漏斗状のモデル
• BtoBにおける最大のボトルネックは、マーケと営業の接続点（MQL→SQL）
• MQL/SQLの定義合意とSLA設定で、両部門の分断を解消する
• KPIは段階別（転換率）と全体（CAC・LTV・パイプラインカバレッジ）の両軸で評価
• 改善は「最も漏れが大きい段階」をベンチマーク比較で特定し、ピンポイントで対策
• ファネルは現場の戦術ではなく、CMO・経営が握るべきアジェンダ

次のアクションとして、まず自社ファネルの現状数値を出してみてください。各段階の転換率をベンチマークと比較すれば、優先改善箇所が即座に見えてきます。並行して、営業・マーケのリーダーで「自社のSQL定義」を作るワークショップを開くこと。この2つだけで、半年後の景色は大きく変わります。

walkandでは、BtoB企業の営業×マーケ接続の設計支援、ファネル可視化、コンテンツ戦略の実行までを一気通貫でサポートしています。「ファネルを作りたいが、社内に推進役がいない」「マーケと営業の橋渡しに困っている」というCMO・マーケ責任者の方は、ぜひお気軽にご相談ください。

よくある質問

セールスファネルとセールスパイプラインの違いは？

ファネルは「見込み客全体の流れを可視化する概念モデル」、パイプラインは「個別の商談案件の進捗を管理するリスト」です。ファネルが設計図、パイプラインが工程表というイメージで捉えると分かりやすいでしょう。

BtoCでもセールスファネルは使えますか？

使えますが、BtoCは購買検討期間が短く、AIDAやAISASなどの心理モデルの方が一般的です。ECやサブスクなど検討期間が長い商材ではBtoB同様のファネル設計が有効になります。

ファネル設計に最適なツールは？

マーケ寄りならHubSpotやMarketo、Pardot、営業寄りならSalesforceが代表的です。中小・スタートアップは統合型のHubSpotが導入しやすく、大企業はSalesforce＋Marketoの組み合わせが定番となっています。

小規模スタートアップでもファネル設計は必要ですか？

必要です。むしろ初期から設計すべきです。リード数が少ない段階で各段階のデータを取り始めれば、スケール時にすぐ改善判断ができます。後から導入するとデータの蓄積に半年〜1年かかってしまいます。

ファネルの各段階に最適なコンテンツは？

TOFUはSEO記事や業界レポート、MOFUはホワイトペーパーやウェビナー、BOFUは導入事例やデモ動画が基本です。検討度合いが上がるほど、自社製品の具体性が高いコンテンツが有効になります。

ファネル分析の頻度はどのくらい？

月次レビューが基本で、週次は異常検知の目的で軽くチェックします。四半期ごとに転換率のトレンドを見て、施策の方向性を見直すサイクルが運用しやすいでしょう。

ABM（アカウントベースドマーケティング）とファネルの関係は？

ABMはファネル上部を「狙うべき特定アカウント」に絞り込むアプローチです。広く集めて絞るのではなく、最初から受注確度の高い企業群にリソースを集中させる戦略であり、ファネル思考と矛盾しません。

ファネルが機能しない最大の原因は？

営業とマーケでMQL/SQLの定義やKPIが揃っていないことです。ツールを入れる前に、両部門のリーダーが「同じ言葉で同じ数字を語れる」状態を作ることが、ファネル機能化の前提条件になります。