Сервис СМС-рассылок: на что смотреть при выборе платформы

Основной риск находится ниже уровня интерфейса: в регистрации Sender ID, маршрутизации через операторов, статусах доставки, очистке базы и способе интеграции с CRM или внутренней системой.

Платформа может принять запрос на отправку, вернуть успешный HTTP-ответ и не доставить сообщение абоненту. Причины типовые: не зарегистрировано альфа-имя, номер неактивен, трафик классифицирован как рекламный, нарушен формат сообщения, исчерпан лимит канала или не обработан callback о финальном статусе. Считать факт принятия API-запроса доставкой запрещено.

Для бизнеса сервис СМС-рассылок — это не форма для ручной отправки. Это часть коммуникационного контура. Она должна юридически корректно отправлять сообщения, технически подтверждать каждый этап доставки и позволять управлять стоимостью трафика.

Юридическая чистота и регистрация Sender ID

Первый этап выбора — не API и не тарифная сетка. Проверьте, имеет ли оператор или агрегатор официальные договоры с мобильными операторами и может ли зарегистрировать имя отправителя.

Sender ID, или альфа-имя, — это текстовый идентификатор отправителя, который отображается у абонента вместо длинного номера. Для коммерческой рассылки используется бренд, название сервиса или другое согласованное имя. Регистрация проводится у операторов связи. Без нее отправка брендовых сообщений может быть ограничена, заблокирована или переведена в другой режим маршрутизации.

Срок регистрации обычно составляет от одной недели до месяца. В сети МТС процедура может занимать до 15 рабочих дней. В отдельных случаях предусмотрена абонентская плата за зарегистрированное имя — ориентиром для этой сети служит диапазон около 2000–2500 рублей в месяц. Универсальной цены для всех операторов нет: стоимость зависит от оператора, типа трафика и условий агрегатора.

Не закладывайте регистрацию Sender ID в день запуска кампании. Это отдельный операционный процесс. Потребуются:

• юридические данные владельца бренда;
• подтверждение права использовать название;
• описание характера трафика;
• перечень операторов и регионов отправки;
• согласование рекламного или транзакционного типа сообщений;
• подтверждение согласий абонентов на коммуникацию.

Разделяйте два вида трафика.

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

Не используйте один Sender ID для всего бизнеса, если в системе есть разные направления. Сервисные уведомления, маркетинговые кампании и сообщения от нескольких юридических лиц должны иметь раздельную модель отправки. Это упрощает аудит, анализ жалоб и блокировку конкретного потока при инциденте.

Регистрация Sender ID — не формальность перед запуском. Это зависимость проекта, которую нельзя закрыть настройкой в личном кабинете за несколько минут.

Что запросить у оператора платформы

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

1. С какими операторами связи заключены прямые или агентские договоры.

2. Кто регистрирует Sender ID и кто несет ответственность за продление.

3. Какие сроки установлены для новых имен.

4. Как разделяются рекламный и транзакционный трафик.

5. Какие причины отказа возвращаются по каждому оператору.

6. Как оформляется согласие абонента и в каком виде оно хранится.

7. Как обрабатываются жалобы и запросы на отписку.

8. Есть ли ограничения по регионам, объему и времени отправки.

Не принимайте формулировку «доставляем во все сети» как техническую гарантию. Она ничего не говорит о маршруте, статусах, фильтрации и фактическом проценте успешных доставок.

Технологический стек: API, SMPP и интеграция в бизнес-процессы

Платформа СМС-рассылок для бизнеса должна подключаться к существующим системам. Ручная загрузка CSV допустима для разовой кампании. Для регулярных уведомлений, авторизации и автоматических сценариев нужен API.

Минимальный набор интерфейсов:

• HTTP/HTTPS для простых запросов из CRM, сайта или серверного приложения;
• REST API с JSON для типовой интеграции;
• XML, если этого требует устаревшая корпоративная система;
• Webhooks для получения событий в реальном времени;
• SMPP для высоконагруженных систем и массовой отправки.

REST API удобен на старте. Через него передают номер, текст, Sender ID, внешний идентификатор сообщения и дополнительные параметры маршрутизации. В ответ система должна вернуть не только общий результат, но и идентификатор операции. По нему выполняется дальнейшее отслеживание.

