如何建立事故管理流程
如何設計一條由嚴重程度決定其後一切的事故管理流程：先分類後診斷，把重新定級畫成一條路徑，並把成因交給另一份紀錄。
運作方式
先寫優先級矩陣，後畫圖
優先級是影響對緊急程度，而兩者都需要訂明等級：影響多少用戶、屬於哪一級服務、是否牽涉金錢或安全、損害擴大得多快、有沒有可用的替代做法。這些要先議定，因為一份在畫圖過程中臨時發明的矩陣，描述的是上一宗事故，而不是下一宗。
決定重大事故到底改變了甚麼
列出這項宣告換來甚麼：一位指定負責人、一條指揮通話線、按固定時鐘發出的更新、繞過正常變更審批的授權。如果除了標籤之外甚麼都沒有改變，這條分支就只是裝飾。示例在它上面花了整整兩個步驟，而這正是它實際牽涉的工作量。
把登記與分類輸入成列
在 QueryChart 裡每一列就是一個方框。把觸發事件填進「方框文字」欄，然後是登記那一步、分類那一步，再在「連線至」欄裡讓每一列指向下一列。三列之內，這張圖已經把它的論點講完了：第 3 列的優先級，是由第 2 列採集到的東西算出來的，而這令第 2 列成為一項設計決定，不是一張表格。
把嚴重程度判斷分叉，兩個出口都加標籤
把分類那一列的「形狀」欄改成「決策」，在「連線至」列出兩個去處，然後在「連線文字」裡為每個號碼填上它的答案。這張圖只分叉一次，就在「是否重大事故？」，儘管矩陣有四至五級——而這兩個標籤所做的事，比這裡任何一對標籤都多，因為它們是路徑唯一改變的地方。
把重開路徑指向一個較小的列號
一次被報告人否決的修復會回到診斷：第 15 列的「重開」出口指向第 7 列。定錯了的嚴重程度需要同樣的處理，而示例並沒有畫出來——請由診斷那幾列加一條分支回到「分類並設定優先級」。兩者都是「連線至」欄裡一個較小的號碼。
校準矩陣，然後指名由誰宣告
把矩陣放在開工單的人看得到的地方，然後測試它：把同樣三段描述交給輪不同更份的兩個人，比較他們定出來的級別。不一致代表少了一個等級，而不是同事馬虎。然後為每一更指名一個人，讓他在事故經理還未睡醒之前，可以在「是否重大事故？」回答是。
常見問題
事故與問題有甚麼分別？
事故是服務的一次中斷；問題則是一宗或多宗事故背後的成因。兩者被保持為獨立的流程，是因為它們跑着不同的時鐘——事故管理量度的是恢復所需的時間，問題管理量度的是成因究竟有沒有被清除，而那可能要花上幾個星期。把兩者合併，成因這部分工作就會繼承事故的緊急程度，並在服務一回復的那一刻被放棄。
怎樣決定事故的優先級？
由公布過的矩陣上的影響與緊急程度決定，而不是由誰在問決定。影響是機構受波及的範圍：多少用戶、多少地點、屬於哪一級服務、是否牽涉金錢或安全。緊急程度是損害擴大得多快，以及有沒有可用的替代做法。矩陣把這一對轉換成一個優先級，而它要站得住腳，前提是判斷背後的數字與它一併記錄下來——一個沒有人重構得出來的優先級，在事後證明定錯了的時候也無從質疑。
甚麼時候應該把一宗事故宣告為重大事故？
當它越過一條事先議定的門檻——一級服務中斷、訂明數目的人無法工作、有監管或安全上的風險敞口、懷疑發生資料外洩。這項宣告要站得住腳，前提是它改變行為：一位指定的事故經理、一條指揮通話線、按固定節奏發出的更新。宣告得太遲是常見的失誤，而宣告之後再解除的代價，遠低於一小時安靜的代價。
重開的事故應該另開一張工單嗎？
不應該——請重開原本那一張，因為兩份紀錄回答的是不同的問題。新開一張工單會重設解決時鐘，並把一次失敗的修復報成兩次成功的修復，而這正正是掩蓋服務不穩定的那種失真。在同一份紀錄上重開，可以把歷史保存在一個地方，並令重開率變得可以量度；而重開率是事故流程所能產出的、最誠實的品質訊號。