資訊科技服務台流程圖（事故與服務要求）
服務台流程圖：事故與服務要求共用一個受理隊列，涵蓋分流分類、優先次序、一線修復、二線升級、要求交付與關閉確認。
運作方式
把泳道改成你們真實的角色
把用戶、服務台、二線支援、資產與採購，以及問題管理，換成你們實際擁有的團隊。規模較細的機構經常把資產與採購併入服務台泳道，而問題管理可能是一個指定的人，而不是一個團隊。每個決策者一條泳道，而不是每個人一條，這樣有人轉職時圖仍然用得上。
寫下區分事故與服務要求的判定準則
「事故還是服務要求？」這個分岔，只有當工程師可以在數秒之內作出判斷時才有用。把判定準則寫在決策旁邊：是本應正常運作的東西壞了，還是用戶在要求一件標準的、事先議定好的工作？把你們真實存在的臨界情況列出來，例如一部變慢的手提電腦與一份換新機的申請，並寫明每一種各走哪條路。
公開你們的優先次序矩陣
把你們對影響程度和緊急程度的定義附在「按影響程度和緊急程度訂定優先次序」上，寫明每個優先級別在受影響用戶數目和業務後果上分別代表甚麼。把這張矩陣放在用戶看得到的地方，正是令優先次序變成推導出來的結果、而不是逐張工單爭論出來的關鍵。
訂定一線的界線，以及一次升級必須帶甚麼
界定一線獲准、亦有能力修復的範圍，以及二線接手之前，一次升級必須包含哪些內容：已經嘗試過的步驟、受影響的服務、證據，以及用戶何時方便聯絡。同時決定是否要加一道以時間為本的兜底規則，把毫無進展的工單自動升級，並寫明交接之後由誰負責這張工單。
決定哪些需要審批、哪些屬於事先批准
把低成本、低風險的目錄項目標記為事先批准，讓它們完全繞過「直屬主管是否批准該要求？」，把這道關卡留給開支、授權，以及任何會改變一個人可以存取甚麼的要求。如果要求的是系統權限，就移交你們的存取申請流程，而不是在這裡批准。
就關閉、重新開啟和問題移交達成共識，並只發佈一個版本
寫明甚麼算用戶確認、一張已解決的工單要等多久才自動關閉，以及「是否屬重複或已知問題？」上觸發問題紀錄的準則。然後帶着每條泳道的人走一次這張圖，修正他們實際執行的步驟，並把它作為現行版本發佈，附上已記錄的批准，令所有人讀的是同一個修訂版。
常見問題
服務台流程和事故管理有甚麼分別？
服務台流程是服務台本身的運作流程：任何渠道進來的每一次聯絡，都被導向對應的處理方式。事故管理是它裡面的一條支線，只處理服務的非計劃中斷。ITIL 4 正是出於這個原因，把服務台、事故管理、服務要求管理和問題管理當作各自獨立的實務，儘管小團隊通常由同一批人在同一個隊列裡把它們全部完成。這張圖是服務台層面的視角，展示這些支線如何共用一個受理入口和一個關閉動作，並把事故的深層細節——例如重大事故的宣佈和 SLA 逾時升級——交給事故管理流程。
事故和服務要求有甚麼分別？
事故是本應正常運作卻沒有運作的東西：登入失敗、打印機離線、應用程式報錯。服務要求是標準的、事先議定好的工作，不涉及任何故障：新軟件、一個授權、一部替換裝置、為新入職同事開設一個郵箱。這個區分之所以重要，是因為它幾乎改變了下游的一切。事故按影響程度和緊急程度得到優先次序，量度的是復原；要求走審批和交付路徑，量度的是交付。把兩者混在一起，要麼令例行要求掛在故障時鐘上，要麼令真正的故障排在手提電腦訂單後面。
服務台工單何時應該升級到二線？
當這項工作超出了一線的技能、工具或權限界線時就升級，這屬於職能升級。它與層級升級是兩回事：層級升級是因為影響或延誤已經由技術問題變成業務問題，才把管理層拉進來。不少服務台會加一道以時間為本的兜底規則，令毫無進展的工單自動升級；這作為安全網相當有用，但單獨用作主要規則並不理想。無論觸發條件是甚麼，交接都必須帶上已經嘗試過的內容，否則二線會把第一小時花在重複一線的工作上。
工單可以在用戶確認修復之前關閉嗎？
已解決和已關閉是兩種不同的狀態，這張圖把它們清楚分開。工程師在修復完成時把工單標記為已解決；只有當「用戶是否確認已修復？」得到「是」，工單才會關閉。如果用戶表示問題仍然存在，工單會重新開啟並返回一線，而不是開立一張新的，這樣歷史紀錄和最初的時鐘才會留在一起。由於總有一些用戶從不回覆，多數服務台會設定數個工作天的自動關閉時限，並先發一次提示，同時把這個期限寫入服務說明，令關閉不會令人措手不及。
涉及採購的服務要求如何納入這個流程？
它們走交付分支：目錄要求審批的先審批，然後是「物品是否有存貨？」，要麼由現有存貨發出，要麼在交付前開立採購訂單。人們最常略過的一步是更新資產紀錄，所以這裡把它放在與交付同一個節點上。如果在發出的那一刻不更新資產登記冊，授權數量和硬件更換規劃在數個月內就會失準。對於金額較大或目錄以外的採購，服務台提出需求，由更完整的採購訂單流程接手，它有自己的供應商挑選和發票核對環節。