Как мы развели OTP и сервисные SMS по разным маршрутам внутри одного шлюза

Проблема. У клиента два потока SMS. Один — сервисные уведомления: эвакуатор в пути, техпомощь подъедет через 15 минут, истекает Карта помощи. Второй — OTP-коды для входа на сайт. Когда оба идут через одни маршруты, критичный OTP может застрять в очереди за массовой рассылкой статусов. Для пользователя на обочине это ожидание без информации, на сайте — невозможность авторизоваться.

Что мы сделали.

— Сначала аудит. Из каких систем уходят сообщения, какая фактическая доставляемость, средняя скорость. Без замеров нечего оптимизировать.

— Зарегистрировали альфа-имена. Согласовали с операторами связи два узнаваемых имени отправителя — отдельно для сервисных и отдельно для OTP. Клиент видит знакомое имя бренда, а не случайный короткий номер.

— Подключили шлюз через API. К операционной системе обработки заявок и к CRM. Сообщения формируются в источниках и уходят через единую точку.

— Развели потоки маршрутизацией. OTP — по приоритетным маршрутам, минимальная задержка. Сервисные — по оптимальным, с контролем доставляемости. Один поток не блокирует другой.

— Поставили мониторинг 24/7. Дашборд с разбивкой по потокам, оповещения о сбоях, регулярная отчётность.

Что получилось. Доставляемость сервисных уведомлений ≥98%. OTP доставляется в среднем менее чем за 10 секунд. Два потока — один шлюз — одна статистика — одна поддержка.

Что вынести. Если у вас в одном канале живут разнотипные сообщения с разными требованиями к скорости, не нанимайте двух подрядчиков. Просите CPaaS-провайдера развести потоки маршрутизацией внутри одного шлюза. Это и дешевле, и управляемее.