カスタマージャーニーとは：BtoBの購買段階ごとに必要なページの作り方

カスタマージャーニーとは、顧客が課題に気づいてから、調査や比較を経て購入や相談に進むまでの過程のことです。BtoBのサイトでは、各段階で発注者が何を確かめるかと、その答えを載せるページを対応させます。

最初に問い合わせ記録と、今あるページの一覧を開いてください。記事を増やす前に、相談までに聞かれた質問がどのページで読めるかを書き込みます。答えがあるのに見つからない箇所と、答え自体がない箇所を分けます。

AIに何を聞いて自社を探すかは相談段階と確認段階の問いの決め方⁠で扱っています。このページでは、調べ始めた人が社内で検討を進め、相談に至るまでのページを整理します。

購買段階とページは、どう対応させる？

樹脂部品の不具合に気づいた設計担当が、外部へ加工を相談する場面で考えます。次の表は設計用の例です。実際の顧客がこの順番で購入したという記録ではありません。

これは記事の配信予定表ではありません。各行に既存URLを入れ、質問に答えられていれば、そのページを使います。同じ仕様説明を段階の数だけ複製する必要はありません。

たとえば、不具合の原因を知った人が、すぐ発注できるとは限りません。材質、形状、加工の可否を確認してから、上司や購買担当へ説明することもあります。記事末の問い合わせボタンだけでは、その途中に必要な情報が欠けていないか確認できません。

課題に気づいた人へ、何を見せる？

技術記事では、読者が使っている現象の名前と確認方法から答えます。ヒケを調べる設計担当へ、冒頭から設備一覧を見せても、今の部品に関係があるかは判断できません。

記事に入れるのは、起きている現象、考えられる原因、確認に必要な条件です。個別の部品を見ずに原因を断定したり、自社に頼めば解決すると約束したりしません。公開できる根拠のある範囲を技術担当に確認します。

原因を説明した後には、関連する加工や材質のページへ案内します。読者が調べたいのは、自社の分類名ではなく、自分の課題の続きです。関連が薄い記事をまとめて並べず、次の確認に使うリンクを選びます。

比較する人には、仕様と事例をどう渡す？

仕様ページでは、対応材質、加工範囲、相談時に確認する条件を読み取れるようにします。公開できる確定値と、図面を見てから答える内容は分けます。未確定の範囲を、幅広く対応という一文で埋めません。

事例には、結果だけでなく依頼時の条件と、選んだ方法の理由を入れます。同じ不具合名でも条件が違えば、そのまま当てはめられないためです。事例の原稿を作る手順は課題解決事例の書き方⁠へ進めます。

比較する人が仕様から読み始めても、関連する事例と相談先へ進めるようにします。技術記事を入口と決めたからといって、全員を記事の冒頭へ戻す必要はありません。

仕様と事例で説明が違うなら、リンクを増やす前に修正します。過去の事例に書いた条件が現在も有効か、個別案件だけの条件だったかを社内で確認してください。

社内承認では、誰に何を説明する？

調査した人と、購入を承認する人が同じとは限りません。設計担当が加工の可否を判断できても、購買には供給条件、品質担当には検査の進め方などを確認されることがあります。

自社の問い合わせ記録から、実際に何が求められたかを拾います。部門ごとの一般的な人物像を作るより、どの資料を渡したときに検討が進んだか、何が足りず質問が戻ったかを調べてください。

会社概要は、この段階で提供元を確かめる材料になります。事業内容や相談先を仕様ページと一致させます。取引条件や保証に関する説明は、担当部署が承認した内容だけを載せます。

社内へ渡す資料には、比較の前提、未確定の条件、現行情報を確認できるURLを入れます。担当者が保存した資料だけ古いまま残ることも想定し、版と更新日を管理します。

ペルソナ設定は、問い合わせ記録からどう作る？

ペルソナは、サービスを利用する人の課題や行動をまとめた代表像です。BtoBのページ設計では、架空の名前や趣味を埋めるより、どんな仕事の責任を持ち、何を決められずにいる人かを整理します。

