GrowthBrief

知見・解説

カスタマージャーニーマップの作り方|初心者でも使える手順と記入例

カスタマージャーニーマップの作り方を、BtoBの比較・稟議・導入を含む記入例で解説。事実と仮説を分け、施策・KPI・担当・期限を決める手順を紹介します。

顧客の検討段階と接点を横にたどるカスタマージャーニーの記事画像

カスタマージャーニーとは、顧客が課題を認識してから商品・サービスを選び、利用するまでの行動や接点を時系列で捉えるものです。マップを作る際は、まず目的と対象顧客を決め、購買段階ごとに顧客の行動・課題を整理します。確認できた事実と仮説を分け、各段階で提供する情報や施策を決めることが重要です。この記事では、BtoB企業の比較・稟議・導入を含む記入例を使い、テンプレートの項目、施策への落とし込み方、KPI・担当・期限を設定して検証する手順を示します。ペルソナが未確定の場合の進め方も取り上げます。

カスタマージャーニーとは何か

カスタマージャーニーとは、顧客が課題を認識し、情報収集や比較を経て商品・サービスを選び、利用するまでの行動や考え方の流れです。その流れを、顧客との接点や疑問とともに時系列で整理したものをカスタマージャーニーマップと呼びます。

企業が想定する販売手順だけを並べるのではなく、顧客が各段階で何を知り、何に迷い、次の行動をどう判断するかを顧客の視点から捉えることが重要です。対象とする顧客や商品によって、検討の長さや購入後に確認すべき範囲は異なります。

BtoBの購買プロセスを可視化する目的

BtoBでは、商品を使う担当者と、費用を承認する人が異なる場合があります。例えば、利用部門は業務上の使いやすさを確認し、決裁者は導入の目的や費用を判断します。誰の判断が必要かは案件によって異なるため、一人の顧客だけを想定すると、検討が進まない理由を見落とす可能性があります。

購買プロセスを可視化する目的は、各担当者がどの段階で関わり、どの情報を必要とするかを捉えることです。例えば、資料請求があっても、社内で費用や運用方法を説明する材料が不足していれば、検討はそこで止まり得ます。顧客側の行動と判断材料を整理すると、マーケティング部門と営業部門が、どの接点で何を確認すべきかを共有できます。

カスタマージャーニーとマーケティング戦略の関係

マーケティング戦略では、対象顧客と提供価値を定めます。カスタマージャーニーは、その顧客が課題を認識してから利用に至るまでをたどり、提供価値が伝わる接点や、判断の妨げになる疑問を確かめるために使います。戦略で定めた「誰に何を提供するか」を、顧客の行動に照らして具体化する関係です。

例えば、対象顧客が比較検討時に社内説明用の情報を必要としているなら、製品の特長を伝えるだけでなく、費用や導入条件を確認できる情報が必要かを検討します。ただし、マップに記入した行動や課題がすべて事実とは限りません。顧客への聞き取りなどで確認できたことと、社内で立てた仮説を区別して扱います。

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

カスタマージャーニーマップは、対象顧客が課題を認識してから導入を判断するまでの行動や接点を、時間の流れに沿って整理するものです。まず対象と購買段階を決め、確認できた事実と仮説を分けて記入します。そのうえで、各段階の施策と検証方法を決めます。

目的と対象顧客を決める

最初に、マップを使って何を判断するかを決めます。例えば「資料請求後に商談へ進まない理由を調べ、対応を見直す」という目的なら、資料請求前後の情報収集や営業との接点を詳しく確認します。目的が曖昧なままでは、記入する情報を選べません。

次に、対象とする企業の業種・規模・抱えている課題と、購買に関わる担当者を定めます。同じ製品でも、初めて導入する企業と既存製品から切り替える企業では、確認する事項が異なります。一つのマップで扱う対象と判断したい課題を絞ることが、後の分析につながります。ペルソナの詳細が未確定でも、分かっている条件から着手し、不明点は仮説として残せます。

