BtoBファネルとは？購買グループ・稟議・営業連携を管理する設計手順
BtoBの検討は、資料をダウンロードした一人だけで完結しません。同じ会社の利用部門が製品を調べ、情報システム部門が要件を確認し、決裁者が投資判断をする一方で、稟議やセキュリティ審査が並行することがあります。個人の行動を上から下へ並べるだけでは、誰の合意が足りず、案件がどこで止まっているかを説明できません。
結論：BtoBファネルとは、個人のクリック数ではなく、アカウント×購買テーマ・案件×購買関与者×合意ゲートで検討の進み具合を管理する運用モデルです。各段階に観測できる退出条件、必要な関与者、担当者、次の処理を置き、条件がそろったときだけ営業や次工程へ渡します。一般的なマーケティングファネルを、複数関与者と社内承認があるBtoB向けに実装し直したものと考えると整理しやすくなります。
本記事のポイント
- BtoBファネルは、個人ではなくアカウント×購買テーマ・案件を単位にし、関与者と合意条件を関連付けて管理します。
- 段階名だけを置かず、観測できる証拠、必要な関与者、退出条件、次の担当を定義すると、稟議や審査による停滞を特定できます。
- MQLやSQLは社内の受け渡し状態、顧客側の購買状態は別に保持し、営業の受け入れ・差し戻し理由から条件を更新します。
BtoBファネルは「アカウント×購買テーマ・案件」で管理する
BtoBファネルの最小単位は、会社だけでも個人だけでもありません。同じ会社が複数の製品や課題を同時に検討することがあるため、原則は「どのアカウントが、何の購買テーマ・案件を、誰と検討しているか」を一組として持ちます。
例えば、同じ企業が営業支援システムと生成AI研修を検討していても、予算、利用部門、決裁者、導入時期は別です。会社単位にすべての行動を合算すると、別案件の反応が混ざり、実際より検討が進んでいるように見えます。反対に個人単位だけで見ると、同じ案件へ関わる複数人の動きを一つにまとめられません。
| 管理対象 | 答える問い | 保持する情報の例 | 混同すると起きること |
|---|---|---|---|
| 個人 | 誰が何に反応したか | 所属、役割、接点、関心テーマ、最終反応日 | 一人の強い反応を会社全体の合意と誤認する |
| アカウント | どの会社・組織を扱うか | 法人、事業部、支店、企業属性、親子関係 | 表記揺れや組織階層で行動が分散する |
| 購買テーマ・案件 | 何を、いつ、なぜ検討しているか | 課題、対象製品、導入時期、予算、現在の状態 | 別テーマの行動を同じ検討として足してしまう |
| 購買関与者 | 誰の合意や評価が必要か | 推進者、利用部門、決裁者、技術評価、購買担当 | 問い合わせ担当者だけに依存し、合意の欠落を見逃す |
アカウントを正しくまとめるには、法人名だけでなく、法人番号、ドメイン、親子会社、支店・部署の扱いを先に決めます。表記揺れや組織階層の整理は、会社マスタの設計方法と合わせて確認すると、人物・企業・案件のひも付けを安定させられます。
この管理単位は、社内のマーケティング状態や営業状態とも分けます。MQL、SQL、商談ステージは自社が次にどう扱うかを表す状態です。一方、課題の合意、要件の整理、稟議の承認は顧客側の購買状態です。二つを同じ一列に詰めると、「営業へ渡したから顧客の検討も進んだ」という誤った見方になります。
段階は名称ではなく「退出条件」で設計する
「認知、比較、稟議、商談、受注」と名前を並べただけでは、担当者ごとに進行判断が変わります。段階ごとに、観測できる証拠、必要な関与者、次へ進む条件を定義してください。ページ閲覧やメール開封は関心の手掛かりにはなりますが、それだけを退出条件にしません。
次の6状態は初期設計の例です。すべての案件が同じ順で進むわけではなく、技術評価と予算確認が並行したり、決裁者の要請で要件整理へ戻ったりします。順序を固定するより、現在そろっている条件と未解決の条件を残すことが重要です。
| 購買状態の例 | 観測する証拠 | 退出条件の例 | 次の担当・処理 |
|---|---|---|---|
| 対象・テーマ特定 | 対象企業、課題テーマ、接点の発生 | 会社と購買テーマを区別できる | マーケティングが情報を補完する |
| 課題合意 | 現状、影響、優先度の確認 | 推進者が解決したい課題を説明できる | 関係部門と検討範囲を確認する |
| 要件合意 | 利用条件、技術条件、運用制約 | 必須要件と評価基準が言語化される | 不足する専門関与者へ接点を広げる |
| 解決策評価 | 比較、デモ、事例、適合性の確認 | 候補と判断理由、未解決事項が分かる | 営業が提案と検証計画を更新する |
| 社内承認 | 予算、稟議、法務、購買、セキュリティ審査 | 承認者と残るゲート、期限が分かる | 必要な根拠資料と回答をそろえる |
| 契約・導入準備 | 条件調整、契約、開始体制 | 契約条件と導入責任者が合意される | 受注処理と導入引き継ぎを行う |
退出条件は「資料を3本読んだ」のような回数ではなく、次の判断に必要な事実で書きます。「決裁者が特定済み」「技術要件の未回答が0件」「稟議予定日が確認済み」のように、担当者が同じ証拠を見て同じ判断をできる粒度が目安です。
段階を戻す条件も必要です。担当者の異動、予算凍結、要件変更、審査差し戻しが起きたら、以前の高い段階を残したままにせず、戻した状態、理由、再開条件を記録します。直線的な段階が現場と合わない場合は、稟議と決裁を含め、停滞を生む構造から点検します。
購買関与者の充足と合意ゲートを別々に見る
同じ会社から複数人が反応していても、必要な役割がそろっているとは限りません。利用部門の参加者が増えていても、予算責任者や技術評価者が未確認なら、検討人数と意思決定の準備度は別です。人数ではなく、案件ごとに必要な役割と未充足の役割を確認します。
Adobe Journey Optimizer B2B EditionのBuying Groupsの説明では、販売するソリューション、対象アカウント、必要な役割テンプレートを分け、役割の充足度と関与の強さを別の指標として扱います。これは製品固有の実装例であり、役割数やスコアをそのまま業界標準にはできませんが、「誰がそろったか」と「どれだけ反応したか」を分ける考え方は設計の参考になります。
| 役割の例 | 主な関心 | 確認したいこと | 用意する情報 |
|---|---|---|---|
| 推進者 | 課題解決と社内前進 | 優先度、関係者、承認の進め方 | 課題整理、社内説明の要点、次の合意事項 |
| 利用部門 | 使いやすさと業務適合 | 現行業務、利用者、定着条件 | 利用シナリオ、運用例、導入後の支援 |
| 決裁者・予算責任者 | 投資妥当性と優先順位 | 期待成果、費用、代替案、リスク | 費用対効果の前提、導入範囲、意思決定材料 |
| 技術・セキュリティ評価 | 連携、安全性、運用負荷 | 要件、データ、権限、審査項目 | 構成、セキュリティ回答、責任分界 |
| 購買・法務 | 契約条件と取引統制 | 契約、支払、審査、必要書類 | 見積、約款、審査資料、回答期限 |
Microsoft Dynamics 365の商談関与者の管理方法でも、推進者、利用者、経済的な買い手、影響者、技術評価者などを商談へ関連付けられます。役割名は製品や自社商材に合わせて変え、すべての案件に同じ役割を強制しないことが大切です。
役割別の接触設計を具体化する場合は、BtoB購買委員会の役割別ジャーニーを使い、誰へ同じ説明を繰り返すのではなく、各関与者が判断するために不足している情報を整理します。
CRM・MAには人物、企業、案件、判断根拠を関連付ける
CRMでは、人物、企業、購買テーマ・案件を別レコードとして保持し、関係をたどれるようにします。一つの自由記述欄に「A社は検討中」とだけ残すと、誰が、何を、どの条件で検討しているかを集計できません。
MAの閲覧、フォーム、メール、イベント反応は、人物の行動明細として残し、企業・案件へ関連付けます。同一企業の行動を集約する場合も、元の人物、発生日時、テーマを消さないようにします。
HubSpotのレコード関連付けの仕様は、コンタクト、企業、商談などを別レコードとして関連付け、関係をラベルで表す例です。主企業や自動関連付けの挙動はHubSpot固有なので、自社のCRMでは「どの企業を正とするか」「兼務やグループ企業をどう扱うか」を別途決めます。
| 必須項目 | 内容 | 更新契機 | 責任者 |
|---|---|---|---|
| アカウントID | 企業・組織の正規キー | 名寄せ、組織変更 | データ管理者 |
| 購買テーマ・案件ID | 検討対象と案件の識別子 | 新テーマ発生、案件化、分割・統合 | マーケティング／営業 |
| 関与者と役割 | 人物、役割、影響範囲、確認状況 | 面談、紹介、役割変更 | 接点を持った担当者 |
| 現在の購買状態 | 状態、観測証拠、未解決ゲート | 条件成立、差し戻し、休止 | 案件オーナー |
| 最終進行日 | 最後に退出条件が成立した日 | 段階更新 | システムまたは案件オーナー |
| 次の行動 | 担当、期限、必要な情報 | 会議、引き渡し、差し戻し | 次工程の担当者 |
| 受け入れ・差し戻し理由 | 営業判断、情報不足、時期、対象外 | 営業確認時 | 営業担当者 |
MQLやSQLは、マーケティングと営業の受け渡しに使う社内状態です。HubSpotのライフサイクルステージでは、MQLをマーケティングが営業対応可能と判断した状態、SQLを営業が見込み顧客と判断した状態として例示し、独自ステージへの変更も認めています。これはHubSpotの既定定義であり、業界共通の点数や日数ではありません。
個人を判定するMQL、アカウントを判定するMQA、購買グループを判定するMQBGなどの名称を使う場合も、略語を増やすこと自体が目的ではありません。MQL・MQA・MQBGの判定単位を確認し、次の情報を営業へ一緒に渡します。
- 対象の企業と購買テーマ・案件
- 検討が進んだと判断した証拠と発生日
- 確認済みの関与者、役割、未充足の役割
- 成立済みの合意ゲートと未解決事項
- 営業に期待する次の行動と期限
- 受け入れ、差し戻し、再育成の選択肢と理由コード
遷移率・滞留・逆戻りを見て改善する
ファネルの改善対象は、最も人数が少ない段階ではなく、事業上重要な案件が止まっている条件です。総数だけでは、最近入った案件と長期停滞案件が混ざります。状態へ入った月や四半期でコホートを分け、遷移、滞留、逆戻り、営業受け入れを同じ期間で見ます。
| KPI | 分かること | 確認する切り口 | 改善例 |
|---|---|---|---|
| 状態遷移率 | 次の退出条件を満たした割合 | 流入元、商材、企業層、担当 | 不足情報や評価支援を補う |
| 状態滞在時間 | どの条件で時間を使っているか | 中央値、長期滞留、コホート | 期限と次担当を明確にする |
| 逆戻り・差し戻し率 | 合意やデータが崩れる場所 | 理由、戻り先、関与者 | 退出条件と確認項目を修正する |
| 関与者充足 | 必要な役割へ接点があるか | 案件タイプ、未充足役割 | 紹介依頼や役割別情報を用意する |
| 営業受け入れ率 | 受け渡し条件が実務に合うか | 受け入れ・差し戻し理由 | 判定条件と引き渡し情報を更新する |
| 商談化・受注率 | 購買状態が成果につながったか | 判定時の状態、役割、ゲート | 成果に寄与しない条件を見直す |
AIは、接点履歴の要約、未確認の役割候補、停滞理由の分類、次の行動案の作成を補助できます。ただし、段階を自動で断定させる前に、入力データ、判定理由、人が確認する条件、営業結果の評価方法を決めます。観測できない社内事情や、記録されていない決裁関係をAIに推測させて進行条件を満たしたことにしてはいけません。
30日で最小運用を始める手順
- 第1週：直近の受注、失注、停滞案件を少数選び、実際に関わった人物、合意、審査、差し戻しを時系列で確認する。
- 第2週：購買状態を5〜6個に絞り、各状態の証拠、退出条件、戻す条件、次の担当を一枚にする。
- 第3週：人物・企業・案件・役割・ゲートをCRM項目へ割り当て、MQLや営業受け渡しに必要な情報を固定する。
- 第4週：一つの商材と少数案件で試し、営業の受け入れ、滞留、入力負荷を確認してから対象を広げる。
最初から全商材、全チャネル、全担当へ広げる必要はありません。一つの購買テーマで退出条件と受け渡しが機能することを確認し、役割テンプレートや項目を商材ごとに調整します。段階数を増やすより、同じ証拠から同じ判断ができる状態を優先してください。
よくある質問
BtoBファネルはどの単位で管理しますか？
原則は「アカウント×購買テーマ・案件」です。そこへ個人の行動、購買関与者の役割、合意・承認ゲートを関連付けます。会社単位だけでは複数案件が混ざり、個人単位だけでは同じ案件に関わる複数人をまとめられません。
同じ会社の複数人が反応したら、検討が進んだと判断できますか？
人数だけでは判断できません。同じ購買テーマへの反応か、必要な役割が含まれるか、直近の行動か、営業が確認した課題や時期と一致するかを確認します。元の人物と行動明細を残したうえで企業・案件単位へ集約してください。
MQLとMQAはどう使い分けますか？
MQLは自社が定義したマーケティング適格状態、MQAはアカウント単位の適格状態を表す名称として使われます。ただし製品や会社によって定義が異なるため、名称より判定単位、成立条件、営業へ渡す情報を明文化することが重要です。
BtoBファネルで最も重要な段階はどこですか？
すべての会社に共通する一段階はありません。状態遷移率、滞在時間、逆戻り、営業差し戻し、失注理由を見て、自社の商材と顧客層で成果を止めている条件を特定します。上部の流入不足とは限らず、要件合意や社内承認がボトルネックの場合もあります。
関連ページと関連記事
BtoBファネルの進行条件を整理する
個人の行動、企業、案件、関与者、合意ゲートが分断していると、流入を増やしても停滞理由を特定できません。現在のCRM・MA項目と営業プロセスを確認し、退出条件、受け渡し情報、改善KPIを一つの運用へ整理できます。
