Timothe AI(ティモシーAI)

BtoB SaaS のカスタマージャーニーマップの作り方

BtoB カスタマージャーニーマップの作り方を7ステップで解説。複数の購買関与者の思考・不安を捉え、施策と KPI に直結させる方法をテンプレート例とともに紹介する。

鈴木凌介 (Ryosuke Suzuki)
約5,280文字約11分
BtoB SaaSのカスタマージャーニーマップの作り方

BtoB SaaS のカスタマージャーニーマップとは、複数の購買関与者が「課題認識」から「活用・定着」まで各フェーズで必要とする情報・接点・施策を一枚に可視化した設計図である。単なる認知→購入の流れ図ではなく、起案者・情シス・決裁者それぞれの思考と不安を捉え、施策と KPI に直結させる点が BtoC 向けのマップと決定的に異なる。少人数チームでも実行できる7ステップの作成手順を、記入テンプレート例とともに解説する。


BtoB SaaS のカスタマージャーニーは BtoC と何が違うのか

BtoC の購買は個人が短期間で完結する。一方、 BtoB SaaS には3つの構造的な違いがある。①購買関与者が複数存在する、②検討期間が長い、③感情より合理的評価基準( ROI ・セキュリティ・運用負荷)が意思決定を左右する。この3点を無視したマップは、実態と乖離した「願望図」になりやすい。

では、どれほど複雑化しているのだろうか。電通グループが2024年に発表したグローバル調査「 dentsu B2B Superpowers Index 」によれば、 BtoB 購買ジャーニーで考慮されるブランド数は2021年以降62%増加し、意思決定に要する平均時間は54日増加している(出典)。世界全体の傾向であり日本の SaaS 企業にそのまま当てはめられる数値ではないが、購買プロセスの長期化・複雑化という方向性は共通する。

関与者の数も見過ごせない。 IDEATECH の2026年調査では、年間契約金額500万円以上の BtoB SaaS 導入において、意思決定に7名以上が関与した案件が58.5%に達した(出典)。高額帯に限った結果ではあるものの、「担当者1人のペルソナだけで作ったマップ」では稟議やセキュリティ審査で止まる理由を捉えられない。


作成前に準備すること

目的とゴールを決める

マップ作成の目的は「リード獲得の強化」「商談化率の改善」「オンボーディング離脱の削減」など、1つに絞る。目的が複数あると全フェーズを均等に埋めようとして施策の優先順位がつかなくなる。「どのフェーズのボトルネックを解消したいのか」を先に決めれば、最初に埋めるべきセルが明確になり、形骸化を防げる。

重点 ICP を1つ選ぶ

BtoB SaaS のペルソナは二層構造で設計する。第一層は企業ペルソナ( ICP: Ideal Customer Profile )で、業種・従業員規模・既存システム環境・予算帯・導入背景を定義する。第二層は個人ペルソナで、 DMU ( Decision Making Unit )を構成する関与者を役割別に整理する。

役割主な関心事
起案者課題解決、業務効率マーケ担当、営業企画
利用者使いやすさ、日常業務への影響現場メンバー
影響者セキュリティ、既存システム連携情シス、法務
決裁者ROI 、予算、経営方針との整合部門長、経営層
推進者社内展開、定着プロジェクトリーダー

少人数チームでは、最初に企業ペルソナ1種類、個人ペルソナは起案者と決裁者の2種類に絞るのが現実的である(Sansan)。完璧を目指すよりも、施策に使えるマップを先に1枚仕上げることを優先すべきだ。

材料を集める

顧客インタビューが理想だが、それだけに頼る必要はない。商談議事録、失注理由のログ、 CS への問い合わせ内容、 CRM/SFA/MA のデータ、 Web アクセス解析、レビューサイトの口コミも有力な材料になる。インタビューが難しい場合は、営業 FAQ や失注理由を分析するだけでも仮説版の材料として十分に機能する。


BtoB SaaS カスタマージャーニーマップの作り方【7ステップ】

課題認識から導入後の活用・更新までをつなぐBtoB SaaSの7段階ジャーニー
課題認識から導入後の活用・更新までをつなぐBtoB SaaSの7段階ジャーニー

ステップ1:購買フェーズを7段階で定義する

横軸に設定するフェーズは、以下の7段階を推奨する。

  1. 課題認識
  2. 情報収集
  3. 解決策の理解
  4. 比較・評価
  5. 社内稟議・意思決定
  6. 契約・導入
  7. 活用・定着・更新

BtoC の「認知→興味→購入」と比べると、稟議・意思決定や契約後の活用・定着が独立したフェーズとして存在する点が決定的に違う。 SaaS では契約がゴールではない。トライアル、オンボーディング、初回価値実感、更新、アップセルまでを含めなければ、チャーン低減の施策がマップ上で管理できなくなる。

