← Все статьи
Кейс

Мы построчно разобрали счёт за WhatsApp — 60% оказалось платой за инфраструктуру, которой мы не пользовались — UnifyPort

$187.42 — таким был общий счёт команды поддержки из четырёх человек за WhatsApp за месяц, против $134 месяцем ранее, при том что объём сообщений и численность команды не изменились. Финансовый отдел спросил не “не слишком ли это дорого”, а “за что конкретно это начислено?”. Команда выгрузила детальную разбивку из панели BSP (Business Solution Provider — провайдера бизнес-решений для WhatsApp) и прошлась по ней построчно.

Итоговая сумма складывалась из четырёх позиций:

СтатьяСумма
Оплата диалогов (Meta)$74.10
Оплата шаблонных сообщений (переклассифицированных)$41.20
Наценка BSP$23.12
Платформенный сбор$49.00
Итого$187.42

Дальше — сам этот разбор: за что на самом деле отвечает каждая строка и возникает ли она в реальной работе команды (клиент пишет — команда отвечает).

Строка 1: оплата диалогов — $74.10, единственная строка, которая отражает реальное использование

Это плата Meta за диалоги, которые команда действительно ведёт: клиент пишет первым, команда отвечает в рамках открытого окна диалога. Это самая дешёвая и простая категория тарификации WhatsApp, и она прямо отражает то, чем команда занимается весь день. Здесь всё в порядке — это и есть стоимость самой работы.

Строка 2: оплата шаблонных сообщений — $41.20, за сообщения, которые никто не считал “шаблонами”

Эту строку пришлось разбирать отдельно. Часть ответов команды не были простыми репликами внутри окна диалога — это были последующие сообщения: обновление статуса заказа, отправленное на следующее утро, проверка “решился ли вопрос?” через день. Как только ответ выходит за пределы 24-часового окна диалога, WhatsApp больше не считает его ответом — он становится шаблонным сообщением, тарифицируемым отдельно по категории и стране получателя, точно так же, как маркетинговая рассылка.

Никто в команде не подавал и не согласовывал шаблоны — все считали эти сообщения просто “немного запоздавшим ответом”. Но с точки зрения тарификации сообщение с задержкой 18 часов и маркетинговая рассылка проходят через один и тот же счётчик.

Строка 3: наценка BSP — $23.12, процент от платежей, которых не должно было быть

Сверху на всё, что начисляет Meta — и на легитимную плату за диалоги, и на случайно возникшую плату за шаблоны — BSP добавляет собственную маржу. В индустрии это обычно 15–20%. $23.12 от $115.30 платежей Meta — это почти ровно 20%.

Сама наценка не проблема — BSP берёт её за реальную инфраструктуру (об этом ниже). Проблема в том, что она накладывается на строку 2 — платёж, о возникновении которого команда даже не знала. К неожиданному счёту автоматически добавилась ещё и 20%-ная надбавка.

Строка 4: платформенный сбор — $49.00, за набор инструментов, который никто не открывает

Это фиксированная ежемесячная плата за само существование подключения к BSP, независимо от объёма сообщений. За эти деньги предоставляются: процесс подачи и согласования шаблонов, конструктор массовых рассылок и кампаний, интерфейс почтового ящика с планировщиком маркетинговых сообщений.

Команда проверила: ни один из четырёх агентов ни разу не открывал конструктор кампаний. Их реальный рабочий процесс — сообщения приходят, агенты отвечают из очереди — вообще не касается ни одного из инструментов, за которые платится этот сбор.

Итог: 60% счёта — при нулевой исходящей активности

Сложим: строка 2 ($41.20) + строка 3 ($23.12) + строка 4 ($49.00) = $113.32, или 60% от общей суммы $187.42 — и каждый доллар из этой суммы восходит к исходящей инфраструктуре (тарификация шаблонов, маржа BSP, инструменты кампаний), которой эта команда никогда не пользовалась и не планирует пользоваться. Оставшиеся 40% (строка 1) — это реальная стоимость того, что “клиент пишет нам, мы отвечаем”.

На что они перешли

Команда подключила свой существующий номер WhatsApp через неофициальный интерфейс входящих сообщений UnifyPort вместо BSP. Тот же номер, без Business Verification и без повторного онбординга. Входящие сообщения теперь приходят в виде нормализованного webhook-события message.received:

{
  "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"
}

Бэкенд проверяет каждую доставку с помощью HMAC-SHA256 по signing_secret, заданному в настройках webhook-эндпоинта, и кладёт сообщение в ту же очередь, с которой и так работали агенты:

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 с указанием аккаунта и получателя — и попадают прямо в диалог, который открыл клиент: без шаблонов, без категорий, без поминутного счётчика. У строк 2–4 здесь просто нет аналога, потому что в этой конфигурации нет ничего похожего на исходящую инфраструктуру для кампаний: нет системы шаблонов — значит, нет тарификации шаблонов; нет BSP — значит, нет наценки; и нет платформенного сбора за набор инструментов, который изначально не был нужен.

Проведите такой же разбор своего счёта

Если ваше использование WhatsApp похоже на это — клиенты пишут первыми, вы отвечаете, кампаний нет — возьмите свой детальный счёт и задайте три вопроса:

  1. Какие строки отражают диалоги, которые вы действительно ведёте? (Это нужно оставить — это реальная стоимость работы.)
  2. Какие строки — это плата за шаблоны/категории для сообщений, которые вы считали просто ответами? Проверьте, сколько ваших “ответов” выходит за пределы 24-часового окна.
  3. Какие строки — это наценка или платформенный сбор за инструменты — конструкторы кампаний, планировщики рассылок, согласование шаблонов — которые никто в команде не открывал?

Для этой команды вопросы 2 и 3 в сумме составили 60% счёта. Если вам действительно нужен только приём входящих сообщений, то для этих 60% в нормализованном входящем webhook просто нет соответствующей строки.