客戶支援升級流程圖（決策樹）
客戶支援升級流程圖：由八項判定組成的決策樹，把個案分派給一線、二線、研發、客戶負責人或當值經理。
甚麼是客戶支援升級流程圖（決策樹）流程
本頁是一棵決策樹，不是流程圖。流程圖回答的是接下來會發生甚麼、由誰去做，由登記工單一直到結案。決策樹回答的則是藏在其中一個更窄、也爭議大得多的問題：面對眼前這宗個案，它是否留在一線？如果不留，由誰接手？要看包括登記、定級、重大事故處理和結案在內的端到端流程，請用事故管理流程圖。要處理客戶對服務本身的不滿而非產品故障，請用客戶投訴流程圖。當爭論的焦點正是路徑本身時，就用這張圖。
升級會朝兩個相反的方向出錯，而兩種代價都很高。升級過於隨意，二線就會變成一線本來可以自己結掉的個案的第二條隊列，這會推高每張工單的成本，也會令真正需要專家的個案等得更久。升級過於罕有，一個受合約保障的客戶就會由自己的用戶口中得知一項被錯過的承諾。這兩種失敗都不是靠加強監督解決的，而是靠寫下來的判定條件解決——本圖中共有八項，每一項都可以由工單和客戶紀錄中得到答案，而不是憑對話給人的感覺。
泳道命名的是決策權，不是部門。一線支援人員決定職責範圍，以及一個已記錄的解決方案是否真的有效。支援組長負責風險、SLA 和缺陷這三項判定。客戶負責人回答該客戶是否屬於策略客戶或受合約保障。當值經理只回答一條問題——是否涉及關鍵客戶——而且只有在風險已經確認之後才會被問到。按這個次序執行判定，意味著權限最高的一方勝出：一宗帶有法律風險的個案，不可能悄無聲息地把自己排進研發的待辦隊列。
本流程圖涵蓋的內容
本範本包含
- 在考慮任何升級之前的一道一線關卡：「是否在一線職責範圍內？」和「已記錄的解決方案能否解決？」必須都回答「是」，才能到達「一線解決」這個結果。任何一項回答「否」，個案都會進入「由組長進行升級覆核」。
- 風險是最先判定的，而不是最後。「是否存在聲譽或法律風險？」回答「是」，直接進入當值經理泳道的「是否涉及關鍵客戶？」，其「是」終止於「當值經理接管指揮」，其「否」終止於「客戶負責人接手」。
- 「SLA 目標是否有風險？」把「有風險」與「仍在目標之內」分開：有風險的個案在任何技術分派之前先繞經客戶判定，仍在目標之內的個案則直接進入缺陷問題。
- 「是否屬策略客戶或受保障客戶？」位於客戶負責人泳道。回答「是」終止於「客戶負責人接手」；回答「否」則匯回技術分派路徑，而不是另開一條並行隊列。
- 經由「是否確認為產品缺陷？」進行的技術分派：「否」終止於「升級至二線支援」，「是」繼續走向「是否有變通方案？」，其中「否」終止於「作為缺陷升級至研發」。
- 一個刻意設計的「不升級」結果：當存在變通方案時，支援人員把方案提供給客戶，個案終止於「登記為缺陷，不予升級」，於是這個缺陷進入常規的研發待辦隊列，而不是消耗一次升級。
何時使用本範本
- 在你們團隊裡，是否升級取決於個人性格，同一宗個案兩位支援人員的處理方式並不相同。
- 二線或研發正在就升級品質提出異議，你們需要的是雙方認可的準入條件，而不是更嚴厲的語氣。
- 客戶經理總是先由客戶口中、而不是先由內部聽到嚴重個案。
- 你們正在編寫或修訂升級政策，希望在有人動筆寫正文之前，先把判定條件和決策權談定。
- 你們正在培訓新的支援人員，需要一頁紙說明何時升級、升級給誰，與端到端流程圖配套使用。
運作方式
指名這四位決策者
把一線支援人員、支援組長、客戶負責人和當值經理換成你們機構裡真實存在的角色。小團隊經常把客戶負責人併入組長；設有非辦公時間當值安排的機構通常保留獨立的當值經理，因為這個角色隨更表輪換。每一條泳道都必須是一個聯絡得到、而且有權作出判斷的人，而不是一個部門名稱。
把一線職責範圍寫下來
「是否在一線職責範圍內？」這項判定決定了你們有多大比例的工單永遠不會升級，因此它值得一份成文定義。按能力而不是按投入程度來界定範圍：一篇已發佈的知識庫文章、一項已記錄的設定調整或一次標準的帳戶操作屬於範圍之內；任何需要改動程式碼、存取生產資料或作出合約讓步的事項，按定義就屬於範圍之外——無論支援人員多願意一試。
把 SLA 風險觸發點設在期限之前
決定剩餘的回應或解決時間達到多大比例才觸發「SLA 目標是否有風險？」，並提前約定好，讓工具可以自動觸發。這條分支的全部價值在於：它要在目標仍然可以達成的時候運行。把觸發點設在期限本身，只是在告訴你承諾已經錯過了。
提前訂定受保障客戶名單
「是否屬策略客戶或受保障客戶？」必須可以在幾秒內由 CRM 得到答案。維持一份明確的名單，並記錄一個客戶憑甚麼被視為受保障：獲指定的策略地位，或者寫入協議的回應與解決承諾。逐宗個案判斷，正是令嗓門最大的客戶、而不是最重要的客戶獲得優先處理的原因。
與法律部門一起訂定風險觸發條件
「是否存在聲譽或法律風險？」是那條會壓過其他所有判定的分支，因此它的準則應該在支援部門以外獲得簽署確認：個人資料外洩、涉及監管機構或審核方、存在安全風險、出現公開帖文或傳媒查詢，或者合約罰則被觸發。清單要短到在壓力之下也記得住，並且任何單一條件成立即為充分。
約定甚麼算確認缺陷、甚麼算可接受的變通方案
為「是否確認為產品缺陷？」訂定證據門檻，例如已在受支援版本上按另一位工程師可以照著走的步驟重現，這樣未能重現的報告就會轉交二線做診斷，而不是轉交研發。然後決定由誰判斷變通方案是否可接受。如果這個判斷只由支援部門作出，「登記為缺陷，不予升級」這個結果就會被從未同意過它的客戶質疑。
常見問題
這與客戶支援升級流程圖有甚麼分別？
流程圖是一條序列：登記工單、分流、處理、解決、結案，並以泳道標明每一步由誰執行。本圖是一棵決策樹，它的主幹是一連串問題而不是一連串任務，它的分支通向五個不同的具名結果，而不是匯聚到同一個結案步驟。用流程圖去看一宗個案的完整生命週期，用這棵樹去處理生命週期中必須選擇路徑的那一個點。兩者是互補的：事故管理流程圖顯示升級決策位於何處，而本圖說明這個決策該怎樣做。
甚麼時候應該升級一宗支援個案？
當一小組寫下來的判定條件中有一項回答「是」的時候，而不是當個案已經開了很久的時候。本圖八項判定之中有五項決定是否升級：個案超出一線能力、沒有已記錄的解決方案能夠解決、SLA 目標有風險、客戶屬於策略或受合約保障，或者存在聲譽或法律風險。其餘三項決定它去哪裡。已耗時長是覆核個案的有用觸發條件，但單獨作為升級觸發條件就很差，因為它只是搬動了工作，並沒有增加這宗個案真正需要的能力。
升級到二線和升級到管理層有甚麼分別？
它們解決的是不同的問題，ITIL 把它們分為職能式升級和層級式升級。職能式升級把個案交給技能更專、系統權限更深的人，也就是這裡的「升級至二線支援」和「作為缺陷升級至研發」。層級式升級引入權限更高的人，用來重設客戶期望、批准例外或調配資源，也就是這裡的客戶負責人和當值經理兩個結果。一宗個案可能兩者都需要。當個案真正需要的是專家時卻把它送上管理層，既浪費了經理的時間，也沒有推動工單前進。
每一個確認的產品缺陷都需要升級給研發嗎？
不需要，而且把每一個缺陷都當成升級，正是升級失去意義的原因。本圖在「是否有變通方案？」處分叉。沒有可接受的變通方案，客戶就被卡住了，於是個案終止於「作為缺陷升級至研發」，並帶有影響服務的優先次序。有變通方案時，支援人員把方案提供給客戶，個案終止於「登記為缺陷，不予升級」：這個缺陷仍然會經常規的缺陷接收與排期路徑到達研發，只是不會打斷任何人。第二個結果被刻意畫成一個「拒絕」型終止節點，因為決定不升級是評估的一項正當結果，就應該這樣被記錄下來。
誰有權拒絕一次升級？
誰負責那項未通過的判定，誰就有權拒絕——這也是本圖泳道代表決策權而非部門的原因。組長可以拒絕一宗在風險、SLA 和缺陷三項判定上都未通過的個案，並把它退回一線。客戶是否受保障由客戶負責人決定，而不是由支援部門決定。當值經理決定客戶是否屬於關鍵客戶，而且只有在風險已經確認之後才會被問到，這令這個角色留給真正需要指揮的場合。沒有記錄理由就被拒絕的升級，正是會再回來的那些，因此請把是哪一項判定未通過記錄在個案上。