← 所有文章
個案分析

我們逐行審視咗 WhatsApp 帳單——60% 都係幫從未用過嘅基建埋單 — UnifyPort

187.42 美元。呢個係一個 4 人客服團隊當月 WhatsApp 帳單嘅總額,比起上個月嘅 134 美元又貴咗一截,而訊息量同人手都無變。財務無問「係唔係太貴」,而係問:「呢究竟係咩錢?」於是團隊從 BSP(Business Solution Provider,WhatsApp 商業解決方案供應商)後台攞出明細帳單,逐行核對。

總額由四項費用組成:

項目金額
對話服務費(Meta)74.10 美元
範本訊息費(被重新分類)41.20 美元
BSP 加價23.12 美元
平台費49.00 美元
合計187.42 美元

接住就係呢次審計嘅內容——每一項究竟係收咩錢,以及呢個團隊日常嘅工作(客戶發訊息、團隊回覆)究竟有無觸發佣。

第一項:對話服務費——74.10 美元,唯一對應真實用量嘅一項

呢係 Meta 對團隊實際發生嘅對話收嘅費:客戶先發訊息,團隊喺開放嘅對話視窗內回覆。呢係 WhatsApp 計費裡最平、最簡單嘅一種,亦直接對應團隊每日做嘅事。呢一項無咩可挑——呢就係工作本身嘅成本。

第二項:範本訊息費——41.20 美元,幫一啲無人意識到係「範本」嘅訊息埋單

呢一項要解釋一下。團隊部分回覆並唔係視窗內嘅簡單回應,而係跟進訊息:第二日早上發嘅訂單狀態更新,一日後發嘅「問題解決咗未」回訪。一旦回覆落喺 24 小時對話視窗之外,WhatsApp 就唔再當佣係「回覆」,而係當佣係範本訊息——按類別同接收國家分別計價,同推廣群發行嘅係同一套計價方式。

團隊裡無任何人提交過範本、審核過範本,大家都以為呢啲訊息只係「回覆遲咗少少」。但喺計費層面,一條遲咗 18 個鐘嘅跟進訊息同一條推廣群發,行嘅係同一張表。

第三項:BSP 加價——23.12 美元,一筆本來唔應該存在嘅百分比費用

喺 Meta 收取嘅費用之上——唔論係合理嘅對話服務費,仲係意外產生嘅範本訊息費——BSP 都會再加埋自己嘅利潤。業界常見比例係 15%-20%。23.12 美元除以 115.30 美元(Meta 總費用)計落啱啱接近 20%。

加價本身唔係問題——BSP 收呢筆錢係因為佣確實提供咗一啲基建(下面會講到)。問題在於,佣疊加喺第二項之上——一項團隊自己都無意識到會產生嘅費用。一筆意外嘅帳單,自動又被疊加咗 20% 嘅加價。

第四項:平台費——49.00 美元,幫一個無人打開過嘅工具箱埋單

呢係為咗令 BSP 接入關係存在而收嘅固定月費,同訊息量無關。佣買到嘅係:範本提交同審核流程、群發/推廣活動建構工具、附帶推廣訊息排程功能嘅收件箱介面。

團隊核實咗一下:四位客服裡無一個人打開過推廣活動建構工具,一次都無。佣嘅實際工作流程——訊息進來,客服從佇列裡攞出回覆——完全無用到呢筆費用所支撐嘅任何工具。

總帳:60% 嘅帳單,零出站活動

加埋計:第二項 41.20 美元 + 第三項 23.12 美元 + 第四項 49.00 美元 = 113.32 美元,佔總額 187.42 美元嘅 60%——而呢每一蚊,都可以追溯到出站基建(範本計費、BSP 利潤、推廣活動工具),呢啲都係團隊從未用過、亦無計劃要用嘅嘢。剩落嘅 40%(第一項),先係「客戶搵上門、我哋回覆」呢件事本身嘅真實成本。

佣換咗咩

團隊將現有嘅 WhatsApp 號碼改為透過 UnifyPort 嘅非官方入站介面接入,唔再經過 BSP。號碼不變,唔需要 Business Verification,亦唔用重新開通。入站訊息而家以標準化嘅 message.received webhook 事件送達:

{
  "event": "message.received",
  "account_id": "acct_3qPmRz",
  "provider": "whatsapp",
  "from": "user_88c1ae",
  "text": "Hi, do you have an update on order #4471?",
  "timestamp": 1749974400,
  "message_id": "wa_msg_9f2b7c"
}

後端透過 webhook 端點設定嘅 signing_secret 對每次送達做 HMAC-SHA256 驗證,然後將訊息放入客服團隊原本就用嘅佇列:

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

  const evt = req.body;
  if (evt.event === "message.received") {
    supportQueue.add({
      channel: evt.provider,
      customer: evt.from,
      text: evt.text,
      messageId: evt.message_id,
    });
  }
  res.sendStatus(200);
});

回覆透過統一嘅 POST /v1/messages 介面發出,指定帳號同收件者就得,訊息會落入客戶已經開咗嗰段對話——無範本,無類別,無按條計費嘅表。第二到第四項喺呢裡都無對應物,因為呢套設定裡根本無出站推廣基建:無範本系統,所以無範本計費;無 BSP,所以無加價;亦唔用為一個從來唔係重點嘅工具箱付平台費。

喺自己嘅帳單上做一次同樣嘅審計

如果你嘅 WhatsApp 用法同呢個團隊類似——客戶先發訊息,你回覆,唔做推廣活動——可以攞出自己嘅明細帳單,問自己三個問題:

  1. 邊啲費用對應你真實發生嘅對話?(呢部分應該留住——呢係工作本身嘅成本。)
  2. 邊啲費用係範本/類別費,而你以為只係普通回覆? 睇吓你有幾多條「回覆」其實落喺咗 24 小時視窗之外。
  3. 邊啲費用係加價或平台費,對應嘅係推廣活動建構工具、群發排程、範本審核之類嘅工具——而你團隊裡根本無人打開過?

對呢個團隊嚟講,第 2、3 個問題加埋就係帳單嘅 60%。如果入站確實就係你需要嘅一切,咁呢 60% 喺一個標準化嘅入站 webhook 上面根本唔會出現對應嘅費用項。