英国政府の体験マップ作成手順は、複数の利用者の経験を集め、共通する段階を見つける方法を示しています。異なる段階や手順を通る利用者は、別のマップに分ける考え方です。これは行政サービスの手順ですが、実際の記録から流れを作る点をページ設計にも使えます。

問い合わせ記録では、次を抜き出します。

• 相手の担当分野と、相談を始めたきっかけ
• 最初に使った言葉と、分からなかった条件
• 比較したい点と、社内で確認が必要だった点
• 最終的に依頼された返事と、検討が止まった理由

社内の整理でも必要な情報に絞り、記事へ問い合わせ原文や個人情報を転記しません。記録にない気持ちは推測として分け、追加の聞き取りで確かめます。

たとえば、図面が未完成の設計担当と、仕様が確定した購買担当を一人に混ぜると、フォームに必要な情報が決まりません。前者には相談の受付条件、後者には見積もりに必要な資料を示す、と役割を分けます。

マップを作ったら、どこから直す？

営業が繰り返し説明している情報から、既存ページを探します。掲載済みなら見出しや案内を直し、情報がなければ担当者へ確認して追記します。流れの図が完成したことを、サイトの改善完了にはしません。

私たちは暦の自社メディアで、検索語と本文を照合した際、読み方を知りたい検索に対する記載の不足を見つけました。出典はSearch Consoleと、2026年8月21日以降の作業記録です。持っている説明を、読者が探す問いとして出せていませんでした。

BtoBのページでも、資料が社内にあることと、発注者が読めることは別です。表の各段階にURLを入れた後、そのページだけで必要な条件が分かるかを読み直してください。

ページを足したら、その前の段階から進めるかまで点検します。新しい記事の確認だけで終えず、そこへ案内する製品ページや既存記事も開きます。

作業表には、段階以外に何を残す？

購買の段階を横に並べた図だけでは、修正する担当が決まりません。実務の表には、質問、答えの根拠、既存URL、不足、確認担当を残します。根拠を社内で確かめる欄と、読者が公開ページで確認する欄を分けてください。

たとえば、材質の比較から問い合わせへ進めない箇所を見つけたとします。最初に確認するのは、相談を受ける条件が未記載なのか、窓口へのリンクがないのかです。前者なら営業と技術担当へ条件を聞き、後者なら既存の窓口へ案内をつなぎます。どちらも、比較記事をもう一本作ることが答えにはなりません。

不明点が社内承認の場面に集中しているなら、記事の本数より共有する情報を見直します。仕様の根拠や、相談後の進め方を、調査した担当者以外も読める場所へ置きます。問い合わせ記録でその質問があったかを確認し、図の空欄を埋めるためだけの資料は作りません。

変更する箇所には、確認を依頼する日と公開する日を記します。判断が必要な条件は、文章を整える担当だけで確定しないようにします。表を作った後に担当者が交代しても、なぜその説明を置いたか追える状態を残します。

問い合わせまでの流れを、どう確かめる？

技術記事から仕様、事例、会社概要、相談窓口へ実際に進みます。資料を読んだ人がフォームで同じ情報を探し直したり、何を相談できるか分からなくなったりする箇所を記録します。

図面がないと相談できないのか、最初は課題だけでよいのかを送信前に伝えます。窓口の項目や完了までの確認は問い合わせ導線の作り方⁠で扱っています。

公開後は、閲覧の多さだけでマップの正しさを判断しません。営業に届いた質問が変わったか、社内承認用の資料が足りたかを聞き、表の不足を更新します。展示会や営業を含む分担はBtoBマーケティングの進め方⁠で整理できます。

オウンドメディアの構築と運用⁠を依頼する際は、記事の希望本数と一緒に、相談前に繰り返される質問を渡してください。ページを増やすべき場所と、今ある説明を直す場所を分けて決められます。

出典の確認日：2026年10月23日⁠。