熟客與團體用餐服務如何檢討：核對當次需求、加點與餐點交付

檢討熟客與團體用餐服務時，先分別確認當次需求是否已確認、由誰彙整加點，以及餐點是否全數送達。熟悉不代表需求沒有改變，人數多也不代表一定會混亂。週會應聚焦於一個有根據的交接問題，再說明人數、餐點和排班上的差異；不能只比較營業額，或憑一次爭執就判斷整週的情況。

週會紀錄卡：只保留有助於做決定的欄位

• 本次問題：寫明具體環節，例如這筆訂單有哪些項目未送達，或由誰接手新增項目；不要先對某類客人或員工貼標籤。
• 檢視範圍：記錄門市時區、營業時段、選擇這些服務經過的原因，以及相關訂單識別資訊。
• 可查證的事實：註明訂單或工作站紀錄實際顯示的內容；製作完成與外場送達情況應分別查找依據。
• 現場觀察與事後回憶：分別說明員工當場看到的情況和事後回想的內容；缺乏依據的部分標示為未知，不要自行補出時間線。
• 比較條件：列出人數、餐點組合、加點輪次、付款約定、排班和菜單變動；條件不同時，應說明比較上的限制。
• 下次行動：只選一項目前可執行的措施，寫明負責職務、開始執行的班次、例外情況交由誰處理，以及如何觀察執行情況。
• 複查結論：下次紀錄應保留、調整或繼續觀察的依據；資料不足時，不要補寫成問題已解決或措施有效。

日常接待與活動團體不必硬要逐一對應，但應說明條件差異。紀錄不完整的服務經過可用來提出線索，不能據此計算精確的等候時間或漏送比例；銷售、已確認收款和服務交付也不能彼此替代，當作結論。紀錄只應針對當次服務，不建立顧客的長期行為檔案。

熟客與團體，不要用同一種印象來判斷

檢視熟客案例時，重點在於員工是否未經確認，就沿用過去的規格、內用或外帶方式，或付款習慣。即使確實沒有問題，也應說明本次觀察到的依據，而不是以彼此熟悉作為替代。店主可以請員工複述如何確認顧客當次的需求，並檢查換由另一位同事接手時，是否仍能取得相同資訊。

檢視活動團體案例時，則沿著加點、共享餐點和分批交付的流程，查看資訊在哪個環節。人多不代表必然混亂，但多人提出需求，可能導致不同職務的人各自只掌握部分資訊。檢討時應找出哪一次新增項目沒有彙整、哪一份餐點無人負責送齊，而不是要求員工以後對團體更用心這種難以執行的表態。

工作站紀錄與實際交付，分別查找依據

MenuSnap 後廚指南分別說明製作狀態與職務交接；KDS 和紙本單據則依各自適用條件使用。檢討時可以先查工作站完成了哪些事項，再向外場了解實際送達情況，並分別為這兩個環節查找依據。顧客回饋應另作服務線索，並與餐點交付紀錄一併檢視；工單已完成或顧客當時沒有提出異議，都不足以單獨證明整筆訂單已全數送達。

店主只查看目前版本、權限和方案下實際可存取的紀錄，不要假設已有等候時間、催菜次數或漏送原因的報表。若要了解這些事實，可以安排下一個班次進行簡短觀察，並事先約定紀錄的起訖點。沒有一致的計算口徑，就不要比較數字；也不要把訂單存在系統中的總時間直接稱為顧客的等候時間。

下週複查的是行動，不是預先宣告成效

如果熟客案例的問題是預設規格，下一個班次可以要求接單前複述顧客當次的選擇；如果團體案例的問題是無人彙整加點，就指定負責處理本輪加點的職務。不必把這兩項調整同時推行到所有情況。負責人應寫明由誰執行、何時開始，以及例外情況交由誰處理；不要把檢討變成採購或功能需求清單。

• 保留：說明在哪些服務條件相近的情況下觀察到措施確實執行；結論不要擴大到所有班次或長期成效。
• 調整：指出資訊仍在哪個環節中斷，並調整負責職務或紀錄位置，而不是只要求大家更用心。
• 繼續觀察：如果下週只有一般接待，先確認各班是否找得到加點彙整、待送項目和接手職務等資訊。若尚未遇到條件相近的團體，或紀錄仍不足，就只記下已完成的準備與執行情況；不要把一次說明或沒有出現反例，當成問題已經解決。

提交、列印或付款發生故障時，負責人應先查核原訂單並聯絡支援；顧客訂單只用於正常服務，不要拿來嘗試不熟悉的操作。週會可以說明已知故障與仍待查證的事實，但不要把尚未查明的問題轉化為服務效率的結論。