事故管理流程圖
跨職能的事故管理流程圖，涵蓋事故登記、優先次序判定、重大事故升級、SLA 違約預警、修復復原、用戶確認結案與問題記錄移交。
運作方式
把泳道改成你們真實的角色
把報告人／用戶、服務台、事故經理和二線／三線支援換成你們機構中真實存在的角色。小團隊常把事故經理併入服務台泳道；設有 NOC 的團隊會在報告人之上增加一條監察泳道。
界定你們的優先次序矩陣
把你們對影響程度和緊急程度的定義附在「分類並設定優先次序」步驟上。寫清楚 P1 到 P4 分別在受影響用戶數和業務影響上意味著甚麼，令優先次序是推導出來的，而不是每張工單都要重新商議。
訂定重大事故的觸發條件
決定甚麼情況會令「是否為重大事故？」得到「是」：某項影響收入的服務中斷、某個具名的關鍵系統、某個客戶數量門檻。指明誰有權宣佈，以及宣佈之後隨即會發生甚麼，例如開啟應急會議並展開固定頻率的通報。
接上你們的 SLA 目標與違約升級
把你們的應答和解決目標放在「是否在 SLA 目標之內解決？」決策上，並寫明違約分支上通知誰、提前多久通知。這條分支的意義在於提前預警，而不是事後報告。
約定結案與問題管理的規則
界定甚麼算作用戶已確認、工單在「已解決」狀態下多久之後自動結案，以及「根本原因是否仍未知？」上把事故推入問題管理的判定準則。反覆出現的徵狀和每一次重大事故是常見的觸發條件。
與每條泳道走一次，然後發佈附版本的副本
與每條泳道中的人一起檢視這張圖，修正他們實際執行的步驟。達成一致之後，把它作為當前版本發佈並附上簽署確認，這樣日後讀到它的人就知道當時生效的是哪一版。
常見問題
事故管理和問題管理有甚麼分別？
事故管理復原服務。問題管理消除原因，令事故不再復發。兩者運行在不同的時鐘上：事故按分鐘或小時對照 SLA 量度，而一份問題記錄可以為了調查而開放數星期。在本圖中，兩者在結案處連接——「根本原因是否仍未知？」提出一份問題記錄，同時並不令事故繼續掛著。把兩者混在一起是最常見的失敗，其表現就是用戶早已恢復工作、工單卻仍然長期開放。
甚麼時候應當把一次事故宣佈為重大事故？
當影響大到值得打破正常隊列時：某項業務關鍵服務不可用、一大批用戶被阻塞，或者存在安全、財務或聲譽方面的暴露。觸發條件應當在你需要用到它之前就寫下來，並且客觀到一線人員在凌晨兩點也能套用。一經宣佈，流程會改變形態，而不只是加快速度。一位具名的事故經理接過責任，應急會議開啟，並且不論是否有新進展，都按固定節奏向持份者發出通報。
當一次事故即將違反 SLA 時會發生甚麼？
違約分支是一次層級升級，而不是技術升級。工作仍在繼續，但事故經理被拉進來重新調整與客戶的預期、在必要時重新調配資源，並記錄目標為何未能達成。關鍵細節在於時機：這條分支應當在時限過去之前觸發，依據的是諸如剩餘時間已用掉百分之七十五這樣的門檻，好令與客戶的溝通發生在違約之前，而不是事後的一句道歉。
由誰結案，甚麼才算已解決？
解決和結案是兩種不同的狀態。工程師在修復實施完畢、服務復原時把事故標記為已解決。只有當報告人確認服務對他們確實可用之後，事故才被結案——這正是本圖在結案之前要經過報告人泳道中的「確認服務已復原」和「用戶是否確認已解決？」決策的原因。如果用戶表示問題依舊存在，工單會重開回到初步診斷，而不是新開一張。多數團隊還會設定一個自動結案窗口，通常是三至五個工作天沒有回覆。