Zalo 2026 年 6 月新版 OA 資費上路：一支跨境團隊如何繼續接收 Zalo 訊息，又不被 OA 流程牽著走 — UnifyPort

2026 年 6 月 1 日，Zalo 全新的官方帳號（OA）服務資費正式生效。對於一支在胡志明市小辦公室裡賣保養品的五人跨境團隊來說，這封郵件來得不是時候：正值大促期間，兩名同事幾乎一整天都在 Zalo 和 WhatsApp 的聊天裡回覆客戶。這份資費通知把他們一直拖著沒面對的問題逼了出來——繼續做我們現在做的事，到底要花多少錢？

而他們現在做的事其實很單純：客戶在 Zalo 上向店家發訊息，有人回覆。就這樣。沒有群發、沒有行銷推播、沒有自動滴灌序列。可是 Zalo 為「想以程式方式接收訊息的企業」鋪的那條路，要走完整套官方帳號的流程——而這套流程是為群發方設計的，不是為一支只想回覆主動上門客戶的團隊設計的。

OA 這台「跑步機」，為什麼不適合他們

透過官方途徑接收 Zalo 訊息，意味著要開通官方帳號、完成驗證，然後在 OA 的規則裡生活。最難受的是互動視窗：OA 只能在使用者主動聯絡你之後的一段有限時間視窗內，自由地向該使用者發訊息。一旦超出這個視窗——隔天早上跟進、兩天後發個訂單更新——你就進入了 Zalo Notification Service（ZNS）的範疇：每則訊息都要掛在一個事先審核過的範本上，而且按則收費。

對群發方而言，這筆交易很合理；對一家五人小店來說，這就是一台跑步機。每個範本都要先撰寫、送出、等待審核，才能使用。6 月 1 日的資費調整重新劃分了 OA 方案的級距，也改變了哪些算在免費額度內、哪些要計費——而團隊的解讀是：他們這種真正低頻、對話式的用法，眼看著既要變貴、又要變得更繁瑣。他們並沒有在發成千上萬則行銷訊息，他們只是在回答問題，卻被要求套用一家「做著他們根本沒在做的事」的公司的成本結構與審核流程。

而且 Zalo 還只是其中一個收件匣。同樣這兩名同事一整天也泡在 WhatsApp 裡，那邊又有自己一整套機制——企業驗證、按則計費、自家的範本審核。兩個平台、兩套完全不同的規則；真要做自動化，就是兩套對接。代價不只是錢，更在於每個管道都要求團隊先學會一套不同的系統，才能做成他們真正想做的那一件事：看到訊息進來，然後回覆。

重新定義問題：他們要的是入站，不是一個官方帳號

真正解開這道題的洞察，是把他們需要什麼和官方路徑打包了什麼分開來看。OA 的群發機制——範本、ZNS、互動視窗、額度級距——存在的意義，是讓企業能夠大規模地主動發起聯絡。而這支團隊從不主動發起，每段對話都由客戶先開口。他們需要的，僅僅是可靠地接收入站訊息，並在客戶已經打開的那段對話裡回覆。

這比「經營一個官方帳號」要小得多。只做入站、只在對話內回覆的用法，根本用不上那套群發工具。一旦這樣看，問題就不再是「我們該買哪個 OA 方案」，而變成了「把一則入站的 Zalo 訊息送到我們後端、再把回覆發回同一個聊天，最簡單的辦法是什麼」。

一個 webhook，同時管 Zalo 和 WhatsApp

他們透過 UnifyPort 的非官方入站介面把兩個帳號都接了進來。它把每個管道都收到同一個正規化的 webhook 之後，而不是每個平台做一套對接。一則 Zalo 訊息和一則 WhatsApp 訊息以完全相同的結構抵達，唯一的差別就是 provider 欄位：

{
  "event": "message.received",
  "account_id": "acct_7Hm2pX",
  "provider": "zalo",
  "from": "user_9a3f21",
  "text": "Sản phẩm này còn hàng không ạ?",
  "timestamp": 1749513600,
  "message_id": "zalo_msg_4c8e1d"
}

他們的後端只訂閱一個事件 message.received，並按單一欄位分流。處理 Zalo 訊息的那段程式，和處理 WhatsApp 訊息的是同一段——接收端沒有任何按平台分叉的邏輯：

app.post("/webhook", (req, res) => {
  if (!verifySignature(req)) return res.sendStatus(401);

  const evt = req.body;
  if (evt.event === "message.received") {
    // evt.provider 是 "zalo" 還是 "whatsapp" —— 分流邏輯完全一致
    queue.add({
      channel: evt.provider,
      customer: evt.from,
      text: evt.text,
      accountId: evt.account_id,
    });
  }
  res.sendStatus(200);
});

每一次投遞都帶簽章，所以團隊在信任任何 payload 之前，會用他們在 webhook 上設定的 signing_secret 做一次 HMAC-SHA256 驗證——無論訊息來自哪個平台，都是同一個 verifySignature 步驟。回覆則是鏡像操作：一次 POST /v1/messages 呼叫，指明帳號與收件人。因為是客戶先發的訊息，每則回覆都落在客戶打開的那段對話裡——正是團隊原本手動在做的「對話內互動」，現在可以腳本化，而且不需要事先審核任何範本。

實際結果是，6 月 1 日的資費通知不再是一場預算危機。團隊沒有為了繼續回覆這些低頻、客戶主動發起的聊天，而被迫往 OA 更高的級距上買。兩名客服還是守著同樣的兩個收件匣，只不過這兩個收件匣現在匯入同一個佇列、同一套結構、同一條回覆路徑——而日後為一個泰國供應商再接入 LINE，依舊是那段 message.received 處理邏輯，而不是第三個對接專案。

可以帶走的結論

教訓不是「別用 Zalo 的官方帳號」——如果你在做規模化的群發行銷，OA 和 ZNS 正是為此而生，你就該用它們。教訓是：先確認官方路徑解決的，是你的問題，還是一個你其實沒有的更大的問題。一項針對高頻群發方的資費調整，可能悄悄抬高了你「僅僅回覆客戶」的成本，因為官方途徑把這兩種行為打包進了同一個帳號。

如果你需要的只是接收入站訊息、在對話內回覆，那這是一個可以單獨拆出來、便宜得多的問題。把你的後端指向一個正規化的入站 webhook，訂閱 message.received，Zalo 訊息就會進入你的佇列，而不必踩 OA 這台跑步機——等哪天你需要其餘五個管道時，它們也會從同一段處理邏輯裡到來。