申込フォームを短くしたのに、契約までの日数が変わりません。営業資料を増やしたのに、トライアル開始後の問い合わせが減りません。顧客に見える画面や説明だけを直しても、裏側の審査、データ連携、担当者間の引き継ぎが詰まっていれば、体験は良くならないからです。
サービスブループリントとは、顧客体験と提供側の業務を同じ時間軸に置き、接点の裏側まで可視化する図です。顧客が止まる場面と業務上の原因を切り分け、誰が何を検証するかまで決めます。この記事では、5層の構成要素と8段階の書き方を押さえたうえで、BtoB SaaSの架空例、改善課題の選び方、更新方法までを扱います。
サービスブループリントとは何か
サービスブループリントは、顧客が取る行動と、サービス提供者の表側・裏側の活動、支援業務、顧客が触れる証拠を時系列で対応させる図です。
G. Lynn Shostackが1984年にHarvard Business Reviewで発表した「Designing Services That Deliver」は、サービス提供プロセスを図示し、顧客から見える活動と見えない活動を分けて設計する考え方を示しました。Nielsen Norman GroupのSarah Gibbonsによる2017年の解説では、サービスブループリントを、特定のカスタマージャーニーに結び付く人、物、過程の関係を可視化する図として説明しています。
顧客体験だけを見ていると、「説明が分かりにくい」「待ち時間が長い」といった現象が表に出てきます。ただし、その原因が営業担当者の説明不足なのか、承認ルールなのか、システムの権限設定なのかまでは分かりません。サービスブループリントは、顧客から見える現象と提供側の工程を同じ横軸に置き、原因候補を調べられる形へ変えます。
横軸には、顧客が目的へ進む場面を置きます。たとえばBtoB SaaSなら、「候補を調べる」「資料を請求する」「担当者へ相談する」「試用する」「社内審査を通す」「契約する」「初期設定する」といった流れです。縦軸には顧客行動、顧客から見える対応、その裏で行う作業、支援するシステムや部門を並べます。
カスタマージャーニーマップとの違い
Nielsen Norman GroupのKate Kaplanは2016年の解説で、カスタマージャーニーマップを、ある目標を達成するために人がたどる過程の可視化と位置づけています。カスタマージャーニーマップは顧客の行動、接点、思考、感情、障壁を中心に描き、サービスブループリントは顧客側の流れに提供側の活動と依存関係を重ねます。どちらか一方を選ぶ関係ではありません。顧客の停滞点が見えた後、その停滞を生む業務工程まで調べたいときに、サービスブループリントへ展開します。
次の表は、BtoB新規事業の作成会議で使う観点別の比較です。
比較する観点 | カスタマージャーニーマップ | サービスブループリント |
|---|---|---|
主に見る対象 | 顧客の行動、判断、感情、接点 | 顧客行動とサービス提供業務の対応 |
発見したいこと | 顧客がどこで迷い、何を求めるか | どの業務、担当、システムが体験へ影響するか |
主な参加者 | 顧客調査、企画、マーケティング | 企画、営業、開発、運用、審査、顧客対応 |
更新のきっかけ | 新しい顧客事実、行動変化 | 顧客事実に加え、業務手順、役割、システムの変更 |
顧客一人の内面を詳しく掘るなら、共感マップも使えます。三つの図は対象範囲が違うため、問いに合わせて分けます。
サービスブループリントの構成要素
サービスブループリントを構成するのは、顧客行動、表側の活動、裏側の活動、支援業務、物的証拠の5層です。
Gibbonsによる2017年の解説は、利用者の行動、顧客から見える活動、顧客から見えない活動、支援プロセス、物的証拠を主要な構成要素として示しています。担当者、利用システム、所要時間、証拠の状態は、目的に応じて補助欄へ追加します。
層 | 書く内容 | BtoBでの記入例 |
|---|---|---|
顧客行動 | 顧客が目的のために実行すること | 比較する、相談する、試用する、稟議を作る |
表側の活動 | 顧客から見える人・画面・通知の対応 | 営業面談、デモ、申込画面、案内メール |
裏側の活動 | 顧客には見えないが、表側を成立させる作業 | 見積承認、アカウント発行、引き継ぎ、個別設定 |
支援業務 | 複数の場面を支える部門・仕組み・ルール | 契約審査、顧客管理、請求、権限管理、商品情報管理 |
物的証拠 | 顧客が見聞きし、判断材料にするもの | Webページ、資料、メール、画面、契約書、請求書 |
Gibbonsの解説では、顧客との相互作用、顧客から見える範囲、内部の相互作用を区切る境界線が示されています。境界線は、責任範囲を確定する規則ではなく、受け渡しを見つける補助線です。営業から導入担当へ要件を渡す、審査結果を顧客へ戻す、といった箇所へ担当、手段、必要情報を書きます。所要時間は実測値と目標値を分け、記録がなければ「未確認」とします。
作成前にサービスブループリントの対象と粒度を決める
サービスブループリントを描く前に一文ずつ固定するのは、対象顧客、扱う場面、開始点と終了点、作成後に決めることです。
「自社サービス全体」を一枚で描こうとすると、資料請求、契約、導入、利用、更新の情報が横に伸び、誰も全体を確認できなくなります。最初は一つの判断に必要な範囲へ切ります。契約率を調べるなら比較開始から契約判断まで、利用定着を調べるなら初期設定から最初の業務完了まで、といった区切り方です。
作成前に、次の項目を短く決めます。
- 対象顧客：業種や企業規模だけでなく、利用者、導入推進者、決裁者、審査担当者など役割まで書く
- 対象場面：顧客が何を始め、何を終えようとしているかを定める
- 開始点と終了点：今回の図に含める最初と最後の出来事を置く
- 判断したいこと：改善する接点、調べ直す仮説、変更する業務の候補を明記する
- 参加者と材料：表側・裏側・支援業務の担当者を集め、顧客インタビュー、問い合わせ、操作記録、業務手順などを確認する
BtoBでは「顧客企業」を一人にしません。利用者、導入推進者、決裁者、審査部門では行動も判断材料も異なるため、役割が入れ替わる箇所を示します。社内記録から確認した事実、担当者の解釈、未確認の仮説にも別の印を付けます。顧客の発言や行動を取り直すときは、顧客インタビューで事実を確認し直します。
サービスブループリントの書き方
サービスブループリントは、顧客行動から書き始め、表側、裏側、支援業務、物的証拠を対応させ、最後に受け渡しと未確認箇所を検証課題へ変えます。
白紙から部門別の業務を書き始めると、既存組織の説明図になりがちです。起点は顧客が終えようとしている仕事です。以下の順に作成します。
- 作成後の判断を一文にする。 「体験を改善する」ではなく、特定する原因候補と次の検証を明記します。
- 顧客行動を時系列に並べる。 施策名ではなく、「相談する」「申請する」「設定する」と顧客の動詞で書きます。
- 物的証拠を対応させる。 顧客が見る画面、資料、メール、契約文書を置きます。
- 表側の活動を書く。 営業、サポート、画面、通知など、顧客が直接見聞きする対応を結びます。
- 裏側の活動を書く。 承認、審査、入力、発行、引き継ぎなど、表側を成立させる作業を置きます。
- 支援業務を書く。 法務、経理、開発、顧客管理、請求、権限ルールなどの依存先を置きます。
- 受け渡しと例外を確認する。 誰が誰へ、何を、どの手段で渡すかを示し、差し戻しや二重入力も残します。
- 未確認箇所を検証計画へ変える。 顧客への影響、確認方法、担当者、期限、判断者を決めます。
一度に理想の業務へ書き換えません。最初に描くのは現在の状態です。現状と理想を同じ図に混ぜると、実際に起きている問題と提案が見分けられなくなります。現状版を確認した後、変更案だけを複製した将来版へ反映します。
空欄は、そのまま調査対象です。裏側の作業を誰も説明できない、転記理由が分からない、通知条件が担当者によって違うなら、推測で埋めず確認相手を決めます。
BtoB SaaSを想定したサービスブループリント作成例
BtoBの作成例では、顧客担当者の試用開始から初回設定までを切り出すと、営業、審査、導入支援、システムの受け渡しを具体的に確認できます。
以下は、業務申請を管理する架空のSaaSを想定した例です。対象は導入推進者、開始点は営業担当者との相談、終了点は利用部門が最初の申請を完了する時点とします。
層 | 相談・要件確認 | 試用申込 | 審査・初期設定 | 最初の申請 |
|---|---|---|---|---|
顧客行動 | 現行業務を説明し、試したい範囲を決める | 申込情報を入力し、関係者へ共有する | 審査質問へ回答し、管理者設定を行う | 利用者へ案内し、申請を試す |
表側の活動 | 営業が画面を説明し、確認事項を記録する | 申込画面が受付結果と次の手順を示す | 導入担当が審査項目と設定方法を案内する | 画面が入力内容と承認状況を表示する |
裏側の活動 | 営業記録を導入担当へ引き継ぐ | 申込情報から試用環境を発行する | 回答内容を確認し、権限と初期データを設定する | 問い合わせを分類し、必要な修正を担当へ渡す |
支援業務 | 顧客管理、商品情報、説明資料の更新 | アカウント管理、利用条件、通知設定 | 契約・情報管理の確認、権限管理、導入手順 | 問い合わせ管理、利用記録、障害対応 |
物的証拠 | 面談資料、確認メモ、デモ画面 | 申込画面、受付メール、利用条件 | 質問票、案内メール、管理画面 | 操作画面、通知、ヘルプ、問い合わせ返信 |
この表だけでは、問題があるとは断定できません。たとえば「申込後に試用環境が届かない」という顧客の訴えがあった場合、受付メールの送信、環境発行、メール到達、管理者の社内共有のどこで止まったかを調べる必要があります。サービスブループリントは、原因を一つに決めるのではなく、確認すべき工程を並べます。
BtoBでは審査と承認を省きません。導入推進者が説明資料を作れない、情報システム部門が確認事項を解消できない、といった停滞もあります。自社版では直近の一件を選び、実際の顧客行動、担当作業、画面や文書へ差し替えます。架空例は事実確認の代わりになりません。
サービスブループリントから改善課題を決める
改善課題は、顧客への影響が確認でき、提供側の原因候補を調べられ、変更後の判断方法まで置ける箇所から選びます。
図に赤い付箋が多い場所を、そのまま最優先にしてはいけません。目立つ接点が原因とは限らないからです。顧客が止まった場面、困った内容、発生条件を確認し、その場面に対応する表側、裏側、支援業務をたどります。
課題候補は、次の観点で比較します。
判断観点 | 確認する問い | 残す材料 |
|---|---|---|
顧客への影響 | 顧客は何を完了できず、どんな代替行動を取ったか | 発言、行動、問い合わせ、離脱した場面 |
発生条件 | どの顧客、役割、場面で起きたか | 対象条件、取得日、利用環境 |
原因候補 | 表側、裏側、支援業務のどこに依存するか | 業務記録、担当者確認、システム記録 |
変更可能性 | 誰が何を変更でき、他工程へ何が波及するか | 責任者、依存先、例外処理 |
検証方法 | 変更後に何を観察すれば判断できるか | 対象、方法、判定条件、確認日 |
たとえば、顧客が試用開始前に止まった状況です。「申込画面を改善する」と先に決めず、入力項目の意味、社内審査に必要な情報、受付後の案内、環境発行、メール到達、社内共有を分けて確認します。原因候補を絞ったら、どの工程を変え、顧客のどの行動を見るのかを対応させます。
図から分かるのは、確認済みの事実、依存関係、次に調べる箇所です。事業仮説の継続、変更、保留まで決める場合は、検証仮説の判定へ進みます。
サービスブループリントを作って終わりにしない更新方法
サービスブループリントを運用するには、顧客行動、業務手順、担当、システムのいずれかが変わった時点で、根拠と変更理由を付けて更新します。
料金、契約、画面、通知、担当分担が変われば、顧客行動と裏側の工程も変わります。更新の引き金と責任者を決め、変更前後を追える状態にします。
機能しにくい書き方は、次の通りです。
- 顧客行動ではなく自社施策を横軸にする：広告、営業、サポートという部署名を、顧客の動詞と目的へ戻す
- 理想の業務だけを書く：現在の手作業、個別対応、差し戻しを消さず、将来版と分ける
- 複数の顧客役割を一人へまとめる：利用者、推進者、決裁者、審査部門の行動と判断材料を分ける
- 表側の担当者だけで作る：裏側の処理、システム、ルールを説明できる担当者を参加させる
- 感想で優先順位を決める：顧客への影響、発生条件、原因候補、確認方法をそろえる
- 空欄を推測で埋める：分からない箇所は［未確認］として、確認相手と方法を記載する
更新履歴には、更新日、変更した箇所、得られた事実、根拠、判断した人、次の確認を残します。顧客から新しい発言を得たときは、発言した事実と客観的な業務実態を分けます。担当者が「毎回行っている」と話しても、記録で確認できないなら位置づけは本人報告です。
定例会議では、変更があった場面と前後の受け渡しを確認します。管理者は、顧客事実、業務変更、担当、検証結果の対応を保ちます。
まとめ｜サービスブループリントで顧客体験と提供業務を一緒に直す
サービスブループリントの価値は、顧客の停滞を接点だけの問題にせず、裏側の業務、支援部門、システムまでたどって次の検証を決められることです。
作成時は、対象顧客、場面、開始点と終了点、作成後の判断を固定します。顧客行動から書き始め、物的証拠、表側の活動、裏側の活動、支援業務を対応させます。現状と理想、確認済みの事実と仮説も分けて書きます。
BtoBサービスでは、利用者だけでなく、導入推進者、決裁者、審査部門の行動を扱います。営業から導入、審査から契約、問い合わせから開発といった受け渡しを明記すれば、顧客から見える問題と提供側の原因候補を同時に確認できます。
顧客行動、表側、裏側、支援業務、物的証拠を一つの場面に対応させ、受け渡し、未確認箇所、改善課題、更新履歴を残せる形にすれば、サービスブループリントは作成会議と改善判断の共通資料になります。