服務補救流程圖（由恢復服務到重建客戶信任）
用於服務恢復後的客戶補救：驗證穩定、識別受影響客戶、計算 SLA 額度、按損失訂方案、取得客戶驗收並把反饋用於預防。
甚麼是服務補救流程圖（由恢復服務到重建客戶信任）流程
系統恢復代表事故應對告一段落，卻不會自動修復客戶關係。客戶可能失去工作、錯過限期，或花幾個鐘頭證明故障，一封劃一的恢復通知無法補救這些影響。本圖由技術恢復之後開始，先驗證服務能否承受真實流量，再按證據建立受影響客戶名單，評估持續時間和業務損失，並檢查合約是否要求自動 SLA 額度。之後按實際損害而不是投訴聲量選擇主動補救，草擬事實說明和相配方案，只有超出授權的方案才進入審批。
流程刻意限於故障之後。事故管理負責發現、技術指揮和恢復；投訴流程負責仍要正式調查的指控；流失挽留負責客戶提出的緊急離場風險。服務補救使用這些流程的結果，但回答服務恢復後還要為客戶修復甚麼。客戶收到解釋和補救，接受或者令未解決個案進入受控修訂迴路；團隊再確認沒有承諾或服務缺口遺留。最後，根本原因和客戶反應一併進入預防與支援手冊，避免把額度當成糾正措施，或者把技術修正當成信任恢復。
本流程圖涵蓋的內容
本範本包含
- 六條角色泳道橫跨穩定、識別影響、規劃補救、修復關係以及驗證與學習，並且只在技術恢復之後開始
- 以真實流量驗證穩定；服務未能通過觀察窗口時重新開啟事故
- 按證據識別受影響客戶並評估損失，在設計自願補救之前分開判斷合約 SLA 額度
- 按損害和關係風險選擇高接觸或標準補救，並為例外方案設定審批界線
- 客戶驗收、未解決補救的修訂迴路、逐項核對承諾，並把根本原因和客戶反應回饋至預防工作
何時使用本範本
- 中斷或嚴重服務故障已經恢復，但支援與客戶成功團隊沒有一致方法找出和聯絡全部受影響客戶
- SLA 額度發放不一致或只給主動投訴的客戶，自願善意補償亦與合約責任混為一談
- 團隊在監察恢復正常時結束事故，但客戶承諾、失去的工作或關係損害仍未解決
- 事後覆核改善了基建，卻沒有把客戶反應和溝通失誤回饋至支援手冊
運作方式
定義補救交接
訂明事故指揮在恢復時必須提供的證據：觀察窗口、受影響組件和客戶、開始與結束時間、已知資料損失及技術負責人。不要令客戶補救由一句含糊的恢復通知開始。
按證據評估損害
建立簡短等級，涵蓋持續時間、失去的工作、受阻業務事件、安全或合規影響和策略承諾。使用遙測和工單證據，不要按投訴數量排序。
分開合約額度與補救
按協議自動計算 SLA 額度，再為時間損失、重複故障和關係損害定義自願補救、授權上限及審批人。合約要求的額度不是道歉，善意措施亦不能取代它。
寫好客戶溝通
要求如實說明故障、已驗證影響、已改動事項、補救以及每位負責人和日期。根本原因調查完成前不要作虛假承諾，但亦不能以技術不確定掩蓋已知影響。
結束每項未完成承諾
把客戶驗收和後續承諾與事故行動分開記錄。將根本原因和客戶反應回饋至預防工作，只有服務與關係承諾完成或清楚分派之後才結案。
常見問題
服務補救流程有哪些步驟？
驗證穩定，不穩定時重開事故，按證據識別受影響客戶，評估損失，決定 SLA 額度，選擇高接觸或標準補救，有需要時指定高級負責人，草擬事實說明和方案，審批例外，聯絡客戶，修訂未解決方案，核對所有承諾，並在結案前把根本原因和客戶反應回饋至預防工作。
服務補救與事故管理有甚麼分別？
事故管理負責發現、控制、診斷和恢復服務。服務補救由恢復之後開始，處理客戶後果，包括受影響證據、SLA 額度、溝通、自願補救、驗收和跟進。事故已經解決，並不代表客戶補救亦已完成。
哪些客戶應該獲得服務補救？
依據證據和成文損害等級，而不是只看收到的投訴。所有合約列明可以獲得 SLA 額度的客戶都應該按協議收到額度。主動或高接觸補救再考慮失去的工作、業務受阻、重複故障、策略承諾和關係風險。
服務補救何時完成？
穩定已經證明、合約額度和獲批補救已經交付、客戶已驗收或未解決路徑已有清楚負責人，而且每項承諾均已完成或排期，才算完成。根本原因和客戶反饋亦必須進入預防及支援工作。