服務請求和事故怎麼分：三個判斷問題加 20 個分類示例

簡短回答：事故是原本能用、現在壞了或變差的東西。服務請求是用戶向你要一項服務目錄裡已有的、可重複的標準服務。事故的目標是盡快恢復服務；請求的目標是按約定的時間交付約定的內容，通常帶審批。拿不準時，按下面三個問題的次序問一遍。

本文寫給服務台主管、IT 經理，以及要設定工單系統的人。看完後，你可以在一分鐘內把任何一張工單歸到正確類型，用 20 個示例培訓新同事，並建立兩套不同的處理流程，讓日常請求不再被當成緊急故障。

服務請求和事故有什麼分別？

ITIL 4 術語表把服務請求定義為：用戶或其授權代表提出的、啟動一項已被約定為正常服務交付一部分的服務動作的請求。事故則是服務的計劃外中斷，或服務質素下降（2026 年 10 月 28 日核對）。

說得直接一點：

• 事故：「原本能用，現在不能用了，或者比以前差了。」
• 服務請求：「我需要一樣東西，你們已經有標準的給法。」

分清楚的意義，在於兩者的量度和處理方式不同。事故的計時看服務多快恢復；請求的計時看是否在約定日期前交付。混在一起，真正的故障會淹沒在日常工作裡，日常工作又會被當成救火。

三個判斷問題

按次序問，遇到第一個「是」就停。

1. 原本正常的東西，現在壞了、變慢或不穩定嗎？是，就是事故，即使用戶的說法像請求（「請幫我修一下電郵」）。
2. 沒有東西壞的話，用戶要的東西在服務目錄裡，或有標準程序嗎？是，就是服務請求。包括權限、新設備、軟件安裝、帳戶變更和「怎麼操作」類問題。
3. 都不是的話，它是對環境的改動或新事物嗎？那是變更請求（或項目），開工前要評估。如果同類事故反覆出現而原因不明，另開問題記錄，並與相關事故連結。

兩條處理邊緣情況的策略：

• 看用戶需要什麼，不看他怎麼說。「我打不開財務共享文件夾」可能是權限從來沒開過（請求），也可能是共享掛了（事故）。先查這位用戶以前能不能打開。
• 按最初的需要分類。請求在交付過程中失敗，請求繼續保留，並針對失敗另開事故。不要悄悄把一種改成另一種。

20 個分類示例

事故（8 個）

1. Outlook 由今早起連不上：昨天還能用，服務中斷。
2. 共用打印機印出空白頁：原本正常的服務質素下降。
3. 會議室 Wi-Fi 每隔幾分鐘斷線：服務降級。重複報障要連結到同一個主事故。
4. 手提電腦開機藍屏：硬件或作業系統故障。
5. VPN 連得上但內部文件共享打不開：服務的一部分中斷。
6. 某位用戶的 Teams 通話沒有聲音：對該用戶服務中斷。如果影響很多人，就升為更高優先級的事故。
7. 內部網頁應用程式顯示錯誤頁：所有用戶都受影響的服務中斷。
8. 昨晚的備份工作失敗：服務失敗，用戶可能還沒發現，但它仍是事故。

服務請求（8 個）

1. 新同事需要帳戶、手提電腦和電郵郵箱：標準入職項目。
2. 把某人加入共用郵箱：標準的權限變更，一般由郵箱擁有者批准。
3. 安裝已批准的軟件：有成熟程序的目錄項目。
4. 申請某個 SharePoint 網站的權限：由網站擁有者審批的請求。
5. 更換磨損的鍵盤或滑鼠：標準硬件請求。
6. 提高郵箱或 OneDrive 配額：在約定上限內的標準變更。
7. 離職：停用帳戶並回收設備：標準離職請求，常由人事部觸發。
8. 「手機上怎麼設定公司電郵？」：資訊類請求。回答之後，把答案補進知識庫。

邊界情況（4 個）

1. 忘記密碼：標準重設能成功時是服務請求；重設流程本身出錯，或很多人同時無法重設，就是事故。
2. 帳戶被鎖定：解鎖一次是請求；反覆鎖定又找不到原因是事故，通常還要開問題記錄（例如手機上存著舊密碼）。
3. 「我的手提電腦很慢」：比以前慢了是事故；用戶想換一部比標準配置更快的機器，則是需要審批的例外申請。
4. 軟件安裝報錯：安裝本身是請求，報錯是掛在它名下的事故，這樣兩個計時都準確。

兩套處理流程有什麼不同