ステップ2:各フェーズの主な購買関与者を配置する

フェーズごとに「主役」となる関与者を対応づける。課題認識〜情報収集では起案者が主役であり、比較・評価から情シスや法務が影響者として加わり、稟議フェーズで決裁者が前面に出る。契約後は利用者と CS が中心になる。

どの関与者を優先すべきか迷ったら、「情報収集を最初に始める人は誰か」を問う。その人物のジャーニーを主軸に据え、他の関与者は該当フェーズに列を追加する形で拡張するのが効率的である。

ステップ3:顧客の「現実の行動」を記入する

「資料請求してほしい」「問い合わせてほしい」という企業側の希望を、顧客行動として書いてしまうケースが非常に多い。だが、マップに書くべきは顧客が実際に取った行動である(才流HubSpot)。

たとえば、こんな行動がある。営業に連絡する前に検索エンジンで調べる。比較サイトや口コミを読む。社内の知人に「あのツールどう?」と聞く。 AI 検索で候補を3つに絞る。営業と接触せずに無料トライアルを開始する。稟議のためにセキュリティチェックシートを自分で探す。

こうした行動パターンはどこから見つけるのか。商談議事録や失注理由のログを読み返すと浮かび上がってくる。

ステップ4:顧客の思考・不安・不足情報を書き出す

各フェーズで顧客が抱える疑問と、それを解消するために必要な情報を対にして記入する。

  • 課題認識フェーズ:「これは自社だけの問題か、業界共通か分からない」→ 課題の整理と原因分析が必要
  • 比較・評価フェーズ:「自社のシステム環境で本当に使えるのか」→ 連携仕様とセキュリティ要件が必要
  • 社内稟議フェーズ:「費用対効果を上長に説明できない」→ ROI 試算と TCO 比較が必要

思考と不安の欄が空欄のまま施策だけ並べるとどうなるか。「誰の何を解決するコンテンツか」が曖昧になり、作ったコンテンツが刺さらない。この対応づけこそがマップの核である。

ステップ5:タッチポイントとコンテンツを配置する

フェーズと関与者の交差点ごとに、顧客接点と提供コンテンツを配置する。

フェーズ主なタッチポイントコンテンツ例
課題認識検索エンジン、 SNSSEO 記事、課題診断コンテンツ
情報収集オウンドメディア、ウェビナー解説記事、ホワイトペーパー
比較・評価サービスサイト、デモ、比較サイト導入事例、機能比較表、デモ動画
社内稟議営業資料、提案書ROI 試算シート、稟議テンプレート、セキュリティチェックシート
契約・導入管理画面、 CSオンボーディングガイド、初期設定マニュアル
活用・定着ヘルプセンター、 CS 、ユーザー会活用 Tips 、定例レポート

SEO 記事は主に課題認識〜情報収集フェーズに位置づけられる。リード獲得の全体設計については、リードジェネレーションとは? BtoB SaaS におけるリード獲得の全体設計で詳しく解説している。

購買フェーズと関与者の交点に、必要なコンテンツを配置したマッピング図
購買フェーズと関与者の交点に、必要なコンテンツを配置したマッピング図

ステップ6:担当部署・ CTA ・ KPI を紐づける

マップを「分析図」から「施策実行計画」に変えるために、各セルへ3つの項目を追記する。

  • 担当部署(マーケティング、インサイドセールス、フィールドセールス、 CS など)
  • CTA (顧客を次のフェーズへ導くアクション。資料 DL 、デモ予約、トライアル開始など)
  • フェーズ KPI (流入数、資料 DL 数、 MQL 転換率、 SQL 転換率、商談化率、受注率、アクティベーション率、継続率)

MQL はマーケティングが「商談化の可能性あり」と判定したリード、 SQL は営業が「商談として対応する」と受け入れたリードである。マップ上では、 MQL は情報収集〜解決策理解フェーズのアウトプットに、 SQL は比較・評価フェーズのアウトプットに対応することが多い。

この3項目を埋めると、「誰が何を担当し、何で成果を測るか」がマップ一枚で共有できるようになる。詳細な定義と引き渡し基準については、MQL と SQL の違いとは? BtoB SaaS のリード管理・引き渡し基準を参照してほしい。

ステップ7:まず1枚を完成させ、運用サイクルに載せる

完成度100%を目指さない。重点 ICP の主要ペルソナ分を1枚仕上げ、マーケティング・営業・ CS の3者でレビューし、施策の優先順位を決定する。

見直しのタイミングは、四半期ごとの定期レビューに加え、プロダクトの大型アップデート時や市場環境の変化時に臨時レビューを行う組み合わせが現実的だ。ただし最適な頻度は自社の変化速度に応じて決めるものであり、固定の正解はない。


