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 呢部跑步機——等到你需要其餘五個渠道嗰日，佢哋亦會從同一段處理邏輯裡到嚟。