サービスブループリントは、サービスの全体構造を「顧客の行動」と「組織の内部プロセス」の両面から可視化するダイアグラムです。ユーザーが体験するフロントエンドと、その体験を支えるバックエンドの運営プロセスを一枚の図に統合することで、サービスの断絶箇所（ガップ）と改善機会を発見します。
起源：G. Lynn Shostack（1984）
サービスブループリントは、バンカーズ・トラストのマーケティング担当者だったG. Lynn Shostackが1984年に Harvard Business Review で発表した論文「Designing Services That Deliver」で初めて提唱されました。
Shostackの出発点は「サービスは製品と違い、設計図（Blueprint）がない」という問題意識でした。製品は工場の製造仕様書があり、品質の再現性が担保されます。しかし接客サービスや医療、教育などのサービスは、提供者と顧客の相互作用の中で毎回「生産」されるため、品質のばらつきが大きい。この問題を解くために、サービスのプロセスを可視化する設計図が必要だとShostackは主張しました。
その後、Mary Jo Bitnerらの研究者がフレームワークを体系化し、現在のサービスブループリントに発展しています。
5レイヤー構造
サービスブループリントは5つの水平レイヤーで構成されます。これらのレイヤーは時系列（左→右）に並んだサービスの流れの中で、それぞれ異なる視点からプロセスを記述します。
レイヤー1：Physical Evidence（物的証拠）
顧客が各ステップで触れる「モノ」のリストです。Webページ、看板、受付票、領収書、ユニフォーム、店舗の内装——サービスを「可視化」するすべての有形要素がここに記録されます。
サービスは無形であるため、顧客はしばしば物的証拠によって品質を評価します。ホテルの客室の清潔さ、弁護士事務所の内装の重厚さ、医院の待合室の明るさ——これらは治療や法律相談の「本質的な質」とは別に、体験の印象を決定します。
レイヤー2：Customer Actions（顧客の行動）
顧客がサービスを利用する過程で行う行動の時系列です。「予約する」「到着する」「注文する」「待つ」「受け取る」「支払う」「評価する」——というように、顧客の視点から一連の行動を記述します。
このレイヤーはユーザージャーニーマップの「行動レーン」に相当しますが、ブループリントではより簡潔に「何をするか」を記述することに集中します。
レイヤー3：Frontstage（フロントステージ）
顧客の目に見えるスタッフの行動と、顧客との直接的なインタラクションです。接客、案内、説明、提供——など、顧客との「接点」にある業務がここに属します。
カスタマージャーニーマップとサービスブループリントの最も重要な違いは、このレイヤーの存在です。ジャーニーマップが「顧客の体験」を描くのに対して、ブループリントは「それを提供しているスタッフが何をしているか」まで可視化する点が特徴です。
レイヤー4：Backstage（バックステージ）
顧客の目には見えないスタッフの行動と組織内部のプロセスです。料理の調理、システムへのデータ入力、在庫管理、スタッフ間の連絡——など、フロントステージを支えるすべての内部業務がここに記述されます。
バックステージは、しばしばサービスの「問題の本源」が隠れている場所でもあります。顧客から見えない部分で起きているプロセスの断絶や遅延が、フロントステージでの体験悪化として現れます。
レイヤー5：Support Processes（サポートプロセス）
Frontstage・Backstageのスタッフを支える組織インフラです。ITシステム、サプライチェーン、トレーニングプログラム、外部パートナーとの連携——など、サービス提供全体を下支えする仕組みがここに記述されます。
3本の分離線
5つのレイヤーは3本の「分離線」によって構造化されます。
可視の線（Line of Visibility）：Frontstage（顧客から見える）とBackstage（顧客から見えない）を分ける線。この線より上が顧客体験の領域、下が組織内部の領域です。
インタラクションの線（Line of Interaction）：顧客とスタッフが直接接触する境界線。顧客のサービス体験は、この線を越えるたびに形成されます。
内部インタラクションの線（Line of Internal Interaction）：FrontstageとBackstageを分ける線。このラインを越える連携がどれだけスムーズかが、バックステージの問題がフロントステージに影響するかを決定します。
作成手順
Step 1：サービスシナリオを定義する
どのサービス体験をブループリント化するかを決めます。「初めてUberEatsを使うユーザーが、ランチを注文して受け取るまで」のように、開始点と終了点を明確にします。
一つのブループリントに「すべてのシナリオ」を詰め込もうとすると複雑になりすぎます。対象ユーザーとシナリオを一つに絞ることが重要です。
Step 2：Customer Actionsを左から右に並べる
対象シナリオを歩く顧客の行動を、時系列で付箋に書き出します。この段階では完璧さより「大きな流れ」を掴むことを優先します。
Step 3：Frontstageを顧客の下に配置する
各顧客アクションに対応するスタッフの行動（または自動化されたシステムの反応）を記述します。「顧客がアプリで注文する」→「システムが注文確認メッセージを送る」というように対応させます。
Step 4：Backstageを可視の線の下に追加する
Frontstageの各ステップを支える内部プロセスを記述します。「注文確認メッセージを送る」を支えるバックステージには、「決済システムとの連携」「店舗への注文転送」「ドライバーへのマッチング」などが存在します。
Step 5：Physical Evidenceを最上段に配置する
各ステップで顧客が触れる「モノ」を上段に書き加えます。アプリのUI画面、プッシュ通知、配達員の外観と袋のデザイン、領収書——など。
Step 6：ガップ（断絶箇所）を特定する
完成したブループリントを眺めながら、「どこでフロントステージとバックステージの連携が断絶しているか」を特定します。情報が渡されない箇所、待ち時間が生じる箇所、顧客に不確実性が生まれる箇所がガップの候補です。
UberEatsへの適用例
UberEatsの「初回注文体験」をブループリントに落とすと、以下のガップが浮かび上がります。
ガップ1：配達状況の「最終1km」の不確実性。リアルタイムの位置情報は提供されますが、「いつ到着するか」の精度が低い時間帯があります。顧客は「近くにいるのに来ない」という不確実性の中でストレスを感じます。
ガップ2：配達完了通知と実際の受取のタイムラグ。「配達完了」の通知が来ても、実際にはドアの前に置かれているだけで顧客がそれを知らない場合があります（置き配の場合）。
ガップ3：問題発生時の解決フロー。注文が届かない、中身が違う、といった問題が生じたとき、誰に連絡すればいいか（ドライバー？店舗？UberEats?）が顧客に不明確です。
これらのガップは、ブループリントなしでは「なんとなく使いにくい」という感覚として分散して認識されます。ブループリントによって可視化することで、改善の優先順位と責任の所在が明確になります。
ジャーニーマップとブループリントの使い分け
| ジャーニーマップ | サービスブループリント | |
|---|---|---|
| 視点 | 顧客中心 | 顧客+組織の両面 |
| 感情の記述 | あり（感情の起伏を描く） | なし（行動の記述に集中） |
| 用途 | 共感フェーズの洞察整理 | サービス設計・改善の設計図 |
| 作成タイミング | 問題の発見・定義 | 解決策の設計・最適化 |
二つの手法は競合しません。ジャーニーマップで「どこに問題があるか」を発見し、ブループリントで「なぜその問題が起きているか」を診断するという組み合わせが最も効果的です。
参考文献
- G. Lynn Shostack, “Designing Services That Deliver”, Harvard Business Review, January–February 1984
- Mary Jo Bitner, Amy L. Ostrom & Felicia N. Morgan, “Service Blueprinting: A Practical Technique for Service Innovation”, California Management Review, Vol. 50, Spring 2008
- Marc Stickdorn & Jakob Schneider, This Is Service Design Thinking, BIS Publishers, 2011
- Jürgen Tangemann, “Blueprint It: Service Blueprinting Explained”, UX Collective, 2020