服務藍圖 Service Blueprint

什麼時候該用它？

User Journey Map 只畫使用者看到的那一面。但產品體驗不好，問題通常出在使用者看不到的後台。服務藍圖把前台和後台攤開在同一張圖上，讓你看到「使用者等了 3 秒」背後是「系統跑了 5 個 API call + 2 次資料庫查詢 + 1 個人工審核」。

• 服務體驗斷裂：使用者抱怨某個環節很卡，但團隊找不到問題在哪裡
• 跨部門協作不順：前端、後端、客服、物流各做各的，沒有人看全貌
• 新服務設計：從零設計一個涉及多個觸點的服務流程（線上到線下、App 到門市）
• 數位轉型：把線下服務搬到線上，需要釐清哪些流程可以自動化、哪些必須保留人工
• 效率優化：找出服務流程中的瓶頸、冗餘、等待時間過長的環節

框架結構

服務藍圖是一張橫向的流程圖，縱向分成五個泳道（swim lane），由三條關鍵分隔線劃分。

五個泳道

1. 實體證據（Physical Evidence）

使用者在每個觸點看到、摸到、收到的東西。網站介面、App 畫面、收據、包裹、門市裝潢。這些「實體證據」塑造了使用者的第一印象。

2. 顧客行為（Customer Actions）

使用者實際做的每一個動作。搜尋商品、加入購物車、輸入地址、等待出貨、拆包裹、寫評價。這一層基本上就是 User Journey。

3. 前台互動（Frontstage Actions）

使用者能直接感知到的服務人員或系統行為。客服回覆、推播通知、出貨通知、退貨處理回信。使用者知道有人（或系統）在服務他。

4. 後台行為（Backstage Actions）

使用者看不到但直接支撐前台的活動。倉庫揀貨、風控審核、推薦演算法運算、庫存同步。這些是讓前台能順利運作的幕後功夫。

5. 支援流程（Support Processes）

支撐後台運作的系統和流程。ERP 系統、物流串接、金流處理、資料庫維護。離使用者最遠，但一出問題影響最大。

三條分隔線

• 互動線（Line of Interaction）：顧客行為與前台之間。跨過這條線 = 使用者跟服務產生了接觸
• 可見線（Line of Visibility）：前台與後台之間。這條線以下的東西，使用者看不到
• 內部互動線（Line of Internal Interaction）：後台與支援流程之間。跨部門、跨系統的銜接點

標註項目

在藍圖上標註：

• 等待時間：使用者在每個步驟要等多久
• 失敗點：哪些環節最容易出錯（用 ✗ 或紅色標記）
• 關鍵時刻：哪些觸點對使用者滿意度影響最大（用 ★ 標記）

來源與歷史

• 1984：G. Lynn Shostack 在 Harvard Business Review 發表〈Designing Services That Deliver〉，首次提出服務藍圖概念，主張服務設計需要像工程藍圖一樣精確
• 1992：Mary Jo Bitner 在 Journal of Marketing 擴展 Shostack 的模型，加入「實體證據」層和三條分隔線，形成現代服務藍圖的標準格式
• 2008：服務設計社群（如 Service Design Network）將服務藍圖納入核心工具，與 Customer Journey Map 並列為服務設計雙璧
• 2016：Nielsen Norman Group 發表服務藍圖實務指南，推動 UX 團隊將服務藍圖納入日常設計流程
• 至今：在 OMO（Online Merge Offline）趨勢下，服務藍圖成為整合線上線下體驗的必備工具

真實案例：星巴克行動點餐的服務藍圖

星巴克 2015 年推出 Mobile Order & Pay 時，服務藍圖發揮了關鍵作用：

問題：使用者用 App 點完咖啡到門市取，結果發現還是要排隊等 10 分鐘。行動點餐的價值瞬間歸零。

服務藍圖拆解：

解法：藍圖讓團隊看到問題不在 App（前台），而在門市動線（後台）。他們設立了獨立的 Mobile Order 取餐區、調整 POS 系統讓行動訂單優先製作、並在 App 上加入即時製作進度通知。

數據成果：優化後，行動訂單佔美國門市交易量的 26%（2023 年），平均取餐等待時間從 10 分鐘降到 3-5 分鐘，行動訂單使用者的消費頻率比一般使用者高 2.4 倍。

使用步驟

Step 1：選定服務場景

挑一個完整的服務場景（例如：使用者從搜尋商品到收到包裹）。範圍太大會失焦，太小會看不到全貌。

Step 2：畫出顧客行為

先畫最上面那條線 — 使用者做了什麼。從頭到尾走一遍，不要遺漏任何步驟。建議找真實使用者做一次 walkthrough。

Step 3：補上前台與後台

順著每個顧客行為，往下問：「這個動作背後，前台做了什麼？後台做了什麼？支援系統做了什麼？」找各部門的人一起填，PM 自己填一定會漏。

Step 4：標註問題點

在藍圖上標出等待時間、失敗點、關鍵時刻。用紅色標記痛點，用綠色標記做得好的地方。

Step 5：找出優化機會

看整張藍圖，找出：等待時間最長的地方、失敗率最高的環節、後台可以自動化的流程。優先處理「使用者感受最痛 + 改善成本最低」的項目。

這樣做 vs 避免這些

這樣做

• 讓真正執行服務的人參與繪製 — 客服、倉管、店員，他們知道實際流程跟 SOP 差多少
• 用真實數據標註 — 「平均等待 47 秒」比「等了一下」有用太多
• 從使用者最痛的場景開始畫 — 不要從「一切順利」的 happy path 開始
• 把藍圖貼在辦公室牆上 — 讓所有人都能看到全貌，跨部門溝通效率會大幅提升

避免這些

• 不要畫成理想流程 — 要畫「現在實際是怎樣」，不是「我們希望怎樣」
• 不要只有 PM 自己畫 — 你不知道倉庫的揀貨流程，你以為 3 分鐘的事情實際要 30 分鐘
• 不要把每個微小步驟都放進去 — 粒度太細會讓藍圖變成天書，抓大放小
• 不要畫完就放著 — 藍圖的價值在於「找到問題並改善」，不在於「畫了一張很漂亮的圖」