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