退菜原因應把「客人怎麼說」「現場發生什麼」和「後續確認的原因」分開記。顧客說太鹹，是回饋；廚房查到調味與規格不符，才是已確認的製作原因。兩者有關，但不能在聽到第一句話時就把責任與改善措施全部定案。
退菜事件也不等於同樣重量的廚餘。可能整盤退回、只剩一部分，或餐點尚未製作就取消。保留事件與物料結果兩條記錄，才不會把訂單取消數直接當成浪費份數。
先定義哪些事件要進退菜表
店內可將已製作餐點因錯單、製作不符或顧客反映而撤回列為退菜事件；單純正常收盤則放在餐盤剩食觀察。若把所有吃剩餐盤都當退菜，外場事件數會很大，卻看不出真正需要當下處理的服務問題。
EPA的餐飲減量資料把顧客退回與損耗原因連結，提醒菜單與製作問題需要分辨。店內可以用此原則設計原因碼，但代碼應對應實際工作，不需要把每一種口味形容詞都做成一類。
先確認事件時間、餐點代碼、是否已交付、退回程度及處理結果。若涉及食品品質或安全疑慮，依既有處理程序優先處置，不為了完成統計而延後回應。記錄不能代替現場判斷。
原因碼保留未知，避免被迫選錯答案
| 原因示範 | 要留下的資訊 | 先交給誰看 |
|---|---|---|
| 訂單或交付不符 | 原訂內容、實際交付、錯在哪一段 | 外場與出餐核對人 |
| 製作規格疑問 | 顧客原話、當批內容、可核對的規格 | 廚房主管 |
| 份量不合需求 | 剩餘情況、原選份量、是否共食 | 菜單與服務負責人 |
| 飲食偏好未傳達 | 客人已說明與實際製作內容 | 接單及廚房共同核對 |
| 原因未知或不願說明 | 客觀退回情況，不填猜測 | 主管安排後續觀察 |
不要把「客訴」當最終原因，因為它只說有一個回饋事件，沒有說明可改什麼。同樣也不建議預設「客人挑剔」或「廚房失誤」，這些判斷容易讓後續調查被先入為主的標籤帶走。
不確定你的店適合哪一款？
輸入每日廚餘量，30 秒看建議機型和一年省多少。
三個判例，示範如何分開原話與結論
假設客人說「我沒有點辣」，外場查到訂單確實選不辣，而餐點製作依一般辣度完成。可以保留原話，事件記為訂單要求未正確傳至製作或未依要求執行，並追查是哪一段。若訂單原本沒有選項記錄，就不能直接認定其中一方說錯。
第二個假設是客人說「太鹹」，廚房核對配方與當批紀錄未發現偏離。此時保留口味回饋，觀察是否在相同菜色重複出現；不能因一次回饋就把整道菜改配方，也不能因符合規格就把回饋刪掉。
第三個假設是四人共食點了多道菜，最後一盤幾乎完整退回，客人表示吃不下。先記份量或點餐組合相關回饋，再看服務時有沒有清楚說明菜量。改善可能是點餐提醒，而非把單道菜份量直接縮小。
事件數與剩餘重量要各自有分母
假設某菜一週供應一百份，有五次退菜事件，其中兩次是錯桌後撤回、三次有口味回饋。可以先看五次事件占供應份數的比例，再把原因分開；但不應把五份全部當成相同重量的報廢，物料結果需另記。
若其中一次退回半份、一次整份，重量與事件數會呈現不同資訊。事件數適合追蹤服務或製作發生頻率，淨重適合了解實際物料負荷。比較不同菜色前，也要看供應量與規格，不只比較退菜次數。
正常吃剩的盤子可另外做份量與菜單減量分析，重量記法則依每日廚餘量測統一。兩種資料可以連結，但不必硬塞進同一張表的同一欄。
每個已確認原因，都接一個可驗證動作
錯單類可以檢查接單欄位與出餐核對；份量類可以調整選項或點餐說明；重複口味回饋則先確認配方、批次與顧客情境。寫下負責人、要做的變更及回看日期，避免事件結案只剩一句「已提醒」。
改善後繼續看相同原因是否重複，同時確認資料是不是仍有完整記錄。若退菜數下降但外場開始不願填表，表面結果不可信。主管可以抽看少數事件，核對訂單、廚房與外場記錄是否一致。
紀錄以菜色與事件為主，通常不需要收集顧客姓名或其他不相關個資。保留足夠辨識該次訂單的內部編號即可。已退回的餐點能否另作用途，不能由原因碼決定；可食用剩食安排另參考剩食處理與捐贈條件。
常見問題
客人沒有說原因，可以請員工猜一個嗎？
不要猜成確定原因。記客觀狀況與未知，若適合再以中性問題詢問；客人不願回答時，保留這個狀態即可。
退菜率下降，就代表廚餘一定下降嗎？
不一定。退菜事件與餐盤剩餘是不同資料，菜單與供應量也可能改變。應同時看事件原因與實際物料結果。
若需要評估剩餘物料的現場處理，可透過綠獸合作流程提供已確認的來源與重量，讓服務問題和處理需求各自有依據。