購買段階と関与する担当者を整理する

対象顧客が導入に至るまでの段階を、実際の購買の進み方に合わせて区切ります。BtoBでは、情報を集める人、製品を使う人、予算を承認する人が異なる場合があります。段階ごとに「誰が、何を判断するか」を記入し、担当者間で情報が引き継がれる場面も確認します。

横にスクロールして表全体を確認できます

購買段階 確認する判断 関与する担当者の例
課題の認識・情報収集 現状を変える必要があるか 現場担当者、部門責任者
候補の比較 自社の要件を満たすか 利用部門、情報システム部門、購買担当者
稟議・契約 費用や契約条件を承認できるか 決裁者、購買担当者、法務担当者
導入 利用を始めるために何が必要か 利用部門、導入担当者

この区分や担当者は固定ではありません。既存の商談記録や顧客への聞き取りと照らし合わせ、対象企業の購買プロセスに合わせて修正します。

顧客の行動・接点・課題を事実と仮説に分けて記入する

各段階について、顧客の行動、接点、その時点で知りたいこと、判断を妨げている課題を記入します。接点には、自社サイト、営業との面談、問い合わせ、提案資料などがあります。顧客が何を考えたかを、行動履歴だけから断定しないようにします。

記入する際は、商談記録や問い合わせ内容などで確認できた「事実」と、担当者の解釈である「仮説」を区別します。例えば「比較資料の送付後、返答がなかった」は記録で確認できれば事実ですが、「価格が高いため検討をやめた」は、顧客に確認できていなければ仮説です。仮説には確認方法も添え、事実として扱わないことが重要です。確認方法には、顧客への聞き取りや、該当する商談記録の確認などを設定します。

各段階の提供価値と施策を決める

整理した課題をもとに、その段階の顧客が判断するために必要な情報や支援を決めます。例えば、候補を比較する担当者に必要なのが機能の適合性を判断する情報なら、対応範囲と制約を確認できる資料を検討します。稟議で費用の説明が必要なら、見積もりの前提条件を明確にする対応が考えられます。

施策は、課題との対応関係を示して選びます。「比較時に確認できない項目がある」という課題に対し、「該当項目を資料に追加する」と記入すれば、何のために変更するかが分かります。課題が仮説にとどまる場合は、施策の実施前に確認するか、小さく試して反応を確かめます。実施の可否と優先順位は、得られた情報をもとに社内の担当部門が判断します。

KPI・担当・期限・検証条件を設定する

最後に、施策ごとにKPI(進み具合を確認する指標)、実行担当者、期限、検証条件を決めます。例えば、比較資料を見直す施策なら、「対象となる商談のうち、資料提供後に次の打ち合わせへ進んだ割合」を指標の候補にできます。ただし、その割合だけで資料の効果が出たとは判断せず、商談条件の違いや顧客からの反応も確認します。

検証条件には、対象とする顧客、集計期間、指標の数え方、結果を確認する日、継続・修正を判断する基準を記入します。データの定義や部門をまたぐ集計が難しい場合は、必要に応じて外部の専門家に設計や実行管理の支援を求めることもできます。ただし、結果を踏まえて施策を続けるか変更するかは、社内で判断します。

架空のBtoB企業で見るカスタマージャーニーマップの記入例

ここでは、承認ワークフローを提供する架空のA社が、顧客企業の購買プロセスを整理する例を示します。対象は、申請・承認を表計算ソフトとメールで管理している企業です。以下の顧客行動や課題はすべて説明用の仮説であり、A社の実際の顧客データや導入実績ではありません。

検討開始から比較・稟議・導入までの記入例

利用を検討する現場担当者だけでなく、予算を判断する責任者や、システムを確認する情報システム担当者も記入します。段階ごとに「誰が、何を判断するために、どの情報を必要とするか」を分けると、接点ごとの不足を確認できます。

横にスクロールして表全体を確認できます

