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