Коды ответов SMPP помогают понять, что произошло с SMS после отправки: шлюз не принял запрос, оператор отклонил сообщение, номер больше не обслуживается или система упёрлась в лимит скорости. Для малого бизнеса это рабочий способ отделить разовую техническую ошибку от контакта, который пора убрать из рассылок. В статье разберём, какие статусы собирать, как не удалить хороший номер по одному сбою и какие правила автоматической очистки базы задать в API-интеграции.
Какие статусы SMPP нужны для разбора недоставленных SMS?
Смотрите на два уровня ответов. Первый приходит сразу после передачи сообщения в SMPP-шлюз: он показывает, приняла ли платформа запрос. Второй уровень — статус доставки, который приходит позднее отдельным уведомлением. Именно он помогает понять судьбу конкретного SMS у оператора.
Ошибка при отправке запроса ещё не означает, что номер плохой. Например, шлюз мог временно не отвечать, соединение могло оборваться, а приложение могло отправить неверный параметр. В такой ситуации повторная отправка уместна, но её нужно ставить в очередь и контролировать, чтобы клиент не получил одно и то же сообщение дважды. Для таких сценариев пригодится материал о том, как избежать дублей SMS при сбоях API и SMPP.
Статус доставки полезнее разделить на несколько групп:
- сообщение доставлено — контакт остаётся в рабочей базе;
- сообщение принято, но итог доставки ещё неизвестен — системе нужно подождать следующий статус;
- ошибка связана с номером или маршрутом — контакт стоит пометить для проверки;
- ошибка связана с текстом, подписью отправителя или параметрами сообщения — меняют настройки кампании, а номер не удаляют;
- временная ошибка сети или шлюза — сообщение возвращают в очередь с ограниченным числом повторов.
Поставщики по-разному называют статусы и коды, поэтому в CRM или собственной базе полезно хранить исходный код вместе с понятной внутренней категорией. Например, «временная ошибка», «недоступный номер», «ошибка содержимого». Тогда менеджер видит причину без расшифровки технического ответа, а разработчик сохраняет исходные данные для диагностики.
Как отличить устаревший номер от временного сбоя?
Один отрицательный статус не повод сразу исключать контакт. Номер мог оказаться вне зоны сети, устройство могло быть выключено, а у оператора могли идти технические работы. Среди причин проблем с доставкой SMS источники также называют технические сбои, ошибки в содержании сообщений и операторскую фильтрацию. Для диагностики рекомендуют проверять статусы через API, разбирать коды ошибок и делать тестовые отправки (Проблемы с доставкой SMS: диагностика и решения).
Рабочее правило строится на повторяемости. Если система получает временный статус, она делает отложенную повторную попытку по вашему сценарию. Если один и тот же контакт несколько раз получает статус, который провайдер относит к недействительному или недоступному номеру, его переносят в отдельный сегмент «на проверку». Этот сегмент не участвует в обычных рассылках, пока сотрудник не уточнит контакт через другой канал.
| Что видно в статусе | Что делать с SMS | Что делать с номером |
|---|---|---|
| Шлюз не принял запрос из-за ошибки параметров | Исправить запрос и отправить заново | Оставить в базе |
| Временная проблема сети, соединения или маршрута | Вернуть в очередь и повторить по правилам | Оставить в базе до новых результатов |
| Ошибка текста, подписи или фильтрации сообщения | Проверить шаблон и параметры кампании | Не считать номер битым |
| Повторяющийся статус недействительного номера | Не повторять отправку по старому шаблону | Перенести в сегмент для проверки или исключения |
| SMS доставлено | Зафиксировать успешную доставку | Оставить активным |
Внутреннее правило стоит описать прямо в карточке контакта: дата последней успешной доставки, последний код, число неудачных попыток и решение по номеру. Тогда база не превращается в набор непонятных отметок вроде «не отправлять», а сотрудник понимает, почему контакт исключили.
Почему ошибка Throttling требует очереди, а не удаления номера?
Throttling означает, что на текущем SMPP-соединении превышен допустимый темп отправки. Такая ошибка относится к скорости передачи, а не к качеству номера. Документация Devino рекомендует вернуть сообщение в очередь и выдержать на этом соединении таймаут в одну секунду (Протокол SMPP — Документация Devino).
Если при throttling сразу отправлять запрос повторно, система получит новую ошибку и начнёт копить очередь. Если же удалять получателей, база потеряет рабочие номера без причины. В обработчике ответа задают паузу, снижают темп на конкретном соединении и повторяют отправку после задержки. При большом потоке полезно вести отдельный журнал: время ошибки, идентификатор соединения, размер очереди и результат повторной попытки.
Для бизнеса это важно в дни, когда нужно разослать много уведомлений: напоминания о записи, изменение статуса заказа или код подтверждения. Высокая скорость отправки без контроля очереди создаёт проблему сама по себе. Аналитика трафика показывает, на каком участке возникло ограничение: в приложении, на SMPP-сессии или при передаче в маршрут.
Как настроить автоматическую очистку базы через API?
Начните с таблицы соответствий между ответами поставщика и действиями системы. Её лучше согласовать с тем, кто обслуживает SMPP-шлюз, потому что текст статусов и правила маршрута зависят от конкретной интеграции. В коде не стоит привязывать логику только к тексту ошибки: сохраните код, статус доставки, время и идентификатор сообщения.
Дальше настройте три группы обработки. В первую попадут временные ошибки: для них система создаёт повторную попытку с задержкой. Во вторую — ошибки кампании: система останавливает шаблон или помечает его для проверки. В третью — повторяющиеся статусы, связанные с недействительным номером: система исключает контакт из новых отправок и сохраняет историю причины.
Если CRM получает событие о смене статуса SMS, она может сама обновить карточку клиента и список рассылки. Такая связка строится через API: CRM передаёт сообщение шлюзу, а затем получает статусы и меняет сегмент контакта. Автоматизация SMS через CRM опирается именно на события, переменные в шаблонах и передачу данных через API или встроенный модуль (Автоматизация SMS-рассылок через CRM: настройка триггеров, интеграция шлюзов и правовые нюансы в 2026 году).
Отдельно предусмотрите защиту от повторов. Пока нет финального статуса, система должна связывать все попытки с одним сообщением и не создавать несколько одинаковых записей в карточке клиента. Если основной маршрут временно недоступен, логично заранее описать, как настроить fallback-маршрутизацию SMS при сбоях SMPP.
Типичные ошибки при работе со статусами SMPP
- Удалять номер после первой ошибки доставки, хотя причина была во временном сбое сети или маршрута.
- Считать ошибку throttling отказом номера и не ограничивать скорость отправки.
- Хранить в базе только текст «не доставлено» без исходного кода, времени и идентификатора сообщения.
- Повторять отправку без паузы и лимита попыток, из-за чего очередь растёт, а клиент получает дубли.
- Менять номер в базе вручную, не сохранив историю статусов и причину исключения.
3 шага, которые можно сделать на этой неделе:
- Выгрузите последние статусы SMS и разделите их на доставленные, временные ошибки, ошибки кампании и повторяющиеся ошибки номера.
- Добавьте в CRM или таблицу контактов поля для последнего статуса, даты успешной доставки и причины исключения из рассылок.
- Настройте очередь для временных ошибок, паузу при throttling и отдельный сегмент номеров, которые требуют проверки.
