要用 AI 建立服務藍圖，先由一項範圍明確的服務和經核實的旅程證據出發，再把客戶動作、前台互動、後台工作、支援流程、系統、證據、交接和負責人分層對齊。讓假設一直清晰可見：一個聽來合理的後台故事，並不是觀察到的流程。

以負責任的 AI 流程整理紀錄、質疑缺口。實際發生了甚麼，必須由服務負責人和實際執行工作的人確認。

關鍵要點

旅程圖以用戶體驗為中心；服務藍圖把這種體驗與交付連繫起來。

先固定服務範圍、角色、情境、渠道以及起點和終點。

在客戶可見的活動與內部活動之間畫出可見線。

每項後台主張都要附上證據、負責人或假設狀態。

覆核交接、輪候、失敗點和恢復，而不只是順利路徑。

用 AI 建立服務藍圖會帶來甚麼不同？

體驗圖或旅程圖整理的是用戶隨時間推移所做、所遇、所想或所需。GOV.UK 建議團隊按研究繪製體驗圖，用它理解整體體驗，而不是孤立的接觸點。［1］服務藍圖則加上產生這些接觸點的營運層：前台人員或介面、後台操作、支援流程、系統、政策、證據、負責人和交接。

問題	旅程圖	服務藍圖
主要角度	用戶體驗和目標	服務如何交付這種體驗
典型證據	研究觀察、引述、行為、需要	旅程證據，加上流程、系統、政策和營運紀錄
主要行	階段、動作、接觸點、需要、痛點	客戶、前台、後台、支援、系統／證據、失敗
主要邊界	用戶由始至終的問題	一個界定清楚的服務交付範圍
決策負責人	研究和產品團隊	服務、營運、技術、政策和支援負責人

不要以一張內部流程圖取代客戶旅程圖。把旅程作為一項承載證據的輸入，再以藍圖把它與交付連繫起來。

如何確定服務範圍和證據？

步驟 1：寫清服務範圍

界定一個情境、角色、渠道組合、觸發條件、結果和時間邊界。「客戶支援」太籠統；「現有帳戶持有人經網上聊天報告一筆不認識的扣款，收到個案決定，並看到帳戶已更新」才可以檢驗。

記錄：

藍圖 ID、版本和負責人；
目標用戶或角色，以及經核實的需要；
起始觸發條件和期望結果；
開始和結束事件；
渠道、地點和相關變體；
納入和排除的服務組成部分；
來源旅程圖的版本和研究參考；
覆核參與者和決策權限。

GOV.UK 有關「完整問題」的指引要求團隊理解用戶最終想做成甚麼，包括超出某一機構服務範圍的互動。［2］以這種較寬的角度識別依賴關係，但不要悄悄擴大一張藍圖，直至它試圖代表所有可能的旅程。

步驟 2：先建證據登記表

為訪談、觀察筆記、分析資料、客戶支援紀錄、SOP、系統文件、政策、培訓資料和員工走查建立穩定的證據 ID。每一項都記錄來源、版本或日期、確切位置、適用的渠道或個案類型、負責人、存取邊界和覆核狀態。

區分四種狀態：

Observed：有用戶或營運證據直接支持。
Confirmed：經問責的流程負責人確認。
Assumption：看似合理，但有待確認。
Conflict：來源之間不一致，或做法各有不同。

AI 不得因為好幾個人都這樣說，便把假設升格為事實。重複可能只顯示某種看法很普遍，而不是系統的實際行為。把資料交給模型之前，盡量減少個人和機密資料；NIST 把私隱、虛構內容、資訊完整性和人機配置列為生成式 AI 的風險。［4］

如何繪製客戶動作和前台互動？

步驟 3：建立客戶動作時間軸

由有旅程證據支持的客戶動作開始。每一欄放一個可觀察的動作或有意義的等候狀態。使用「提交」「等候」「收到」「查看」「重試」之類的動詞，而不是「互動」這類籠統的階段。

每一欄記錄觸發條件、動作、渠道、預期結果、證據 ID、不確定性和下一個事件。研究顯示有放棄、重複嘗試、轉換渠道和等候時，亦要納入。這些時刻往往能揭示順利路徑流程圖所掩蓋的營運問題。

