擴大AI收件量之前，先預留例外處理預算

概覽

給營運負責人的決策備忘錄

建議： 對下面這家假設的服務企業，在有足夠預算支持例外處理之前，不要把自動化收件量加倍。應先核准有限的收件上限，並透過可衡量的試驗改善分流。真正的限制是人工例外處理能力。

本備忘錄使用虛構的營運資料，金額單位為美元。它們用於說明產能決策，並非實際客戶成果、供應商報價或財務預測。

桌上的擴量提案

團隊每週處理1,000筆請求。AI流程負責例行分類，但其中12%仍需人工解決資料缺漏、指示矛盾或不受支援的情況。每個例外平均需要8分鐘實際操作時間。團隊每週可以安排20小時處理這類工作。

原創產能表：假設的平均值，不包括等待客戶回覆的時間。

剩餘4小時聽起來不算少，但只夠處理30個平均難度的例外。會議、員工缺席或更複雜的個案組合，都可能耗盡這點餘裕。應把實際操作時間與等待時間分開統計，否則客戶回覆慢，很容易被誤判成人手不足。

如果例外率不變，卻把收件量加倍至2,000筆，就會產生240個例外，需要32小時。現有產能只能處理150個平均難度的個案，每週將累積90個未解決個案。模型呼叫再便宜，也不能補上缺少的12個人工小時。

AWS關於隊列積壓的指引說明，當到達速度超過處理能力時，延遲可能持續擴大，最終完成的工作也可能已經失去時效。將這個工程經驗用於人工例外隊列，是本文的營運類比，不是AWS提供的人力配置公式。 AWS Builders’ Library，發表於2019年12月5日；核驗日期：2026年10月29日。

下次預算會議上的三個選擇

假設規劃時按每個人工操作小時40美元計算。承諾增加收件量之前，先比較不同方案。

原創方案表：數值經過四捨五入；改善情境尚未得到驗證，也未包含實作成本。

看似零成本的方案會用盡全部名義產能，沒有空間應對波動。同樣，承諾把例外率降到8%，並不等於預算已經節省。必須先透過試驗說明：哪些例外消失了，是否確實得到了正確解決。悄悄放行難處理個案，也能讓比例變好，卻會讓服務變差。

優先試驗消除一個反覆出現的原因，例如在提交前要求補上遺漏的參照編號。個別記錄工程投入和持續維護成本。評估試驗時，應看未解決個案是否減少、處理結果是否合格，而不只是被貼上「例外」標籤的數量有沒有下降。

核准條件

在這個示例中，應先把每週收件量限制在1,000筆，同時收集有代表性的處理時間分布。明確指定誰能承接超額工作、哪些承諾需要優先處理，以及何時必須如實告知新請求預計完成時間有所延長。

原創決策表：建議的控制措施，不構成自動拒絕客戶工作的授權。

不要為了讓儀表板好看而刪除棘手個案。保留原請求、應履行的責任及解決路徑。只有實際觀察到的例外處理需求能落在已安排的人力產能以內，並留出明確餘裕，擴量才比較合理。預算會議最終應確定收件上限和有資金支持的解決方案，而不只是核准更多AI用量。