%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}
この記事の結論
マーケティングファネルは、TOFU・MOFU・BOFUの段階ごとに「量」と「転換率」を追い、見込み顧客がどこで止まっているかを特定するための設計図です。
マーケティングファネルは、TOFU・MOFU・BOFUの段階ごとに「量」と「転換率」を追い、見込み顧客がどこで止まっているかを特定するための設計図です。
「リードは獲得できているのに商談につながらない」「どの段階で見込み顧客が離脱しているのかわからない」「マーケと営業で見ている数字が合わない」——こうした悩みの多くは、購買プロセスを段階として定義し、同じ物差しで数えていないことから生まれます。
マーケティングファネルとは、見込み顧客が「認知→興味→比較→検討→購入」へと進む購買プロセスを逆三角形（漏斗）の形で可視化したモデルです。BtoBでは購買サイクルが長く、関与者が複数いるため、BtoC以上にファネル設計の重要性が高まります。
本記事では、マーケティングファネルの基本概念からBtoB特有のファネル構造、各段階で実施すべき施策とKPI、ボトルネックを見つける分析方法、さらにHubSpotのライフサイクルステージとの対応まで解説します。
本記事は「BtoBマーケティングとは？BtoCとの違い・基本施策・始め方を完全解説」シリーズの一部です。
この記事でわかること
マーケティングファネルを理解し、リード獲得から商談化までのボトルネックを解消したいBtoBマーケティング担当者の方に向けた内容です。段階の定義、施策、分析、HubSpotでの管理までを順に解説します。
- ファネルの基本概念と3つの段階 — TOFU/MOFU/BOFUの違いと、購入後まで含めて考えるフライホイールの考え方を整理します。
- BtoB特有のファネル構造 — 検討期間の長さや関与者の多さが、段階の分け方や部門の役割分担にどう影響するかを解説します。
- 各段階の施策とコンテンツ — 段階ごとの施策・コンテンツ例・KPIを表で比較し、どこから手を付けるかの判断軸を示します。
- ファネル分析とボトルネックの特定法 — 「量」と「転換率」の追い方と、ボトルネック別の改善アプローチを紹介します。
- HubSpotのライフサイクルステージでの管理と設計ステップ — ファネルの段階をHubSpot上の仕組みに落とし込み、運用し続けるための手順を解説します。
マーケティングファネルの基本概念
ファネルは、見込み顧客の状態を段階に分けて数えるための共通言語です。まず定義と3段階の区分を押さえ、そのうえで購入後まで含めて考えるフライホイールの考え方を整理します。段階の呼び方を社内でそろえておくことが、後の分析や施策設計の土台になります。
ファネルとは
マーケティングファネル（Marketing Funnel）は、見込み顧客が認知から購入に至るまでの購買プロセスを段階的に表したモデルです。「ファネル（Funnel）」は日本語で「漏斗」を意味し、上部が広く下部が狭い逆三角形の形をしています。
これは、最初に多くの見込み顧客がファネルの上部に入り、各段階を経るごとに人数が絞られていく（離脱する）様子を表しています。ファネルを使う価値は、「全体として成果が出ていない」という漠然とした状態を、「どの段階からどの段階への移行で人数が減っているのか」という具体的な問いに分解できる点にあります。
ファネルの上部で見込み顧客を集め、育てていく具体的な実践方法はデマンドジェネレーションとは？BtoBで成果を出す3つのプロセスと実践法で詳しく解説しています。
ファネルの3段階（TOFU/MOFU/BOFU）
ファネルは大きく3つの段階に分けて考えるのが基本です。
| 段階 | 名称 | 顧客の状態 | 目的 |
|---|---|---|---|
| TOFU | Top of Funnel（認知段階） | 課題に気づき始めた段階。まだ具体的な解決策を探していない | 認知を獲得し、興味を喚起する |
| MOFU | Middle of Funnel（検討段階） | 解決策を調査・比較している段階。複数のベンダーを検討中 | 自社を選択肢に入れ、信頼を構築する |
| BOFU | Bottom of Funnel（決定段階） | 具体的なベンダーを絞り込み、導入を検討している段階 | 購入決定を後押しし、受注する |
見込み顧客がどの段階にいるかを判断するときは、「課題を自覚しているか」「解決策を比較しているか」「特定のベンダーと導入条件を詰めているか」の3点で見ると区分しやすくなります。課題の自覚がまだ弱ければTOFU、比較している最中ならMOFU、導入時期や体制の話に入っていればBOFUとして扱い、その区分を顧客情報の項目として記録しておくと、後のファネル分析で段階別に数えられるようになります。
従来型ファネルの限界とフライホイール
従来型のファネルは「認知→購入」の一方向モデルです。一方で、購入後の顧客体験が新たな認知を生む「フライホイール」モデルという考え方もあります。フライホイールの循環は、次の順番で表せます。
| 段階 | 次に向かう段階 |
|---|---|
| 顧客の成功 | 認知・集客 |
| 認知・集客 | 検討・商談・受注 |
| 検討・商談・受注 | 維持・拡大 |
| 維持・拡大 | 顧客の成功 |
フライホイールモデルでは、顧客の成功（カスタマーサクセス）が口コミや紹介を生み、新たな見込み顧客の獲得につながるという好循環を重視します。
自社のファネルの終点をどこに置くかは、紹介や継続取引が新規獲得にどれだけ影響しているかで決めるとよいと考えています。紹介経由の商談や既存顧客からの追加受注が目立つ事業であれば、Customer以降（Evangelist）まで段階として定義し、紹介元を記録する項目を用意します。そうでなければ、まずは受注までのファネルを整えることを優先し、購入後の段階は後から足しても間に合います。
BtoB特有のファネル構造
BtoBのファネルは、BtoCのファネルをそのまま当てはめるとうまく回りません。検討期間が長く、関与者が多く、段階の行き来も起こるためです。ここでは特徴を比較したうえで、BtoBで使われる詳細なステータス区分と、スプレッドシート管理でファネルが崩れやすい理由を整理します。
BtoBファネルの特徴
BtoBとBtoCの違いの全体像についてはBtoBマーケティングとは？BtoCとの違い・基本施策・始め方を完全解説が参考になります。BtoBのファネルはBtoCと比較して以下の特徴があります。
| 特徴 | BtoB | BtoC |
|---|---|---|
| ファネルの長さ | 長い（検討が長期化するケースがあります） | 短い（その場で決まるケースもあります） |
| 関与者 | 複数人（部門・役職をまたぐケースがあります） | 個人 |
| 各段階の滞留時間 | 長い | 短い |
| ファネル内の行き来 | 頻繁（比較→認知に戻るなど） | ほぼ一方向 |
| MOFU（中間段階）の重要性 | 非常に高い | 比較的低い |
この表から読み取れるのは、BtoBでは「一度進んだ段階から戻ってくる見込み顧客」を前提に管理する必要があるという点です。例えば、比較検討まで進んだものの予算時期が合わずに保留になった見込み顧客を、受注か失注かの二択で処理してしまうと、次の検討タイミングで声をかけるきっかけを失います。行き来を前提に、段階を戻すときのルールまで決めておくことがBtoBのファネル設計の特徴です。
BtoBの詳細ファネル
BtoBでは3段階のファネルをさらに細分化して管理することが効果的です。
| 段階 | リードステータス | 定義 | 責任部門 |
|---|---|---|---|
| TOFU | Subscriber | メルマガ登録者 | マーケティング |
| TOFU | Lead | 資料DLやフォーム送信した見込み客 | マーケティング |
| MOFU | MQL（Marketing Qualified Lead） | マーケティングが「質が高い」と判断したリード | マーケティング |
| MOFU | SQL（Sales Qualified Lead） | 営業が「商談の可能性がある」と判断したリード | インサイドセールス |
| BOFU | Opportunity | 商談中の見込み客 | フィールドセールス |
| BOFU | Customer | 受注した顧客 | カスタマーサクセス |
| — | Evangelist | 自社を推薦してくれる推進者 | カスタマーサクセス |
この表で特に意味を持つのは「責任部門」の列です。責任部門が切り替わる地点（MQL→SQL、SQL→Opportunityなど）は、引き継ぎ漏れや対応の遅れが起きやすい場所でもあります。
MQLとSQLを分けるかどうかは、マーケティングから営業へ引き渡す間に、商談化の可否を判断する役割（インサイドセールスなど）がいるかどうかで判断できます。その役割がいる体制ならMQLとSQLを分けて管理し、マーケティング担当が直接営業に渡す体制なら、まずはMQLを引き渡し地点として一本化し、営業側の判断基準が固まってからSQLを追加する進め方もあります。
スプレッドシート管理でファネルが崩れる理由
ファネルを設計しても、日々の管理をスプレッドシートで続けていると数字が崩れやすくなります。展示会のリストはマーケティングのシート、商談は営業のシート、契約は管理部門のシートといった形で情報が分かれると、同じ会社やコンタクトが複数のシートに別々の状態で記録され、差分が生まれます。段階が変わった日付も手で書き換えるため、「いつMQLになり、いつ商談化したか」が残らず、転換率を後から計算できないケースがあります。
| 項目 | スプレッドシート管理 | CRMでの一元管理 |
|---|---|---|
| リード情報の所在 | 部門ごとのシートに分散する | コンタクト・会社・取引が紐づいた1つのデータベースにまとまる |
| 段階の更新 | 担当者が手作業で書き換える | フォーム送信やスコアなどの条件で自動更新できる |
| 転換率の算出 | 集計のたびにシートを突き合わせる | レポートで段階別の数を継続的に見られる |
| 部門間の共有 | シートの最新版を探して共有する | 同じ画面で過去のやり取りまで確認できる |
ファネルを継続的に改善したいなら、段階の更新を人の手作業に頼らず、仕組みとして自動で記録される状態を作ることをおすすめします。
各段階の施策とコンテンツ
ファネルの段階が定義できたら、段階ごとに顧客が求めている情報に合わせて施策とコンテンツを配置します。同じホワイトペーパーやウェビナーでも、TOFU向けとMOFU向けではテーマと測るKPIが変わります。ここでは段階別に施策を比較し、最後にどこから施策を増やすかの判断方法を示します。
TOFU（認知段階）の施策
TOFUで獲得したリードを次の段階へ育てる設計は、リードナーチャリングの設計と実践で詳しく解説しています。
目的： ターゲット顧客に自社を認知してもらい、最初の接点を作る
| 施策 | コンテンツ例 | KPI |
|---|---|---|
| SEO/ブログ | 課題解決型の記事、業界トレンド解説 | オーガニック流入数、セッション数 |
| SNS | 業界インサイト、ノウハウ投稿 | インプレッション、フォロワー増加数 |
| Web広告 | ディスプレイ広告、動画広告 | リーチ数、CTR |
| PR | プレスリリース、メディア露出 | 掲載数、被リンク数 |
| ウェビナー | 業界課題テーマのウェビナー | 参加者数、新規リード数 |
TOFUで重要なポイント：
- この段階では売り込まず、顧客の課題や疑問に答えるコンテンツを提供します。
- 広くリーチすることが目的ですが、ターゲット外の流入を増やしても成果にはつながりません。
- 顧客が自分の課題を言葉にできるよう支援する「課題の言語化」型のコンテンツが効果を出しやすい傾向があります。
MOFU（検討段階）の施策
目的： 見込み顧客との関係を深め、自社を「有力な選択肢」として認識してもらう
| 施策 | コンテンツ例 | KPI |
|---|---|---|
| ホワイトペーパー | 導入ガイド、比較レポート、チェックリスト | DL数、MQL転換率 |
| メールナーチャリング | セグメント別の教育コンテンツ | 開封率、クリック率 |
| 導入事例 | 業界別・課題別の成功事例 | 閲覧数、商談化への寄与 |
| 比較コンテンツ | 製品比較表、選び方ガイド | ページ滞在時間、CVR |
| ウェビナー | 製品活用法、顧客事例共有 | 参加者のMQL化率 |
MOFUで重要なポイント：
- BtoBではMOFUが長くなりやすく、ここでの離脱がボトルネックになりやすい段階です。
- リードスコアリングを活用し、「今すぐ客」と「まだまだ客」を区別します。
- 複数の意思決定者それぞれに対応したコンテンツを用意します。
MOFUのメールナーチャリングは、ステップメールを送る間隔の設計が成果を左右します。
BOFU（決定段階）の施策
目的： 購入決定を後押しし、受注につなげる
| 施策 | コンテンツ例 | KPI |
|---|---|---|
| 個別デモ/トライアル | 製品デモ、無料トライアル | デモ実施数、トライアル開始数 |
| ROI試算 | 投資対効果のシミュレーション | 提案書送付数 |
| 稟議支援 | 稟議用比較資料、導入効果レポート | 稟議通過率 |
| 個別提案 | カスタマイズされた提案書 | 受注数、受注率 |
| 導入計画 | 導入スケジュール、サポート体制の説明 | 受注金額 |
BOFUで重要なポイント：
- この段階では「比較」ではなく「安心」が重要です。導入後のイメージを具体的に示します。
- 稟議を通すための材料（ROI、他社事例、リスク対策）を網羅的に提供します。
- 営業とマーケティングの密な連携が受注率を大きく左右します。
どの段階から施策を増やすかの判断
3つの表の施策をすべて同時に始める必要はありません。施策を増やす段階は、次の順で決めることをおすすめします。
- 直近の一定期間について、段階別のリード数を並べます。
- 隣り合う段階の転換率を出し、前の期間と比べて下がっている段階、または他の段階より極端に低い段階を探します。
- その段階の表から施策を1つ選び、対応するKPIを決めてから実施します。
例えば、リードは増えているのにMQL化が進んでいないなら、TOFUの施策を足すよりもMOFUのホワイトペーパーやメールナーチャリングを整えるほうが効果的です。逆に、MQL以降の転換は安定していてリード数そのものが少ないなら、TOFUの施策を優先します。施策の追加先を「転換率が落ちている段階」に絞ることで、限られたリソースを分散させずに済みます。
ファネル分析の方法
ファネル分析は、段階ごとの「量」と「転換率」を継続的に追い、改善すべき段階を決めるための作業です。数字を集めること自体が目的にならないよう、指標の定義、ボトルネックの読み方、時系列での比較方法をセットで決めておきます。
ファネルの数値管理
ファネル分析では、各段階の「量」と「転換率」を追跡します。
| 指標 | 計算方法 | ベンチマーク目安 |
|---|---|---|
| 訪問→リード転換率 | リード数 ÷ 訪問者数 | 自社の過去実績から設定 |
| リード→MQL転換率 | MQL数 ÷ リード数 | 自社の過去実績から設定 |
| MQL→SQL転換率 | SQL数 ÷ MQL数 | 自社の過去実績から設定 |
| SQL→商談転換率 | 商談数 ÷ SQL数 | 自社の過去実績から設定 |
| 商談→受注率 | 受注数 ÷ 商談数 | 自社の過去実績から設定 |
転換率の目安は、商材の単価や検討期間、リードの獲得経路によって大きく変わります。他社の一般的な数値と比べるよりも、自社の過去の数値を基準にし、前の期間より上がったか下がったかで判断するほうが改善の打ち手を決めやすいと考えています。
計算するときは、「どの時点で何を1件と数えるか」を先に決めておきます。例えば、同じコンタクトが資料を2回ダウンロードしたときにリードを1件と数えるのか2件と数えるのかが部門ごとに違うと、転換率の比較が成り立ちません。数え方を決めたら、その定義をレポートの説明欄や社内の資料に書き残しておくと、担当者が替わっても同じ基準で数え続けられます。
ボトルネックの特定
ファネル分析で中心になるのは「ボトルネック（最も転換率が低い段階）」を特定することです。
ボトルネック別の改善アプローチ：
| ボトルネック | 考えられる原因 | 改善施策 |
|---|---|---|
| 訪問→リードが低い | CTAが弱い、コンテンツとのミスマッチ | CTA改善、LP最適化、フォーム簡略化 |
| リード→MQLが低い | ターゲット外のリードが多い | ターゲティング精度の向上、コンテンツ見直し |
| MQL→SQLが低い | ナーチャリング不足、スコアリング精度 | ナーチャリングシナリオ改善、スコアリング見直し |
| SQL→商談が低い | インサイドセールスの対応品質 | トークスクリプト改善、対応速度の向上 |
| 商談→受注が低い | 提案力不足、競合に負ける | 提案資料改善、差別化ポイントの明確化 |
表の「考えられる原因」は複数あるため、改善施策を選ぶ前に原因を絞り込みます。例えばMQL→SQLが低い場合、営業がSQLにしなかったリードの理由を見て、「まだ検討段階ではなかった」が多ければナーチャリングシナリオを、「ターゲットとずれていた」が多ければスコアリングの条件を見直す、というように判断が分かれます。営業が却下理由を選択肢から選べる項目を用意しておくと、この切り分けがしやすくなります。
商談→受注の段階を詳しく見るときは、取引をクローズ日別に集計すると月ごとの動きを追いやすくなります。次の画面は、HubSpotのレポートで取引をクローズ日別に集計し、色分けしたテーブルの例です。
コホート分析
リードの獲得時期（コホート）ごとに、各段階への移行状況を追跡することで、施策の効果を時系列で評価できます。以下は、獲得月ごとに数値を記入していくための型です。
| コホート | リード数 | MQL化率 | 商談化率 | 受注率 | LTV |
|---|---|---|---|---|---|
| 獲得月1 | 実数を記入 | 実数を記入 | 実数を記入 | 実数を記入 | 実数を記入 |
| 獲得月2 | 実数を記入 | 実数を記入 | 実数を記入 | 実数を記入 | 実数を記入 |
| 獲得月3 | 実数を記入 | 実数を記入 | 実数を記入 | 実数を記入 | 実数を記入 |
BtoBでは検討期間が長いため、ある月に獲得したリードが受注に至るまで数か月かかることもあります。月ごとの全体の受注数だけを見ていると、施策を変えた効果が表れる前に「効果がない」と判断してしまいがちです。コホートで見れば、施策を変えた月に獲得したリードの商談化率が、それ以前の月と比べて上がっているかを比較できます。新しい施策を始めた月をコホート表に書き添えておくと、どの変更が数字に効いたのかを後から振り返りやすくなります。
HubSpotのライフサイクルステージとの対応
ファネルの段階は、HubSpotでは「ライフサイクルステージ」として管理できます。ここでは段階との対応関係を整理し、自動化やレポートでファネル管理をどう回すか、失注した見込み顧客をどうファネルに戻すかを解説します。
ファネル段階とライフサイクルステージの対応表
HubSpotではファネルの各段階を「ライフサイクルステージ」として管理できます。
| ファネル段階 | HubSpotライフサイクルステージ | 説明 |
|---|---|---|
| TOFU | Subscriber | ブログ購読者、メルマガ登録者 |
| TOFU | Lead | フォーム送信、資料DL |
| MOFU | Marketing Qualified Lead | マーケが認定した有望リード |
| MOFU | Sales Qualified Lead | 営業が認定した商談候補 |
| BOFU | Opportunity | 商談進行中 |
| BOFU→Post | Customer | 受注・契約済み |
| Post | Evangelist | 推薦者・紹介者 |
（出典：Use lifecycle stages）
標準のステージ名をそのまま使うか、自社の言葉に置き換えるかは、営業とマーケティングがその名前を見て同じ状態を思い浮かべられるかで判断するとよいと考えています。BtoBとBtoCでは顧客の進み方が違うため、標準の段階が自社の購買プロセスに合わない部分は、カスタマージャーニーを書き出したうえで定義を決めることをおすすめします。
HubSpotでのファネル管理の実践
HubSpotのCRM/MAを活用すると、以下のファネル管理が自動化できます。
- リードスコアリング：行動（ページ閲覧、メール開封、資料DL）に応じて自動でスコアリングします。
- ステージ自動移行：スコアが閾値を超えたらMQLに自動遷移させます。
- ワークフロー：ステージ変更をトリガーにしたメール自動配信や営業アラートを設定します。
- ファネルレポート：ステージ別の数量と転換率をダッシュボードで可視化します。
これらは個別の機能として見るより、コンタクト→取引→顧客→請求という一連の流れのどこを担っているかで捉えると設計しやすくなります。リードスコアリングとステージ自動移行はコンタクトの段階を進める役割、ワークフローは段階が変わった瞬間に次の担当者を動かす役割、ファネルレポートは流れ全体のどこで止まっているかを示す役割です。Opportunity以降は取引（商談）のパイプラインに引き継がれ、受注後の契約・請求の情報まで同じCRM上でつながっていると、マーケティング施策が最終的な売上にどう結びついたかまで追えるようになります。
Marketing Hubの機能全体と導入時の注意点は「HubSpotのMA（Marketing Hub）とは？機能一覧と、実務での活用・導入での注意点を徹底解説！」で解説しています。
失注をナーチャリングに戻すループ
BtoBのファネルでは、失注した見込み顧客を「終わった案件」として放置しないことが成果につながると考えています。失注の理由が「時期」や「社内決裁」であれば、検討が再開する可能性が残っているためです。
失注した見込み顧客の扱いは、失注理由で分けて決めることをおすすめします。
| 失注理由のカテゴリ | 判断 | 次の行動 |
|---|---|---|
| 時期・社内決裁 | 検討再開の可能性あり | ナーチャリングに戻し、検討時期に合わせて情報提供を再開する |
| 価格・競合他社 | 条件次第で再検討の可能性あり | 失注理由を記録し、提案内容や差別化の見直しに活かす |
| 製品機能 | 現時点では要件を満たせない | 不足していた機能をマーケティングや製品側に共有する |
HubSpotでこのループを作るときは、取引が失注になったことをきっかけに、関連するコンタクトのライフサイクルステージをいったんクリアし、ナーチャリング用の段階に設定し直すワークフローを組む形になります。失注理由を選択式の項目で入力してもらえば、理由ごとの件数を円グラフなどで集計でき、営業とマーケティングの間で「どこで負けているか」を共有しやすくなります。
コンタクト単位と会社単位の両方で見る
BtoBでは、1つの会社から複数の担当者がリードとして入ってくることがよくあります。コンタクト単位だけでファネルを見ていると、リード数は多いのに会社数で見ると意外と少ない、という状態に気づけません。
コンタクト単位と会社単位のどちらでファネルを見るかは、施策の目的で使い分けるとよいと考えています。メールやコンテンツの反応を改善したいならコンタクト単位、営業がアプローチすべき企業の数や商談化の状況を把握したいなら会社単位で見ます。会社のライフサイクルステージは、紐づくコンタクトのうち最も先の段階に合わせるといったルールを決めておくと、両方の数字を矛盾なく扱えます。
ファネル設計の実践ステップ
ここまでの内容を、実際にファネルを設計するときの手順に落とし込みます。いきなりすべてを整えようとせず、各ステップで次へ進む条件を満たしてから先に進むと、途中で設計が崩れにくくなります。
| ステップ | 内容 | 次へ進む条件 |
|---|---|---|
| 1 | 現状のファネルを可視化する | 各段階の人数と転換率を一度出せている |
| 2 | 各段階の定義を明確にする | MQL・SQLの定義をマーケと営業が合意している |
| 3 | 各段階の施策とコンテンツを設計する | ボトルネックの段階に優先施策が決まっている |
| 4 | KPIを設定し、測定の仕組みを整える | ダッシュボードで数値を継続的に見られる |
| 5 | PDCAを回す | 定例のレビューで改善策を決めている |
ステップ1〜2：現状のファネルを可視化し、段階を定義する
まず、現在のマーケティング・営業プロセスを「ファネル」として書き出します。各段階の人数（量）と転換率を把握します。この時点ではデータが不完全でも構いません。スプレッドシートや営業担当者の記憶から概算でも出してみると、どの段階のデータが取れていないかが見えてきます。
次に、各段階の定義を決めます。MQLとSQLの定義は特に重要で、マーケティングと営業で共通認識を持つことが不可欠です。
MQLの定義例：
- ターゲット企業の従業員規模・業界に該当する
- ホワイトペーパーDLに加えて、複数回のサイト訪問がある
- スコアが自社で定めたしきい値を超えている
SQLの定義例：
- 予算が確保されている（または確保見込み）
- 導入時期が自社で定めた検討期間内に収まっている
- 意思決定者とのコンタクトが取れている
定義は、営業のマネージャーや成果を出している担当者が普段どこで「これは商談になる」と判断しているかを聞き取り、その判断基準を言葉にする形で作ると現場で使われやすくなります。
ステップ3〜4：施策を設計し、測定の仕組みを整える
ファネルの各段階に対して、必要な施策とコンテンツを洗い出し、優先順位をつけます。前述の「どの段階から施策を増やすかの判断」に沿って、ボトルネックになっている段階の施策から着手します。
続いて、ゴールから逆算して各段階のKPIを設定し、ダッシュボードで可視化します。例えば受注目標から逆算して「必要な商談数」「必要なSQL数」を出しておけば、月の途中でも目標に対する進み具合を判断できます。KPIは最初から細かく設定せず、受注件数や商談数のように数えやすいものから始めるのがおすすめです。
ステップ5：PDCAを回す
月次でファネルの数値をレビューし、ボトルネックの特定と改善を繰り返します。レビューでは、転換率が前月から下がった段階を1つ選び、原因の仮説と次月に試す施策を決めて記録します。翌月のレビューでその施策の結果を見て、効果があれば継続、なければ別の仮説に切り替えます。決めた施策と結果を同じ資料に残し続けると、担当者が替わっても過去の判断の経緯をたどれます。
ファネル運用を人に依存させないための考え方
ファネルは設計して終わりではなく、日々のデータが正しく入り続けて初めて機能します。担当者の頑張りに頼る運用は、異動や退職で崩れやすくなります。ここでは、小さく始めて広げる順番、定義と入力の仕組み化、AIとの役割分担、そしてファネルモデルの限界について整理します。
スモールスタートで始める順番
ファネル管理を一度に整えようとすると、項目設計やワークフローの作り込みに時間がかかり、運用が始まる前に止まってしまいがちです。まずは「Lead→MQL→商談→受注」のように段階を絞り、段階の人数と転換率が毎月出せる状態を作ることから始めることをおすすめします。
数か月運用して数字が安定してきたら、ボトルネックになっている段階だけを細分化します。例えばMQL→商談の間で多く止まっているなら、その間にSQLを追加して営業側の判断を分けて見る、といった具合です。必要になった段階だけを足していくと、使われない段階や項目が増えずに済みます。
定義と入力ルールを仕組みにする
「SFAにちゃんと入力してほしい」と呼びかけるだけでは、入力の質はそろいません。人ではなく仕組みで解決するために、次のような設定をおすすめします。
- 取引ステージを移動するときに入力必須の項目を決め、未入力では次に進めないようにします。
- 失注時には失注理由を選択式で必須入力にし、自由記述だけに頼らないようにします。
- プロパティ（項目）の作成・変更は管理者のみに限定し、似た項目が乱立しないようにします。
- MQL・SQLの定義や各段階の意味を社内資料にまとめ、新しく入ったメンバーが最初に読む資料に含めます。
入力必須の項目は、新人が「この段階で顧客に何を確認すべきか」を学ぶ手がかりにもなります。項目は少ないほうが入力に集中できるため、レポートで使う項目と営業プロセス上で知っておく必要がある項目に絞って設計します。
AIに任せる作業と人が決める作業
ファネル運用では、AIに任せる作業と人が決める作業を分けておくと、安心して活用できます。
| AIに任せやすい作業 | 人が判断する作業 |
|---|---|
| 問い合わせ内容の分類（営業目的かどうかなど） | MQL・SQLの定義 |
| レコードやメールのやり取りの要約 | ライフサイクルステージの設計 |
| 企業情報のウェブリサーチ | 最終的なメール送信の判断 |
| パーソナライズしたメールの下書き | 大型案件へのアプローチ方針 |
次の画面は、Breezeが生成した商談動向レポートの例です。
AIが作った下書きやレポートは、叩き台として使い、人が確認してから送信や意思決定に使う形をおすすめします。特に金額の大きい商談につながりそうな見込み顧客へのメールは、AIのリサーチ結果を参考にしつつ、文面は担当者が書くほうがよいと考えています。
ファネルモデルの限界
ファネルは便利なモデルですが、すべてを説明できるわけではありません。BtoBでは複数の関与者がそれぞれ違う段階にいることがあり、1本のファネルでは会社全体の検討状況を表しきれないケースがあります。また、月あたりのリード数が少ない事業では、数件の増減で転換率が大きく揺れるため、単月の転換率だけで施策の良し悪しを判断すると誤りやすくなります。
こうした場合は、転換率を四半期など長めの期間でまとめて見る、会社単位のステージを併用する、商談の中身は営業の定性的な報告と合わせて読む、といった方法で補うことをおすすめします。ファネルの数字は「どこを見に行くべきか」を教えてくれるものと捉え、原因の判断は現場の情報と組み合わせて行います。
よくある質問
Q1. マーケティングファネルとは何ですか？
マーケティングファネル（Marketing Funnel）は、見込み顧客が認知から購入に至るまでの購買プロセスを段階的に表したモデルです。「ファネル（Funnel）」は日本語で「漏斗」を意味し、上部が広く下部が狭い逆三角形の形をしています。
Q2. ファネル分析の方法で押さえるべきポイントは何ですか？
ファネル分析では、各段階の「量」と「転換率」を追跡します。中心になるのは「ボトルネック（最も転換率が低い段階）」を特定することです。転換率は他社の数値よりも自社の過去実績と比べ、下がった段階から原因を絞り込むと改善策を決めやすくなります。
Q3. マーケティングファネルはどのような手順で設計しますか？
まず、現在のマーケティング・営業プロセスを「ファネル」として書き出し、各段階の人数（量）と転換率を把握します。次にMQLとSQLの定義をマーケティングと営業で合意し、ボトルネックの段階から施策を設計します。そのうえでKPIをダッシュボードで可視化し、月次のレビューで改善を繰り返します。
Q4. BtoB特有のファネル構造で押さえるべきポイントは何ですか？
BtoBのファネルはBtoCと比較して、検討期間が長く、関与者が複数いて、段階の行き来が頻繁に起こるという特徴があります。そのため、3段階のファネルをさらに細分化し、段階ごとの責任部門と引き継ぎのルールを決めておくことが効果的です。失注した見込み顧客をナーチャリングに戻すループも設計しておくと、次の検討タイミングを逃しにくくなります。
Q5. HubSpotのライフサイクルステージは後から戻せますか？
ワークフローなどの自動処理では、ライフサイクルステージは基本的に先の段階へ進む方向に更新されます。前の段階に戻したい場合は、既存の値をいったんクリアしてから設定し直す形になります。失注した見込み顧客をナーチャリングに戻すときは、この2段階の処理をワークフローに組み込むのがおすすめです。
まとめ
- マーケティングファネルは、BtoBマーケティングの成果を体系的に管理・改善するための基本的なフレームワークです。
- ファネルを正しく設計・運用することで、「どこに問題があるか」「何を優先して改善すべきか」が明確になります。
- TOFU/MOFU/BOFUの3段階を理解し、各段階に適した施策を設計します。
- MQLとSQLの定義を明確にし、マーケと営業で共有します。
- 転換率を定期的に計測し、ボトルネックを特定・改善します。
- ファネルだけでなく、購入後のフライホイール（顧客成功→紹介）や、失注からナーチャリングに戻すループも設計します。
- 定義や入力ルールを仕組みにし、担当者が替わっても回る運用にします。
まずは、現在のリードが各段階に何件いるかを書き出すことから始めてみてください。そのうえで、次の3ステップで進めることをおすすめします。
- 「Lead→MQL→商談→受注」の4段階に絞って、直近の人数と転換率を出します。
- 転換率が低い段階を1つ選び、その段階の施策表から最初に試す施策を決めます。
- MQLの定義を営業と話し合って言葉にし、HubSpotのライフサイクルステージに反映します。
デマンドジェネレーションの全体像について詳しく知りたい方は、デマンドジェネレーションとは？BtoBで成果を出す3つのプロセスと実践法もあわせてご覧ください。このテーマに関連する記事はBtoBマーケティング基礎カテゴリで網羅的にまとめています。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