如果沒有旅程圖，不要讓 AI 虛構一張作為臨時框架。進行或取得適當的研究，再建立一份可追溯的旅程。臨時藍圖可以列出明確的研究缺口，但不應把想像出來的行為當作事實呈現。

步驟 4：在可見線上方添加前台互動

前台活動是客戶能夠感知的內容：員工對話、訊息、表格、狀態、實物、通知或可見的介面回應。把這些操作放在它們所支援的客戶步驟下方。

每個前台儲存格記錄：

執行者或介面負責人；
動作和渠道；
輸入和輸出；
客戶看到的服務證據；
經核實的回應時間或政策要求（如有）；
無障礙或協助服務的途徑；
失敗訊號和恢復路徑；
來源和狀態。

在客戶動作與前台操作之間畫出互動線，在前台一欄下方畫出可見線。可見線以下的內容，客戶無法直接看到，儘管其結果可能稍後才顯現。

不要按面向客戶的訊息推斷員工做了甚麼。一則「已批准」的通知，並不能證明是哪個團隊、哪條規則、哪個系統或哪次審核產生了它。在營運證據確認其機制之前，把它保留為未知。

如何繪製後台與支援工作？

步驟 5：只按證據繪製後台工作

後台工作包括直接支援某個前台互動的內部決定、準備、分派、檢查、轉換和異常處理。與實際執行流程的人一同訪談或走查。把政策的規定與個案、日誌和員工描述比較。

使用 action ID、trigger、performer、input、rule、system、output、handoff、queue、time、evidence ID、status 和 exception 等欄位。某個欄位未知，便保持未知，並指定一名核實負責人。

AI 提示可以穩妥地守住這條邊界：

只把所提供的證據整理進藍圖結構。讓客戶、前台、後台、
支援、系統、證據和失敗各欄保持分開。
不要推斷隱藏的工作、負責人、系統、規則、次序、時間或因果關係。
無根據的儲存格標為 Assumption，來源衝突標為 Conflict。
傳回沒有著落的證據和欠缺的交接，交由人手覆核。

英國教育部發佈過一個建立服務藍圖的例子，用來理解一項服務，並讓工作在各團隊之間變得可見。［3］以例子學習方法，而不要把它當作證明你的機構亦有同樣欄目或角色的證據。

步驟 6：添加支援流程、系統和規則

支援流程為交付提供條件，但不一定與某個客戶步驟一一對應：編更、採購、身份管理、資料維護、培訓、合規審查、供應商營運和平台可靠性。把它們放在獨立的一欄，以免藍圖暗示它們與客戶直接互動。

加入一欄「系統與證據」，列出應用程式、紀錄、訊息、文件、實物和控制證據。只有經核實，才寫明權威紀錄系統。把渠道與系統分開：電郵可能負責傳遞通知，而個案平台才掌握狀態。

政策和業務規則應寫明負責人、版本、適用範圍和位置。從舊 SOP 抄來的規則不一定仍然有效。有關職責的問題，先連繫到利益相關者地圖；當某項具體決定或交付成果需要明確問責時，再使用 RACI 矩陣。

如何表達交接與恢復？

步驟 7：把交接寫成事件

當職責、資料、工作或狀態在人員、團隊、系統、供應商或渠道之間轉移，便發生了交接。把它畫成一個事件，而不是一支沒有標示的箭嘴。

記錄：

交接欄位	覆核問題
發送方和接收方	雙方是否都是具名的問責方？
觸發條件	甚麼可觀察的事件啟動了轉移？
轉移內容	轉移的是哪些資料、產物或狀態？
接收確認	接收方如何知道它完整而有效？
輪候與時間	工作可能在哪裏等候、過期或亂序到達？
失敗訊號	如何發現遺失、被拒或重複？
恢復負責人	誰負責重試、更正、升級或通知客戶？
證據	哪條紀錄證明交接已經發生？

留意沒有去向的輸出、多個負責人、隱性的輪候、人手複製、渠道轉換，以及沒有驗收準則的工作。這些是藍圖的發現，而不是根本原因的證明。

步驟 8：標記失敗點與恢復

就每一欄，問一問：在可見互動之前、期間和之後，可能出甚麼問題？包括渠道不可用、輸入無效、內容無法存取、依賴未達成、系統逾時、重複個案、紀錄衝突、政策例外、容量限制和交接遺失。

