目前積壓要幾天才能清完？用待辦量與實際完成量估算覆蓋天數

用固定待辦截點與明確觀察窗，將實際完成速度換算成積壓覆蓋天數，並辨認新增工作與案件難度造成的估算限制。

估算積壓清理時間，先把「目前有多少件」和「在明確期間內實際完成多少件」放在同一口徑下，再換算成可執行日數。這是依過去節奏推估的覆蓋天數，並非承諾清空日期；新工作持續進來、案件難度改變或人力調整，都會讓結果偏移。以下用假設數字示範如何建立可重複更新的估算。每次比較都沿用同一口徑，結果才有意義。

固定待辦統計時點

先約定每次統計的截點，例如每週一上午九點，並記下日期、時區與資料來源。若不同人各自挑方便的時間截圖，剛建立或剛結案的事項可能重複計入，週與週之間也無法公平比較。統計範圍要固定到相同隊列、負責團隊和狀態；例如只算已承諾但尚未完成的工作，不把待確認需求、已取消事項或等待對方回覆的項目混進可立即處理的清單。若有多個看板或表單，先用唯一編號去重，明確說明子任務是否另算一件。

清點時同時保存總件數和分類件數，例如待處理、處理中、卡住；是否納入卡住項目，取決於問題是「團隊還欠多少工作」還是「現在可動手的工作有多少」。前者通常保留卡住項目，後者另列可處理數，不能偷偷把兩種口徑合成一個數字。假設週一九點同一隊列有84件未結案事項，其中10件等待外部資料，紀錄可寫「積壓84件；可立即處理74件；截點為週一九點」。下次沿用同一規則，才看得出總量下降是否只是狀態搬移。若資料匯出有延遲，也記錄延遲多久，避免把報表時間誤當實際截點。保留當時清單或篩選條件，讓同事能重做一次統計。

還要把尚未開始與已開工但未結案分開標記，避免團隊用不同理解把進行中工作排除。若工作會因拆單或合併而改變筆數，記下母子關係，整個期間沿用同一計數單位；跨部門轉派只改負責人時，不應把它當成新進一件。這能避免報表增減其實只反映資料整理。必要時抽查幾筆來源記錄，確認清單中的狀態和編號仍符合統計定義。

選擇完成量觀察窗

觀察窗要夠長，能涵蓋例行波動，又不能混入已經不代表現況的工作方式。固定排班、每天都有處理紀錄的團隊，可先看最近十個工作日；工作量按週期起伏、假日或月結影響明顯時，延伸到四至八週，並把特殊期間標出。這些是選窗的實務起點，不是通用標準。不要只挑最忙的幾天或最好的一週，否則分母會被選擇方式扭曲。

起訖日應落在同類工作日，並明確使用日曆日、排班日或實際營運日。若週末無人值班，就不應把週末算成有產能的工作日；若客服七天輪值，則可以用日曆日，但要確認排班涵蓋每一天。先檢查觀察窗內是否有停工、系統轉換、新人訓練、大型專案切換或臨時加班，這些要註記，而不是悄悄刪掉低產出的日子。

例如要估客服佇列，先選最近十個完整排班日，依案件結案日期拉出每天的完成量，再與前一個十日窗並列。如果前窗包含停班日，需照樣保留並註明，或另做「正常排班日」比較；不可一邊計算完整日曆天、一邊把假日排除。最後將窗長和納入規則寫在報表標題，像是「截至週一，最近十個排班日」。若流程剛改版，舊窗與新窗分開呈現，避免用舊流程速度冒充現在的基準。

若新流程剛導入，窗口內前半段可能仍是舊做法；可以把轉換日切開，分別計算，不要混成單一平均。窗口越長通常越能平滑偶然波動，但會降低對近期變化的敏感度，因此可同時看最近十日與前一段十日：兩者方向一致時信心較高，差異很大時先查排班、需求或工作類型，再決定以哪一段做短期排程。若只有零星日期資料，先補齊完成日與休假紀錄再估算。

計算每日完成速度

速度的分子是觀察窗內真正完成並通過團隊定義的結案條件之項目數，分母是同一窗口內的預定營運日數。公式為「每日平均完成量＝完成件數總和÷營運日數」。應以完成日期計入，而非建立日期、指派日期或第一次開始處理日期；若項目結案後常被退回，先定義以首次結案還是穩定結案為準，並保持每期一致。這個數代表整個隊列的平均吞吐，不等於每位同事個人產能。

假設最近十個營運日的完成量如下，合計120件，平均就是每日12件：

分母要按預先說好的班表算，即使某天沒有結案也保留該日；若只除以「有完成紀錄的天數」，低產出日會消失，速度看起來偏快。若窗口中有半天停班，團隊可以換算成等值營運日，但要記錄算法。計算前核對重開案件是否重複計數、批次匯入是否造成單日尖峰，以及不同隊列是否混算。例子中的數字只示範算法，不代表任何行業標準。若完成量集中在少數日期，也要同時展示每日序列，平均值才不會掩蓋忽高忽低。記錄窗口與總完成量，讓下週能用相同口徑更新。