Не стройте логику на одном поле success. Успешный ответ API означает, что запрос принят шлюзом и прошел первичную проверку. Это не означает, что SMS принято оператором и доставлено абоненту.

Разведите статусы минимум на следующие уровни:

• запрос сформирован внутренней системой;
• запрос принят API агрегатора;
• сообщение поставлено в очередь;
• сообщение передано оператору;
• доставка подтверждена;
• доставка не подтверждена;
• произошла временная ошибка;
• произошла постоянная ошибка;
• истек срок ожидания статуса.

Названия могут отличаться. Смысл должен сохраняться. У каждого статуса должен быть код и понятная причина. Если платформа возвращает только «отправлено» и «ошибка», она непригодна для полноценного контроля.

HTTP API против SMPP

Для большинства компаний начинать следует с REST API и Webhooks. SMPP нужен не потому, что он технически престижнее, а когда приложение действительно упирается в объем, задержки или требования к постоянному соединению.

Крупные SMS-шлюзы могут обеспечивать пропускную способность порядка 1500–6000 SMS в секунду. Этот показатель имеет смысл только вместе с параметрами очереди, лимитами конкретного Sender ID и реальной емкостью маршрута. Нельзя переносить пропускную способность шлюза на один проект без оговорок.

Что должно быть в API-документации

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

• аутентификация и управление API-ключами;
• IP allowlist или другие ограничения доступа;
• лимиты запросов;
• формат телефона в E.164;
• допустимые символы и кодировки;
• передача Sender ID;
• идентификатор сообщения клиента;
• синхронный ответ API;
• асинхронный callback;
• повторная доставка Webhook;
• защита от дублей;
• срок хранения статусов;
• коды ошибок;
• sandbox или тестовый контур;
• правила работы с балансом и лимитами.

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

Реализуйте очередь на стороне бизнеса. Не отправляйте SMS непосредственно из пользовательского HTTP-запроса, если задержка критична. Запись должна попасть во внутреннюю очередь, получить уникальный идентификатор, пройти проверку лимитов и только после этого уйти в SMS-шлюз.

Ограничьте права API-ключей. Разделите ключи для production, staging и ручных операций. Храните их в секрет-хранилище. Запретите передачу ключей в клиентский JavaScript, мобильное приложение и открытые репозитории.

Экономика коммуникаций: каскадные рассылки вместо отправки SMS всем

SMS — дорогой канал по сравнению с мессенджерами и социальными платформами. Поэтому платформа должна поддерживать каскадные рассылки.

Каскад — последовательность каналов, в которой сначала используется более дешевый способ коммуникации, а SMS остается резервным маршрутом. Типовой порядок может выглядеть так: VK, OK или Viber, затем SMS для пользователей, которых не удалось охватить предыдущими каналами.

Логика каскада должна опираться на событие и таймер, а не на субъективное решение оператора. Например:

1. Отправьте уведомление через первый канал.

2. Подождите заданный интервал.

3. Получите статус доставки или прочтения, если канал его поддерживает.

4. Отфильтруйте пользователей без подтвержденного результата.

5. Передайте оставшуюся аудиторию в следующий канал.

6. Для SMS примените отдельные лимиты и правила частоты.

7. Сохраните итоговый статус по всей цепочке.

При корректной настройке каскад способен снизить затраты на коммуникации в 2–5 раз. Экономия зависит от доли пользователей, доступных в дешевых каналах, стоимости каждого маршрута, правил повторной отправки и характера аудитории.

Не путайте каскад с массовым дублированием. Отправка одного предложения одновременно в Viber и SMS не является оптимизацией. Это два платных или ограниченных контакта с одним пользователем. Каскад должен прекращаться после подтвержденного результата.

Как считать стоимость каскада

Разбейте расходы на компоненты:

• регистрация и обслуживание Sender ID;
• стоимость сообщения по каждому оператору;
• плата за API или абонентский доступ;
• HLR-запросы;
• стоимость каналов VK, OK и Viber;
• повторные попытки;
• хранение и обработка статусов;
• комиссия за отдельные типы трафика;
• расходы на резервный маршрут.

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

Введите отдельные метрики:

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

