SMS-цепочка через SMPP помогает автоматически вести клиента от заявки до следующего действия: отправить подтверждение, напомнить о предложении и передать менеджеру сигнал о реакции. В статье разберём, как выбрать этапы воронки, связать CRM или сайт с API, настроить очередь сообщений, проверить статусы доставки и избежать дублей. В результате у бизнеса появится понятная схема, которую можно сначала запустить для одного сценария, а затем расширить.
Из каких этапов состоит SMS-воронка?
Начните с события, которое уже фиксирует ваша система. Это может быть заявка с сайта, создание заказа, смена статуса сделки или отсутствие ответа менеджеру. Каждому событию назначают одно сообщение и понятное следующее действие. Например, после заявки клиент получает подтверждение, затем менеджер связывается с ним, а через заданный интервал система отправляет напоминание.
Для малого бизнеса лучше собрать короткую цепочку из двух-четырёх сообщений. Длинная серия требует большего числа условий и сложнее проверяется. Сначала опишите путь клиента на обычном листе:
- клиент оставил заявку;
- система отправила подтверждение;
- менеджер изменил статус сделки;
- клиент получил предложение или напоминание;
- сделка закрыта либо передана на повторный контакт.
У каждого сообщения должен быть собственный триггер. Если один и тот же статус обновляется несколько раз, система обязана проверить, отправлялось ли уведомление раньше. Для защиты от повторов используют уникальный идентификатор события и журнал отправок. Отдельные рекомендации по защите API и SMPP от дублей собраны в материале «Почему SMS отправляется дважды».
Как выбрать между API и SMPP?
API подходит для первого подключения: сайт или CRM отправляет запрос с номером, текстом и идентификатором сообщения. SMPP используют, когда важны постоянное соединение, очередь сообщений и контроль большого потока. Для микробизнеса разумно начать с API, если отправок немного и они возникают по отдельным событиям. SMPP имеет смысл подключать, когда система отправляет сообщения регулярно или должна обрабатывать всплески без ручного вмешательства.
| Задача | Подход | Что настроить |
|---|---|---|
| Подтвердить заявку или заказ | API | Запрос из сайта или CRM после создания события, проверка ответа шлюза |
| Отправлять сообщения из очереди | API с очередью или SMPP | Приоритеты, лимиты, повторные попытки, журнал статусов |
| Обрабатывать высокий или неравномерный поток | SMPP | Постоянную сессию, контроль соединения и распределение нагрузки |
| Разбирать сбои доставки | API и SMPP с отчётами | Получение delivery receipt, хранение кода статуса и времени ответа |
При подключении через SMPP приложение открывает сессию с шлюзом и передаёт сообщения командами протокола. Система получает подтверждение приёма, а позже может получить отчёт о доставке. Эти события нельзя смешивать: подтверждение приёма шлюзом ещё не означает, что SMS дошло до телефона.
Сетевые сбои требуют отдельной логики. Приложение должно распознавать разрыв сессии, выдерживать паузу перед повторным подключением и восстанавливать обмен без создания копий сообщений. Практические варианты поддержания SMPP-сессии при сбоях описаны в материале о работе SMPP-сессии при нестабильной сети.
Как спроектировать триггеры и текст сообщений?
Сначала запишите условие отправки, задержку и действие, после которого цепочка прекращается. Например: «после новой заявки отправить подтверждение сразу; если менеджер не сменил статус в течение рабочего интервала, отправить напоминание; после закрытия сделки остановить дальнейшие сообщения». Такая схема предотвращает ситуацию, когда клиент продолжает получать рекламный текст после покупки.
Текст SMS должен отвечать на три вопроса: кто пишет, что произошло и что сделать дальше. В подтверждении заявки достаточно назвать компанию или сервис, зафиксировать факт обращения и указать следующий шаг. В напоминании нужен конкретный повод: ответить менеджеру, открыть страницу заказа или выбрать время связи.
Длина влияет на число SMS-сегментов. Для GSM-7bit один сегмент обычно содержит до 160 знаков, а при использовании Unicode, например кириллицы, ориентир составляет до 70 знаков. Длинный текст разбивается на несколько частей и увеличивает объём отправки. Поэтому перед запуском проверьте кодировку, длину, ссылку и переменные. Отдельно о длине кириллических сообщений и стоимости сегментов рассказывает материал «Как не переплачивать за SMS с кириллицей и эмодзи».
| Событие | Пример задачи | Что передать в сообщение | Когда остановить цепочку |
|---|---|---|---|
| Новая заявка | Подтвердить обращение | Факт заявки и следующий шаг | После отправки подтверждения |
| Нет изменения статуса | Напомнить клиенту | Короткое напоминание и действие | После ответа или контакта менеджера |
| Сделка закрыта | Подтвердить результат | Информация о заказе или услуге | Сразу после отправки |
| Срок повторного обращения | Напомнить о следующем заказе | Причина сообщения и понятная ссылка | После нового заказа или отказа |
Как настроить очередь, статусы и повторные попытки?
Не отправляйте SMS прямо внутри обработчика заявки, если система должна выдерживать задержки шлюза. Сначала запишите сообщение в очередь. В записи очереди храните номер события, получателя, текст или шаблон, приоритет, время создания и число попыток. Отдельный обработчик забирает записи, отправляет их через API или SMPP и фиксирует ответ.
Разделите сообщения по приоритету. Подтверждение заказа или изменения по доставке обычно важнее маркетингового напоминания. При ограничении пропускной способности сначала отправляйте сервисные уведомления, затем кампании с низким приоритетом. Очередь также защищает систему от резкого всплеска, когда несколько событий возникают одновременно.
Повторная попытка нужна только для временной ошибки: разрыва соединения, тайм-аута или временной недоступности шлюза. Неверный номер, запрещённый формат или постоянная ошибка маршрута требуют статуса «не отправлять повторно». Иначе один сбой превратится в серию одинаковых запросов.
Для очередей с ограничением скорости задайте интервал между отправками и отдельный лимит для каждого направления. Полезная техническая схема с rate limit и приоритетами разобрана в материале о построении очереди SMS в API и SMPP.
Как проверить цепочку до запуска?
Тестируйте каждый триггер отдельно. Создайте тестовую заявку, убедитесь, что SMS попало в очередь, проверьте запрос к шлюзу и сопоставьте его с отчётом доставки. Затем измените статус сделки и проверьте, остановилась ли старая ветка. Повторно отправьте одно и то же событие: система должна распознать его идентификатор и не создать второе сообщение.
Проверка нужна для нескольких вариантов номера, текста и кодировки. Отдельно проверьте пустое имя клиента, длинный номер заказа, специальный символ и ссылку. Если переменная не подставилась, сообщение должно уйти по безопасному шаблону, а ошибка должна попасть в журнал.
В рабочем режиме смотрите на четыре показателя: число сообщений в очереди, долю успешной передачи шлюзу, статусы доставки и количество повторных попыток. Если доставка ухудшилась, сначала сравните время отправки, код ошибки и направление. Технические сбои, ошибки в содержании и фильтрация операторами относятся к разным классам причин, поэтому и проверяют их по-разному (Проблемы с доставкой SMS: диагностика и решения, IBZ Source).
Какие ошибки встречаются чаще всего?
- Цепочка запускается повторно при каждом обновлении одной и той же сделки.
- Приложение считает подтверждение шлюза доказательством доставки.
- Повторная попытка выполняется для постоянной ошибки номера или формата.
- Кириллический текст и эмодзи увеличивают число сегментов, но это не учтено в расчёте.
- В очередь попадают рекламные сообщения с более высоким приоритетом, чем подтверждения заказа.
- В журнале нет идентификатора события, поэтому невозможно найти источник дубля.
3 шага, которые можно сделать на этой неделе:
- Нарисовать одну цепочку: заявка, подтверждение, напоминание, завершение.
- Связать каждый этап с уникальным событием и настроить очередь через API или SMPP.
- Провести тестовые отправки, проверить статусы, повторы и длину SMS до запуска для клиентов.