同一案件若在觀察窗內被多次關閉，必須避免把重開又結案算成多件產出；可以以唯一案件編號按結案事件去重，或明確把每次處理回合當單位。兩種方法都能使用，關鍵是分子與積壓件數採同一單位。若管理者只看團隊總量，也不必先按個人排名；個人差異可能來自案件分派、值班比例和支援工作，不代表每人承接相同工作。

估算積壓覆蓋天數

基本換算是「積壓覆蓋天數＝截點的未結案件數÷觀察窗的每日平均完成量」。沿用假設例子，84件除以每日12件，得到7個營運日。這表示若接下來工作組成、排班與完成速度接近觀察窗，而且沒有新工作加入這個積壓範圍，現有清單約需七個營運日處理完。若團隊只在週一至週五營運，七個營運日大約跨越一週半的日曆時間，實際落點要按假日和班表換算，不能把七日直接寫成確切日期。

持續有新事項進來時，單純相除只描述現有工作的「毛覆蓋量」，不等於佇列真的會歸零。若每天新進4件且每日仍完成12件，在簡化假設下淨減少速度為8件，84件約需10.5個營運日；若每日新增量等於或超過完成量，現有積壓就不會按這個模型逐步清空。新增和完成必須採用相同隊列範圍、日期規則與件數單位，否則淨速度沒有解讀價值。

報告時保留未四捨五入結果，再以方便排程的方式呈現，例如「7.0個營運日，約7個營運日」，不要假裝模型能預測某天某時清零。若結果小於一天，也要註明依目前平均需不足一個完整營運日，而非零天。每次更新時說明這是簡單覆蓋估算還是扣除新增後的淨清理估算，讀者才能知道數字回答哪個問題。

結果應使用原單位表達。若一天的計算速度是12件，而截點有84件，估算值是7個排班日；若用四捨五入到整日，可向上取整為7日，不能向下取整讓排班看起來更短。當比值是7.2日，排程上呈現約7.2日，若需完整工作日則採8日並說清規則。將「估計清理日」與「預定承諾日」分開欄位，避免推估被轉述為對外承諾。

標記案件難度變化

件數把每個項目看成同樣大小，但實際工作可能差很多：有的只需補一個欄位，有的必須跨部門確認或等候外部回覆。當近期結案多為簡單事項，而積壓中複雜案占比升高，直接用平均完成件數除積壓件數，常會低估所需時間。先對照積壓與已完成工作的類型、優先級、等待狀態、年齡，以及是否需要專業人員；用相同分類列出各類件數，不必急著把每件事換算成看似精確的工時。

例如，假設十日窗口完成120件，其中90件是可在一次接觸內處理的簡單事項，30件需多方確認；此時隊列尚有84件，但其中一半為需多方確認的案件。報告可同時列出總件數覆蓋天數7日，以及簡單、複雜兩類的數量和近期各自完成量。若複雜類型過去十日只完成15件，平均每天1.5件，按1.5件／日粗估，複雜類42件約需28個營運日，仍要考慮兩類是否共用人力。這些分類是協助比較的工作標籤，不是所有團隊共用的難度分數。

若團隊已有可靠的預估工時，可另以預估工時總量除以同期完成工時，作為工作量視角；不要把自行設定的1、3、5分包裝成客觀單位。當分類比例明顯改變、等待案件增加或某類工作長期卡住時，將總件數估算標為參考，並用分層結果安排人力或先處理阻塞。每期保留分類定義，變更時新舊口徑並列一段時間，否則分類調整本身會造成假性趨勢。

也可追蹤最舊案件落在哪個年齡區間，因為同樣84件，若大量項目已等待數週，平均覆蓋天數不會說明服務風險。把超過團隊自訂等待界線的案件數獨立列出，界線由團隊依承諾與資源設定，不套用未經確認的行業標準。

每週更新並比對

選一個固定週期和截點，例如每週一九點，更新積壓件數、前一觀察窗完成量、平均每日完成速度、覆蓋營運日數及同期新增量。把本週估算與上週估算並排，也記下前一週實際經過幾個營運日、積壓最後何時降到零或是否仍未清空。若未清空，不要把預測誤差藏起來；比較當時假設和實際情況，例如新增超出預期、有人休假、複雜案件比例提高，或卡住事項沒有解除。這些差異可指出下週應重新檢視的變數。

使用短表即可：截點、未結案數、窗口天數、完成總量、日均完成、同期新增、估算覆蓋日、實際清理日、偏差原因。每週固定使用同一欄位和單位；若決定把窗口由十日改為四週，另註明切換週，必要時同列舊窗與新窗結果，避免誤以為速度突然改變。對比數字的目的在修正假設，不是追求預測永遠命中。若新增資料缺漏，明確標成待補並暫停比較該週，別用猜測補成完整觀測值。

可以保留連續數週的小型紀錄表，而非只覆寫儀表板上的最新數字；沒有歷史快照，就難以追溯估算失準來自資料口徑還是實際變化。出現一次很大的落差先註記事件，持續多週方向一致再調整基準，避免因單週異常來回修正。對外分享時只提供理解這個估算所需的口徑、窗口和假設，內部的原始案件資訊則依團隊既有存取方式處理。

現在可先選定一個固定截點，匯出同一隊列的未結案清單，再取最近十個營運日的逐日結案數，照本文公式算出第一版並標註假設。若你正在重新整理工作流程或系統需求，可到ZhenheAI 官網了解品牌目前資訊。