BtoBの顧客理解で起きやすい失敗は、資料請求や商談の窓口になった「1人」を顧客全体と見なしてしまうことです。実際には、現場の利用者、技術評価者、予算責任者、購買・法務など、異なる立場の人が別々の懸念を持ちながら意思決定に関わります。
結論から言うと、BtoBの顧客理解はペルソナを細かく増やすよりも、誰が、どの購買タスクを、何を根拠に完了させる必要があるかを整理するほうが実務に効きます。本記事では、購買委員会・利用部門・購買タスクを一枚にまとめ、Webサイト、コンテンツ、広告、営業連携に使える「購買委員会マップ」を作る6ステップを解説します。
Webマーケティングの施策全体をゼロから整理したい場合は、先にWebマーケティングの始め方｜施策選びで迷わない「目的・顧客・導線・指標」5ステップも確認してください。
BtoBの顧客理解は「担当者像」ではなく「合意形成の構造」を読む
BtoBの購買は、個人が商品を選んで購入するプロセスとは異なります。ある人は導入後の使いやすさを気にし、別の人は既存システムとの連携やセキュリティを確認し、さらに別の人は投資対効果や取引リスクを判断します。
そのため、「情報システム部長」「マーケティング責任者」といった属性だけでペルソナを作っても、何を伝えれば商談が前進するかは分かりません。見るべきなのは役職名ではなく、購買における役割、未解決の問い、社内で提示すべき根拠です。
| 層 | 確認すること | 施策への変換例 |
|---|---|---|
| 対象アカウント | 業種、事業課題、既存環境、導入契機 | ターゲット企業群、訴求テーマ、広告配信条件 |
| 購買委員会 | 誰が推進・評価・承認・阻止に関わるか | 役割別の導線、営業の確認項目、接点設計 |
| 利用部門 | 誰が日常的に使い、何を変える必要があるか | 導入イメージ、運用設計、現場向け事例 |
| 購買タスク | 比較、要件化、検証、稟議、合意で必要な判断材料 | 比較表、仕様書、ROI試算、導入計画、FAQ |
特に見落とされやすいのが、購買委員会と利用部門は一致しないという点です。決裁者に刺さる経営課題の説明だけでは、現場が「自分たちの運用に落とせる」と判断できません。反対に、現場向けの機能説明だけでは、予算責任者が投資を承認できません。
2023年の研究では、BtoBのカスタマージャーニーを、購買に関わる人だけでなく、利用に関わる人の目標・接点・関係性も含むものとして整理しています。BtoBのジャーニーは直線的なファネルではなく、複数人の経路が重なった構造として捉える必要があります。
購買委員会マップを作る6ステップ
1. まず「同じ買い方をする案件群」を決める
最初から全顧客を一枚にまとめると、抽象的なマップになります。優先すべきは、売上や戦略上の重要性があり、かつ購買条件が似ている案件群です。
例えば、同じ製品でも「新規導入」と「既存システムの置き換え」では、比較基準も関与者も変わります。新規導入では導入価値や事例が重視されやすく、置き換えでは移行負荷、データ連携、停止リスクが論点になりやすいからです。
- 対象業種・企業規模
- 商材の購入形態（新規、更新、追加、乗り換え）
- 想定契約規模と検討期間
- 導入のきっかけ（制度変更、事業拡大、人員不足、リスク対応など）
- 受注・失注時に繰り返し出る条件
この単位を決めることで、「誰に届けるか」ではなく「どの購買状況を前に進めるか」という施策設計に変わります。
2. 仮説ではなく、案件の証拠を集める
購買委員会マップの材料は、理想の顧客像ではなく実際の商談記録です。営業担当者へのヒアリングだけで終わらせず、受注・失注案件を横断して確認します。
| 証拠の種類 | 見るもの | 分かること |
|---|---|---|
| CRM・商談履歴 | 接触部署、停滞理由、失注理由、受注までの期間 | 関与者、止まりやすい段階、案件条件 |
| 商談録画・議事録 | 質問、反論、持ち帰り事項、社内共有の依頼 | 担当者ごとの不安と必要な根拠 |
| 顧客・失注先インタビュー | 導入契機、比較方法、社内の議論、導入後の評価 | 表面化しにくい判断過程と利用実態 |
| サイト・コンテンツ行動 | 閲覧ページ、資料、再訪、フォーム入力前後の行動 | 検討中の論点の仮説。ただし個人の意図の断定はしない |
重要なのは、事実と解釈を分けて記録することです。「セキュリティ資料を求められた」は事実ですが、「セキュリティ担当者が反対している」は解釈です。解釈には必ず根拠となる発言、商談状況、複数案件での再現性を添えます。
3. 肩書きではなく「購買上の役割」で関与者を置く
購買委員会には、すべての案件で同じ役割が揃うわけではありません。それでも、次のような役割を仮置きすると、聞くべきことと不足するコンテンツが見えやすくなります。
- 課題提起者：現場課題や事業課題を認識し、検討を始める人
- 推進者：情報収集、社内調整、ベンダーとの連絡を担う人
- 利用者：導入後に実務で使い、定着の成否を左右する人
- 専門評価者：技術、セキュリティ、法務、運用要件を確認する人
- 経済的承認者：予算、投資対効果、優先順位を判断する人
- 購買・審査担当：契約、取引条件、調達ルール、リスクを確認する人
ここでの注意点は、役割ごとに別々のメッセージを作り込みすぎないことです。BtoBでは、推進者が資料を社内に転送し、説明し、質問を回収します。したがって、役割別の情報に加えて、立場の異なる人が同じ資料で合意しやすい共通の判断材料を用意する必要があります。
4. ファネルではなく「完了すべき購買タスク」を洗い出す
「認知→興味→比較→問い合わせ」というファネルは、施策を管理するには便利です。しかし、顧客が何に迷い、何を終えれば前に進めるかを十分に説明できません。
実務では、次のような購買タスクに分解すると、コンテンツと営業支援の不足が見えます。
- 課題を言語化する：現状維持のコストやリスクを社内で共有する
- 解決策を比較する：内製、既存ベンダー、別カテゴリも含めて選択肢を把握する
- 要件を定める：必要機能、運用条件、連携、導入体制を決める
- 候補を評価する：自社に適合するか、実績や技術で確かめる
- 不安を検証する：費用、セキュリティ、移行、成果の不確実性を下げる
- 合意をつくる：関係者が稟議・会議・比較表で説明できる状態にする
GartnerもBtoB購買を、問題認識、解決策探索、要件構築、サプライヤー選定、検証、合意形成といった繰り返し発生するタスクとして整理しています。段階を一方向に進むものと決めつけず、案件の停滞時に「どのタスクが未完了か」を確認する視点が有効です。
5. 「人 × タスク × 根拠」で一枚のマップにする
ここまでの情報を、関与者ごとの関心だけで終わらせず、購買タスクと必要な根拠を交差させます。以下は、業務システムを提供する企業を想定した簡易例です。
| 関与者 | 未完了の購買タスク | 主な問い | 必要な根拠 | 用意する情報 |
|---|---|---|---|---|
| 現場責任者 | 課題の言語化 | 現場負担は本当に減るか | 導入前後の業務フロー、類似企業の運用例 | 活用シーン、導入事例、運用イメージ |
| 情報システム部門 | 要件化・検証 | 既存環境と安全に連携できるか | 仕様、連携方式、権限、セキュリティ回答 | 技術資料、セキュリティシート、FAQ |
| 部門長・役員 | 投資判断・合意形成 | 優先投資に値するか | 効果の前提、導入ロードマップ、リスク | ROI試算の考え方、経営向け要約、導入計画 |
| 購買・法務 | 取引先評価 | 契約・運用上の懸念はないか | 契約条件、サポート、会社情報、継続性 | 会社概要、支援体制、標準契約の説明 |
このマップで見つけたいのは、「誰向けのコンテンツがないか」だけではありません。より重要なのは、複数の関与者に共通する未解決の問いです。例えば「導入後の運用負荷」は現場・情報システム・決裁者の全員に関係します。ここに対して、導入ステップ、役割分担、支援範囲、立ち上げ期間を一貫して説明できれば、個別コンテンツを増やす以上に合意形成を支えられます。
6. 施策一覧ではなく、検証できる改善バックログへ変換する
マップを完成させる目的は、きれいな図を作ることではありません。未解決の購買タスクを減らす改善を、優先順位付きで実装することです。
優先順位は、次の4軸を各1〜5点で評価すると、議論を進めやすくなります。
- 案件への影響度：対象案件でその論点が発生する割合
- 停滞への寄与：未解決のまま失注・長期化につながる度合い
- 証拠の不足度：顧客が判断するための根拠が不足している度合い
- 実装可能性：必要な情報・担当者・制作工数を確保できる度合い
たとえば、「技術資料が見つからず、商談のたびに営業が個別送付している」という課題なら、資料を増やすことだけが答えではありません。サイト内の導線、資料の更新責任、フォームの有無、営業が説明する前提との整合まで確認します。戦略、制作、営業運用を分けると、顧客には情報があっても届かない状態が残ります。
マップの効果は「リード数」だけで測らない
購買委員会マップに基づく改善は、短期的にはCV数に直結しないことがあります。特に高単価・長期検討のBtoBでは、問い合わせ前の調査、社内説明、技術検証を支える情報も必要だからです。
そこで、コンテンツ単体のPVや資料DL数だけで評価せず、CRMとWeb行動をつないで次のような指標を見ます。
| 見る指標 | 定義例 | 判断できること |
|---|---|---|
| 関与者把握率 | 主要案件で、推進・評価・承認の役割を把握できた割合 | 営業・マーケティングが窓口依存から抜けつつあるか |
| 重要タスクの根拠充足率 | 頻出する購買タスクに対し、説明資料やページがある割合 | 情報不足を放置していないか |
| 合意形成コンテンツ利用率 | 比較表、導入計画、ROI資料などが商談で活用された割合 | 社内説明に使える材料になっているか |
| 停滞理由の構成比 | 失注・長期化理由を購買タスク別に分類した比率 | 次に解くべき論点は何か |
GA4はページ閲覧やコンバージョン前行動の把握に役立ちますが、誰が社内で承認を止めたか、どの資料で合意が進んだかはGA4だけでは分かりません。匿名行動、営業が把握した関与者、商談・受注結果を分けて設計する方法は、GA4コンバージョン設計のやり方｜BtoBのアクセス解析で商談につながるリードを見極める7ステップで詳しく解説しています。
BtoBの顧客理解でよくある4つの失敗
失敗1：役職ごとにペルソナを量産する
役職別ペルソナは、表現や広告配信の補助には使えます。しかし、肩書きだけでは案件ごとの影響力や未解決の論点は分かりません。「誰が何を決めるのか」を確認せずにペルソナを増やすと、制作物だけが増えます。
失敗2：利用者の声を導入前の訴求に使わない
導入後の利用者は、現場定着、工数、例外対応、サポート品質を最も具体的に知っています。利用部門の声は、導入事例の素材であるだけでなく、検討段階の不安を減らす根拠です。受注後のカスタマーサクセスやサポート部門も、顧客理解の重要な情報源に含めましょう。
失敗3：カスタマージャーニーを一直線に描く
実際のBtoB購買では、候補選定の後に要件へ戻ったり、稟議のために事例を探し直したりします。「現在地」を一つに固定するより、どの購買タスクを再確認しているのかを記録するほうが、打ち手を誤りにくくなります。
失敗4：マップをサイト設計へ反映しない
調査・整理だけで終わると、顧客理解は会議資料のままです。頻出する問いを、サービスページ、事例、FAQ、資料、比較コンテンツ、CTAに割り振り、実際に探しやすい構造へ変える必要があります。購買委員会マップをサイトマップへ落とし込む方法は、BtoBサイトの情報設計｜検討段階・意思決定者・証拠からサイトマップを作る7ステップを参照してください。
まとめ：最適化すべき単位は「人」でも「チャネル」でもなく、未完了の購買タスク
BtoBの顧客理解では、窓口担当者の属性や単一のカスタマージャーニーだけでは不十分です。購買委員会と利用部門の関係を捉え、それぞれが完了させるべき購買タスクと必要な根拠を整理することで、マーケティング施策と営業活動のつながりが見えてきます。
- まず、同じ買い方をする重要案件群を一つ選ぶ
- 受注・失注・商談記録から、関与者と論点の証拠を集める
- 役職ではなく、購買における役割で関与者を整理する
- ファネルではなく、比較・検証・合意などの購買タスクを捉える
- 人・タスク・根拠・コンテンツを一枚にし、改善優先度を決める
- Web行動だけでなく、CRM上の関与者・停滞理由・商談結果で検証する
最初から精密なマップを作る必要はありません。直近の受注案件5件、失注案件5件から始め、仮説を営業・顧客接点・行動データで更新してください。小さく実装し、案件の進み方で検証することが、実務で使われる顧客理解につながります。
