Как связать SMS Boom и Vakas-tools без ручной работы

Ручная выгрузка базы подходит для разовой кампании. В регулярном процессе она быстро становится источником задержек: менеджер должен заметить событие, подготовить файл, проверить номера и запустить сообщение. Интегратор снимает эту часть работы и отправляет данные между сервисами по заранее заданному правилу.

На стороне Vakas-tools есть готовая интеграция с SMS Boom. Она рассчитана, в частности, на события из форм регистрации, CRM, чат-ботов, вебинарных и учебных платформ. В этой статье разберём не рекламное обещание, а устройство рабочего сценария: что считать триггером, какие поля передавать и как контролировать результат.

Какие задачи решает связка SMS Boom и Vakas-tools

Интеграция полезна там, где сообщение должно зависеть от конкретного события, а не от ручного календаря рассылок.

• Регистрация. Отправить подтверждение заявки, время вебинара или ссылку на личный кабинет.
• Напоминание. Сообщить о занятии или встрече за заданное время до начала.
• Заказ и оплата. Подтвердить получение заказа, оплату или открытие доступа.
• Сегментация после события. Отправить разные сообщения тем, кто посетил вебинар, пропустил его или остановился на определённом этапе.
• Резервный канал. Использовать SMS для критичного уведомления, если основной сценарий в другом канале не сработал.

Из чего состоит сценарий

Любое правило удобно описывать четырьмя блоками. Если один из них сформулирован расплывчато, сценарий трудно тестировать и сопровождать.

1. Источник события

   Система, в которой произошло действие: форма на лендинге, CRM, вебинарная платформа, GetCourse или другой подключённый сервис.

2. Условие

   Точное правило запуска. Например: «регистрация подтверждена, телефон заполнен, согласие зафиксировано, SMS по этому событию ещё не отправлялось».

3. Действие

   Отправка сообщения через SMS Boom с выбранным именем отправителя, текстом и подстановкой переменных.

4. Результат

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

Такое описание полезно составить до настройки интерфейса. Оно сразу показывает, каких данных не хватает и где может появиться повторная отправка.

Три рабочих сценария

Напоминание о вебинаре

После регистрации контакт получает подтверждение. Затем отдельные правила отправляют напоминания, например за день и за час до начала. Время вебинара хранится как поле события, а отправка учитывает часовой пояс участника.

Не помещайте всю программу вебинара в SMS. Задача сообщения — напомнить о времени и дать одно понятное действие.

Подтверждение оплаты

Триггером служит подтверждённый платёж, а не создание заказа. В текст передаются номер заказа и ссылка на доступ. Если платёжная система повторно отправит одно и то же событие, правило не должно создавать второе SMS.

Сообщение после вебинара

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

Какие данные передавать между сервисами

Передавать «все поля на всякий случай» не нужно. Чем меньше данных участвует в правиле, тем проще понять его работу и ограничить доступ к персональной информации.

Как избежать дублей и потерянных сообщений

Заведите ключ отправки

Для каждого события сформируйте уникальную комбинацию, например contact_id + event_id + message_type. Перед запуском проверяйте, не была ли такая комбинация уже обработана. Это защищает от повторов при повторной передаче события.

Не смешивайте технический запуск и доставку

Статус «правило выполнено» означает, что интегратор передал запрос. Окончательный результат нужно оценивать по ответу сервиса и статусу сообщения. Для отчёта полезно хранить как минимум время, номер сценария, ID контакта, ID отправки и итоговый статус.

Ограничьте повторные попытки

Если внешний сервис временно недоступен, повтор оправдан. Если номер неверный или шаблон не прошёл проверку, бессмысленные повторы только создадут очередь. Разделяйте временные и постоянные ошибки, а после нескольких неудачных попыток переводите событие на ручную проверку.

Учитывайте отказ от рассылки

Стоп-лист должен проверяться непосредственно перед отправкой. Если клиент отказался от рекламы после того, как сценарий был поставлен в очередь, старое условие согласия уже нельзя считать достаточным.

Чек-лист проверки перед запуском

1. Создайте отдельный тестовый контакт с доступным номером телефона.
2. Проверьте сценарий с заполненными и пустыми переменными.
3. Повторно передайте одно и то же событие и убедитесь, что дубль не ушёл.
4. Проверьте дату и время на контактах из разных часовых поясов.
5. Смоделируйте неверный номер и временную ошибку сервиса.
6. Убедитесь, что идентификатор отправки сохраняется в журнале.
7. Добавьте контакт в стоп-лист до выполнения отложенного правила.
8. Запустите сценарий на небольшом внутреннем сегменте и только затем включайте его для рабочей базы.

Источники: официальная страница интеграции SMS Boom в Vakas-tools и инструкция Vakas-tools по сценариям SMS. Возможности и интерфейс внешнего сервиса могут меняться; перед настройкой сверяйтесь с его документацией.