購買段階 関与者と行動の仮説 想定される接点 顧客の課題の仮説 確認する資料・情報
検討開始 現場担当者が申請の進捗確認にかかる手間を感じ、管理部門の責任者に改善を相談する。 検索結果、課題解説記事、社内での相談 現行業務のどこに時間がかかっているかを説明できず、改善の検討が進まない。 顧客への聞き取り、現行の申請手順、問い合わせ時に挙がった課題
比較 管理部門の責任者が複数のサービスを比較し、情報システム担当者に運用上の確認を依頼する。 製品ページ、資料請求、商談、デモ 自社の承認経路に対応できるか、既存の業務やシステムとどう併用するかを判断できない。 商談での質問、資料請求後の問い合わせ、デモで確認された操作
稟議 管理部門の責任者が費用と導入目的を整理し、決裁者が投資の妥当性を判断する。 見積書、提案資料、社内稟議 費用に対して何を改善するのか、導入時に誰が何を担当するのかが明確でない。 稟議時の質問、見積条件、提案資料への修正依頼
導入 現場担当者と情報システム担当者が設定・試用を進め、管理部門の責任者が運用開始を判断する。 初期設定の案内、操作説明、サポート窓口 承認経路の設定方法や社内への周知方法が分からず、運用開始が遅れる。 初期設定時の質問、サポートへの問い合わせ、試用時の操作記録

表の「顧客の課題」は確認済みの事実として扱わず、顧客への聞き取りや商談記録と照合して更新します。たとえば比較段階で承認経路についての質問が多いかどうかは、質問の記録を確認するまで判断できません。

分析結果を施策に落とし込む記入例

次の表は、上記の仮説が検証対象になった場合の施策案です。A社が社内で実施を決めるための記入例であり、施策の効果を示すものではありません。担当者は、着手前に計測できるデータと現状値を確認します。

横にスクロールして表全体を確認できます

対象段階・提供価値 施策案 KPIと計測方法 担当・期限の例 検証条件
検討開始:現行業務の課題を整理できる 申請件数、確認方法、差し戻しの発生箇所を書き込める課題整理シートを用意する。 シート経由の相談件数。対象期間にシートを経由して届いた相談を、問い合わせ記録から数える。 マーケティング担当が公開前に計測方法を決める。 顧客への聞き取りで、課題を整理できないことが検討上の障害か確認する。公開後は相談内容を確認し、件数だけで施策を評価しない。
比較:自社の承認業務への適合を判断できる 承認経路の設定例と、デモで確認できる操作項目を資料にまとめる。 デモ後に適合可否を判断できた商談の割合。対象商談数を分母、判断結果を記録できた商談数を分子とする。 営業担当と製品担当が次回の資料改訂までに確認項目を整える。 比較段階で承認経路が判断材料になっているか商談記録で確かめる。デモ後に判断できなかった理由も記録する。
稟議:費用と導入体制を社内に説明できる 見積条件に加え、顧客側で必要な作業とA社の支援範囲を提案資料に明記する。 稟議中の追加質問の内容と件数。対象案件ごとに、同じ論点の質問が繰り返されていないか確認する。 営業責任者が次回の提案資料改訂時に反映する。 失注・保留案件も含め、資料不足が判断の障害だったかを確認する。質問件数の減少だけを受注への効果とみなさない。
導入:担当者が設定と社内周知を進められる 初期設定の手順と、利用者への案内文例を提供する。 契約から運用開始までの日数。運用開始の定義を決め、案件ごとに契約日と開始日を記録する。 導入支援担当が次回の導入案件から記録を始める。 遅れの理由を案件ごとに確認し、顧客側の承認待ちなど資料では解消できない要因を分けて見る。

施策を採用するかは、顧客への聞き取り結果、対応に必要な工数、計測できるデータを踏まえてA社の担当部門が判断します。現状値を確認する前に改善率を約束せず、何をもって仮説が支持されたと判断するかを先に決めます。外部専門家が加わる場合も、データの定義や部門間の記録の照合、検証方法の整理を支援し、施策の採否はA社が決めます。