寫文件時兩套流程用同樣的條目次序，方便同事對照。

事故流程

• 觸發：東西壞了或變差了。
• 目標：恢復服務，暫時繞過的方案也算恢復。
• 優先級：由影響和緊急程度決定。見嚴重程度和優先級的區別和 IT 支援 SLA 優先級 P1 至 P4。
• 審批：開始處理不需要審批。用於修復的緊急變更按變更規則走。
• 時限：按優先級設回應和解決時間。
• 升級：按支援層級向上，再到供應商；影響面大時轉入重大事故處理（見重大事故管理流程）。
• 關閉：用戶確認服務已恢復。重複出現的事故交給問題管理。

服務請求流程

• 觸發：用戶從目錄選一項，或提交標準表格。
• 目標：按約定交付該項內容。
• 優先級：通常每個目錄項目有一個約定的交付時間，而不是影響和緊急程度的評分。特別加急由經理決定，不由用戶自己選「高」。
• 審批：按項目規定（經理、數據擁有者、保安）。無需審批應是例外，而不是預設。
• 時限：每個項目一個交付時間，例如「新同事的設備在入職前一天準備好」。
• 升級：只在審批或交付延誤時才升級。
• 關閉：項目交付，用戶確認，審批和操作都有記錄。

在工單系統裡怎麼設定

1. 把工單類型設為必填，三個選項：事故、服務請求、變更請求。問題是與事故連結的獨立記錄，不是表格上的第四個選項。
2. 用服務目錄產生請求表格，帶上必填欄位（誰、要什麼、開始日期、審批人），減少反覆追問。
3. 每個目錄項目指定負責人、審批人和交付時間。
4. 跑兩種 SLA 計時：事故看恢復時間，請求看交付時間。L1、L2、L3 支援層級可以共用一個隊列，但計時必須不同。
5. 允許重新分類，但要寫明原因並保留歷史。不要刪掉工單再重建。
6. 把上面 20 個示例放進知識庫，讓服務台每次都按同一個標準分類。

常見錯誤

• 所有工單都當事故處理。日常請求得到緊急優先級，真正的故障反而被淹沒。解決：分開類型，分開計時。
• 讓用戶在請求表格自選優先級。人人都選「高」。解決：交付時間來自目錄項目，特別情況由經理決定。
• 因為用戶說了「請」，就把壞掉的東西當請求。解決：每次先問第一個判斷問題。
• 沒有審批路徑。權限請求變成誰先看到誰就辦。解決：每個項目指定審批人。
• 用自由輸入框代替表格。第一次回覆全花在追問缺失的數據上。解決：每個項目設必填欄位。
• 悄悄改類型。統計失真，用戶也困惑。解決：改類型時寫明原因並告知用戶。

怎樣驗證做對了

1. 每月隨機抽 20 張已關閉的工單，對每張重新問一遍三個問題，與記錄的類型比較。
2. 統計被重新分類的工單數量。數量偏高，代表表格或示例需要改進。
3. 確認每張已關閉的請求都寫明了目錄項目，需要審批的也有審批人。
4. 按項目查看交付時間。總是延誤的項目需要重新訂目標或增加人手，而不是多發催辦。
5. 在請求工單裡搜尋「不能用」「報錯」「掛了」之類的詞。每個命中都可能是被誤分類的事故。

常見問題

在 ServiceNow 裡，服務請求和事故有什麼分別？

在 ServiceNow 裡，和在任何工單工具裡一樣，判斷方法相同：原本能用的服務壞了或變差，就開事故；用戶要的是目錄裡的項目，就開請求。兩者用不同的記錄類型，也用不同的 SLA 計時。

重設密碼算服務請求還是事故？

正常的密碼重設是服務請求，因為這是用戶有權獲得的標準操作。如果重設流程本身壞了，或很多人同時被鎖，那就是事故。

服務請求和變更請求有什麼分別？

服務請求要的是目錄裡已有、程序成熟的東西，例如權限或標準安裝。變更請求要修改環境，例如新增防火牆規則或新系統，開工前要評估和審批。

服務請求的 SLA 是多少？

通常是每個目錄項目事先約定的交付時間，而不是按影響程度訂的恢復時間。目標怎樣寫，見 IT 支援裡的 SLA 是什麼意思。

可以給一些事故和服務請求的例子嗎？

可以。上面的 20 個示例包含故障（事故）、標準需求（服務請求）和四個邊界情況。

如果你想要一個已經把事故和請求分開管理、並分別出報告的服務台，請了解我們的 7x24 服務台 IT 支援。