Главная метрика — не объем отправки. Сервис, который отправляет много сообщений, но не различает неактивные номера и временные ошибки, просто ускоряет расход бюджета.

Считать нужно не SMS в отчете, а подтвержденный результат после всех маршрутов. Остальное — технический шум.

Баланс и лимиты

Проверьте, как платформа защищает аккаунт от ошибочной кампании. Нужны:

• дневные и часовые лимиты;
• отдельные лимиты на транзакционный и рекламный трафик;
• аварийная остановка;
• ограничение по списку номеров;
• подтверждение массовой отправки;
• журнал изменений;
• уведомления о резком росте объема;
• блокировка при превышении бюджета.

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

Гигиена базы: зачем нужны HLR-запросы и Ping-SMS

Сервис СМС-рассылок по своей базе не должен отправлять сообщения на каждый номер, который когда-либо попал в CRM. База устаревает. Абоненты меняют номера, SIM-карты отключаются, телефонные номера переоформляются, записи дублируются.

HLR-запрос позволяет проверить состояние номера до отправки сообщения. Он помогает выявить неактивные и несуществующие номера. В непроверенных базах средняя доля неактуальных номеров может составлять около 15%. Это не универсальный норматив для любой базы, а ориентир, показывающий масштаб потерь при отсутствии валидации.

Используйте HLR перед крупной кампанией. Для постоянных транзакционных потоков настройте периодическую проверку с учетом частоты изменений базы. Не выполняйте HLR без причины перед каждым уведомлением: это отдельная операция, которая также влияет на стоимость и нагрузку.

Ping-SMS решает другую задачу. Сервис отправляет технический запрос или короткое сообщение для проверки доступности маршрута и номера. Метод может использоваться там, где HLR недоступен или его данных недостаточно. Уточните у провайдера, как именно тарифицируется Ping-SMS и попадает ли такая операция в отчетность по отправке.

Порядок очистки базы

1. Нормализуйте номера в едином формате. Удалите пробелы, скобки, дефисы и неоднозначные локальные записи.

2. Уберите дубли по номеру и связанному идентификатору клиента.

3. Отделите номера с подтвержденным согласием от записей без доказуемого основания для рассылки.

4. Выполните HLR-проверку или другой доступный тип валидации.

5. Исключите неактивные и несуществующие номера.

6. Сохраните дату и результат проверки.

7. Не отправляйте маркетинговый трафик по номерам с истекшим или отсутствующим согласием.

8. Обновите статус контакта в CRM.

9. После кампании обработайте отписки, жалобы и постоянные ошибки.

10. Повторно проверьте базу перед следующим крупным запуском.

Сохраняйте результат проверки. Нельзя каждый раз считать базу новой и терять историю. Для каждого номера полезно иметь дату последнего HLR, статус, источник контакта, дату согласия, дату последней отправки и причину исключения.

Не используйте HLR как замену согласию. Активный номер не означает, что его владелец разрешил рекламную коммуникацию. Валидация отвечает на технический вопрос: существует ли и доступен ли номер. Основание для отправки — отдельный юридический и процессный контур.

Лимиты SMS: длина сообщения, кодировка и стоимость

Стандартное SMS в кириллице вмещает до 70 символов. При использовании латиницы лимит составляет до 160 символов. Ограничение связано с кодировкой. Русский текст обычно использует Unicode, поэтому доступный объем одного сегмента значительно меньше.

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

Проверьте в тестовом контуре:

• количество символов в сообщении;
• наличие кириллицы;
• кавычки и специальные знаки;
• переносы строк;
• emoji;
• URL;
• подстановочные переменные;
• итоговое число сегментов;
• отображение текста на устройствах разных операторов.

Один случайный символ Unicode может изменить кодировку всего сообщения. Это особенно часто происходит с типографскими кавычками, длинным тире, нестандартным пробелом или emoji. После изменения кодировки длина сообщения уменьшается, а стоимость отправки увеличивается.

Практический контроль текста

Не обрезайте текст простым substring по количеству видимых символов. Сначала определите кодировку и доступное число сегментов. Затем оставьте запас под переменные: имя клиента, номер заказа, код или ссылку.

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