実務で使えるテンプレートと運用のポイント

カスタマージャーニーマップは、顧客の動きを整理するだけでなく、どの課題に対応するかを社内で決めるために使います。購買段階ごとに同じ項目を記入し、確認できた事実と未検証の仮説を分けて管理します。

そのまま使える記入項目

以下の表を購買段階ごとに複製して使ってください。対象顧客が同じでも、利用部門の担当者と決裁者では関心や接点が異なるため、必要に応じて行を分けます。

横にスクロールして表全体を確認できます

項目 記入する内容 記入欄
対象顧客・関与者 対象とする企業の条件と、この段階で関わる担当者・決裁者 ____
購買段階・顧客の目的 現在の段階と、顧客が次に進むために判断したいこと ____
行動・接点 顧客の行動と、自社との接点。接点が確認できない場合はその旨 ____
確認できた事実・出典 商談記録、問い合わせ内容、顧客への聞き取りなどで確認した内容と確認日 ____
仮説・未確認事項 事実から推測した課題と、顧客に確認すべきこと ____
提供価値・施策 顧客の判断に必要な情報や支援と、それを届ける施策 ____
KPI・担当・期限 施策の進捗を確認する指標、実行責任者、実施期限 ____
検証条件・次の判断 何をいつ確認し、どの結果なら継続・修正・中止を判断するか ____

出典を示せない内容は事実欄に入れず、仮説欄で確認方法と併せて管理します。例えば「比較資料が不足している」という見立てだけで資料を制作せず、まず商談記録や顧客への聞き取りで、比較時に必要な情報を確かめます。

運用時は、営業やマーケティングなど関係部門の担当者が、商談で新たな判断理由が分かったときや施策の検証期限を迎えたときに記入内容を見直します。事実が変われば仮説と施策も更新し、変更日と判断理由を残してください。施策の採否は社内の責任者が決め、必要に応じて外部専門家にデータの定義や部門をまたぐ分析、検証設計、実行管理の支援を依頼します。

カスタマージャーニーマップに関するよくある質問

Qペルソナが決まっていなくても作れるか

A作れます。ただし、対象を「すべての顧客」とすると、誰の行動や課題を記入するのか判断できません。詳細なペルソナがなくても、対象企業の条件と、起点となる担当者の役割は仮に定めます。例えば、法人向けサービスを検討する企業の「情報収集を担当する現場責任者」を起点にし、稟議では決裁者も関わる、と範囲を明確にします。

その際、商談記録や顧客への聞き取りで確認できた内容と、「決裁者は費用対効果を重視するはず」といった仮説を混同しないようにします。役割ごとの課題や判断基準が不明な部分は仮説として残し、顧客への確認を通じて修正します。対象顧客が異なると分かった場合は、一枚のマップにまとめず、対象を分けて検討します。

まとめ

カスタマージャーニーは、顧客が検討を始めてから導入するまでの行動や接点、課題を時系列で捉える考え方です。マップを作る際は、まず目的と対象顧客を決め、BtoBでは購買に関わる担当者も整理します。

各段階で確認できた事実と仮説を分けて記入し、顧客の課題に対して提供する情報や施策を決めます。担当者、期限、KPI、検証条件まで設定すると、実行後に施策を見直せます。

ペルソナが固まっていない場合は、想定している顧客像を仮説として明記し、顧客への確認を通じて更新します。マップは作って終わりにせず、得られた事実に合わせて修正してください。

補足のよくある質問

Q部署や担当者ごとにマップを分けるべきですか

A一つの購買に複数の担当者が関わる場合は、役割ごとの行動と判断材料を分けて記録します。対象顧客や購買の流れが大きく異なる場合は、別のマップにすると課題を追いやすくなります。

Q作成後はいつ更新しますか

A新しい商談記録や顧客への聞き取りで見立てが変わったとき、または施策の検証期限を迎えたときに更新します。変更した事実と判断理由を残し、担当者と次の確認日を決めます。

参考資料