火鍋店線上訂位自動確認流

🎯 這條流程解決什麼

火鍋店的尖峰時段，前台往往是全店最忙的一個位置。一手拿著電話接訂位，一手要招呼剛進門的客人帶位，眼睛還得盯著訂位本上密密麻麻的塗改。最常見的災難有三種：同一張桌子被排給兩組客人、人數記錯導致到場才發現沒有合適桌型、以及客人線上送了訂位卻一直沒收到任何回覆，乾脆當天不來了。

把這些「隱形成本」攤開來看其實很驚人。假設一間 40 桌的火鍋店，週末晚上靠人工處理訂位，前台一筆訂位從查桌況、回電話、登記到提醒，平均要花 6 到 8 分鐘；一個晚上 30 筆訂位就吃掉前台將近三到四個小時，這還沒算上講錯、排錯後重新協調的時間。更痛的是爽約：餐飲業線上訂位的 no-show 率普遍落在一成到兩成之間，一張四人桌客單價抓 1,200 元，假日晚上五張桌子爽約，當天就少了 6,000 元營收，而那段黃金時段的現場排隊客人卻被擋在門外。

這條流程把這些重複又容易出錯的環節交給自動化來扛：每一筆線上訂位送出後，系統自動檢核當日當時段的桌況、即時回傳確認訊息、並在用餐前主動提醒客人。前台不必反覆翻訂位本、不必在電話和帶位之間切換，桌位安排的準確度和回覆速度都大幅提升。想把現場排隊一起納進來統一調度，可以搭配 候位叫號自動通知流 與 自動化專區 的其他門市流程一起部署。

導入後的改變

導入前，前台的訂位處理是「事件驅動、人腦記憶」：電話一響就放下手邊事去查桌況，記在紙本上，忙起來忘了回覆是常態，用餐前更不可能一筆筆打電話提醒。導入後，整個流程變成「自動接單、自動確認、自動提醒」，前台只需要處理真正需要判斷的特殊狀況。

具體的效益估算如下。以前述 40 桌火鍋店為例：

• 前台訂位處理工時：從每筆 6 到 8 分鐘壓到 1 分鐘以內（只需處理特殊需求），週末晚上省下約七到八成的訂位作業時間。
• 爽約率：加上用餐前 3 小時的自動提醒後，餐飲業實務上 no-show 率通常能從一成五降到半成左右，等於每個假日晚上多救回兩到三張桌子。
• 訂位回覆速度：從「忙完才回、可能忘記」變成「30 秒內自動確認」，客人收到即時回覆後取消改約的比例明顯下降。
• 桌況排錯：因為由系統統一比對名單，重複排桌、人數記錯的情況幾乎消失。

換算成金額，光是爽約率改善這一項，一個月四個週末就可能多回收兩到三萬元的營收，而流程本身一次建好幾乎零邊際成本。

流程怎麼運作

整條流程對應 frontmatter 裡的五個節點，逐步驟說明如下。

1. 📥 觸發：新訂位——客人在你的線上訂位連結（可以是表單、LINE 官方帳號的圖文選單，或既有訂位系統）填好日期、時段、人數、姓名電話後送出，這筆資料就成為流程的起點，自動寫入待處理佇列。
2. 🪑 檢核桌況——系統拿這筆訂位去比對當日該時段的既有訂位與桌型配置，判斷現有空桌能不能容納這組人數，並標記適合的桌型（兩人桌、四人桌、可併大桌或包廂）。AI 整理節點會把客人填的自由文字（例如「想要靠窗、有小孩要兒童椅」）抽取成結構化標籤，方便後續判斷。
3. ✅ 回傳確認——若桌況允許，立即透過 LINE OA 回傳一則確認訊息，內含訂位時間、人數、店家地址與停車資訊，並附上一句明確的「如需更改請回覆」引導，讓客人有清楚的取消管道。
4. ⏰ 用餐前提醒——排程器在用餐前數小時（建議 3 小時）自動推送提醒訊息，附上「確認前來／需要取消」的快速回覆，把可能爽約的桌子提早釋出給現場排隊客。
5. 👤 特殊需求人工確認——凡是涉及包廂預訂、大桌併桌、低消或訂金條件的訂位，系統只負責標記並通知前台，最終由前台人工確認後才正式成立。

需要的工具與串接重點

平台用 n8n 或 Make 都可以。建議的角色分工如下：

• 線上訂位表單 / LINE OA：客人輸入訂位的入口，也是確認與提醒訊息的出口。LINE OA 的訊息推送費用要留意每月免費額度，量大時可改用 Webhook 觸發。
• Google Sheet 或既有訂位系統：當作桌況與訂位名單的單一真實來源（single source of truth）。如果你已經有訂位系統，優先串它的 API，避免兩套名單對不起來。
• AI 整理節點：負責把客人填寫的自由文字解析成結構化欄位（人數、時段、特殊需求標籤），降低人工判讀。
• 排程器：負責用餐前提醒的定時觸發。

串接時最容易踩的雷有兩個：一是時段與桌況的判斷邏輯要先講清楚（例如一張桌子的用餐時長抓 90 分鐘、翻桌緩衝抓 15 分鐘），否則系統會誤判可容納量；二是避免重複觸發，同一筆訂位若客人連送兩次，要靠電話號碼加時段做去重，不然會發兩則確認、佔兩張桌。

常見錯誤與注意事項

• 包廂、大桌、訂金一律人工確認：這些直接牽動實際營收與客訴風險的環節，自動化只做檢核與通知，不取代前台對現場桌況的最終判斷。
• 個資保護：客人的姓名與電話屬個資，名單試算表要設權限、限授權人員可見，提醒訊息也不要把完整電話回貼到公開群組。
• 提醒不要太密集：用餐前提醒一次就夠，連環轟炸反而讓客人反感、退訂或封鎖你的官方帳號。
• 桌況估算只是參考：實際翻桌速度受出餐、客人用餐時長影響，遇到滿場時系統判斷的「還有空桌」要由前台二次確認，避免超賣。
• AI 不取代專業判斷：所有自動回覆與檢核結果都是輔助，遇到模糊或衝突狀況，以現場人員的判斷為準。

台灣中小企業情境案例

台中一間 36 桌的個人火鍋店「鍋語」，假日晚上原本由一位工讀生專職接訂位電話，還是常常排錯桌、漏回 LINE 訊息，爽約率長期在一成五上下。導入這條流程後，客人改走線上訂位連結，送出 30 秒內就收到 LINE 確認，用餐前 3 小時再收到一次提醒。

實際跑了一個月，店長回報三個明顯變化：前台工讀生不再被電話綁死，可以專心帶位與招呼現場客；爽約率從約一成五掉到半成以內，等於每個週末多坐滿兩到三張桌；而且因為提醒訊息附了「臨時不能來請回覆」，提早收到取消的桌子可以馬上補給現場排隊客，黃金時段幾乎不再有空桌空轉。

延伸應用

這條流程的骨架可以往外擴充出好幾種變化。第一，把候位名單也接進來，線上訂位和現場排隊共用同一份桌況資料，前台只看一個畫面就能統一調度。第二，加上用餐後的滿意度詢問與會員導入，把一次性的訂位客變成回頭會員。第三，累積一段時間的訂位資料後，可以做尖離峰分析，反推哪些時段該開放線上訂位、哪些時段保留給現場客，甚至搭配離峰時段的優惠推播提升上座率。想找更多可串接的門市與行銷流程，逛逛 食譜配方庫、工作流總覽 與 自動化專區，可以把整套門市營運自動化一塊塊拼起來。

流程圖

用到的工具

更多「餐飲美食」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →