餐廳每週服務檢討怎麼做：從一筆訂單找出下週的一項調整

餐廳每週服務檢討，先挑出一個實際問題，再找出相關訂單，最後決定下一個班次要調整哪個動作。營業額不錯，仍可能漏送飲料；等候時間較長，也不一定是廚房出餐慢。把問題聚焦在一次交接，才能把「下週注意配合」變成有人負責的安排。

週會紀錄可用一頁寫下以下項目

• 本週具體問題：____；門市、當地時區、營業日或日期範圍及餐期：____。
• 必要的訂單參考資料及服務方式：____；選擇這些訂單的理由：____。
• 系統有明確紀錄的事實：____；現場觀察：____；當班人員的回憶或推測：____。
• 仍缺少的資訊：____；由誰查明或下次觀察：____。
• 最可能的流程缺口及依據：____；下週只調整的動作：____。
• 負責人、開始執行的餐期及代理人：____；資料或交接依據：____；例外情況的聯絡人：____。
• 下次檢視安排：____；判斷要繼續、調整或停止這項動作的觀察依據：____。

只保留本次討論必要的訂單識別資訊和經過，不要複製完整的顧客資料。清楚標示事實、回憶和推測的來源；沒有紀錄的時間，不要填成精確的分鐘數。先說清楚這些原則，再聚焦討論本週的問題。

先選問題，再挑可比較的訂單

問題要具體，例如飲料為什麼漏送、換桌後原本的訂單在哪裡，或拆帳時哪一筆款項反覆被詢問。不要把所有狀況都歸納成「服務不好」，也不要只憑一次爭執評斷員工。可挑選餐期、餐點組合和服務方式相近的順利訂單作比較；若找不到足夠依據，就先保留問題，安排下次觀察。

檢視前先確認門市時區和期間；跨午夜的營業日不能和曆日混為一談。銷售額、已確認收款、退款和班次現金是不同的統計口徑；未結帳的帳單也不等於實收款項。不能用範圍不同的合計數字，解釋同一件服務事件。

沿著同一項需求，查清完整經過

依序梳理需求提出、訂單輸入、廚房接單、餐點彙整、實際送達和帳單處理。有明確時間紀錄，就按其原本含義使用；若缺少送達紀錄，就註明資料不足，不要因為餐點已完成便推測顧客已經拿到。MenuSnap 依照現有版本、權限和方案提供實際可存取的紀錄；若缺少排隊、催菜和送達資訊，就由必要的人工觀察補充，不要聲稱系統已自動蒐集這些資訊。

KDS 顯示製作完成、紙本單據被移開和餐點實際送達，是不同的事情；拆分出各筆金額和實際收到款項也不一樣，使用獨立刷卡終端完成的交易還需要先在外部核實。檢視經過不需要重新建立訂單、再次送單到廚房或重做付款；查看必要的既有紀錄並詢問相關人員即可。

原因必須能對應到一項行動

• 資訊沒有寫下來：檢查是否缺少規格、品項歸屬或未送內容，並補上相應欄位。
• 資訊有寫，但沒有人接手：明確指定下一個負責的職位和代理人，而不只是再次提醒大家溝通。
• 接手的人難以執行：檢視位置、動線或共用設備是否造成阻礙，不要直接歸咎於不夠用心。
• 紀錄不足，無法判斷：保留未知，指定下次要觀察的具體環節和觀察起訖時間，不要自行補出完整經過。

設備或設定方面的疑問，由店主和支援人員核對；先確保已接下的服務能繼續進行，不要讓檢討中斷廚房作業或更動正在處理的帳單。每次選一項最相關的調整，例如彙整前確認同一筆訂單的飲料，或換桌後通知吧台；不要同時更動菜單、排班和設備。

下週先回頭檢視上週的決定

在條件相近的情況下，查看同類的漏送、反覆詢問或歸錯帳是否仍然發生、員工能否持續照流程執行，以及等候是否轉移到下一個職位。若客流、排班和菜單差異很大，就不要直接下因果結論；少量訂單只能提供線索，不代表所有顧客的情況。

有效的做法寫進班前安排；無效的做法回頭檢查原訂單是否有遺漏；尚未確定的部分繼續觀察，並停止蒐集不再必要的資訊。每週留下有依據的決定，比不斷增加報表更有助於改善；不要把未經觀察的做法寫成能保證接待量或效率的承諾。