餐廳桌數 AI 訂位系統：桌型×桌數容量模式怎麼防搶訂｜2026 台灣
TL;DR — 餐廳桌數 AI 訂位系統不能只看「18:30 有沒有空」，而要看 2 人桌、4 人桌、包廂在 90 分鐘用餐時間內有沒有重疊。Brightalk 的容量模式把桌型、桌數、人數與時長放進同一張訂位表，讓 AI 電話接單、人工新增、改期取消都走同一個容量規則。
餐廳桌數 AI 訂位系統真正難的不是接電話，是不要把同一張桌賣兩次
餐廳訂位最常見的錯誤，是把「有沒有空」理解成單一時段。對醫美諮詢、單一會議室或一位顧問來說，18:30 只要有一筆預約，就可以視為滿了。但餐廳不是這樣運作。18:30 可以同時有 2 人桌三組、4 人桌兩組、包廂一組；19:00 又會吃掉 18:30 到 20:00 的桌況。
這也是為什麼舊式 Google Calendar 訂位常讓餐廳卡住：只要那個時段有任何事件，就被判定為沒空。餐廳需要的是容量，而不是單一行事曆空檔。
2026 年 5 月，台灣餐飲業單月營業額達 947 億元、年增 4.8%；其中餐館年增 4.0%（經濟部統計處 2026）。前 5 個月餐飲業營業額累計 4,642 億元、年增 4.1%（經濟部統計處 2026）。需求還在，但座位、人手與尖峰餐期都有限。訂錯一組，不只是客訴，而是整個餐期翻桌節奏被打亂。
「5 月餐飲業營業額 947 億元，年增 4.8%。」——經濟部統計處，2026
⚠️ 如果你的 AI 訂位只問「日期、時間、姓名」，沒有問「幾位」，它不是餐廳訂位系統；它只是把通話內容寫進行事曆。
Brightalk 的容量模式：桌型、桌數、人數、用餐時長一起算
新版容量模式上線後，訂位能力從「單一資源」擴到「容量模式」。對外講人話，就是餐廳可以在訂位設定裡定義：
| 設定項目 | 餐廳語言 | 系統要解決的事 |
|---|---|---|
| 桌型 | 2 人桌、4 人桌、6 人桌、包廂 | 依人數選最小可容納桌型 |
| 數量 | 2 人桌 4 張、4 人桌 4 張 | 同一時段可接多組 |
| 用餐時長 | 預設 90 分鐘，包廂 120 分鐘 | 用重疊區間算容量 |
| 營業視窗 | 週二到週日午餐、晚餐 | 到店時間必須落在可訂視窗內 |
| 公休日 | 特定日期不開放 | 假日、店休、包場不誤接 |
AI 電話接到訂位時，先問人數，再問日期、時間、姓名與電話。系統會以人數挑合適桌型，例如 3 位客人先找 4 人桌，而不是直接塞到 6 人桌。若 18:30 的 4 人桌已滿，AI 不會硬說「有空」；它會回報衝突，並提供同日或隔日較近的替代時段。
這件事看似小，其實是餐廳訂位的核心。餐廳老闆真正想避免的不是「沒有行事曆事件」，而是以下三種事故：
- 兩通電話同時訂進最後一張 4 人桌。
- 18:30 的客人還在用餐，19:00 又被排進同桌。
- 10 人大組被 AI 硬塞進最大 6 人桌。
容量模式把這三件事都變成規則：同一桌型在同一段用餐時間內不能超過桌數；太大組不線上硬確認，而是建立回電任務請店家處理。
用戶怎麼設：一張餐廳模板就能先跑
餐廳導入時，不必從零發明模型。先用一個保守模板：
| 桌型 | 數量 | 可坐人數 | 時長 |
|---|---|---|---|
| 2 人桌 | 4 | 2 | 90 分鐘 |
| 4 人桌 | 4 | 4 | 90 分鐘 |
| 6 人桌 | 2 | 6 | 90 分鐘 |
| 包廂 | 1 | 8 | 120 分鐘 |
再設定每週可訂時段，例如週二到週日 11:30–14:00、17:30–21:00。AI 電話只接受到店時間落在視窗內的訂位；客人 13:30 到店，用餐到 15:00 可以，但 14:10 到店就不該收，因為到店時間已超過午餐視窗。
💡 這裡的重點是「到店時間」落在視窗內，不是整段用餐都必須在視窗內。餐廳可以 13:30 收最後一組客人，讓客人用餐到 15:00；但不能 14:30 才開始收午餐訂位。
人工訂位也必須走同一套規則。後台的訂位清單讓店員手動新增、取消、改期時，也會占用相同容量。這避免「AI 說滿了，但店員手動又塞進一組」的雙軌混亂。
如果餐廳仍想把訂位同步到 Google Calendar，可以把行事曆當作鏡像，而不是容量真相來源。也就是說，餐廳容量以訂位清單為準，Google Calendar 只是讓團隊看得到事件。這個邊界很重要：只靠行事曆事件，無法可靠表示桌型、桌數與用餐重疊。
舊訂位流程 vs 容量模式：差在哪裡？
| 情境 | 單一資源行事曆 | 容量模式 |
|---|---|---|
| 同一餐期多組訂位 | 第一組後就可能被判滿 | 依桌型數量計算 |
| 客人說 5 位 | 無法判斷要哪種桌 | 自動找 6 人桌或以上 |
| 兩通電話搶最後一桌 | 可能同時成功 | 原子檢查，一成一敗 |
| 店員手動新增訂位 | 常與 AI 路徑分開 | 同一張訂位清單佔容量 |
| Google Calendar 事件 | 常被當作唯一真相 | 只做鏡像，不當容量依據 |
| 大組訂位 | 可能被硬塞 | 建回電任務，不線上硬確認 |
這篇和既有的餐廳訂位尖峰漏接案例不同：那篇談怎麼接住漏接、電話與 LINE 確認、候補補桌；這篇談的是更底層的「桌數容量怎麼不被訂爆」。若你正在評估整體 AI 電話導入路徑，先讀AI 電話行銷完整指南，再回來看餐廳容量模式。
量化效果：先算一張桌在尖峰餐期的價值
餐廳最該算的不是「AI 每通多少錢」，而是一張桌被錯排的代價。
假設晚餐尖峰：
- 4 人桌平均客單 NT$600／人。
- 一桌 4 人營收 NT$2,400。
- 晚餐時段可翻 2 輪。
- 一張 4 人桌一晚理論營收 NT$4,800。
如果 AI 把最後一張 4 人桌重複賣給兩組客人，你不只要道歉，還可能失去其中一組客人的長期回訪。若每週發生 3 次，一個月就是 12 次桌況事故；以一桌 NT$2,400 估算，直接風險就是 NT$28,800，還沒算負評與店員補救時間。
✅ Brightalk 客戶在餐廳場景的第一個 KPI 不該是「AI 多會聊天」，而是「尖峰餐期重複訂位事故歸零」。語音自然度是加分，容量正確才是底線。
導入時可以追 4 個數字：
| KPI | 怎麼看 |
|---|---|
| 尖峰漏接訂位數 | AI 接住多少原本漏接的訂位電話 |
| 衝突攔截數 | 系統擋下多少已滿時段 |
| 替代時段接受率 | 客人是否接受 AI 提供的附近時段 |
| 人工覆核任務數 | 大組、包場、特殊需求有沒有交給真人 |
這些數字會回到 Brightalk 通話自動化 與 Brightalk 聯絡人管理：通話結果、訂位紀錄、回電任務、客戶電話都在同一條紀錄裡，而不是散在店員手機、紙本訂位本和行事曆截圖。
常見問題
餐廳桌數 AI 訂位系統一定要接 Google Calendar 嗎？
不一定。容量模式應以訂位清單為準，Google Calendar 只適合做團隊可視化鏡像。餐廳真正要控的是桌型、桌數、用餐時長與重疊，不是一個行事曆時段有沒有事件。
AI 訂位一定要問人數嗎？
餐廳模式一定要。沒有 party size，就無法決定要用 2 人桌、4 人桌或包廂。容量模式會把「先問幾位」變成訂位話術的一部分；若舊設定沒有這個欄位，應先同步語音代理人設定後再開放。
10 人以上大組怎麼處理？
不要讓 AI 硬確認。若人數超過最大桌型，應建立回電任務，請店家判斷是否併桌、包場或收訂金。這一版容量模式也明確把「併桌、訂金、no-show 狀態」列為非 v1 範圍，避免第一版過度承諾。
同一張桌 18:30 與 20:00 算不算衝突？
看用餐時長。若 18:30 訂位時長 90 分鐘，結束時間是 20:00，20:00 可視為貼齊、不算重疊；19:30 則重疊。這就是容量模式比單純行事曆更適合餐廳的原因。
人工新增訂位會不會繞過 AI 容量？
不該繞過。人工新增、AI 電話訂位、取消、改期都要走同一套容量檢查。否則店員手動塞單會破壞 AI 的判斷，最後又回到紙本訂位本時代。
這套也能用在其他產業嗎？
可以，但要誠實看限制。若是同質資源池，例如美容床 3 張、美甲桌 4 張、諮詢席 2 個，容量模式很適合；若是「指定某位設計師」或多段服務接力，仍需要真人覆核或更細的排班規則。
結語：餐廳訂位的 AI，不該只會講話，還要懂桌況
餐廳需要的不是一個會聊天的語音機器人，而是一個知道 4 人桌還剩幾張、90 分鐘內會不會重疊、太大組該轉真人的訂位入口。
想先看整體 AI 電話導入路徑，讀 AI 電話行銷完整指南；想把尖峰訂位電話交給 AI 接，從 Brightalk AI 語音代理人 開始；要估導入成本，直接看 Brightalk 方案。