客戶支援升級流程圖（一線到二線）
泳道式客戶支援升級流程圖：一線解決嘗試、有紀錄的二線交接、嚴重程度與 SLA 重評、升級至研發。
運作方式
把泳道改成你們真實的角色
把客戶、一線支援、二線／專家、支援經理和研發換成你們實際擁有的職能。小團隊通常把二線併入研發；設有專責客戶經理的團隊經常把支援經理泳道拆成當值經理和客戶負責人。即使客戶泳道只有兩個節點，也要保留它，因為那正是由客戶、而不是由你們控制流程走向的兩個點。
界定一線獲准做甚麼
「一線是否已解決？」需要同時掛上範圍和時限：支援人員可以存取哪些系統、可以執行哪些操作，以及一次一線嘗試進行多久之後個案就必須往下走。兩者缺一，升級量就會隨當更的人而波動。請明確寫出：在時限之內升級是正確的結果，而不是一次失敗，否則支援人員會為了保住自己的數字而壓住個案不放。
固定交接紀錄的內容
決定「記錄升級交接說明」必須包含甚麼，並把它做成服務台系統裡的範本：受影響的客戶與環境、重現步驟、已經嘗試過並排除了甚麼、對客戶的影響，以及已經向客戶說過甚麼。由對話紀錄貼出來的交接，是專家把第一個小時的工作重做一次的最常見原因。
為關鍵分支寫出客觀觸發條件
「是否關鍵個案或重點客戶？」不應該取決於客戶寫得多大聲。使用可以核實的條件：業務關鍵流程被阻斷、獲指名的策略客戶、合約回應目標面臨風險，或者個案已經被重新開啟過一次。寫明每個觸發條件通知誰，並聲明通知本身不會重新排定隊列的優先次序，否則每一宗個案都會變成關鍵個案。
決定研發暫時無法修正時該怎麼辦
缺陷一旦被接受，就進入研發的發佈節奏，而它比支援的節奏慢。請約定在這段期間由誰負責維繫客戶關係、即使沒有新消息也要多久更新一次，以及你們承諾的是一個目標版本還是一個具體日期。「尚未」這條分支存在的意義，就是令變通方案成為與客戶明確達成的協議，而不是一段沉默。
約定重新開啟的規則，然後發佈一個附版本的副本
本範本把確認失敗的個案退回交接步驟，因此重新開啟的個案會被重新記錄、重新評估，而不是被丟進某條隊列。如果你們希望重新開啟的個案直接回到上一位負責人手上，就改掉它。然後與每一條泳道一起走一次這張圖，修正大家實際執行的步驟，並把它作為當前版本發佈並簽署確認，好讓日後閱讀的人知道適用的是哪一版。
常見問題
甚麼是客戶支援升級流程？
它是一宗支援個案在一線無法解決之後所遵循的、有紀錄的路徑。它涵蓋的不是完整的工單生命週期，而是由一線能力邊界開始的那一段：升級的決定、向專家的交接、在個案注定要花更長時間之後對嚴重程度與 SLA 影響的重新評估、調查本身，以及令個案結束的確認與檢討。它的價值不在於各個步驟本身——大多數團隊本來就在做——而在於就每一個節點由誰負責、以及個案易手之前必須寫下甚麼達成一致。
支援個案甚麼時候應該由一線升級到二線？
使用支援人員可以核實的條件，而不是主觀判斷。涵蓋大多數情況的三條是：支援人員缺少診斷所需的權限或工具；徵狀超出已記錄的一線職責範圍；或者一線嘗試的時限已過而仍未解決。第四條被刻意單列：個案需要一個只有其他人才能作出的決定，例如一筆貸記或一項合約讓步。唯獨不應該單獨作為觸發條件的，是客戶要求升級，因為那會把層級分派變成一場談判。這類要求應該經通知分支來處理。
職能式升級與層級式升級有甚麼分別？
職能式升級把個案橫向轉給更專門的人，例如一線交給專家。層級式升級把它縱向轉給權限更大或需要知情的人，例如通知支援經理和客戶負責人。它們解決的是不同的問題，在本圖中亦表現為兩條獨立的分支：「一線是否已解決？」的升級分支是職能式，「是否關鍵個案或重點客戶？」的關鍵分支是層級式。常見的失敗是做了其中一個，就以為涵蓋了另一個，於是專家在默默處理一宗個案，而客戶負責人卻是由客戶那裡第一次聽到它。
這與事故管理有甚麼分別？
升級是把一位客戶的個案轉給更有條件解決它的人。事故管理是為所有受同一個故障影響的人恢復服務。觸發條件、時間尺度和成功準則都不一樣：一宗被升級的個案，量度標準是這位客戶是否已解決並確認；一宗事故，量度標準是服務多快恢復。當多宗被升級的個案指向同一個故障時，就由事故流程接手，這些個案被連結到該事故，並在服務恢復且每位客戶確認之後結案。把兩者分開，正是防止服務台把一次故障當成五十條並行調查來跑的關鍵。
升級之後由誰負責這宗個案，交接紀錄應該包含甚麼？
調查的責任轉給專家，但客戶關係的責任通常仍然留在最初那位支援人員手上——本圖透過回到一線執行「與客戶確認解決結果」體現了這一點。請明確訂定這條分工，因為雙方都以為對方在更新客戶，是沉默最常見的來源。交接紀錄應該載明受影響的客戶與環境、重現步驟、已經嘗試過並排除了甚麼、對客戶的影響，以及已經向客戶說過甚麼。把它保持為一條紀錄而不是一串訊息，這樣重新開啟的個案再次經過同一步驟時，會累加進同一份歷史。