Запуск за три дня: приём входящих WhatsApp-сообщений без очереди на верификацию — UnifyPort
В начале 2026 года небольшая операционная команда, управляющая интернет-магазином электроники в Юго-Восточной Азии, упёрлась в знакомый тупик. Объём обращений в поддержку через WhatsApp вырос до уровня, с которым ручная обработка входящих уже не справлялась. Нужно было, чтобы бэкенд-система сама принимала и маршрутизировала входящие сообщения. Схема выглядела просто: подключиться к WhatsApp Business API, принимать входящие webhook-события, передавать их в логику маршрутизации поддержки.
Business Verification подали в конце января. Очередь на проверку растянулась до марта.
Проблема была не в объёме запросов — а в ожидании
Пока команда ждала, входящие в поддержку продолжали накапливаться вручную. Покупатели писали в WhatsApp — статусы доставки, изменения заказов, наличие товара — потому что этот канал был для них привычным. Сообщения поступали. Желание отвечать у людей было. Узким местом была архитектура: каждое сообщение приходилось читать и обрабатывать вручную, потому что автоматизация не могла заработать до получения доступа к API.
Двое специалистов поддержки тратили примерно по четыре часа в день суммарно на сортировку WhatsApp-сообщений — запросы о статусе заказа, на которые бэкенд мог ответить за секунды, FAQ-ответы, не требующие суждения, маршрутизация эскалаций, реализуемая несколькими правилами. Ожидание было не только неудобным — у него была реальная стоимость, которая накапливалась каждую неделю.
Смена направления
В середине февраля, после трёх недель без ответа по верификации, команда пересмотрела подход. Реальная потребность была не в официальном API. Она была в том, чтобы получать входящие сообщения как структурированные события, с которыми система маршрутизации могла работать. Официальный API — один из путей к этому, но не единственный.
Команда подключила существующий WhatsApp-аккаунт — обычный номер, который использовался для поддержки, — к UnifyPort. Настройка заняла половину дня. Никаких документов, никакого окна ожидания, никакой очереди.
С этого момента каждое входящее сообщение от покупателя приходило в бэкенд как событие message.received с единой структурой: текст сообщения, ссылка на отправителя, ID ветки диалога, временная метка. Логика маршрутизации, простаивавшая в ожидании доступа к API, наконец получила данные для обработки.
Первые три дня
День 1. Аккаунт подключён, webhook-эндпоинт настроен, первые тестовые сообщения получены и залогированы. Команда убедилась, что структура event-payload соответствует ожидаемой схеме бэкенда, и проверила корректность валидации подписей HMAC-SHA256.
День 2. Задеплоены правила маршрутизации. Сообщение содержит номер заказа → автоматический запрос статуса и ответ. Первое сообщение от нового отправителя → создание записи в CRM и добавление в очередь отдела продаж. Всё остальное → флаг для ручной обработки с предзаполненным контекстом сообщения.
День 3. Запуск на реальном трафике. Двое специалистов, тративших полсмены на сортировку WhatsApp-сообщений, переключились на работу с эскалациями — теми диалогами, которые действительно требуют человеческого суждения.
К концу третьего дня система автоматически обрабатывала около 70% входящего потока. Оставшиеся 30% доходили до специалистов в виде предварительно классифицированных тикетов, а не сырых сообщений.
Цифры по итогам месяца
За первые тридцать дней работы:
- Время первого ответа снизилось с 2,4 часа в среднем (при ручной сортировке) до менее 90 секунд для автоматических ответов и менее 8 минут для эскалированных случаев
- Время специалистов в WhatsApp сократилось с суммарных ~4 часов в день до менее 45 минут, полностью сосредоточенных на случаях, требующих суждения
- Запросы о статусе заказа (самая крупная категория сообщений): 94% случаев решаются от начала до конца без участия человека
Business Verification в итоге прошла в конце марта. К тому моменту команда уже шесть недель работала с автоматизированным приёмом входящих. Мигрировать с работающего решения они не стали.
Чего не потребовалось
Никаких документов компании для сторонней платформы. Никакого создания и согласования библиотеки шаблонов. Никакого отслеживания многоуровневых тарифов за сообщение по категориям и странам получателей. Аккаунт, обрабатывавший входящие, — тот самый, который команда использовала для ручной поддержки: обычный номер, уже сохранённый в контактах покупателей.
Логика маршрутизации, которую выстроила команда, с самого начала не зависела от канала. Когда позже для части покупателей добавили Telegram, те же правила маршрутизации заработали без изменений. Структура события message.received была идентичной. Верификация HMAC-подписи — тоже. Единственным отличием в payload оказалось поле с платформой отправителя.
Этот паттерн
Случившееся не уникально для этой команды. Одна и та же цепочка повторяется в операциях поддержки у мерчантов: нужна автоматизация входящих → предполагается официальный API → требования к верификации и допуску превращают задачу разработки в задачу закупок → проходят недели, а ничего не построено.
Путь с обратным входящим интерфейсом — подключить существующий аккаунт, получать нормализованные события, подключить имеющуюся логику маршрутизации — сжимает эту цепочку. Задача разработки остаётся задачей разработки. UnifyPort и есть это соединение: входящие события из WhatsApp, Telegram, LINE, TikTok, Zalo и X нормализуются в единую схему и доставляются на ваш webhook-эндпоинт с HMAC-подписью — без очереди на верификацию.
Три дня — не исключительный результат. Именно так выглядит сроки, когда не нужно ждать чужого процесса согласования.