團膳配送異常處理：從通報到改善結案的紀錄

團膳配送異常處理最常見的狀態是：有通報、沒結案。溫度超標的那一則訊息確實發出去了，之後這批餐點怎麼判、車子怎麼處理、下次怎麼不再發生，都沒有留下來。

異常處理常被理解成有通報就算做到了。但通報只證明有人知道，不證明有人處理——真正會被追問的是通報之後那幾個小時發生了什麼。

▍四個問題決定這次算不算處理完

誰被通知到、當下做了什麼、這批餐點怎麼判定、下次怎麼避免。四題都有紀錄才算結案，缺一題就是掛著。

用這四題去檢視過去三個月的異常，通常會發現前兩題有、後兩題空著。

▍問題一：誰被通知到

要留的不是發送紀錄，是接收紀錄。系統發了訊息、簡訊送出成功，不等於有人看到並接手。

可行的做法是要求確認接手，未在時限內確認就升級到上一層。這也是判斷通報機制有沒有真的在跑的唯一方式。

▍問題二：當下做了什麼

現場處置只有人能記，設備記不了。要留的是採取什麼措施、幾點做的、誰做的，必要時附照片。

這一題最需要的是輸入方式夠簡單。要求司機在路邊填一份表格等於不會有紀錄，改成手機選擇處置類型加一段簡短說明與拍照，才留得下來。

▍問題三：這批餐點怎麼判定

這是最關鍵也最常空白的一題。要留的是判定結論、判定依據與判定人。

判定依據一般看超標幅度、持續時間與餐點型態三者，具體認定標準應依主管機關相關規定與內部規範辦理。要避免的是只寫已處理三個字——那在事後說明時等於沒有紀錄。

▍問題四：下次怎麼避免

富啟科技的做法是把改善做成閉環：異常自動預警推送後線上登記處置，改善措施與完成照片線上提交、管理者線上審核，不符合要求可退回重新改善；紀錄依時間、區域、問題類型檢索，並自動生成高頻違規問題、各區域占比與改善完成率報表。資料在雲端固化不可篡改，處置過程留存憑證，支援事後複盤追溯。

退回重做這個設計很關鍵。少了它，改善回覆只要寫已改善就能結案，同一個問題下個月會原樣出現。

▍分清單次處置與根因處理

這一車的餐點怎麼辦是單次處置；為什麼會超標是根因處理。兩者常被混在一起，結果是餐點處理完就結案。

同一台車、同一個路段、同一個時段重複出現的異常，要當成一件事處理而不是三件。高頻問題報表的用途就在這裡。

▍誤報也要留

判定為誤報的異常不要直接刪除，留下判定為誤報的原因。累積之後才看得出門檻是不是設得不合理，而不是每次都靠現場說一聲沒事。

▍小結

異常結案要四題齊全：誰接手、當下處置、餐點判定、根因改善。其中餐點判定最常空白、根因處理最常被單次處置取代；配套需要接手確認、逾時升級與改善可退回重做三個機制。

▍團膳配送異常處理常見問題

Q1：通報之後多久要處理完？

建議分兩種時限：接手確認要短，因為餐點狀態隨時間變化，越晚接手可處置的空間越小；改善結案可以長一些，因為需要查原因與驗證。實務上會設定未確認就自動升級到上一層，避免訊息停在某個人的手機裡。具體時限依配送規模與線路長度自訂，重點是兩種時限要分開，用同一個標準會讓緊急的事被當一般件處理。

Q2：餐點判定要由誰做？

建議由品保或具備判斷職責的人員，不建議由現場配送人員決定。原因是判定時點通常正是趕著供餐的時候，決定權留在現場等於沒有判定。若時間緊迫，可先採取保留與隔離，再由有職責的人判定，並把兩個時間都記下來。判定依據與相關認定標準應依主管機關規定與內部規範建立，系統端負責讓結論、依據與判定人一併留存。

Q3：異常件數變多，代表管理變差嗎？

剛導入時通常相反。過去靠人工量測時，沒量到的異常等於不存在；改為連續採集後，原本看不到的都浮現出來，件數自然上升。這階段要看的是結案率與重複發生率，而不是總件數。若件數上升但結案率維持、重複件數下降，代表偵測能力提高而管理在跑。反而是件數長期為零才需要留意，那通常表示門檻設得太寬或警示被關掉。

接手升級規則、判定職責與改善審核層級，需依組織分工與配送規模設定。富啟科技可就現行異常處理流程規劃結案紀錄架構，取得客製化建置方案與報價。

電話(02)2516-6100｜手機0979-382-058｜LineID:@964dmmig
地址：台北市南京東路二段178號6樓