Резервный SMS-шлюз помогает сохранить отправку важных сообщений, когда основной сервис недоступен: например, клиент ждёт код входа или подтверждение заказа. Для бизнеса в Беларуси такой резерв стоит продумать вместе со сценариями CRM, чтобы система знала, какое сообщение отправить повторно, когда переключить маршрут и как показать сотруднику результат. Ниже — схема работы, вопросы к провайдеру и порядок проверки, который поможет подготовить резерв до первого сбоя.
Опубликовано: 11 ноября 2026 года.
Каким сообщениям в CRM нужен резервный маршрут?
Начните со списка сообщений, из-за задержки которых останавливается действие клиента или сотрудника. Код входа нужен, пока человек пытается авторизоваться. Подтверждение заказа помогает покупателю понять, что заказ принят. Сообщение об оплате важно, если сотрудник ждёт реакции клиента и ведёт сделку дальше. Для каждого сценария запишите, что произойдёт, если SMS не уйдёт: клиент повторит запрос, менеджер позвонит ему или заказ останется в ожидании.
В CRM полезно разделить сообщения по назначению. Напоминание о визите обычно допускает ручную проверку сотрудником, а код входа теряет смысл, если приходит после окончания срока его действия. Поэтому у каждого сценария должны быть свои правила ожидания и повторной отправки. О том, как сообщения связать с действиями сотрудников, подробнее рассказано в материале о работе RocketSMS и CRM.
Запишите также, где рождается сообщение. CRM может сама отправлять уведомление после смены статуса заказа, а код входа часто создаёт отдельный сервис. Резерв нужно предусмотреть именно там, где система выбирает шлюз: иначе в CRM будет виден заказ, но она не сможет переключить отправку кода.
Как система решает, когда переключиться на резерв?
Обычная схема выглядит так: приложение передаёт SMS основному шлюзу и ждёт ответа. Если шлюз не принимает запрос из-за ошибки соединения или сообщает об ошибке при приёме, приложение пробует резервный маршрут. Решение принимает ваша система. Сам по себе второй аккаунт у SMS-провайдера отправку не переключит.
Сложнее случай, когда ответ не пришёл вовремя. Основной шлюз мог принять сообщение, а соединение оборвалось уже после этого. Если сразу отправить ту же SMS через резерв, клиент получит два сообщения. Для кода входа это особенно неприятно: человек увидит два кода и не поймёт, какой вводить. Сначала выясните, позволяет ли основной провайдер проверить судьбу запроса по вашему идентификатору или другому признаку, который он возвращает.
| Ситуация | Что делает система | Что проверить заранее |
|---|---|---|
| Основной шлюз явно отклонил запрос | Пробует отправку через резерв, если ошибка допускает повтор | Какие ответы означают технический сбой, а какие — ошибку в номере или тексте |
| Ответ от шлюза не получен | Уточняет статус запроса, если это возможно; при неизвестном статусе действует по правилу конкретного сценария | Как избежать двух SMS при повторе |
| Шлюз принял сообщение | Сохраняет результат приёма и следит за дальнейшим статусом, если провайдер его передаёт | Чем подтверждение приёма отличается от подтверждения доставки |
Храните у себя идентификатор каждой попытки, выбранный маршрут и ответ шлюза. Для сотрудника в CRM понятнее запись «основной шлюз не ответил, сообщение передано резервному», чем общий статус «отправлено». Последний не объясняет, дошла ли SMS до телефона.
Что подготовить перед подключением второго шлюза?
Проверьте условия резервного сервиса до разработки. Нужны доступ к API, возможность отправлять сообщения в нужные направления и ясный порядок получения статусов. Уточните, можно ли использовать нужное имя отправителя и сколько времени займёт его подготовка. Наличие API ещё не означает, что весь ваш текущий сценарий заработает через него без изменений.
Затем сопоставьте поля запросов двух провайдеров: номер, текст, имя отправителя и идентификатор сообщения. Если ответы устроены по-разному, добавьте в своей системе единые внутренние статусы. Тогда CRM покажет сотруднику одинаковую картину независимо от маршрута, а технические подробности останутся в журнале отправки.
Заранее решите, кто отвечает за сбой. Ответственный сотрудник должен знать, где посмотреть ошибку, как временно остановить повторные попытки и когда вернуть основной маршрут. Если технической команды внутри компании нет, такую логику разумно включить в задачу на настройку сценариев уведомлений в CRM вместе с проверкой статусов и действий менеджера.
Пример схемы подключения резервного провайдера и вопросы перед запуском собраны в статье на rocketsms.by. Используйте её как ориентир для обсуждения своей интеграции: точные условия отправки и доступность нужных направлений уточняйте до теста.
Как проверить резерв, не дожидаясь аварии?
Проверка начинается с одного тестового сообщения на номер, к которому у вас есть доступ. Убедитесь, что система записала попытку, ответ шлюза и итоговый статус, если он доступен. После этого в тестовой среде отключите основной маршрут или задайте для него ошибку. Сообщение должно пройти через резерв, а в журнале должен остаться понятный след переключения.
Следующий тест — неопределённый результат. Смоделируйте ситуацию, когда основной шлюз не ответил, хотя запрос уже мог принять. Проверьте, запускает ли система повтор и сможет ли сотрудник понять, почему клиент сообщил о двух SMS. Если статус первого запроса выяснить нельзя, правило для такого случая придётся выбрать заранее: риск задержки и риск дублирования зависят от назначения сообщения.
Отдельно проверьте возвращение к обычной работе. После восстановления основного шлюза новые сообщения должны идти по выбранному вами правилу, а старые попытки не должны внезапно отправляться ещё раз. Для кода входа проверьте и срок его действия: резервный маршрут не принесёт пользы, если приложение отправит уже недействительный код.
Какие ошибки чаще всего мешают резервной отправке?
Типичные ошибки появляются на стыке CRM, приложения и двух шлюзов. Их проще заметить в тесте, чем разбирать по словам клиента, который не получил сообщение.
- Резервный аккаунт создали, но переключение нигде не настроили. Проверьте, какое приложение выбирает маршрут и по какому событию.
- Любую задержку считают отказом основного шлюза. Добавьте проверку статуса там, где провайдер её поддерживает, и отдельное правило для неизвестного результата.
- CRM показывает «доставлено» сразу после приёма запроса шлюзом. Разделите приём сообщения провайдером и подтверждение доставки, если оно доступно.
- Проверили отправку вручную, но не проверили сбой в рабочем сценарии. Пройдите путь от события в CRM до записи результата у сотрудника.
- Не определили, кто следит за переключением. Назначьте человека, который увидит ошибку и проверит возврат на основной маршрут.
Резерв работает тогда, когда заранее проверены оба пути сообщения и понятен статус каждой попытки. Начните с одного действия: откройте список автоматических SMS в CRM и отметьте сообщение, задержка которого остановит работу клиента.
