← 所有文章
案例分析

我們逐行審視了 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 上根本不會出現對應的費用項。