餐飲 SaaS 的 AI，不該只是聊天機器人

寫在前面：之前寫過餐飲 SaaS 出海團隊怎樣使用 AI，談的是管理者怎樣用 AI 整理資訊、協助判斷和改善溝通。

但當 AI 進入餐飲 SaaS 產品、交給餐廳客戶用，問題就不同了。顧客和門店不是來找一個聊天對象，他們是來完成點餐、訂位、退款、服務，或一個營運決定。兩篇是不同搜尋意圖，但底層原則一致：AI 是用來放大人，不是代替人。

一家餐廳從開門到打烊，要處理很多細小決定：今天備多少貨、哪道菜臨時停售、哪條差評要由店長處理、哪個班次需要調人、哪筆外賣訂單出餐慢了。

每個決定單獨看都不大，加起來卻佔用了店長大量時間。

現在不少餐飲 SaaS 談 AI，首先想到的是增加一個聊天機器人。

所以，判斷一個餐飲 SaaS 把 AI 做進產品做得好不好，不應先看它有沒有聊天框，而應先問：

它替門店減少了哪一項重複判斷？

多一個聊天框，不等於產品有了 AI

顧客可以問：

「四個人吃飯，有甚麼推薦？」

店長也可以問：

「為甚麼昨天的差評增加？」

AI 回答得很完整，畫面也很智能。但回答之後，顧客仍然要回到菜單重新選菜、確認價格和建立訂單；店長仍然要自己找出哪家門店、哪個時段和哪一類訂單出了問題。

原來的工作沒有消失，只是前面多了一段對話。

減少判斷，不一定代表完全交給 AI。系統可以先整理資料、找出異常和提出建議，讓店長從「由頭分析」變成「確認建議是否合理」。人的責任沒有消失，但重複工作可以減少。

所以餐飲 SaaS 的 AI 有沒有價值，可以先問四個問題：

它完成了甚麼任務，或減少了哪一項重複判斷？
它有沒有進入原有工作流程？
它依靠甚麼數據，餐廳是否有權持續使用？
效果怎樣衡量，出錯時由誰接手？

四個問題答不清楚，這項功能再會聊天，也很難形成真正的產品價值。

場景一：AI 怎樣協助門店經營

顧客端 AI 比較容易被看見，營運端 AI 才直接面對店長每天的工作。

AI 可以整理歷史訂單、預訂和門店異常，協助管理者判斷備貨、商品調整和人力安排。它不應自行假設原因，而是先指出值得調查的地方：

哪家門店的出餐時間正在增加？
哪類商品的作廢、退款和投訴同時上升？
外賣訂單增加後，堂食服務有沒有受到影響？
某項優惠帶來的是回購，還是只降低了單筆收入？
不同門店是否重複出現同一類問題？

一份 AI 日報如果沒有人跟進，仍然只是一段文字。如果問題沒有被分配和追蹤，那就不只是 AI 能力問題，也是管理沒有上。

AI 要進入門店營運，就要與通知、工單、責任人和改善結果連接。系統找出異常後，還要說明使用了哪些數據、把問題交給誰，以及之後怎樣確認問題有沒有改善。

低風險工作可以逐步自動化。備貨、排班和商品調整等建議，則需要管理者根據現場情況確認。

場景二：評價、回訪與問題追蹤

評價與回訪是一個邊界較清楚，也容易衡量結果的 AI 場景。

之前在差評不是客服問題中，我談過怎樣把線上評價變成營運數據。後來又在外賣平台帶來訂單，但誰掌握顧客關係中，討論餐廳怎樣在平台規則和顧客同意下，建立下一次直接互動。

把兩件事連起來，AI 可以協助：

在合規渠道中發送售後回訪；
整理不同語言的顧客意見；
把評價分成等候時間、服務態度、錯漏單、清潔和配送問題；
找出同一問題是否集中在某家門店或某個時段；
把需要補救、退款或承擔責任的個案交給人處理；
追蹤改善後，同類問題有沒有再次出現。

店長不必逐條閱讀所有評價。系統先整理需要關注的信號，人再處理例外和高風險問題。

AI 可以協助起草一般回覆，但不能替餐廳承認責任，也不應自行決定退款或賠償。

場景三：AI 點餐的兩條路

AI 點餐真正的產品問題，不是聊天框能否推薦菜品，而是 AI 能否把顧客需求轉成可以確認、執行和追蹤的交易。

這裏有兩條路。

路線一：讓外部 AI Agent 調用餐廳能力

未來顧客未必先打開餐廳 App 或外賣平台。他可能直接告訴自己的 AI Agent：

幫我找一家附近適合四個人的餐廳，今晚七點訂位。

或者：

幫我訂上次那家餐廳的套餐，六點半到店自取。

要進入這種交易入口，餐飲 SaaS 需要把以下能力整理成外部 Agent 可以安全調用的工具：

查詢門店、營業時間和可訂時段；
讀取菜單、價格、庫存和過敏資料；
建立及修改購物車；
建立、修改或取消訂位；
建立堂食預點、外賣或自取訂單；
查詢訂單狀態；
進入付款確認流程。

外部 Agent 負責理解顧客想做甚麼，餐飲 SaaS 則提供可信的門店資料和交易結果。

這不是開放一個 API 或 MCP 接口就完成了。

MCP 可以讓 AI Agent 發現和調用餐廳提供的工具，但顧客身份、操作權限、價格確認、重複提交保護和交易記錄，仍然要由餐飲系統處理。

AI 可以幫顧客組合需求，最終交易仍要由確定的餐飲系統完成。系統也要處理取消、退款和人工接管。

