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