餐廳候位通知 AI 要先解決的不是「會不會自動傳訊息」，而是現場是否知道每組客人的來源、等待時間、可回座狀態、取消原因與後續聯絡同意。台灣餐飲 SME 如果只把叫號改成自動訊息，客人仍可能等太久、回不來、被重複通知，或被推送不該收到的行銷。比較穩的做法，是先建立 5 個候位狀態，再讓 AI 協助預估等待、整理備註、提醒現場與產生追蹤報表。
餐廳候位通知 AI 為什麼不能只做「桌子好了」
候位通知看起來只是前台流程，但實際上牽涉三件事：現場翻桌節奏、客人等待體驗，以及後續顧客資料能不能合規使用。Toast Tables 的說明把候位流程拆成加入候位、通知、到店、入座、完成、未到與取消等狀態；inline 也把訂位、排隊、簡訊確認、排隊狀態查詢與遠端監控放在同一個餐廳營運系統裡。這些頁面共同暗示一件事：通知本身不是重點，狀態同步才是重點。
台灣場景還多一層 LINE 生態。LINE Biz-Solutions 在 2025 年 4 月介紹 AI 語音預約服務時，提到餐飲業官方帳號成長、電話訂位人力成本、LINE Call、inline 系統同步與通知型訊息。這代表台灣餐廳導入 AI，不應只看「電話能不能接」，也要看候位、訂位、現場與後續 LINE 經營能不能接成同一條流程。
先補 5 個候位狀態，再談自動化
1. 來源狀態：客人從門口、Google、LINE 還是電話來
同樣是候位，門口現場加入、Google 或訂位平台入口、LINE 官方帳號、電話與社群私訊，代表的期待不同。現場客人通常需要即時等待時間；LINE 來的客人可能還在附近移動；電話客人可能需要人工確認人數、兒童椅、寵物或包廂需求。AI 可以先把來源、時段、人數與備註整理給前台，但不要讓 AI 自行承諾座位或折扣。
2. 等待狀態：不要只顯示號碼，要給可行的等待區間
Waitlist Me、Toast 與 inline 類型的候位工具都把等待時間、排隊位置或簡訊通知列為核心功能。對小店來說，不一定要一開始就做複雜預測，但至少要讓系統記錄加入時間、預估區間、桌型、人數與是否已通知。AI 的價值在於根據歷史尖峰、桌型與平均翻桌時間提出提醒，而不是在沒有資料時亂報精準分鐘數。
3. 可回座狀態：叫到號後，現場要知道客人是否看見訊息
只送出「桌子好了」仍不夠。Toast 的候位文件把通知後的狀態、回覆與到店分開，這對現場很重要：客人已收到但還在路上、沒有提供電話、回覆取消、或超過保留時間，都應該有不同處理。台灣餐廳若用 LINE 或 SMS，也要設計短句、保留時間與人工轉接條件，避免尖峰時段一直追同一組客人。
4. 取消與未到狀態：把流失原因留下來，而不是只刪掉名單
候位流失不是單純「客人沒耐心」。可能是等待時間超過預期、通知太晚、沒有兒童椅、天氣因素、客人改去附近店家，或前台未更新狀態。AI 可以幫忙把取消備註歸類，例如等待過久、需求不符、聯絡不上、已改約下次。這些資料比單次叫號成功率更能幫老闆判斷尖峰排班、座位配置與預約政策。
5. 再行銷同意狀態：候位資料不等於可拿來推促銷
候位需要姓名或暱稱、電話、LINE 或人數資訊，但這不代表店家可以把所有候位客人直接加進促銷名單。個人資料保護法第 20 條要求非公務機關利用個資應在蒐集目的必要範圍內，首次行銷也要提供拒絕方式。實務上，候位通知、訂位確認與服務必要訊息要和優惠券、生日禮、會員推播分開記錄，AI 分眾也只能使用已取得合適告知與同意的資料。
AI 在候位通知裡可以做什麼
AI 適合處理重複、整理與提醒，不適合替現場做風險承諾。它可以把電話或 LINE 來的候位需求整理成結構化欄位、根據桌型與歷史資料估算等待區間、提醒前台哪些客人快超過保留時間、把取消原因做週報，或把客訴訊息先分類給店長。OpenAI 企業隱私頁面也提醒，企業與 API 資料在預設情況下不會拿來訓練模型，但店家仍要確認自己使用的工具、供應商與保存設定。
AI 不應該做的事包括：在沒有空桌時保證座位、替店家承諾補償、把候位電話直接拿去做促銷、讓客人誤以為一定會在某分鐘入座，或在爭議時自動回覆法律責任。這些都應該回到現場主管、店長或客服規則。
候位通知流程比較表
| 流程 | 常見做法 | AI 可以補強 | 台灣 SME 要注意 |
|---|---|---|---|
| 紙本候位 | 店員手寫姓名、人數與號碼 | 幾乎無法自動分析，只能事後人工整理 | 容易看不出來源、等待時間與流失原因 |
| 簡訊或 LINE 叫號 | 桌子好時傳通知 | 整理未回、取消、回座與保留時間 | 通知文案要短，服務訊息與促銷訊息要分開 |
| 候位系統 | 記錄人數、桌型、狀態與訊息 | 預估等待、尖峰提醒、取消原因分類 | 要先定義狀態欄位，不要只買工具 |
| AI 語音或聊天入口 | 接電話、收集需求、同步訂位或候位 | 語音轉文字、欄位整理、例外轉人工 | 不能讓 AI 自行承諾座位、優惠或個資用途 |
GA4 與 CRM 要追什麼，不要只看訊息送出數
Google Analytics 4 的 recommended events 把 generate_lead、qualify_lead、working_lead 與 close_convert_lead 放在 lead generation 漏斗中。餐廳不一定要把候位稱為銷售名單，但可以借用同樣邏輯：加入候位、通知成功、回座、取消、完成用餐、加入會員或回訪。對老闆有用的報表不是「今天傳了幾封訊息」，而是尖峰時段有多少人等到、哪些來源容易流失，以及哪些取消原因可由排班或座位配置改善。
誰適合導入，誰不適合
這篇建議適合排隊明顯、尖峰翻桌壓力大、已有 LINE 官方帳號、電話訂位多、候位流失常被店長抱怨，或想把現場名單接進 CRM 的餐飲 SME。它也適合多分店、小型連鎖、熱門甜點店、燒肉火鍋、早午餐、親子餐廳與需要特殊桌型管理的店。
它不適合每天只有少量來客、幾乎沒有排隊、還沒有固定現場 SOP，或只是想用 AI 取代員工判斷的店。如果桌況、桌型、保留時間與取消規則都還沒有共識，先用一週紙本或試算表把狀態定清楚，再導入工具會更穩。
資料更新與來源
本文依 2026 年 7 月 5 日可查資料整理。主要參考 LINE Biz-Solutions 的 AI 語音預約服務文章、LY Corporation 對 LINE Taiwan AI agent 應用的說明、Toast Tables 的 候位操作文件與顧客簡訊體驗文件、Waitlist Me 的候位通知頁、inline 的餐廳營運平台頁、Google Analytics 的 recommended events、全國法規資料庫的個人資料保護法，以及 OpenAI 的 企業隱私說明。平台功能、簡訊可用地區、LINE 方案與法規解釋會變，導入前應以最新官方文件與合約為準。
結論：候位 AI 的第一步，是讓狀態比訊息更清楚
餐廳候位通知 AI 的成敗，不在於訊息發得多快，而在於前台、客人、店長與後續行銷是否看到同一套狀態。先補來源、等待、可回座、取消與再行銷同意，再讓 AI 做整理、提醒與分析，才比較不會把自動化變成新的混亂。對台灣餐飲 SME 來說，最小可行做法是先用一週定義欄位與 SOP，再選擇 LINE、SMS、訂位平台或候位系統接上 AI。
FAQ
餐廳候位通知 AI 一定要接 LINE 嗎？
不一定。LINE 對台灣餐飲很常見，但候位通知也可以用簡訊、訂位平台或候位系統。重點是狀態欄位、同意紀錄與現場 SOP 要一致。
AI 可以自動告訴客人還要等幾分鐘嗎？
可以提供等待區間或提醒，但不建議在資料不足時承諾精準分鐘數。翻桌、桌型、人數與現場例外都會影響結果。
候位電話或 LINE 名單可以拿來發優惠券嗎？
不能直接混用。候位通知屬於服務必要訊息，促銷推播要有清楚告知、合適同意與拒絕方式，並和服務訊息分開管理。
小餐廳沒有候位系統，還能先做什麼？
可以先用一週表格記錄來源、人數、加入時間、通知時間、是否回座、取消原因與同意狀態，再決定是否導入 LINE、SMS 或候位工具。
候位通知成效要看哪些指標？
建議看加入候位數、通知成功率、回座率、取消原因、平均等待時間、尖峰流失率與完成用餐後是否加入會員，而不是只看訊息送出數。