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