有效工作時間區間
300 分鐘此範例涵蓋已設定支援時段內的五小時。
這是支援應用程式的計算實例。數值為範例計算結果,並非客戶績效宣稱。
此範例涵蓋已設定支援時段內的五小時。
兩段允許扣除的等待分別為 30 與 15 分鐘,不計入解決時間。
範例政策不因等待供應商而暫停計時。
300 − 45。這不是實際投入工時,也不是首次回應時間。
| 衡量項目 | 計時區間 | 計算規則 |
|---|---|---|
| 首次回應 | 回報時間 → 首次記錄的回應 | 依工作分鐘數計算;後續進度備註不會重設首次回應。 |
| 解決 | 本次處理週期加上先前各處理週期 | 僅扣除工單所保留政策允許的等待原因。 |
| 結案期間 | 解決 → 重新開啟 | 不要將結案空檔加入新的處理週期。 |
| 支援工作日曆 | 週一至週五,每日一個服務時段 | 排除已設定的休息日期,並使用記錄中的 UTC 時差。 |
將第二段允許扣除的等待從 15 分鐘改為 5 分鐘後,同一範例的合計會變成 265 分鐘。更正會更新連結工單的計算結果,不會保留過時的複製總數。
重新開啟後再累計 60 分鐘工作時間,加上先前的 265 分鐘,合計為 325 分鐘。結案後跨夜的區間不屬於有效解決時間。
目標狀態與連結的升級處理記錄,會指出哪項承諾需要主管關注。請記錄負責人的處理措施;只有狀態顏色不代表已採取行動。
明確列出休息日期,並避免重複。此範例支援固定 UTC 時差,以及週一至週五每日一個服務時段,不支援輪班或自動切換日光節約時間。
未結案工單會依可設定的排程重新檢查;此範例每 15 分鐘檢查一次,並非持續監控。排程檢查與記錄觸發的更新都會消耗自動化執行次數,請依未結案工單數量選擇間隔與方案。
不等於。經過時間可能包含夜間、週末、結案期間及允許的等待。解決計時依設定的工作日曆與暫停規則計算,技術人員實際投入工時則另記於工作記錄。
此範例透過明確的「首次回應」活動記錄。服務政策應定義何謂有效回應,不應默默將自動收件通知視為人工答覆。
在服務日曆中維護休息日期,工作時間計算會排除符合的日期。用於合約報告前,請先確認日曆與固定 UTC 時差。
不支援。它採用週一至週五每日一個服務時段與固定 UTC 時差。每日多班、輪班、自動切換日光節約時間及複雜合約日曆,需要額外設計或專門的服務工具。
記錄變更會觸發重新計算,未結案工單也會定期檢查,此範例設為每 15 分鐘一次。可能要等到檢查執行才會偵測到逾時,請勿將其視為即時服務中斷監控。
不能。自動化執行次數與資料用量皆有方案上限。先以未結案工單數乘上排程檢查次數估算,再加入活動觸發的自動化用量,據此選擇間隔與方案。
查看計算方式與等待歷程,再依團隊可落實的政策,調整目標、服務時段及升級處理負責人。