如何製作客服工單報表：逐步指南
客服工單報表本質上大多是定義的問題。建立的工單、解決的工單、首次回覆時間和解決時間，聽起來都很直觀。但在同一個客服系統中，每一個指標都有不只一種官方定義。
只要明確制定計算規則，報表自然水到渠成。跳過這個步驟，兩個誠實的人匯出相同的資料，算出來的結果可能會相差好幾個小時。
本指南將介紹報表中應包含的內容、定義產生分歧的四個地方，以及如何透過工單匯出檔案來建立報表。
客服工單報表應包含哪些內容
單看工單數量幾乎無法說明任何問題。合理的編排才能讓數據呈現真實的意義。
| 要素 | 存在的原因 |
|---|---|
| 期間內建立的工單 | 需求端 |
| 期間內解決的工單 | 供給端（依據明確的狀態規則） |
| 期末積壓工單 | 所有未解決或未關閉的工單 |
| 首次回覆時間 | 依據明確的時間計算方式與定義 |
| 解決時間 | 首次或完整解決，需明確標示 |
| 重新開啟的工單 | 其他數據所隱藏的品質訊號 |
| 未回覆的工單 | 流程完全失效之處 |
| 明確的日期基準與範圍 | 包含哪些管道、品牌和佇列 |
有兩列數據的分量比表面上看起來更重要。重新開啟和未回覆的工單，是讓報表不再只是個記分板，而是開始發揮實用價值的關鍵。
Zendesk 公布了底層的計算公式，這讓定義變得可以驗證，而不再只是各執一詞。其 指標與屬性參考指南 詳細列出了每一項。
先從最簡單的開始。解決的工單是指「已解決或已關閉的工單數量」，因此該指標涵蓋了兩種狀態，而非僅有一種。
「首次回覆時間」有兩種官方定義
這是最容易引起爭議的分歧點，且系統廠商也直接對此提出了警告。
Zendesk 的 SLA 說明文件 用一句話點明：「請勿將 SLA 回覆時間與 Zendesk 原生的回覆時間指標混淆。」
原生指標對於「由誰回覆」有嚴格的限制。Zendesk 指出「首次回覆時間完全是根據專員的回覆來計算」。自動化和機器人相關的操作「在計算首次回覆時間時不會被考慮在內」。
但 SLA 指標則不然。在 SLA 中，首次回覆時間是「工單建立與專員首次發表公開留言（或自動回覆）之間的時間」。Zendesk 補充說明，「如果您設定了觸發程序以公開留言進行自動回覆，即可滿足回覆時間指標的要求」。
將這兩者結合來看，結果顯而易見。自動回覆可以滿足您的 SLA 目標，但原生的首次回覆時間卻會繼續累計。
因此，一份顯示 98% SLA 達成率和 4 小時首次回覆時間中位數的報表並沒有自相矛盾。它只是正確地報告了兩件不同的事情。
還有兩個值得注意的小例外。以專員建立工單且第一條留言為公開留言的情況為例，時長指標參考指南 指出，第二個時間戳記會「轉移到專員的第二條公開留言」。
此外，共用的工單不予計算。Zendesk 指出，當專員使用工單共用功能從另一個帳戶發表公開留言時，「這不會計入您帳戶的首次回覆時間」。
「解決時間」也有兩種定義
相同的分歧也存在於解決時間指標中，而且系統預設會同時提供這兩種版本。
首次解決時間是「工單建立到首次解決之間的時長」，結束於「工單狀態首次被設定為已解決的時間」。
完整解決時間是「工單建立到最近一次解決之間的時長」。它結束於「工單狀態最後一次被設定為已解決的時間」。
對於只解決過一次的工單，這兩者是完全相同的。但對於被解決、重新開啟、然後再次解決的工單，兩者之間就會產生差距，差距的時間取決於第二輪處理花了多久。
這正是為什麼重新開啟的工單必須包含在報表中的原因。Zendesk 將其定義為「解決後重新開啟」的工單，並指出該指標「不包括在同一次更新中被解決並重新開啟的工單」。
還有一個人們常忽略的次級效應。每日平均解決工單數「僅在工單目前處於已解決或已關閉狀態時」才會將其計入。因此，今天被重新開啟的工單，會悄悄地從上個月的已解決工單數中剔除。
因此，您在 6 月產生的報表，到了 8 月就無法重現相同的數據。這並非系統出錯，而是底層的狀態發生了變化。
另外還有兩個指標可以區分「等待時間」與「處理時間」。請求者等待時間是工單處於「新建」、「開啟」和「暫停」狀態的累計時間；而專員等待時間則是工單處於「待處理」狀態的累計時間。
這兩個指標回答了平均解決時間無法解答的問題。因等待客戶回覆而導致的解決時間過長，與因佇列過長而導致的解決時間過長，本質上是完全不同的問題。
日曆時數或工作時數
每個回覆和解決數據都存在於兩種時間計算方式中，您必須從中做出選擇。
Zendesk 會同時儲存這兩者。在首次公開回覆後，「系統會以日曆時數和工作時數來計算首次回覆時間」。這兩個指標「都會與工單資料一起儲存」。
您看到的預設值並非中立。Zendesk 指出，預建的 Explore 報表「以日曆時數顯示預建報表中的資訊」。工作時數指標「是可用的，且可用於您自己建立的報表中」。
因此，對於朝九晚五的團隊來說，在預設報表上的表現會顯得效率低落。週五晚上 6 點送達的工單，到週一早上大約會累積 63 個日曆小時，但工作小時卻接近於零。
即時對話管道還帶來了另一個複雜情況。簡訊和線上交談的「首次回覆時間（秒）」指標「會忽略您的簡訊工作時數和線上交談服務時間設定」。
此外，線上交談回覆時間的 SLA 是需要手動啟用的。Zendesk 指出，線上交談的回覆時間 SLA「預設為關閉」，因此沒有顯示該數據只是因為未配置，而非表現完美。
如何手動製作報表
方案 1：每個指標類別使用獨立的分頁
匯出包含指標欄位的工單清單，然後在進行任何加總摘要之前，先將工單量、回覆時間和解決時間拆分到不同的分頁中。
將日曆時數和工作時數欄位並排保留，而不是在匯出時只選擇其中一個。因為之後一定會有人向您索取另一個數據。
針對時間指標，請計算「中位數」而非「平均值」。少數在連假期間未處理的工單，會將平均值拉高到一個與實際情況完全脫節的數值。
這種做法的限制在於，試算表無法查看狀態歷史紀錄。您只能取得每張工單的目前狀態，因此重新開啟的行為必須來自「重新開啟次數」指標，而無法透過事後重組來得知。
方案 2：先寫好一個「定義」分頁
記錄回覆時間的定義、時間計算方式、解決時間指標、已解決的狀態規則、納入範圍的管道以及日期基準。
接著記錄這份報表「未」聲明的事項。寫下 SLA 達成率與原生首次回覆時間測量的是不同內容，可以防止熱心的同事將它們混為一談。
限制也顯而易見。記錄規則並不等於執行規則，到了下個季度，可能又會有人憑記憶重新建立樞紐分析表。
方案 3：先細分再計算平均值
在計算任何時間指標之前，先按管道進行細分。電子郵件、線上交談和電話工單的處理邏輯截然不同，混合後的中位數無法反映任何真實情況。
接著排除或標記會扭曲數據的工單。等待客戶回覆長達數週的工單應該單獨列出，而不應計入平均解決時間中。
說明您排除了哪些內容以及數量有多少。如果讀者看不到篩選條件，就會預設沒有進行任何篩選。
限制在於細分會使工作量倍增。3 個管道乘以 2 種時間計算方式再乘以 2 種解決時間指標，就意味著有 12 個數據需要釐清。
共同的限制。 這三種方案都假設匯出的資料針對每個佇列都採用相同的日期範圍與日期基準。在不同分頁中混用不同的日期範圍，是此類報表中最常見且不易察覺的錯誤。
手動方式在哪裡會遇到瓶頸
製作第一份客服工單報表需要花費一個下午。到了第四份時花的時間會更長，因為底層的客服系統已經發生了變化。
啟用新管道後，混合中位數會因為與實際表現無關的原因而發生變動。為新區域修改了工作時數，所有歷史工作時數數據也會隨之改變。
接著是「重新開啟效應」。上個季度的數據再也無法重現，而解釋原因所花的時間，甚至比重新製作報表還要長。
還有第四種只有在面臨壓力時才會顯現的成本。當有人詢問本季度的客戶支援速度是否變快時，一個誠實的回答必須先說明時間計算方式、定義以及管道組合。
關於客戶滿意度方面的分析，請參閱我們的 建立 NPS 報表 指南。如果工單量本身才是問題所在，我們關於 建置售前客戶支援 AI 代理 的逐步教學則涵蓋了分流引導的部分。
如何使用 Powerdrill Bloom 建立報表
步驟 1：上傳您的工單匯出檔案
上傳工單匯出檔案，或同時上傳工單與 SLA 匯出檔案。Powerdrill Bloom 會在檔案匯入時分析欄位，因此在計算任何中位數之前，空白的時間戳記、混合的日期格式以及缺少首次回覆的工單都會先被找出來。
步驟 2：用自然語言描述報表
直接說明定義，而不需要重新建構。指定回覆時間定義、時間計算方式、您需要的解決時間指標、已解決的狀態規則以及納入範圍的管道。
然後提出有助於找出錯誤的問題。例如：詢問有多少工單完全沒有專員回覆？哪些工單被重新開啟？要求提供每個管道的中位數，而非單一的混合數據。
步驟 3：匯出圖表、報表或簡報
匯出每個管道的指標表格，或是建立與解決工單對比（背景為積壓工單）的圖表。在同一輪操作中，即可產出在數據旁附帶定義說明的簡報投影片。
常見錯誤
將 SLA 達成率當作首次回覆時間。 前者接受自動回覆，而後者則完全排除自動化操作。
將日曆時數與工作時數進行比較。 預設報表提供的是前者，而您的目標很可能是基於後者設定的。
在回覆和解決時間中使用平均值。 少數被遺棄的工單會將平均值拉高到一個與實際情況完全脫節的數值。
混合不同管道。 線上交談和電子郵件的中位數在設計上本就不同，混合計算會掩蓋這兩者的真實情況。
在未說明是哪一種的情況下報告解決時間。 首次解決時間和完整解決時間是分開儲存的獨立指標，而非四捨五入的變體。
將已解決的工單數視為最終數據。 已解決工單數僅包含目前處於已解決或已關閉狀態的工單，因此重新開啟工單會改變過去的數據。
遺漏未回覆的工單。 它們被定義為專員回覆次數少於 1 次的工單，是報表中所能呈現最明顯的流程失效指標。
結論
指定回覆定義、指定時間計算方式、選擇首次或完整解決時間、說明狀態規則、按管道進行細分，並顯示重新開啟和未回覆的工單。這樣就能製作出一份具備實用價值的客服工單報表。
不過，這份報表可能無法直接與其他公司的數據進行比較。由於定義是可自訂的，您在其他地方看到的基準數據，其測量規則幾乎肯定與您不同。
相反地，您應該在固定的規則下，與自己的歷史數據進行對比。只有這樣，才能真正看出服務品質是否有所改善。
如果每個月重新製作報表會耗費您一整天的時間，不妨試試用 Powerdrill Bloom 來處理您的工單匯出檔案。另請參閱 AI 報表產生器 頁面和 客戶聲音摘要工具。
常見問題
為什麼我的 SLA 達成率與首次回覆時間不符？
它們測量的是不同的事件。Zendesk 的 SLA 首次回覆時間可以透過自動回覆來滿足，而原生的首次回覆時間指標則完全排除自動化和機器人操作。
我應該報告首次解決時間還是完整解決時間？
報告您明確指定的任何一個即可。首次解決時間結束於工單首次被設定為已解決的時間。完整解決時間則結束於最後一次，因此重新開啟的工單會使這兩者產生差距。
客服指標是以日曆時數還是工作時數來計算？
兩者都會儲存。Zendesk 預建的 Explore 報表顯示日曆時數，而工作時數指標則可用於您自己建立的報表中。
為什麼上個季度的已解決工單數會發生變化？
已解決工單數僅包含目前處於已解決或已關閉狀態的工單。在該期間結束後重新開啟的工單，會從該期間的計數中剔除。
我可以將我的解決時間與產業基準進行比較嗎？
只能進行粗略的比較。由於定義、時間計算方式和管道組合都是可自訂的，因此公開發布的數據很可能是基於與您不同的規則測量出來的。