Zest 把訂位搬進短訊：會執行的 AI agent 要甚麼條件

截至 2026-11，美國餐廳探索 App Zest 推出一個住在短訊裡的「餐廳管家」，用戶可以直接用短訊問餐廳、問等位時間，再由它代為訂枱。真正值得香港營運主管留意的，是它最後一步把請求交到 OpenTable、Resy 與 SevenRooms 這些已連接的訂位系統去完成，聊天只是前面的一段。換句話說，它做得到，是因為它接得到。這也是不少公司評估 ai agent development 時最容易跳過的一格：把「答得對」當成「做得到」。據 TechCrunch 的報導，Zest 的管家短訊號碼是 (212) 470-6067，用戶把號碼加入群組對話，它可以把幾個人的口味併起來找店，再在對話裡完成訂枱。

重點摘要

• Zest 把推薦與訂位收進同一個短訊對話，訂位經 OpenTable、Resy 與 SevenRooms 完成。
• 它能給出貼合個人口味的答案，前提是先取得用戶的用餐紀錄，而非靠問卷。
• 短訊助理免費、無訂閱，iPhone 與 Android 皆可用，不一定要另裝 App。
• 企業要複製「做得到」這一步，關鍵在系統是否開放、流程是否清晰、結果能否驗收。
• 只做答覆的 agent 風險低、見效快；要它代客完成交易，先看後台接得通不通。

目錄

• Zest 今次改動了甚麼
• 由答得到到做得到，差的是哪一格
• 一般 AI agent 教學沒講的一件事
• 你的業務適合做會執行的 agent 嗎
• 群組對話與主動訊息的分寸
• 香港餐飲與零售的落地次序
• Topkee 的觀點：把方法、系統與成果放在同一段對話
• 下一步可以做甚麼
• 常見問題

Zest 今次改動了甚麼

Zest 早期取得 $1.8 million pre-seed 融資，賣點是把用戶的信用卡紀錄接上，看出他實際去過哪裡吃飯。據 Zest 官網的說明，用戶把信用卡連結後，去過的餐廳、咖啡店與酒吧會自動落到地圖上，包括旅途中的一家壽司店；官網同時寫明可用 2 分鐘把整個用餐歷史放上地圖，並可讀取信用卡上 2 年的用餐紀錄，平台上已有 250K+ 經核實的到訪紀錄。

這次更新把同一件事換一個入口。過往要開 App、滑地圖、看評分，現在只要在短訊裡講一句「星期四約會，西村一帶，好但不要太吵」，它回三個選擇並說明原因。用戶追問等位時間，它答週五通常等 30–45 分鐘，同時表明可以代為預先訂枱；查詢有冇位，就轉到 OpenTable、Resy 與 SevenRooms 這些已連接的服務。Zest 創辦人 Mario Gomez-Hall 對 TechCrunch 的說法是「agent 本身就是產品」——用戶不需要花幾個星期教它認識自己，它由你實際去過的地方開始。

由答得到到做得到，差的是哪一格

很多公司做 AI 客服的第一步，是把常見問題整理成答案庫，讓機械人回覆。這一步有價值，但它只處理資訊落差。Zest 這個案例把問題往前推了一格：用戶最終要的是「幫我留一張枱」，「邊間好」只是中間一步。前者靠內容，後者靠操作。

第三層才是分水嶺。Zest 之所以能在短訊裡直接訂枱，是因為它不必自己建一個訂位系統，而是透過已連接的平台去查空位、落單。這對應到香港企業的處境：如果你的落單、預約、開單都在一套 ERP 或 POS 裡，agent 要真正完成任務，就得先做 erp 系統 整合，把查詢與寫入的接口接出來，而不是另建一份平行資料。

一般 AI agent 教學沒講的一件事

搜尋「ai agent development」，排在前面的多是教學文、五個難度等級的範例、用 Python 由零開始的課程。它們教你怎樣讓模型呼叫工具，卻很少講工具背後接的是甚麼。工具本身不是能力，接得通才是能力。

