← 所有文章
案例分析

我们逐行审计了 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 上根本不会出现对应的费用项。