テンプレート例: BtoB SaaS 向けカスタマージャーニーマップ

以下のテンプレートを Google スプレッドシートや Excel にコピーし、自社の商材に合わせて記入する。共有と更新のしやすさを考えると、スプレッドシート形式が実務的である。

フェーズ主な関与者顧客の行動思考・不安必要な情報タッチポイント自社施策KPI
課題認識現場担当者課題を検索、社内相談自社の問題か分からない課題の整理、原因SEO 記事、営業会話課題整理記事、診断流入数、再訪率
情報収集担当者・推進者解決方法を調べるどの方法が適切か方法の違い、導入条件検索、資料、ウェビナー解説記事、 WP資料 DL 数、 MQL
解決策の理解推進者カテゴリを絞り込む自社に合うか適用条件、成功要件オウンドメディアカテゴリ解説、事例ページ滞在、回遊
比較・評価推進者・情シス複数サービスを比較自社環境で使えるか機能、連携、セキュリティサービスサイト、デモ比較資料、デモSQL 、商談化率
社内稟議決裁者・部門長稟議書を作成・説明ROI 、運用負荷が不安ROI 、 TCO 、導入体制提案資料、営業ROI 資料、稟議テンプレ提案化率、受注率
契約・導入推進者・利用者契約、初期設定現場が使えるか導入手順、支援体制CS 、管理画面オンボーディング初期設定完了率
活用・定着・更新利用者・管理者継続利用、社内展開効果が出ているか活用方法、成果確認CS 、ヘルプ、メール活用支援、定例会継続率、 LTV

このテンプレートは「顧客が何を考え、何が足りないか」を起点に、「自社は何を提供し、誰が担当し、何を計測するか」まで一枚でつなぐための構造である。空欄が多い状態でも構わない。埋まっていないセルこそが、施策の抜け漏れを教えてくれる。

マーケティングから営業・CSへ担当が移るカスタマージャーニーの記入例
マーケティングから営業・CSへ担当が移るカスタマージャーニーの記入例

よくある失敗と対処法

  1. 企業の希望を顧客行動として書いてしまう 「資料請求する」「問い合わせる」と書きたくなるが、それは企業側の願望だ。商談録や失注理由ログから、顧客が実際に取った行動を検証して書き直す。

  2. マーケ部門だけで作り、営業・ CS の知見が反映されない 比較・評価以降のフェーズは営業が、契約後は CS が顧客の実態を最もよく知っている。最低限、営業1名・ CS1名にヒアリングしてからマップを埋める。

  3. 全フェーズを均等に作り込み、施策の優先がつかない 目的に直結するフェーズから先に埋める。商談化率が課題なら比較・評価と稟議フェーズを、チャーンが課題なら活用・定着フェーズを優先する。

  4. 作って終わり、更新されず形骸化する 四半期レビューをカレンダーに入れ、受注・失注分析の結果を反映する仕組みを作る。マップは「完成品」ではなく「運用ツール」である。


FAQ

カスタマージャーニーマップの横軸と縦軸には何を書くのか?

横軸は購買フェーズ(課題認識〜活用・定着・更新の7段階)を設定する。縦軸は顧客の行動、思考・不安、必要な情報、タッチポイント、自社施策、担当部署、 KPI を並べる。この構造により、フェーズごとの施策と計測指標が一覧できる。

BtoB では購買関与者が複数いる場合、誰のジャーニーを作るべきか?

まず起案者(情報収集を始める担当者)のジャーニーを主軸に作る。比較・評価以降で影響者(情シス・法務)と決裁者の視点を列として追加する。少人数チームでは起案者1名分から始めて十分である。

無料トライアルやオンボーディングもマップに含めるべきか?

SaaS では契約がゴールではないため含めるべきである。トライアル開始から初回価値実感、社内展開、更新までを設計に入れることで、チャーン低減やアップセルの施策もマップ上で管理できる。

カスタマージャーニーマップはどのくらいの頻度で見直すべきか?

一律の正解はない。四半期ごとの定期レビューと、プロダクトの大型アップデートや市場環境の変化時の臨時レビューを組み合わせる運用が現実的である。自社の変化速度に応じて調整する。

少人数のマーケティングチームでも作成できるか?

可能である。 ICP を1つ、主要ペルソナを1〜2種類に絞り、商談・受注に近いフェーズから優先的に埋める。営業 FAQ や失注理由ログなど既存データを活用すれば、顧客インタビューなしでも仮説版を作成できる。完成度より「施策に使えるか」を基準にして回し始めることが、形骸化を防ぐ最大のポイントである。