Zest 的訂位能成立，是因為 OpenTable、Resy、SevenRooms 這類平台本身就開放查詢與落單；換成一家只在電話裡收訂枱的餐廳，同一個 agent 就只能留下意向，或者叫你打去問。這條界線，在評估任何代客執行的 agent 時都適用：先問「它最後一步寫入哪個系統」，再問「那個系統是否開放」。想系統地判斷這一格，可以參考我們的 ai agent development 整理。

對香港的餐飲與零售品牌，這通常意味著三件事需要先確認：

1. 訂位、下單、留貨這幾個動作，目前落在哪一個系統，是否有 API 或可用的接口。
2. 該系統是否允許第三方在對話中提交請求，並回傳確認號碼或狀態。
3. 失敗時有沒有回退路徑，例如轉真人、發確認短訊、寫入待跟進清單。

三題有兩題答不出，代表現在適合做「答問題」與「給建議」的 agent，而不適合承諾「幫你完成」；這種情況下，先做 ai 系統整合 比急著上線更有價值。

你的業務適合做會執行的 agent 嗎

不是每個流程都值得交給 agent 執行。可以用下面四個條件自我檢查，全部成立才值得投入。

• 流程相對清晰：同一個任務每次步驟接近，例外情況少，例如訂枱、預約試身、安排送貨時段。
• 資料可獲得：判斷所需的資料已經存在系統裡，例如營業時間、座位數、庫存、客戶等級。
• 結果可驗收：完成與否有客觀憑證，例如確認號、訂單號、系統狀態變更。
• 錯誤可回復：出錯時可以取消、改期或轉人手，損失有限。

反過來說，報價、退貨爭議、涉及合約條款的銷售，現階段交給 agent 直接執行，風險大於便利。這類工作更適合由 agent 整理資料、草擬回覆，最後由人按下確認，再談 ai agent development 的下一步。

群組對話與主動訊息的分寸

Zest 有兩個設計細節，對做營銷的人特別有參考價值。第一，它可以被拉進群組對話，把幾個人的口味併起來，並在對話裡投票決定去哪裡，然後直接在對話裡訂枱，不用跳出去。第二，它的主動訊息有節制：據 Text Zest 頁面的說明，它最多約每週一次主動發訊息，其餘時間只在你發短訊時回覆，頁面的說法是「沒有人喜歡連環短訊」。

這兩點指向同一個原則：agent 的價值在於省掉切換，而不是增加打擾。品牌做 WhatsApp 或短訊渠道時，常把「推送」當成主要功能，結果被客戶封鎖。Zest 的做法是先把主動權交回用戶，只在有明確價值時才主動出現。同一邏輯放到零售，就是會籍提醒、補貨通知、預約前一日確認，而不是每日優惠轟炸。

香港餐飲與零售的落地次序

若要把這個案例套用到本地業務，次序比工具重要。以下是可按月推進的四步。

第一步，挑一個高頻、步驟固定的任務，例如訂枱或預約睇樓，先寫清楚理想流程與例外處理，用真人跑一次，記錄每一步需要查哪個系統。

第二步，確認接口。若現有系統沒有開放接口，先做 ai 系統整合，把查詢與寫入接通，並保留紀錄以便日後核對。這一步往往決定項目是否真的能上線。

第三步，做小範圍試行，只開放一個渠道（例如 WhatsApp），只處理一個任務，並設真人接手。用兩至四星期觀察完成率與錯誤類型。

第四步，把成果沉澱成可重用的資產：對話紀錄、處理規則、成功案例。下一次擴到第二個任務時，不必由零開始。

Zest 本身也是這樣走過來的。據 TechCrunch 的報導，公司在前一個月開始測試管家，但決定等訂位功能做好才正式推出。這個選擇反映一個現實：用戶對 agent 的期待是「幫我做完」，功能半途而廢，反而消耗信任。

Topkee 的觀點：把方法、系統與成果放在同一段對話

把 Zest 的案例放回香港市場，Topkee 的看法是：一個 agent 能否代客完成任務，取決於專業方法、系統操作與成果續用三層是否同時在位。Topkee AI Agent 的定位，正是把專業方法與業務系統組織成能執行任務的 AI 夥伴：它理解自然語言任務，讀取被引用的資料與對象，按任務匹配能力與工具，連接已授權的業務服務，最後交付文件、頁面與業務對象，並可在工作台續改。

在方法一層，專業流程寫進崗位規則、Skill 與 Playbook，讓同一個任務每次按同一套步驟走；在系統一層，業務資料查詢與可用操作接入同一段對話，這正是 Zest 能訂枱的同一道理；在成果一層，報告、頁面與對象存入 Library 可以再用，而不是每次對話完就消失。這個架構適合流程相對清晰、資料可獲得、結果能夠驗收的工作，與上文四個條件一致。

在系統層，Topkee 的工作是把客戶現有的 CRM、ERP、電商商城與舊資料庫接入閉環，而不只是讀標準渠道報表，一般需時幾天而非數月；每項整合作為規範工程化服務持續運行、自動更新。其集成目錄已列出多個預約類資料源，包括 Bookeo Webhook、Weber Booking、Calendly、Jotform 與 ezyVet 預約同步，統一匯入 TTO CDP 作歸因與跟進。這裡要說清楚邊界：這些是資料接入連接器，並不等於「由代理自動完成訂位」；知識庫亦未收錄餐廳搜尋或訂位履約功能。

同樣的邊界也適用於語音渠道。Topkee 的語音產品會記錄「預約意向」，但只有經日曆連接、得到確認的結果才算一宗訂位；系統裡標示「已預約」而沒有確認，並不等於客人真的訂到了枱。這一點與 Zest 依賴 OpenTable、Resy 與 SevenRooms 回傳結果是同一原則：agent 的承諾必須有系統紀錄支撐。

至於規模，Topkee 的目錄以模板形式公開 Skill、Bot Team 與 Plugin，官方註明條目數只是模板數量，不代表全部完成業務驗收。對準備起步的企業，這種分層的意思是：可以先由一個任務、一個 Skill 開始，按實際驗收結果逐步擴展，而不必一次過改動全部流程。

下一步可以做甚麼

如果你的業務目前停留在「答問題」層，一個實際的下一步，是把最常被問的三個問題，連同它們需要查哪個系統、答案哪來，寫成一頁流程；再挑其中一個有清楚確認憑證的任務，做一次小範圍試行。想先了解對話式 agent 與系統整合怎樣配合，可以看 Topkee 的 AI agent 開發頁；若你的場景本來就以電話或 WhatsApp 為主，也可以參考 Voice Agent 如何處理接聽與跟進，以及 TTO Funnel Tuning Agent 如何在漏斗每一段找出漏位。

常見問題

Zest 的短訊管家收費嗎？

據 Text Zest 頁面的說明，助理免費、無訂閱，iPhone 與 Android 皆可用，不一定要另裝 App。它靠訂位與日後的落單交易參與收入。

我的公司沒有訂位平台，還能做代客訂位的 agent 嗎？

可以先做，但完成的定義要改。沒有開放接口時，agent 只能留下意向、整理資料或轉真人，不能自稱完成訂位。要先做系統整合，把查詢與寫入接出來，才有條件承諾「幫你訂到」。

agent 要讀取客戶的歷史消費資料，會不會有私隱問題？

會，而且要事前處理。Zest 的做法是只用信用卡中餐飲類別的交易來建地圖，並經第三方金融資料服務匯入。企業做同類功能，應先界定讀取範圍、告知用途，並保留客戶撤回的途徑。

短訊、WhatsApp 還是 App 內對話，應該選哪個渠道？

看客戶本來在哪裡。Zest 選短訊，是因為它想把 App 從流程中拿走。香港市場若客戶主要用 WhatsApp，先在該渠道做單一任務，比另開一個 App 更易見到效果。

要多久才知道這個 agent 是否值得繼續投資？

按上文建議，用兩至四星期的單一任務試行，觀察完成率、錯誤類型與轉真人比例，再決定是否擴展。若連確認憑證都拿不到，代表問題在系統而不在模型。

Sources

1. Sarah Perez, "Zest’s new AI agent finds restaurants and books reservations over text", TechCrunch, 2026-10-31. https://techcrunch.com/2026/10/30/zests-new-ai-agent-finds-restaurants-and-books-reservations-over-text/
2. "Zest · The restaurant map that builds itself", Zest Maps, 2026-11-03. https://www.zestmaps.com/
3. "Text Zest • Restaurant picks based on where you actually eat", Zest Maps, 2026-10-31. https://www.textzest.com/