冰品店多家外送平台菜單同步與缺貨即時下架流程

🎯 這條流程解決什麼

只要冰品店同時掛在 Uber Eats、Foodpanda，又有自家官網點餐，菜單管理就會變成一場永遠對不齊的拉鋸戰。夏天主打的某口味臨時調漲十元、某款配料當天賣完、新品想上架——每改一次，店主就得分別登入三個後台各改一遍。問題是門市最忙的時段往往就是最需要改菜單的時段，一忙起來總會漏掉一個平台：A 平台改好了、B 平台忘了同步，客人在 B 平台下了單，做不出來只能取消，輕則退單、重則換來一星負評，平台的接單評分也跟著被扣。

純人工同步的隱形成本，比表面上「多登入幾次後台」嚴重得多。第一是「漏改的代價不對稱」：忘了上架新品只是少賣，但忘了下架售完品項卻會直接接到做不出來的訂單，每一筆都是真實的客訴與退單。第二是「現場資訊落差」：店員不知道哪個平台還掛著已售完的品項，接到單才發現出不了餐，當場手忙腳亂。第三是「時間黑洞」：一天改個三、五次菜單，每次三個後台輪流登入，零碎時間加總起來相當可觀。這條流程把多通路菜單收斂成單一資料來源，改一次、處處同步，售完即時下架，徹底擺脫「某平台忘了改」的惡性循環。

導入後的改變

導入前，菜單管理是高風險的重複勞動：店主同一筆變更要在多個後台手動重打，靠記性確保每個平台都改到，售完品項常常還掛在某個平台上接單，現場才驚覺出不了餐。旺季每天因為菜單不同步造成的退單與客訴，累積起來既傷收入又傷評分，店主還得花時間善後道歉。

導入後，店主只在一份主菜單表單調整品項、售價或標註售完，系統自動把變更同步到各外送平台與官網，售完品項即時在各平台暫時下架，同步結果還會推播到門市群組。原本一筆變更要分頭操作三個後台、花上好幾分鐘，現在改一次表單就全通路生效，菜單維護工時省下約七成以上。更實際的效益是「做不出來的訂單」幾乎消失——售完即時下架後，因缺貨被迫取消的訂單大幅減少，連帶降低退單客訴與平台扣分，現場人員也不再接到出不了的單。

流程怎麼運作

整條流程對應 frontmatter 的四個節點，逐步驟說明如下。

第一步「菜單變更」，店主在一份主菜單表單（或試算表）上調整品項、售價、上下架狀態或標註售完。這份表單是所有通路的「單一資料來源」，往後所有平台都以它為準，從根本上消除各平台各改一套、彼此不一致的問題。

第二步「多平台同步」，只要主菜單一有變更送出，系統自動把更新推送到各外送平台後台與自家官網，包含改價、改品名、上下架等，不再需要店主逐一手動登入修改，也就不會發生改了 A 漏了 B 的情況。

第三步「缺貨下架」，當某口味或配料被標記為售完，系統即時在各平台把該品項（以及用到該配料的相關品項）暫時下架，避免繼續接到無法出餐的訂單；等補貨後再把售完標記取消，品項就會自動重新上架。

第四步「團隊通知」，把同步結果與當前下架品項清單推播到門市 Line 群組，現場人員一眼就掌握各平台目前到底哪些能賣、哪些暫停，接單時不用再猜、不用再現場核對。

需要的工具與串接重點

平台用 n8n 或 Make。核心是一份當作單一資料來源的主菜單表單或試算表；同步端串各外送平台後台與官網的菜單介面；缺貨售完用試算表的狀態欄位即時觸發；現場通知用 Line 通知群組；若有需要對客人說明的情境，可用 AI 草擬客服訊息。

串接重點有幾個：第一，主菜單表單的「單一資料來源」原則要徹底落實，所有變更只在這裡改，嚴禁有人偷偷直接去某平台後台手改，否則資料就會分岔。第二，要釐清各外送平台是否提供菜單同步介面或開放接口，部分平台需透過官方後台或合作方式串接，串接前先確認權限。第三，「售完即時下架」務必涵蓋連動品項——某配料售完時，所有用到它的品項都要一起下架，避免漏網。可搭配 冰品店季節新品上市公告流程 讓新品上架就同步進外送菜單，更多自動化設定見 自動化專區。

常見錯誤與注意事項

最容易出事的是「價格」。自動同步的售價與品項以主菜單表單為準，但各外送平台的抽成比例不同，同一個品項在不同平台的合理定價可能本來就不一樣。因此正式生效前務必由店主人工確認各平台的抽成與定價是否一致，避免把官網價直接同步到高抽成平台、做一單虧一單。涉及金錢的定價調整，AI 不取代人工判斷，一律需人工確認後再生效。

涉及外送平台合約條款、費率設定、上架規則的調整，請依各平台官方規範並由負責人確認後操作，本流程不取代平台官方後台的最終設定權限——自動化是把變更推送過去，最終以平台後台實際生效狀態為準，上架後建議抽查各平台顯示是否正確。

台灣中小企業情境案例

新竹一家人氣蛋捲冰淇淋店，同時經營兩家外送平台與自家官網，假日一忙起來菜單常常對不齊，最常見的狀況是某熱門口味中午就賣完了，但忘了在其中一個平台下架，下午陸續接到好幾筆做不出來的訂單，只能一筆筆取消、道歉，平台接單評分被扣得心疼。導入這條流程後，店主只要在主菜單表單把口味標成售完，系統就即時在所有平台下架，並把當前可售清單推到門市 Line 群組。一個月後，因缺貨被迫取消的訂單幾乎歸零，菜單維護時間從每天分頭改後台縮短到改一份表單，店員也不再接到出不了的單，假日營運順暢許多。

延伸應用

這條流程的「單一資料來源 + 多通路同步」骨架可以延伸到更多營運場景：例如把季節限定品項設定排程自動上下架，到檔期就上、過了就收；或是依時段自動調整菜單，把宵夜時段的限定品項定時開關。客訴端則可接續 冰品店客訴回覆與補償處理流程 把外送相關客訴接起來統一處理，讓菜單、缺貨、客訴形成一條完整的外送營運鏈，更多開店點子見 食譜庫。

流程圖

用到的工具

更多「餐飲美食」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →