客戶投訴升級流程圖
客戶投訴升級流程圖，一棵決策樹：圍繞風險、重複投訴、客戶價值與付款權限的九道判斷，通往六個明確的結果，並訂明每一步由誰作決定。
運作方式
把泳道按決策權命名
把前線客服、團隊主管、品質與合規和管理層，換成你們機構中真正握有權限的角色。泳道保持在三至四條。這不是一張部門圖，因此只有當某條泳道裡的人要回答下面的人無權回答的問題時，這條泳道才應該存在。
把四項條件寫在首次接觸判斷上
「能否在首次接觸時解決？」承載著整張圖的絕大部分流量，因為大部分投訴都應該在這裡止步。寫明客服已公布的權限、他們無須請示即可提供的標準補救，以及兩項排除條件：涉及風險，以及屬於重複。如果處理人不問主管就無法作出這個判斷，說明這道判斷寫得還不夠嚴密。
訂立並公布補償上限
為「是否超出主管的金額上限？」給出每宗個案的一個具體金額，並為同一客戶的重複善意補償給出一個較低的金額。策略客戶是像本圖的「高價值」分支那樣蓋過金額上限，還是僅僅知會一聲，要另行決定。沒有寫明的上限，每通電話都會被重新議一次。
定義重複與系統性的觸發條件
決定甚麼會令「同一問題此前是否提出過？」成立：是同一根本成因而不是同樣的措辭，是跨所有客戶而不只是這一位，而且落在訂明的檢視周期之內。然後議定這條分支觸發後品質部門接手甚麼，包括他們是否也負責這位客戶的補救，而不只是根本成因檢視。
按你們所處的行業釐定外部轉介途徑
把「轉介至申訴專員」換成適用於你們的機制，並附上必須先符合的條件。許多機制只有在機構已經發出最終回覆、或者某個期限已過之後才受理個案。例如在英國金融服務業，FCA 的投訴規則要求在訂明的期限內作出最終回覆——大部分投訴為八星期——客戶之後才可以向金融申訴專員服務機構（Financial Ombudsman Service）提出。
拿已結案的個案檢驗這棵樹
抽取一批已經處理完畢的投訴，把每一宗沿著圖走一次，比較樹把它送到哪裡、它當初實際去了哪裡。每一處不一致，要麼是欠了一條分支，要麼是有一條準則大家其實沒有在用，這兩者的價值都勝過再改一版圖。
常見問題
投訴升級流程圖與投訴處理流程圖有甚麼分別？
它們回答不同的問題。投訴處理流程圖是一個次序：登記投訴、確認收到、調查、補救、提出糾正措施、結案。它告訴你接下來會發生甚麼、每一步由誰執行。升級流程圖是一棵決策樹：它告訴你該選哪個選項、誰有權作這個選擇，而且它的分支通往不同的結果，而不是匯合到同一條路上。用流程圖來設計程序，用本圖來定下程序內部那些需要判斷的地方。端到端的版本見 /yue/templates/客戶投訴處理流程。
甚麼時候應該把投訴升級給主管？
只要首次接觸的四項條件中有任何一項不成立。在本圖中，這意味著補救措施超出客服已公布的權限、需要在標準補救之外額外付款、涉及安全、監管或法律因素，或者客戶此前已就同一問題投訴過。把它寫成四項排除條件而不是一次主觀判斷，正是令不同處理人之間的升級保持一致的原因，同時亦令升級變得可量度——畢竟只有在背後的判斷固定下來之後，首次接觸解決率才有意義。
善意補償或賠償應該由誰批准？
按金額和客戶地位分開處理，這也是本圖有兩條通往管理層的路徑的原因。在主管已公布上限之內的付款由主管批准，個案在主管層級結束。超出上限的付款送到「管理層審閱該個案」，然後進入明確的批准或拒絕。另外，策略客戶或高價值客戶不論金額一律送交管理層，因為商業風險在於這段關係本身，而不在於這筆金額。兩個門檻都應該寫下來，因為一個沒有紀錄的上限，在壓力之下往往會一路上移。
投訴在甚麼情況下會走到申訴機構或監管機構？
當客戶對結果提出異議，而機構自身的申訴途徑已經用盡時，也就是圖底部的「內部申訴途徑是否已用盡？」這道判斷。答「否」會把個案退回管理層再看一次，因此外部途徑絕不會成為面對分歧時的第一反應。具體條件因行業而異：許多機制要求先有一封最終回覆信，或者某個期限屆滿，才會受理轉介，而且客戶通常只有一段有限的時間可以提出。要把轉介登記在這宗投訴上，而不是直接結案，因為這些正是監管機構日後會追問的個案。
重複投訴是否應該與首次投訴區別對待？
應該，這也是重複判斷在本圖中排在商業問題之上而不是之下的原因。就同一根本成因提出的第二次投訴，本身就是證據：第一次的補救解決的是個案，而不是成因。把它送往「已作為系統性問題升級至品質部門」會轉移歸屬，令根本成因檢視與給客戶的答覆留在同一條紀錄上，而不是變成兩件互不相干的工作。這個觸發條件需要寫明定義，通常是在訂明的檢視周期內出現同一根本成因，否則它要麼對甚麼都觸發，要麼對甚麼都不觸發。