外賣平台帶來訂單，但誰掌握顧客關係？

寫在前面：之前寫過三個外賣平台的訂單，怎樣進入同一個後台。那篇處理的是訂單整合：餐廳怎樣減少多部平板、重複輸入和漏單。

但訂單進入同一個後台之後，還有一個更難的問題：餐廳收到了一張訂單，是否也建立了一段顧客關係？

一張平台訂單完成之後，餐廳留下了甚麼？

一家餐廳在 GrabFood 上接到一張大單。餐做完了，訂單也完成了。

下一次這位顧客想吃同類餐點時，他仍然會先打開平台，重新決定選哪一家餐廳。

對餐廳而言，這次交易完成了；顧客關係是否開始，卻不一定。

老闆未必知道他是不是第一次下單、之前買過甚麼，或者會不會再次光顧。餐廳完成履約，平台完成交易，下一次互動的入口仍然主要掌握在平台手上。

這不是說平台搶走了餐廳的顧客。

平台提供流量、支付、配送和售後處理，也承擔相應成本。餐廳支付佣金或其他費用，換取的是一套已經存在的交易渠道。

但在平台交易中，餐廳能取得的通常是完成訂單所需的資料，不一定包括可以長期使用的顧客身份和聯絡權限。這個差別可以從三個方面理解：

• 身份：餐廳看到一張訂單，不代表系統已經建立一個經顧客確認的會員身份；
• 數據：餐廳可以看到這次交易，卻未必能辨認跨訂單、跨門店和跨渠道的消費行為；
• 再次接觸：顧客下一次打開平台時，餐廳仍要重新參與平台內的曝光和選擇，除非顧客已主動加入餐廳自己的渠道。

平台帶來訂單機會，不代表餐廳已經建立了可以持續經營的顧客關係。

平台的佣金、排序或曝光規則一旦改變，餐廳的獲客成本和訂單來源也可能受到影響。這就是為甚麼餐廳需要在平台之外建立第二個顧客入口，而不是把全部顧客關係放在單一渠道上。

為甚麼這是產品設計問題？

有人會說，做會員、CRM 和優惠，不就是數位營銷嗎？

真正落地時，問題沒有那麼簡單。

餐廳在哪個場景取得顧客同意？不同渠道的身份能否合併？平台訂單可以保留哪些資料？會員優惠怎樣在 POS 核銷？一次投訴處理後，系統能否追蹤顧客是否再次光顧？

這些不是做一場推廣活動就能解決的問題。它們涉及產品流程、數據模型、系統整合和權限邊界。

把外賣訂單接進後台，只解決了履約效率。把每次交易逐步連接成顧客同意、餐廳可以持續服務的關係，才是 CRM。

所以，建立顧客關係不是一個營銷口號，而是一組產品決策。

顧客關係的三個階段

同樣在使用外賣平台，不同餐廳與顧客之間的關係可以相差很遠。

第一階段：只有平台交易

餐廳收到訂單並完成履約，但下一次互動仍主要由平台發起。

系統可以看到渠道營業額和訂單內容，卻未必能確認新客、熟客和跨渠道回購。顧客下一次打開平台時，餐廳仍要重新競爭曝光和選擇。

第二階段：顧客主動加入會員

顧客透過餐廳自己的入口註冊、訂閱或綁定身份，例如堂食會員、自家網上點餐、預訂、到店自取或電子收據。

重點是顧客清楚知道自己正在與餐廳建立直接關係，也同意餐廳在指定用途下保存和使用資料。

第三階段：建立全渠道顧客關係

在取得同意後，堂食、自取、預訂、會員和售後服務逐步連接。餐廳開始看見顧客在哪些門店和渠道消費、曾經遇到甚麼問題，以及是否再次光顧。

這不代表所有資料都要集中，也不代表系統可以自行推斷顧客身份。無法確認的記錄，寧可保持分開。

餐飲 SaaS 要建立的五個能力

要從平台交易走向直接顧客關係，餐飲 SaaS 至少要處理五件事。

第一步：保留渠道來源

每張訂單要清楚標記來自堂食、外賣平台、自家網店、預訂還是到店自取。

否則餐廳只能看到總營業額，無法判斷不同渠道帶來的是新客、回購，還是優惠推動的短期交易。

第二步：不要強行合併顧客身份

同一個人在不同渠道留下的資料，不一定可以直接判定為同一位顧客。

電話、電郵、裝置或會員資料可能不完整，也可能受平台規則限制。比較穩妥的做法，是讓顧客主動登入、綁定會員或確認身份。系統不能因為兩張訂單看起來相似，就自行合併記錄。

第三步：把同意放進產品流程

顧客加入會員、訂閱訊息或留下聯絡方式時，系統需要說清楚資料由誰收集、用來做甚麼、是否會用於推廣，以及顧客怎樣取消或修改同意。