路線二：建立自己的門店 AI 入口

餐飲 SaaS 也可以自己建立顧客使用的入口。

它可以是餐桌上的智能設備、自助點餐終端，也可以透過 NFC 或 QR Code，在顧客手機上開啟語音或數字人服務。

這種入口與普通聊天框最大的分別，是它知道顧客正在哪家門店、哪張桌，以及目前要完成甚麼服務。

顧客可以直接說：

「我們有四個人，不吃辣，預算大約六百元。」

AI 根據當前門店的菜單、價格、庫存和規則提出組合，再由顧客確認訂單。用餐期間，它也可以處理加單、服務呼叫或付款引導。

它的價值不是讓菜單開始說話，而是把顧客說的話轉成真實訂單，減少顧客尋找選項和員工重複錄單的工作。

這條路讓餐廳掌握品牌體驗和現場語境，但同時要處理設備部署、網絡、門店培訓和日常維護。硬件只是入口，真正決定體驗的仍然是背後的菜單、訂單、支付和服務流程。

兩條路線，共用同一套交易能力

外部 AI Agent 和門店 AI 設備看起來是兩種產品，底層需要的能力其實相同：

外部 AI Agent ─┐
               ├─ 菜單、訂位、訂單、支付、會員
門店 AI 入口 ──┘

一條路把餐廳能力開放給其他 Agent，另一條路由餐廳自己掌握顧客入口。

真正值得投入的，不只是模型或數字人，而是把菜單、訂位、訂單、支付和會員能力，整理成 AI 可以安全調用的工具。

模型可以替換，顧客入口也會改變。能否穩定完成交易，才是餐飲 SaaS 長期需要掌握的能力。

沒有數據整合，AI 只會更快出錯

前面三個場景都有同一個前提：AI 找得到正確數據。

連鎖餐飲的資料通常分散在 POS、KDS、支付、外賣平台、訂位、會員、評價和不同市場的本地服務商裏。

各系統可能使用不同的門店編號、商品名稱、訂單狀態和顧客身份。同一個「營業額」，也可能因為是否包含稅項、服務費、退款和平台優惠，而得出不同結果。

AI 可以快速計算，卻不知道哪一個定義才是集團標準。

如果沒有先處理數據整合和治理，AI 只會用更快的速度，產生一個看起來合理的錯誤答案。

所以，連鎖集團準備 AI，不應先從模型開始，而要先回答：

哪一個系統是菜單和價格的事實來源？
門店、商品、訂單和渠道怎樣統一識別？
營業額、退款和回購使用甚麼共同定義？
顧客身份和同意狀態怎樣管理？
哪些角色和 Agent 可以使用哪些數據？
AI 的建議和操作能否被追蹤及審計？

這些工作不吸引眼球，卻決定 AI 最後能不能進入真實營運。

門店營運、服務商生態與數據中台

數據解耦，不是把所有資料搬進一個大倉庫，也不是要求所有市場使用同一家供應商。

方向應該是：

門店營運
   ↓
不同服務商生態
   ↓
統一整合與數據治理
   ↓
數據中台
   ↓
AI Agent、管理分析與自動化

門店營運仍然是主體。

POS、點餐、出餐、服務和支付，首先要確保前線正常工作。不同市場可以繼續選擇合適的外賣、支付、訂位、會員和本地服務商，但它們要透過清楚的接口、事件和數據定義接入集團體系。

數據中台也不只是存放報表。它需要管理門店、商品、菜單和渠道的統一識別，建立訂單、退款和營業額的共同定義，並保留資料來源、權限、顧客同意和 AI 操作記錄。

這樣，即使集團更換某一個服務商，過去的營運定義、歷史分析和 AI 能力仍然可以延續。

餐廳不一定掌握每一項原始資料，但應掌握自己的營運數據模型、指標定義和使用權限，避免整套分析與 AI 能力被鎖在單一服務商裏。

這個問題值得另外用一篇文章展開。

哪些事情可以交給 AI？

我會用一條簡單界線判斷：

可以驗證、可以撤回、風險有限的工作，可以逐步自動化；涉及金錢、安全、責任和顧客權益的決定，必須保留人工確認。

AI 可以整理評價、協助建立一般訂單、推薦菜品、查詢訂位和發現異常。

涉及過敏資訊、付款、退款、改價、食品安全、賠償或法律責任時，系統需要明確確認、權限控制和人工出口。

餐飲 SaaS 的 AI 不應以完全無人化為目標。更實際的方向，是讓員工少做重複工作，讓管理者更早看見問題，也讓顧客用更自然的方式完成服務。

結語：不要先問 AI 會不會聊天

餐飲 SaaS 的 AI 可以有很多入口：顧客自己的 Agent、餐桌設備、手機數字人、評價回訪和管理後台。

入口不同，判斷標準應該相同：

它完成了甚麼任務，或減少了哪一項重複判斷？
它是否進入真實工作流程？
使用的數據是否可信，而且有清楚權限？
結果能否衡量，出錯時誰會接手？

餐飲 SaaS 的 AI，不應追求完全無人化。

它應該替門店減少重複、可驗證、風險有限的判斷，把涉及金錢、安全、責任和顧客權益的決定留給人。

不要先問 AI 有多聰明。先問它替餐廳完成了甚麼，又替門店減少了哪一項重複判斷。

而這一切的前提，是資料能被整合、被信任、被授權使用。沒有資料中台與治理，AI 再會聊天，也幫不了一家餐廳少做一個決定。先把底座打好，再談 AI 長什麼樣。