一家餐廳同時接 GrabFood、foodpanda、ShopeeFood：三個平台的訂單，怎樣進入同一個後台？
一家餐廳同時經營 GrabFood、foodpanda 和 ShopeeFood，真正的難題不只是接收訂單，而是統一菜單、訂單狀態、廚房、退款和對帳。本文拆解餐飲 SaaS 怎樣把多平台訂單變成一套門店流程。
寫在前面：上一篇談到餐飲 SaaS 出海，怎樣避免把本地化做成客戶定制。其中一類真正值得優先處理的本地化，是當地餐廳普遍依賴的訂單渠道。這類渠道我也分別在香港 POS 市場的四個判斷（外賣整合能力正在重畫 POS 版圖）與餐飲數位營銷（訂單聚合不丟一單）兩篇提過——那兩篇是市場判斷與發現，這篇想把外賣平台整合拆成操作層：一家餐廳同時接 GrabFood、foodpanda 和 ShopeeFood，真正要整合的究竟是三個接口，還是整套門店營運？
三台設備，不等於三倍生意
下午五點半，新加坡一家餐廳準備迎接晚市。櫃台上的 GrabFood、foodpanda 和 ShopeeFood 設備輪流響起。店員一邊接單，一邊重新輸入 POS，再向廚房確認套餐、加料和備註。
高峰期只要看漏一次，後面就是催單、退款和差評。
這不是某一家餐廳才有的問題。當訂單入口不斷增加，很多餐廳都在面對相似的營運壓力。
如果店員仍要盯着三個入口、重複輸入訂單，所謂數字化，只是把紙質訂單換成更多屏幕。
所以我越來越確定一件事：
真正的外賣平台整合，不是把三個訂單通知搬進同一個屏幕，而是讓菜單、訂單、廚房、退款和對帳，共享同一份事實。
最笨的做法：把複雜度全部交給店員
每個平台保留一台設備，店員手動接單、抄單和對帳。這個方法不是不能用，它甚至是很多餐廳開始做外賣時最快的辦法。
但「能運作」不代表「能擴張」。
訂單一多，問題很快出現：
- 漏單：高峰時通知沒有被看到，直到顧客投訴才發現；
- 抄錯：套餐、加料和備註在重新輸入時出錯；
- 售罄不同步：門店賣完一道菜，某個平台仍然可以下單；
- 狀態不一致：平台已取消，廚房卻已開始製作；
- 對帳困難：不同平台的優惠、費用、退款和結算混在一起。
這套做法最大的問題，不是多用了幾台設備，而是把平台之間所有差異，都交給最忙、最容易出錯的前線員工處理。
訂單進入後台，只是整合的第一步
很多產品介紹外賣整合時，最常展示的畫面是： GrabFood 來了一張單，自動出現在 POS；foodpanda 來了一張單，也自動出現在 POS。
這當然比手動輸入好，但它只完成了第一步。
因為三家平台的訂單，根本不是同一種東西：
- 商品、套餐、加料、備註和折扣的資料結構不同；
- 「已接單」「製作中」「已取餐」「已完成」的定義不同；
- 顧客取消、平台取消和餐廳拒單的責任也不同；
- 推送、重試和故障恢復方式不一定相同。
所以目標不是把三個平台的單放在同一頁，而是把三個渠道翻譯成一套統一的內部訂單模型——欄位對齊、狀態對齊、生命周期對齊。做到這一層，後台才真正「接住」了外賣，而不是多開了三個視窗。
這些聽起來像技術細節，背後其實是一個管理問題：
接口可以不同，但訂單真相只能有一份。
餐飲 SaaS 可以先建立一套自己的標準訂單模型：
已建立 → 已接受 → 製作中 → 待取餐 → 已取餐 → 已完成
↘ 已取消／已退款再把不同平台的狀態映射進來，同時保留平台原始狀態、事件來源和時間。這樣平台語言可以不同，門店內部仍然只需要理解一套流程。
否則客戶問「這張單現在在哪裏」，營運、廚房、客服和財務會給出四個答案。
真正的整合，要走完六層
我習慣把多平台訂單整合拆成六層：
| 層 | 要解決的問題 | 最容易忽略的地方 |
|---|---|---|
| 1. 渠道接入層 | 把不同平台的訂單可靠地接進來 | 延遲、重複事件、接口故障和補單 |
| 2. 訂單標準化層 | 把商品、數量、備註、價格和狀態轉成統一格式 | 不同平台對同一件事有不同定義 |
| 3. 菜單同步層 | 對應商品、套餐、加料、價格和可售狀態 | 商品映射失效、售罄沒有同步 |
| 4. 廚房執行層 | 把訂單送到正確門店、工位、打印機或 KDS | 堂食與外賣爭用產能，出餐節奏失控 |
| 5. 取消與異常層 | 處理拒單、取消、退款、斷線和狀態衝突 | 平台已取消，廚房卻已經出餐 |
| 6. 結算與財務層 | 對清銷售、優惠、費用、退款、應收和實收 | 訂單金額不等於銀行到帳 |
前兩層決定訂單能不能接進來；中間兩層決定門店能不能準確執行；最後兩層決定這套系統能不能長期營運。
少任何一層，都只能算「接到訂單」，不能算「完成整合」。
訂單同步只是入口，營運閉環才是整合。
菜單同步，比訂單同步更容易失控
訂單是一次性的，菜單卻每天都在變。
同一道菜，在 GrabFood、foodpanda 和 ShopeeFood 可能使用不同名稱、圖片和價格；一個平台有專屬套餐，另一個平台有不同的加料結構；同一品牌不同門店，營業時間和售罄狀態也可能不同。
所以外賣整合一定要先回答：
哪一個系統，是菜單的唯一主數據源？
我傾向讓餐飲 SaaS 後台管理標準商品、規格、門店菜單和可售狀態；平台保留渠道專屬價格、圖片、描述和促銷，再用映射關係連接兩邊。
這不是要求所有平台顯示完全相同，而是要清楚哪些資料由總部控制，哪些差異屬於渠道。
售罄同步尤其重要。門店不應該在三個 App 裏逐個關閉商品；同步失敗也不能安靜地失敗，系統必須告訴店員哪個平台仍未更新。
如果沒有唯一的菜單主數據源，三個平台很快就會出現三份不同的真相。
前台可以有很多渠道，廚房只能有一套節奏
門店需要知道訂單來自哪個平台，廚房卻不應該學三套生產流程。
平台訂單進入後台後，應按照門店、菜品和製作工位，自動送到正確的打印機或 KDS。堂食和外賣可以保留渠道標記，但製作優先級、配料顯示和出餐確認應使用同一套規則。
到了高峰期，系統還要處理另一個問題：平台承諾時間和廚房實際產能是否一致？
如果訂單不斷進來，門店應該能暫停單一渠道、關閉部分商品，或者調整備餐時間，而不是等廚房塞滿後再逐一向顧客道歉。
前台可以有很多渠道，後台只能有一套生產節奏。
訂單送進廚房，不代表交易已經完成
外賣整合最容易被低估的部分，不是接單，而是退款與對帳。
一張顧客支付 100 元的訂單，最後可能包含商品銷售額、稅項、平台補貼、商戶承擔的優惠、平台費用、全額或部分退款、客訴賠付、實際應收和銀行到帳。
如果後台只記錄「訂單金額 100 元」，營運看到的是銷售，財務看到的卻是另一個數字。
所以每張平台訂單至少要分清：
- 顧客支付多少；
- 商品實際賣了多少；
- 優惠由誰承擔；
- 平台扣了多少；
- 退款或賠付多少；
- 最後應收和實收多少。
這也呼應我之前談海外支付整合時的一個判斷：交易成功不只是頁面顯示「Payment Successful」，而是退款、結算和對帳都能走完。
訂單送進廚房不代表交易完成；錢對得上，整合才算完成。
三條接入路徑，解決的深度不同
餐廳想把多平台訂單集中起來，大致有三條路。
第一條：硬件聚合
把不同平台的訂單集中打印，或者收進一台接單設備。
它的優點是上線快、培訓簡單，適合只想先減少漏單的門店。但它通常只能解決「看見訂單」，未必能處理菜單同步、庫存、雙向狀態和財務對帳。
第二條：平台 API 直連
由餐飲 SaaS、POS 廠商或餐飲集團直接連接平台。
它的控制權最高，也最容易把訂單、菜單和廚房流程做深。但每個平台都要獨立處理合作資格、接口差異、版本更新、故障監控和長期維護。
第三條：第三方聚合服務
由聚合服務先連接不同平台，再把標準化後的訂單交給餐飲 SaaS 或 POS。
它適合快速進入新市場或覆蓋長尾平台。代價是多一層費用和依賴，部分平台能力可能無法完整使用，出問題時責任定位也更複雜。
三條路沒有絕對優劣。真正要問的是：你只需要減少漏單，還是要把菜單、庫存、廚房和對帳一起打通？
自建還是聚合，不要只比較月費
如果只看報價，團隊很容易低估真正成本。
選型時，我會看四件事：
- 現有系統兼容性：目前 POS 已支援哪些平台？支援單向接單，還是雙向同步？
- 訂單規模與分佈：訂單集中在一個核心平台，還是多個平台都不可忽略？
- 需要整合的深度：只要接單，還是要菜單、庫存、廚房、退款和財務閉環？
- 總擁有成本：除了月費，還要計算實施、培訓、維護、故障處理和出錯成本。
一家餐廳 90% 的外賣訂單都來自同一平台，做法可以是先把核心平台接深，其他渠道暫時保留較輕的方案。
但如果三個平台訂單都很多，漏單、售罄和對帳已經成為日常成本，那就不應該只買一個「統一顯示」工具。
對餐飲 SaaS 團隊，我的判斷是：
| 場景 | 建議 |
|---|---|
| 核心市場、訂單量大、平台穩定 | 評估直接整合主要平台 |
| 新市場、訂單量尚未驗證 | 先用聚合服務驗證需求 |
| 小眾或長尾平台 | 交給本地伙伴或中間層 |
| 平台缺少穩定接口 | 保留人工或半自動降級方案 |
| 多個市場共用 | 先建統一訂單模型，再接不同適配器 |
這和本地化與客戶定制的邏輯相同：標準化自己的核心，讓接口和生態吸收市場差異。
核心平台可以直連，長尾平台交給生態。不要為了證明技術能力，把每一條接口都變成自己的長期負債。
接口上線，不等於門店真的用好了
不少整合項目的驗收標準只有一句：「API 已經接通。」
但對門店來說，真正重要的是：
- 有多少訂單可以自動進入後台？
- 還有多少訂單需要店員重新輸入？
- 有沒有漏單或重複訂單？
- 菜單和售罄多久能同步？
- 高峰期系統是否仍然穩定？
- 退款和平台結算能否對上？
如果接口已上線，店員仍要盯三台設備、手動關閉三次售罄、月底再用試算表對帳，這個項目在技術上完成了，在業務上卻沒有完成。
接口上線是技術里程碑，門店少做一步才是業務結果。
結語
餐廳接入更多外賣平台，不代表門店流程也應該跟着增加。
渠道可以是 GrabFood、foodpanda、ShopeeFood，也可以是下一個剛剛出現的本地平台。但進入餐廳之後，它們都應該變成同一套商品、訂單、廚房、退款和對帳語言。
對不少門店來說，第一步不需要追求所有平台、所有功能全部打通。先做到三件事已經很有價值：
訂單不漏、售罄不亂、對帳不靠猜。
再根據訂單規模和業務需要，逐步增加菜單同步、廚房產能和跨平台分析。
所以，餐飲 SaaS 要做的不是一個放着三個平台 Logo 的「統一收件箱」，而是一個能守住訂單真相、菜單真相和財務真相的營運後台。
餐廳真正需要的，也不是接入更多平台。
而是無論訂單從哪裏來，門店都只需要管理一套流程。
好的外賣整合，不是後台多了三個平台 Logo，而是午市高峰時，店員終於可以少看幾塊屏幕。
如果你正在做餐飲 SaaS 的外賣平台整合，可以先拿一張真實訂單走完整條鏈路：從菜單映射、接單和出餐，一直追到取消、退款和銀行到帳。任何仍要店員重複操作、靠試算表補回來的地方，都是整合還沒有真正完成的地方。