把客戶可見的徵狀與內部失敗的假設分開記錄。然後記錄偵測方式、遏止、恢復、溝通、升級、負責人和證據。在調查支持之前，不要給出根本原因的標籤。

只有在藍圖揭示了依賴和例外之後，才把穩定、已批准的操作次序轉化為 SOP 檢查清單。藍圖用於診斷和對齊；清單用於指導可重複的執行。

如何驗證並改進服務藍圖？

步驟 9：跨職能走查

召集用戶或研究代表、前台員工、後台操作人員、支援團隊、系統負責人、政策負責人和服務負責人。以真實的個案由左至右走一遍，其中最少包括一個失敗個案和一個渠道變體。

請每位參與者只確認屬於其證據和權限範圍內的儲存格。把更正記錄為新的修訂版本，而不是覆寫紀錄。透過調查實際個案和職責誰屬來解決做法上的衝突；不要讓職級最高的人或模型最整齊的字眼來決定。

以可觀察的紀錄檢驗藍圖。某個選定的客戶動作，能否追溯到前台結果、後台活動、系統狀態、交接紀錄和負責人？團隊能否說明等候由哪裏開始、在哪裏結束？能否指出恢復失敗時客戶會看到甚麼？

步驟 10：治理改進

按經核實的頻率、對用戶的後果、營運成本、風險和策略重要性，為失敗點排定優先次序。讓證據質素保持可見。一個未經量化但嚴重的無障礙障礙，不應因另一個問題的數目較大便消失。

每項改進都記錄問題、受影響的藍圖儲存格、證據、假設、負責人、依賴、決定、量度方式、推出界線和重新繪製藍圖的觸發條件。藍圖本身不是批准。產品、營運、技術、法律、無障礙和風險負責人仍各自保留其決定權。

覆核清單

總結

把旅程圖作為用戶體驗的證據，而不是整張藍圖。
讓各營運層與一條範圍明確的客戶動作主線對齊。
把可見的互動放在可見線之上。
把欠缺根據的後台細節標為假設。
與問責的負責人一同檢查交接、輪候、失敗和恢復。
隨服務和證據的變化，為藍圖做版本管理。

常見問題

沒有用戶旅程圖能畫服務藍圖嗎？

你可以先搭一個臨時結構，但客戶動作仍需要研究證據。記錄缺口，避免把假設的行為變成一份完成的旅程。

藍圖需要多少層？

使用能保持客戶、前台、後台、支援、系統／證據和職責區分的最少層數。只有新增一層能釐清真實的職責或依賴時才加入。

服務藍圖的可見線放在哪裏？

放在客戶能感知的互動之下、內部工作之上。如果可見程度因渠道而異，便標示這種差異，而不是強行給出一個答案。

AI 能從旅程圖推出後台流程嗎？

它可以提出問題或佔位內容，但無法把隱藏的工作確立為事實。後台操作要由操作人員、紀錄、系統和政策負責人確認。

藍圖是組織架構圖嗎？

不是。它描繪的是隨時間推進的交付。組織架構圖顯示匯報關係；其他職責問題請使用利益相關者地圖或職責地圖。

每格多詳細？

細緻到足以揭示輸入、輸出、交接、等候、失敗和職責。如果不拆分便會掩蓋不同的執行者或驗收規則，便拆分該儲存格。

每個失敗點都要立項嗎？

不需要。先核實證據，再在機構的決策程序下，按用戶影響、營運風險、頻率、成本和策略排定優先次序。

何時更新藍圖？

在渠道、政策、系統、角色、供應商、流程或研究有重大改變後更新，並保留每次決策所依據的版本。

來源

GOV.UK Service Manual — Creating an experience map — https://www.gov.uk/service-manual/user-research/creating-an-experience-map/
GOV.UK Service Manual — Map and understand a user's whole problem — https://www.gov.uk/service-manual/design/map-a-users-whole-problem
Department for Education — Building a service blueprint — https://design-histories.education.gov.uk/communicating-funding-beta/building-a-service-blueprint
NIST — Artificial Intelligence Risk Management Framework: Generative AI Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 6 日。

如何用 AI 建立服務藍圖，把客戶旅程連到後台與交接