退款審查系統上線兩個月後，Tool Team 在季度報告裡放了一個不太好看的數字。

Fully Automated Rate: 0%
Human Review Rate: 100%

系統其實已經會讀客戶來信、查訂單和付款紀錄、比對退款政策、算出建議金額，也能先把回覆草稿寫好。

審查人員打開案件後，畫面上只剩三個按鈕：

Approve
Request Change
Reject

上線前，每筆案件平均十二分鐘。現在多數不到兩分鐘。

但既然每筆都還要由人按下核准，報表自然把它算成「尚未完成自動化」。下一季的目標也很直白：降低人工 Review 比例。

直到營運團隊把一週的案件紀錄拉出來，才發現這個目標本身有問題。

六百二十七筆案件，都叫人工 Review

那一週共有六百二十七筆退款案件。

報表裡，這六百二十七筆只有同一個狀態：Human Reviewed。

但前四百多筆，審查人員沒有重新查訂單、找政策或重算金額；他們只是確認系統整理出的關鍵資料沒有明顯問題。

最後十八筆則不同。十一筆修改了建議、四筆直接拒絕、三筆轉交財務或法務。這才是人真正需要介入判斷的地方。

系統把兩種工作放進同一個佇列，用同一個按鈕完成，也用同一個 KPI 計算。管理層最後只看見「人還在流程裡」，看不見人留在裡面的原因。

人按下核准，不代表人重新做了一次工作

企業常把自動化切成二選一：

沒有人工介入 = 自動化成功
仍需人工確認 = 自動化失敗

這套判斷放在檔案改名、資料轉檔、固定欄位檢查，沒有太大問題。規則明確，錯誤也容易回復。

退款、合約審查、異常分流這類工作不一樣。它們有資料缺漏、有例外、有權限與責任問題。人被保留在流程裡，不一定是系統做不到，也可能是組織決定不把某種責任交出去。

真正該看的不是人工按鈕有沒有消失，而是人工在按下按鈕前做了什麼。

若審查人員仍得重新查每個系統、自己判讀政策、重算金額、再重寫一封回覆，那這個 Agent 的確只是多了一層介面。

若人只確認幾個關鍵欄位，或者只處理 Agent 標出的異常，前面原本花掉的十分鐘已經被拿走。最後留下的十秒核准，不該和「整筆案件仍由人工處理」混為一談。

這個差別，會直接改變團隊下一步該優化什麼。

先分清楚 Review 是為了什麼

同樣叫人工 Review，至少可能是三種不同工作。

如果不分，組織很容易走向兩個極端：所有案件都要人工點一次，或為了追求全自動，直接拔掉所有人工 Gate。

前者把節省下來的時間浪費在形式核准；後者則把真正該由人承擔的風險一起移掉。

所以「人工 Review Rate 降到 20%」不是一個好目標。它只會逼團隊減少人的出現，卻沒有說哪些工作可以安全地不讓人出現。

不是取消 Review，而是不要讓所有案件走同一條路

退款團隊後來沒有直接調低人工確認率。他們先把案件分流。

差別不在於 Green 案件完全不需要人，而是人不必再替每一筆正常案件證明一次系統沒出錯。

Yellow 案件也不是把完整工作丟回人工。審查人員應該看到的是系統已找出的矛盾、缺少的資料與可能影響，而不是一張等待從頭處理的空白 Ticket。

Red 案件則不該假裝 Agent 可以代替決策。它的產出到「資料與風險整理完成」就停止。後面由誰決定、決定後怎麼留紀錄，是另一段工作。

這樣一來，Dashboard 該看的欄位也會改變：

• Green 案件的抽樣錯誤率
• Yellow 案件的人工修改率與平均處理時間
• Red 案件的攔截率與轉交時效
• 各類案件實際被重新處理的比例

Human Review Rate 可以保留，但它不再單獨代表成敗。

人工留下來，不代表流程沒有變

新版上線後，審查首頁不再堆著六百多筆相同的 Needs Review。

Green：438 筆已自動完成
Yellow：27 筆等待營運審查
Red：4 筆等待專業處理
Quality Sample：15 筆

審查人員還是在流程裡。

但她看到的已經不是所有案件，而是 Agent 無法安全處理的那一小段。她要做的也不再是重跑整個退款流程，而是確認例外、修改判斷，或把不該由自己承擔的案件送到正確的人手上。

企業導入 AI 後，不必把「完全不需要人」當成唯一成功定義。

若人工工作從重複執行，變成例外判斷、責任核准與品質校正，這份自動化已經開始改變工作。下一步該處理的是剩下的人工環節是否真的有必要，而不是為了讓 KPI 好看，先把人從流程圖上刪掉。