同意不是藏在頁面底部的一個勾選框，而是產品流程的一部分。

第四步：把 CRM 與營運連接

顧客關係不能只留在市場部。

投訴需要進入客服和門店流程；會員優惠要能在 POS 正確核銷；回購變化也要能與門店、商品和渠道對照。

這也延續了上一篇怎樣把線上評價變成營運數據的判斷。如果一位顧客留下差評，系統不應只記錄客服是否回覆，還要追蹤問題有沒有解決。

第五步：衡量回購，不只衡量觸達

會員數量、訊息發送量和優惠領取量容易增加，卻不一定代表顧客關係變好。

餐廳更應該看顧客有沒有再次消費、回購來自哪個渠道、優惠停止後是否仍然回來，以及投訴處理後是否繼續光顧。

真正要改善的不是發了多少訊息，而是餐廳能否持續服務同一批顧客，不必每次都重新購買流量。

AI 回訪可以做甚麼？

對比單純發送優惠，售後回訪是一個更自然的接觸點。

但它有明確前提：平台本身提供合規的售後訊息渠道，或者顧客已在餐廳自有渠道主動留下聯絡方式，並同意相關用途。

在這個前提下，AI 可以協助：

• 發送一般回訪，並邀請顧客評價、收集意見；
• 整理回覆並判斷問題類型；
• 發現等候時間、漏單或口味等負面信號；
• 把需要補救、退款或承擔責任的個案轉交真人。

AI 回訪可以是其中一個入口，但不是唯一入口。餐廳還可以在自己的服務場景中，設計幾個成本不高的接觸點：

• 小票或電子收據上的 QR Code：讓顧客主動加入會員、查看訂單或選擇是否接收後續服務；
• 售後與評價入口：讓所有顧客都能提出意見，負面問題及時進入門店處理，正面評價則由顧客自行決定是否公開分享；
• 取得同意後的 Email 或 SMS：用於訂單通知、售後跟進或顧客已選擇接收的會員訊息；
• 包裹卡或堂食提示卡：在平台規則允許的情況下，介紹餐廳的會員、自取、預訂或售後服務入口。

這些接觸點的目的，不是把平台顧客強行導走，而是讓顧客知道：除了平台之外，他也可以選擇直接與餐廳保持聯絡。

接觸點不需要很多。更重要的是，每一個入口都由顧客主動選擇，並且清楚說明資料用途。

AI 的作用是降低處理大量回覆的成本，不是替餐廳取得顧客同意，也不能自行承諾賠償。

如果平台只為履約提供聯絡資料，餐廳便不能把它直接交給自己的 AI 客服，在平台外主動推廣。接觸點能不能使用，要先看平台條款、顧客同意和當地私隱要求。

顧客資料不是餐廳想拿多少就拿多少

談顧客關係，很容易走向另一個極端：認為只要完成過交易，顧客資料就應該屬於餐廳。

不是這樣。

不同平台會按照自己的條款開放不同資料，不同市場也有不同的私隱和推廣要求。履約所需的資料，不能自動轉為其他用途。

幾個邊界不能混淆：

• 平台提供作履約用途的資料，不代表可以用來獨立推廣；
• 顧客在一個渠道同意的用途，不一定適用於另一個渠道；
• 分析營運問題，不等於可以識別和追蹤每一位顧客；
• SaaS 可以管理同意和權限，但不能替餐廳決定合法用途。

建立顧客關係，不是把平台資料搬進自己的資料庫。它是顧客透過餐廳的服務入口，清楚同意再次互動。

平台與自有渠道不是二選一

餐廳不應幻想完全離開外賣平台。

平台適合帶來新客和即時需求，自有渠道則服務已經認識品牌、願意直接互動的顧客。SaaS 要做的，是把各渠道的營運結果放在同一個後台，再在顧客同意下連接會員和服務關係。

餐廳也不需要把所有平台顧客趕到自己的 App，更不應違反平台規則導流。目標是建立第二個顧客入口，降低對單一渠道的依賴。

平台依賴本身不是問題。完全沒有其他顧客入口，才會讓餐廳失去選擇；而哪些顧客值得長期經營，也是客戶選擇要回答的問題。

結語：顧客是否願意再次與餐廳對話？

外賣整合的第一階段，是把不同平台的訂單送進同一個後台。

第二階段，是讓餐廳看懂每個渠道帶來的營業額、成本、顧客反應和回購。

再往後，才是顧客關係。

餐廳不能因為收到一張平台訂單，就宣稱擁有這位顧客。但它可以透過更好的服務和自己的入口，讓顧客願意再次直接回來。

建立顧客關係，不是拿到一個電話號碼，而是顧客願意並同意與餐廳再次對話。

所以，訂單完成之後，餐飲 SaaS 還要幫餐廳回答一個問題：

我們只是多了一筆交易，還是多了一次建立顧客關係的機會？