試算表轉流程圖範本（客戶意見）
把一張步驟試算表變成流程圖，以一份客戶意見追蹤表示範：收集、分流、成因分析、一個決定哪些項目成為改善措施的重複發生門檻，以及結案之前的驗證。
甚麼是試算表轉流程圖範本（客戶意見）流程
追蹤表記錄每一項在哪裡停了下來。流程圖記錄它走到那裡所經的路線。這個落差解釋了為甚麼一份客戶意見表可以完整、及時而準確——一項意見一行，帶日期、渠道、類別、負責人與狀態——卻答不出任何人真正會拿它來問的問題：哪些項目走到了成因分析、由甚麼決定，以及沒有走到的那些後來怎樣了。狀態是一個結果。流程是結果與結果之間那組邊，而一張表在你加上一個寫明每一行交接給哪一步的欄之前，根本沒有地方放一條邊。這些行來自哪裡並無分別：一個 Google Sheets 工作表、一份由服務台匯出的 CSV、一個 Airtable 檢視，或者一份共用追蹤表裡的一個工作表，產生的都是同一張圖。
清單隱藏的是重複。十一位客戶就同一個交付缺口投訴，看上去只是十一項已結案的意見，散佈在四個月裡，由兩個不同的人歸入三個類別，每一項都獲得禮貌回覆並標示為已解決。逐行檢視的方式裡，沒有任何東西令這個模式看得見，而沒有人會為了找一個自己並未懷疑的模式去為追蹤表排序。第二個失敗是結案。一項意見在客戶收到回覆時就結案，而不是在成因被移除時才結案，於是同一個毛病繼續產生新的行。第三個是沒有人檢查過的解決方案：作了一項改動，該項意見在改動當日結案，而它有沒有效，從來沒有對照任何東西量度過。
下面這張圖把那份追蹤表畫成一條流程，並把缺少的判斷放了進去。它橫跨五個階段——收集、分流、措施、驗證與結案——以及四條泳道，由一位客戶提出意見，走到兩個明確結局之一。一個重複發生與嚴重程度的門檻決定哪些項目成為改善措施、哪些作為一次性個案結案，而不作改動就結案的理由是必填。落在你們自己流程之外的成因由自己的路徑離開，而不是併入改善工作的待辦。驗證帶著一條迴路：如果量度出來的檢查說問題仍然重複發生，該項意見會退回重新議定，而不是照樣結案。
本流程圖涵蓋的內容
本範本包含
- 五個階段——收集、分流、措施、驗證與結案——橫跨客戶、客戶服務、流程負責人與品質四條泳道，令追蹤表的負責人欄變成頁面上的一個位置，而不是格子裡的一個名字。
- 收集按它實際發生的樣子：客戶「由任何渠道提出意見」，然後在客戶服務泳道「把意見登記入追蹤表」，一項意見一行，載有收到日期、渠道、帳戶或訂單編號，以及原文保留的客戶自己的措辭。
- 在「客戶是否需要個別回覆？」把服務補救與改善工作分開：是的走過「回覆並記錄承諾了甚麼」，而兩個答案都在「與實際執行工作的人一起調查成因」匯回。
- 任何改善項目開始之前的一道範圍關卡：「成因是否在我們自己的流程之內？」把不受你們控制的成因送往「把成因反饋給第三方」再走到一個有紀錄的結案，令它們既不會失落，也不會變成內部措施。
- 整張圖存在的理由，就是那個重複發生門檻。「是否重複發生或違反服務目標？」落在品質泳道，而它是通往改善措施的唯一路線；一次性、影響輕微那條分支則把該項意見結案，而正是這一點令一宗投訴的第十一次出現變得看得見，而不只是被處理掉。
- 結案之前的驗證，經由「改動後按議定標準量度」與「改動是否解決了問題？」，它的否分支回到「議定措施、負責人與檢查標準」，最後在「已結案，改動經確認」或「結案不作流程改動，理由已記錄」結束。
何時使用本範本
- 你們的意見本來就放在一份共用試算表、一份由服務台匯出的 CSV，或者一個 Airtable 檢視裡，而有人問你流程是甚麼。
- 同一宗投訴一直出現，而沒有人說得出出現過多少次，因為每一次都在自己那一行被回覆並結案。
- 項目在客戶收到回覆之後就標示為已解決，而你懷疑回覆之後的下游幾乎甚麼都沒有發生。
- 客戶服務與流程負責人各自以為對方在做成因分析，而追蹤表的負責人欄解決不了這件事。
- 一位評審員或一位客戶問起投訴是怎樣變成矯正措施的，而你需要一條寫下來、裡面有門檻的路線。
運作方式
在重複發生門檻裡填一個真實的數字
把「是否重複發生或違反服務目標？」重寫成你們真正會執行的觸發條件：例如在滾動一季內同一類別出現三項，或者任何一次違反已公布的服務目標。然後說明這個數目由追蹤表的哪一個欄統計出來。沒有寫明的數字，每一項意見都會變成一個項目，而真正重複的東西得不到任何特別關注。
把泳道改成你們有的團隊
客戶服務、流程負責人與品質是三個角色，不一定是三個人。如果訂門檻與檢查結果的是同一個人，就把品質併入流程負責人。如果一線與二線登記項目的方式不同，就把客戶服務拆開。即使是 B2B 流程也要保留客戶泳道，因為它正是令兩個面向客戶的步驟看得見的東西。
把追蹤表的欄對應到收集那一行
決定「把意見登記入追蹤表」必須包含甚麼，並寫在該步驟上：收到日期、渠道、帳戶或訂單編號，以及未經改寫的客戶措辭。強制一項一行。把兩宗投訴合併在一行，日後無法統計；而改寫過的說法，通常就是成因失落的地方。
保留或改指第三方那條分支
如果你們慣常把成因交給供應商或快遞公司，就在「把成因反饋給第三方」指名他們，並記下反饋是怎樣送出的。如果你們沒有外部依賴，就刪掉那一步，把「成因是否在我們自己的流程之內？」的不受控制分支直接指向那個有紀錄的結案。
在作出改動之前先選定檢查標準
在「議定措施、負責人與檢查標準」指名量度指標、檢視日期，以及該指標現時的數值。事後才選檢查標準，就會令一項改動憑著剛好有變動的那個數字被宣布成功，而這也是「改動是否解決了問題？」為甚麼答得出的原因。
令不作改動的結案要付代價
決定誰可以走「結案不作流程改動，理由已記錄」這條路，以及理由必須寫甚麼——不受我們控制並已反饋給某個具名對象，或者在某個明確日期未達重複發生門檻。理由留空，就會令這個結局變成整條流程要防止的那個無聲垃圾桶。
常見問題
客戶意見流程有哪些階段？
六個，而上面這張圖把它們歸成五個階段。收集把該項意見原文記下，一宗投訴一行。分流為它歸類、定嚴重程度，並判斷客戶是否需要個別回覆。成因分析向實際執行工作的人問清究竟發生了甚麼，以及成因是否在你們自己的流程之內。然後一個門檻判斷挑出哪些項目成為改善措施。措施議定改動、負責人與檢查標準，並作出改動。驗證在事後按議定標準量度。到這時該項意見才結案，或者改動經確認，或者附上一個記錄下來的不作改動的理由。
客戶意見流程由誰負責？
沒有任何單一角色負責，而泳道存在的目的是把這一點說出來，而不是把它藏起來。客戶服務負責收集、歸類與客戶看得見的一切：回覆、承諾了甚麼，以及告知客戶改動了甚麼。流程負責人負責成因分析與改動本身，因為改動落在他的程序裡。品質負責門檻判斷與驗證量度，令修正問題的團隊不是唯一判斷問題有沒有修好的團隊。這樣的劃分只有在結案的權力不在回覆客戶的那個團隊手上時才守得住，而在這張圖裡確實如此：一個結局在品質泳道，量度過檢查標準之後結案；另一個在流程負責人泳道，附上一個記錄下來的理由。
怎樣決定哪些意見會變成改善措施？
用一個寫下來的門檻，而不是逐項憑判斷。兩個觸發條件覆蓋大部分機構：重複發生，即同一類別在一段滾動期內出現的次數超過議定的數目；以及嚴重程度，即任何單一項目違反了已公布的服務目標，或者造成真實傷害。其餘一律作為一次性個案結案，並記下理由。門檻要緊，因為兩種失敗都很常見：門檻定得太鬆，每一宗投訴都變成一個項目，待辦就停止推進；而完全沒有觸發條件，重複出現的毛病所得到的關注，與一次性個案完全一樣。
試算表可以自動變成流程圖嗎？
試算表本身不行。在 Excel 裡，應用程式內唯一的繪圖原件是 SmartArt 與繪製的形狀，兩者都要人手填寫，而 Microsoft 的文件並沒有描述任何格子與形狀之間的綁定。由一張流程步驟表走到一張已連線的圖表，有文件記錄的路徑是經 Visio 的 Data Visualizer 範本，而不是經 Excel，而 Microsoft 的支援頁面把它們描述為需要 Visio Plan 2——Plan 2 是唯一包含 Visio 桌面應用程式的訂閱檔次，而 Microsoft 表示 macOS 根本沒有 Visio 桌面應用程式。QueryChart 走的是另一條路：那張表就是那張圖，在瀏覽器裡編輯，用甚麼作業系統都可以。