Для OTP задайте небольшой срок действия кода. Ограничьте количество повторных запросов. Привяжите код к операции и пользователю. Не отправляйте новый код при каждом повторе клиентского запроса, если предыдущий еще действителен.

Для маркетинговых кампаний разделяйте текст и ссылку. Длинные UTM-параметры увеличивают число сегментов. Используйте короткий домен, но не скрывайте конечный адрес от систем безопасности и пользователя. Контролируйте репутацию домена, с которого ведется переход.

Типовые ошибки при выборе платформы

Ориентация только на цену SMS

Дешевое сообщение не равно дешевому контакту. Если платформа не валидирует базу, не возвращает финальные статусы и не умеет исключать повторную отправку, оплачиваются лишние операции.

Сравните стоимость доставленного сообщения и стоимость полного сценария. Включите в расчет API, HLR, повторные попытки, регистрацию Sender ID и резервные каналы.

Отсутствие Webhooks

Периодический опрос API допустим для небольшого объема. Для оперативных уведомлений он создает задержки и лишнюю нагрузку. Webhooks должны передавать изменения статуса во внутреннюю систему.

Проверьте подпись callback, повторную доставку, порядок событий и защиту от повторной обработки. Не доверяйте входящему Webhook без проверки источника.

Непрозрачные маршруты

Агрегатор может использовать несколько маршрутов с разной стоимостью и качеством. Если в отчете виден только общий статус, невозможно установить, где возникла проблема.

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

Одна база для всех типов сообщений

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

Разделите очереди, Sender ID, шаблоны и отчетность.

Игнорирование временных ошибок

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

Настройте таблицу обработки кодов:

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

Как провести техническое испытание до договора

Запросите тестовый доступ. Не ограничивайтесь отправкой одного сообщения на собственный номер. Тест должен пройти весь путь: создание задания, передача в API, получение статуса, обработка Webhook, запись в CRM и остановка повторной отправки.

Проверьте минимум следующие сценарии:

1. Валидный номер с кириллическим текстом.

2. Сообщение на границе одного сегмента.

3. Длинный текст с несколькими сегментами.

4. Номер с неверным форматом.

5. Номер, который не должен получать рекламу.

6. Повторная отправка с тем же внешним идентификатором.

7. Сетевой тайм-аут после передачи запроса.

8. Временная ошибка оператора.

9. Постоянная ошибка номера.

10. Недоступный Endpoint для Webhook.

11. Повторная доставка одного и того же callback.

12. Отмена кампании после постановки сообщений в очередь.

13. Отправка через резервный канал.

14. Превышение дневного лимита.

15. Отсутствие средств на балансе.

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

Проверьте скорость не на рекламной цифре, а на своем профиле нагрузки. Для OTP критична задержка одного сообщения. Для кампании важны очередь, темп отправки и время получения финальных статусов. Высокая пропускная способность шлюза не компенсирует медленный Webhook или ограничение Sender ID.

Консольный порядок проверки перед запуском

Перед промышленной отправкой выполните последовательность без пропусков:

• проверьте юридическое основание коммуникации и зафиксированное согласие;
• подтвердите регистрацию Sender ID для нужного типа трафика;
• проверьте доступность маршрутов операторов;
• нормализуйте и дедуплицируйте номера;
• выполните HLR или Ping-SMS для крупной базы;
• исключите неактивные и несуществующие номера;
• проверьте кодировку и число SMS-сегментов;
• протестируйте шаблоны с реальными переменными;
• ограничьте API-ключи и сохраните их вне исходного кода;
• настройте очередь и защиту от дублей;
• подключите Webhooks и проверку их подлинности;
• сопоставьте внешние идентификаторы с записями CRM;
• задайте лимиты по кампании, Sender ID и бюджету;
• включите аварийную остановку;
• определите обработку временных и постоянных ошибок;
• настройте каскад только после подтверждения статуса предыдущего канала;
• подготовьте отчет по доставке, стоимости и жалобам.

Сервис СМС-рассылок выбирается по управляемости контура. Регистрация Sender ID закрывает вопрос легитимности имени. API и Webhooks — вопрос интеграции и наблюдаемости. HLR — вопрос гигиены базы. Каскад — вопрос стоимости. Контроль кодировки — вопрос фактического числа оплаченных сегментов.

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