看不見的後台，塑造看得見的體驗【易倢】

 

作者：易倢｜政治大學科技管理與智慧財產研究所 113屆科管組研究生。

研究興趣：數位金融、服務創新

 

在美國北方的科羅拉多河谷，有一艘遊客準備登船的船隊正要啟航。晨光映在湖面上，旅客們帶著期待，彷彿這趟假期只需要一張票與一條航線便能順利展開。然而在碼頭後方的補給倉庫，另一群人已經耗費整整一夜確認物資、校對訂單、安排船長、整合資訊。那些遊客永遠不會看見的流程，卻是維繫整個服務體驗的脊骨。這是ARAMARK 的日常，也是Bitner, Ostrom, and Morgan (2008)試圖回答的問題：為什麼顧客看到的部分很簡單，但企業背後卻充滿複雜？又為什麼許多問題看似發生在前台，其實源自後台的運作？本文以這個視角出發，把服務藍圖當成一種看見服務真實樣貌的方法，而不是一張單純的流程圖。

被藏起的複雜：那些讓服務看起來簡單的幕後力量

許多服務之所以順暢，不是因為流程簡單，而是因為企業把大量複雜工作藏在顧客看不到的地方。舉例來說，當Yellow Transportation運送貨物時，客戶只知道卡車會準時抵達，但背後包含排班、路線、資訊同步與客服支援；ARAMARK的遊船服務看似只需帶旅客上船，但背後牽涉採購、設備整備、食品處理與安全檢查。服務藍圖的價值在於讓企業真正看見自己在做什麼，而不只是依靠經驗猜測。當流程攤開，企業才能理解哪些部分順利、哪些部分常出錯、哪些部分缺乏支援。

顧客看到的是前台互動，但體驗品質卻常受後台影響。若資訊不同步、責任不明確、流程不一致，體驗便會忽快忽慢、時好時壞。服務藍圖的概念指出：企業不能只看前台所發生的事，而應理解後台如何影響整個旅程。許多案例顯示，只靠改前台並無法改善體驗。真正的問題往往出現在後台，例如資訊等待時間太長、指令傳遞不清楚或部門各做各的，服務藍圖則讓這些問題一一浮上檯面。

前台只是表象：真正決定體驗的隱形網絡

傳統流程圖把服務想成一條順序分明的線，但服務藍圖顯示，服務更像一張網：每個人員、系統、部門都彼此依賴。IBM的案例說明，用藍圖當基礎討論時，研發、客服、營運與管理層能站在同一張圖上對話，也開始理解原本看似不相關的環節其實息息相關。服務因此不是一個部門能單獨完成的任務，而是一個需要協作的網絡。

然而，顧客常抱怨流程太多、資訊不清楚、等待太久。這些問題通常不是因為顧客不會使用，而是企業把原本應由自己吸收的複雜性推到顧客身上。ARAMARK的田野研究指出，旅客在登船前必須自行準備大量事項，而企業原本並未意識到這些都是負擔。服務藍圖協助企業重新分配複雜性：哪些該自動化、哪些該由後台承擔、哪些該提前說明。當複雜性安排合理，顧客自然會感到流暢；當複雜性外溢到顧客端，便會增加挫折感。

服務藍圖最重要的價值，是讓所有部門看到同一個服務旅程。當大家開始用相同的服務藍圖討論流程、責任與瓶頸時，改善才有機會一致。無論是Yellow、IBM還是ARAMARK，真正的提升都來自跨部門協作，而非單一部門努力。藍圖使服務從「看不清楚」變成「能討論」、從「各做各的」變成「一起運作」，成為一種治理服務的方法，而非單純的分析工具。

前台改版只是外表，服務脈絡必須從流程看清

若把服務藍圖放進證券業開戶流程，可以看得更清楚。數位流程並不總是因為步驟太多而複雜，而是因為被拆散。許多證券公司在客戶具有同集團銀行帳戶時，會把使用者導入銀行端的網銀登入介面，期待能以此加速開戶、減少填寫。然而實際情況往往相反。由於兩套系統沒有完全整合，資料介面不一致，使顧客在銀行端填過一次資料，回到證券端又需重新輸入一次。表面上是希望簡化流程，但顧客感受到的卻是不斷切換畫面、跳轉頁面、重複填寫的疲憊感。

服務藍圖指出，前台體驗若由多個系統共同拼接，節奏便容易產生斷層。顧客在操作過程中並不會意識到「現在是銀行系統、下一步是證券系統」，顧客只會感覺自己在一個流程中反覆被要求提供相同資料。從流程角度看，跳轉是技術限制；從體驗角度看，跳轉是阻力來源。服務藍圖提醒金融業：當前台流程需要靠不同後台系統共同完成時，若沒有一致的邏輯與節奏，再高明的介面設計也無法帶來真正的順暢。

當流程遇上現場：服務真正發生的地方

服務藍圖擅長把流程畫出來，讓企業能看見整體服務的結構，但實際提供服務的人其實並不會完全依照流程圖逐步運作。Orlikowski (2002)的knowing-in-practice便提供另一種重要視角：服務並非依照手冊與規範進行，而是在具體情境下，被服務提供者即時調整、臨場修補與靈活應對而完成。

從knowing-in-practice的觀點看，流程只是服務的設計版本，而由前線人員依情境進行的實作才是服務的運行版本。證券業若只依賴服務藍圖理解流程，便容易忽略服務真正如何被實際維持。若能把服務藍圖與knowing-in-practice結合，企業就能同時看見兩件事：服務應該怎麼運作，以及服務實際怎麼被完成。兩者交會的地方，也正是金融服務最容易出現落差、但也是最值得重新設計的地方。

參考文獻

Bitner, M. J., Ostrom, A. L., & Morgan, F. N. 2008. Service Blueprinting: A Practical Technique for Service Innovation. California management review, 50(3): 66-94.

Orlikowski, W. J. 2002. Knowing in Practice: Enacting a Collective Capability in Distributed Organizing. Organization science (Providence, R.I.), 13(3): 249-273.