Если push-уведомление не дошло до клиента, резервное SMS помогает передать важный статус заказа, записи, оплаты или заявки другим каналом. В статье разберём рабочую схему фолбэка для малого бизнеса: какие события отслеживать, когда отправлять SMS, как избежать дублей и что проверить до запуска. В результате можно собрать понятный сценарий между сайтом или CRM, push-сервисом и платформой транзакционных SMS.
Когда push нужно дублировать SMS?
Push подходит для приложения, в котором клиент уже авторизован и разрешил уведомления. Сообщение появляется быстро, может содержать кнопку и вести пользователя на нужный экран. Но доставка зависит от подключения к интернету, настроек телефона, разрешения на уведомления и состояния самого приложения.
SMS стоит использовать как резервный канал для событий, где задержка создаёт практическую проблему. Например, клиент ждёт код подтверждения, готовность заказа, изменение времени доставки или уведомление о сбое оплаты. Если сообщение касается рекламной акции, схема будет другой. Здесь речь идёт о сервисных и транзакционных уведомлениях, которые связаны с конкретным действием клиента.
Для каждого события заранее задайте приоритет. Код подтверждения и уведомление о критическом изменении заказа требуют более строгого контроля. Напоминание о записи тоже может дублироваться, если клиент не открыл push в установленный срок. Для второстепенных статусов резервная отправка иногда только увеличит число сообщений и запутает получателя.
| Событие | Основной канал | Когда подключать SMS |
|---|---|---|
| Код подтверждения | Push | Если push не подтверждён за короткий заданный интервал |
| Изменение статуса заказа | Push | Если доставка не подтверждена или клиент не открыл сообщение |
| Перенос записи | Push | Если клиент не получил уведомление до установленного времени |
| Сбой оплаты | Push | Если клиенту нужно повторить действие или связаться с бизнесом |
Для контроля доставки сервисных сообщений полезно заранее определить, какие статусы считаются успехом. Сам факт передачи сообщения поставщику ещё не означает, что клиент его получил. В разборе этой темы помогает материал как контролировать доставку сервисных SMS.
Как работает схема SMS-фолбэка?
Сценарий начинается с события в вашей системе. Клиент оформил заказ, запросил код, записался на услугу или получил новое время доставки. Сайт, CRM или внутреннее приложение передаёт событие в модуль уведомлений. Модуль отправляет push и сохраняет идентификатор попытки, время отправки и канал.
Дальше система ждёт результат. Вариантов несколько: push доставлен, push открыт, push не доставлен, статус неизвестен. Для фолбэка нужен именно понятный критерий перехода к SMS. Если отправлять SMS при любом неизвестном статусе, часть клиентов получит два одинаковых уведомления.
- Создайте событие с уникальным идентификатором, например номером заказа или операции.
- Отправьте push и сохраните время попытки.
- Получите статус доставки или открытия, если push-платформа его передаёт.
- Проверьте, не отправлялось ли SMS по этому событию раньше.
- При выполнении условия отправьте короткое SMS через API.
- Запишите результат SMS в журнал уведомлений.
Уведомление лучше строить вокруг действия. В нём должны быть название события, понятный статус и следующий шаг. Для заказа это может быть информация о готовности и способе получения. Для оплаты, причина сбоя и инструкция по повторной попытке. Для записи, новая дата и способ подтвердить её.
Ссылка в SMS должна вести на страницу, где клиент сразу видит нужную информацию. Длинный адрес увеличивает размер сообщения и сложнее читается. Если бизнес использует сокращённые ссылки, перед запуском проверьте, как система считает переходы и не меняет ли ссылка назначение после создания сообщения.
Какие данные передавать между push-сервисом и SMS API?
Для простой интеграции достаточно передать номер клиента, тип события, текст или шаблон сообщения и уникальный ключ операции. В CRM обычно добавляют поле канала и статус последней попытки. Отдельно полезно хранить время отправки push, результат доставки и причину перехода к SMS.
| Поле | Зачем оно нужно |
|---|---|
| Идентификатор события | Защищает от повторной отправки одного уведомления |
| Номер телефона | Определяет получателя резервного SMS |
| Тип уведомления | Позволяет выбрать нужный шаблон и правило фолбэка |
| Время push | Помогает рассчитать интервал ожидания |
| Статус push | Показывает, нужно ли переходить к SMS |
| Статус SMS | Позволяет проверить результат резервной отправки |
Связь между системами обычно строят через API или вебхук. Например, CRM передаёт событие в сервис уведомлений, а сервис возвращает результат отправки. Вебхук удобен, когда нужно автоматически сообщить сайту или CRM о новом статусе, а не проверять его вручную через равные промежутки времени. Практический разбор такой связки есть в материале как настроить вебхуки для SMS между магазином, CRM и доставкой.
Если в компании нет отдельного разработчика, начните с одного сценария. Хороший кандидат, заказ или запись, где клиенту важно получить информацию в конкретный момент. После теста станет понятно, какие поля отсутствуют и какие статусы действительно возвращают подключённые системы.
Как выбрать задержку перед резервной SMS?
Универсального интервала для всех уведомлений нет. Он зависит от цены ошибки и срока актуальности сообщения. Для кода подтверждения ожидание должно быть коротким, иначе пользователь успеет закрыть форму. Для изменения доставки допустим больший интервал, если клиенту важно получить итоговое время.
Определите три значения: срок ожидания push, момент отправки SMS и максимальное число попыток. Обычно для одного события достаточно одной резервной SMS. Повторная отправка нужна только при конкретном техническом условии, например временной ошибке API. Если причина связана с неверным номером, повтор не поможет.
Текст сообщения должен отличаться от push хотя бы по форме, но сохранять тот же смысл. Иначе клиент не поймёт, какое уведомление актуально. В системе задайте приоритет последнего статуса: если после отправки SMS заказ снова изменился, новый статус должен получить отдельный идентификатор.
Перед запуском полезно проверить задержки и повторные попытки на тестовых номерах. Отдельно проверьте сценарий, в котором push приходит с опозданием уже после SMS. В таком случае приложение должно показать актуальный статус, а не вернуть клиента к старой операции.
Какие ошибки чаще всего ломают SMS-фолбэк?
- Переход к SMS по таймеру без проверки статуса. Push может прийти через несколько секунд, а клиент получит два сообщения. Используйте статус доставки или открытия, когда платформа его предоставляет.
- Отсутствие уникального ключа события. При повторном запросе API система не понимает, что уведомление уже отправлялось. Добавьте идентификатор операции и проверку перед каждой попыткой.
- Повторная отправка после любой ошибки. Ошибка авторизации, неверный номер и временная недоступность сервиса требуют разных действий. Разделите ошибки на повторяемые и окончательные.
- Одинаковые тексты для разных статусов. Клиент видит «заказ обновлён», но не понимает, что именно изменилось. Передавайте в шаблон конкретное действие и следующий шаг.
- Отсутствие журнала. Без истории сложно установить, какой канал сработал и почему ушло SMS. Сохраняйте время, событие, канал и финальный статус.
- Тестирование только успешного сценария. Проверьте отключённые push, отсутствие интернета, позднюю доставку и повторный запрос пользователя.
Если уведомления уже отправляются из сайта или CRM, фолбэк можно добавить как отдельное правило поверх существующего процесса. Для этого не нужно смешивать сервисные сообщения с рекламными рассылками: достаточно выделить события, настроить статусы и подключить API транзакционных SMS. Так команда видит, почему сработал резервный канал, а клиент получает актуальную информацию без ручного звонка менеджера.
3 шага, которые можно сделать на этой неделе:
- Выберите одно событие, где потеря уведомления создаёт проблему, и опишите ожидаемый результат для клиента.
- Зафиксируйте поля события, статусы push и правило перехода к SMS, включая защиту от дублей.
- Проведите тест на нескольких сценариях и подключите журнал доставки, чтобы видеть результат каждой попытки.
