服務藍圖

一句話定義

服務藍圖是從服務提供者角度,把使用者活動、前台互動、後台工作與外部支援流程放在同一張流程圖上,檢查服務如何被交付、哪裡斷裂、哪裡可系統化或自動化的服務設計工具。

核心要點

從「使用者怎麼走」轉到「服務怎麼被交付」

顧客旅程地圖 主要看使用者在時間軸上的行為、想法、感受與痛點;服務藍圖 則把這條旅程往下展開,追問每個接觸點背後有哪些前台、後台與支援流程在運作。

因此服務藍圖常把 journey map 搬到最上方,再往下接:

層次問題
使用者活動使用者在每個階段做什麼?
接觸點 / 前台互動使用者看得到什麼人、介面、通知、配送或客服?
後台工作使用者看不到,但服務團隊必須做什麼?
支援流程哪些第三方系統、供應商、技術或組織外流程支撐服務?

三條基準線

2026-05-06-Unblock-服務設計入門-Ep3-Service-Blueprint-Ecosystem-Map 將服務藍圖拆成三條線:

基準線上方下方判斷意義
互動線(Line of Interaction)使用者 / 消費者活動服務提供者活動使用者在哪些節點開始與服務發生互動
可見線(Line of Visibility)使用者看得見的前台工作使用者看不見的後台工作哪些工作是體驗的一部分,哪些工作是幕後支援
內部互動線(Line of Internal Interaction)服務提供團隊內部活動第三方系統、供應商、外部團隊或組織外流程服務是否依賴外部資源與跨組織協作

三條線的價值,是把「使用者覺得順不順」拆回「前台承諾、後台準備、外部支援是否接得上」。

使用時機

  • 服務效率不佳:流程中有人重工、等待、轉交不清、通知落空,或不同部門各自優化但整體變慢。
  • 使用者體驗已相對完整,但內部體驗很痛苦:服務表面看起來可用,但員工、客服、營運或供應商用大量人工補洞。
  • 想找系統化 / 自動化機會:藍圖能顯示哪些節點可由系統通知、資料串接、標準流程或新科技承接。
  • 需要打破部門各自為政:當每個部門只看自己的局部 KPI,服務藍圖能讓整體交付鏈被共同看見。

標示缺口與互動方向

服務藍圖不只是靜態分層,也要標出互動方向:

  • 單向箭頭:通知、派送、資料傳送、任務移交。
  • 雙向箭頭:客服問答、需求確認、問題回報與修正。
  • 缺口 / 風險標記:流程斷點、資訊不一致、責任不清、使用者看得到但後台支援不足的地方。

藍圖要服務使用者與團隊,不是照抄模板

2026-05-06-Unblock-服務設計常見誤區指南 提醒,設計文件製作前要先確認最終使用者是誰、他們會如何使用,以及這份文件相對其他設計工作的 CP 值。服務藍圖尤其需要這個判斷,因為它可能同時服務流程改善、跨部門溝通、自動化評估與責任分配。

若藍圖只是把模板欄位填滿,卻沒有對應真實使用者活動、前台承諾、後台工作與外部支援,就只是流程版面;有價值的藍圖應該讓團隊能看見斷點、討論責任、提出替代流程,並持續接受利害關係人的回饋。

與其他概念的關係

  • 服務設計 — 服務藍圖是服務設計四工具線中的第三步,回答「服務如何被交付」。
  • 顧客旅程地圖 — 旅程地圖提供使用者活動層;服務藍圖把每個旅程節點往下接到前台、後台與支援流程。
  • 生態系統圖 — 生態系統圖先看服務裡有哪些角色與交換關係;服務藍圖再看這些元素如何沿流程串接。
  • 使用者體驗設計 — UX 關注使用者感受;服務藍圖提醒設計師,感受常由看不見的流程、系統與組織協作間接塑造。
  • 利害關係人管理 — 服務藍圖會暴露哪些團隊、供應商或系統影響交付,後續仍需要利害關係人對齊與責任分配。
  • 最後一哩 — 最後一哩問題常不是單一介面錯,而是前台承諾、後台流程與外部交付沒有接上。

相關來源

備註

  • 本頁目前以 Unblock 服務設計入門影片為主來源。未來若 ingest NN/g / Service Design Tools / This is Service Design Doing 等來源,可補入服務藍圖標準格式、physical evidence 層、fail point / wait time / metric 標記法與 workshop 操作步驟。