# smpp.by > Технологические решения для высоконагруженного SMS-трафикаВ современном B2B-секторе скорость и надежность доставки транзакционных сообщений являются критическими факторами успеха. Платформа smpp.by создана как специализированный хаб для интеграции телекоммуникационных решений, ориентированных на Enterprise-сегмент. ## Organization - Region: Belarus - Contact: office@smpp.by - Contacts: https://smpp.by/contacts - Editorial policy: Материалы готовятся для малого бизнеса Беларуси и обновляются при существенных изменениях. --- # Почему возникают задержки при отправке SMS через SMPP-протокол? Задержки в SMPP-канале чаще всего возникают из-за неправильной настройки параметров сессии или ограничений со стороны оператора. Система может ожидать подтверждения доставки (DLR), пока очередь сообщений переполняется. Чтобы выявить «узкое горлышко», важно проанализировать размер окна подтверждения, латентность сети и текущие лимиты скорости (TPS). Когда эти параметры не согласованы, отправка замедляется независимо от производительности вашего приложения. В этой статье разберем, как именно технические настройки влияют на доставку и на что смотреть в первую очередь, чтобы оптимизировать прохождение трафика. Как размер окна влияет на скорость отправки? Основной параметр, который часто упускают при настройке SMPP, — это Window Size. Это количество запросов (PDU), которые ваш клиент отправил, но еще не получил на них подтверждение от сервера. Если оставить значение по умолчанию, равное 1, вы ограничите пропускную способность скоростью самого канала связи. В таком случае каждое следующее сообщение встает в очередь, пока не придет ответ на предыдущее. Представьте, что время оборота сигнала (RTT) между вашим сервером и SMS-центром составляет 100 миллисекунд. При Window Size, равном 1, физический предел скорости составит всего 10 сообщений в секунду. Увеличение этого параметра позволяет «заполнить» канал запросами, не дожидаясь ответа на каждый из них. Однако избыточное значение может привести к переполнению буфера, если сервер не успевает обрабатывать поток. Оптимальное число подбирается экспериментально исходя из стабильности пинга и текущих ограничений провайдера. Какие параметры пропускной способности важно контролировать? Пропускная способность SMPP-канала определяется взаимодействием трех факторов: размером окна, задержкой сети и лимитами транзакций в секунду (TPS), которые установлены на вашей учетной записи. Если ваш софт отправляет сообщения быстрее, чем разрешено настройками аккаунта, сервер начнет присылать ошибки или сбрасывать соединение. Для диагностики часто полезно изучить логи PDU, чтобы увидеть реальную картину обмена пакетами. Если вы видите массовые таймауты, проверьте, не упираетесь ли вы в TPS-лимит. Часто бывает, что при росте нагрузки на систему диагностика задержек доставки показывает, что проблема кроется не в операторе, а в очереди сообщений на стороне вашего шлюза. Сравнение этих параметров с техническими требованиями к SMPP-шлюзу поможет понять, нужно ли расширять канал или просто оптимизировать код обработки статусов. Сравнение HTTP API и SMPP: когда что выбирать? Не всегда для отправки уведомлений требуется именно SMPP. Разница между методами заключается в способе взаимодействия с сервером оператора или агрегатора. Параметр HTTP API SMPP Сложность настройки Низкая Высокая Объем трафика Малый и средний Высокий и очень высокий Скорость ответа Средняя Максимальная Тип соединения Запрос-ответ (статлесс) Постоянная сессия Типичные ошибки при работе с протоколом Установка Window Size в значение 1 при попытках отправить массовую рассылку. Отсутствие обработки статусов доставки (DLR) в реальном времени, что засоряет очередь. Использование одного соединения для задач с разным приоритетом. Игнорирование ограничений по количеству связок (bind) для одного аккаунта. Отсутствие мониторинга задержек на уровне сетевых пакетов. Для стабильной работы системы рекомендуется следовать простому алгоритму отладки. 3 шага, которые можно сделать сегодня: Проверить текущий лимит TPS и сравнить его с реальной нагрузкой в моменты пиковых отправок. Увеличить размер окна (Window Size) в настройках клиента, если текущее значение равно 1. Настроить логирование PDU-пакетов, чтобы видеть точное время задержки отклика от сервера при интеграции с вашей системой. > Source: https://smpp.by/pochemu-voznikayut-zaderzhki-pri-otpravke-sms-cherez-smpp-protokol --- # Как настроить graceful degradation SMS-рассылки при превышении лимитов оператора SMPP-провайдеры по умолчанию держат жёсткий потолок по скорости — 30 SMS в секунду (Vonage). Если в пик рассылка упирается в этот лимит, SMSC отвечает кодом 0x00000058 (Throttling error, десятиричное значение 88) и просто отбрасывает сообщение. Решение — graceful degradation: вместо бинарного «отправил/не отправил» система сама снижает скорость, переключает канал или складывает сообщения в очередь. В статье — практический сценарий, как собрать такую логику на стороне клиента без дорогих анализаторов и без потери сообщений. Почему операторы вообще вводят лимиты и откуда берётся код 88 Каждый SMSC защищает собственные ресурсы: транзакции, базы пользователей, маршрутизаторы. У SMPP-аккаунта есть «потолок» — он называется TPS, transactions per second, сделки в секунду. По умолчанию у большинства провайдеров это 10–30 SMS в секунду, и цифра зависит от тарифа (Vonage, SMPP Center). Когда клиент отправляет больше, SMSC возвращает NACK с кодом Throttling error. Сообщение теряется на стороне клиента, если тот не повторит попытку. Параллельно у SMSC есть ещё один лимит — число неподтверждённых PDU, которые клиент держит в окне (window size). Если поднимать TPS, не трогая размер окна, число ошибок только растёт (SMSGatewayCenter). Что должна делать система при первом throttle-ответе Главное — не паниковать и не выкидывать сообщение. Сценарий graceful degradation строится на трёх реакциях: пауза, повтор, откат на резервный канал. Пауза. Получили NACK с кодом 88 — ставим экспоненциальную задержку перед следующим submit_sm. Стартовая пауза 100 мс, удвоение при каждом повторе до потолка в 5 секунд. Повтор. Помечаем сообщение флагом retry_count, отправляем снова, но не больше трёх попыток. После трёх NACK переводим в dead-letter queue. Откат. Если retries исчерпаны и TPS не падает — переключаемся на резервный канал или снижаем скорость до 50% от текущей. Снижение делаем постепенно, чтобы не устроить «качели» между throttle и нормальной работой. Как выбрать окно и TPS, чтобы не упереться в лимит Перед настройкой важно понять, что именно сейчас узкое место. Их три, и путать их — самая частая ошибка (SMSGatewayCenter): ПараметрЧто ограничиваетТипичный дефолт TPS аккаунтаСкорость отправки, которую разрешил провайдер10–30 SMS/с Window sizeЧисло неподтверждённых submit_sm в очередиЗадаётся в bind_transceiver Downstream capacityПотолок SMSC по конкретному маршруту в пиковые часыНиже TPS аккаунта Если видите серию throttle-ошибок при умеренной нагрузке — проверьте, не упираетесь ли в downstream. Поднять window size, когда узкое место TPS аккаунта, бесполезно: получите больше ошибок, а не больше доставок. Как собрать очередь с приоритетами, а не «всё в одну кучу» В пиковой нагрузке помогает не одна большая очередь, а несколько с разным приоритетом. Транзакционные SMS (коды подтверждения, уведомления об оплате) уходят первыми. Маркетинговые рассылки ждут своей очереди и снимаются при появлении свободных слотов. Минимальный набор очередей: High. OTP, пароли, уведомления по статусу заказа. Жёсткий SLA в секундах. Medium. Сервисные уведомления — доставка, баланс, изменение тарифа. Low. Маркетинговые кампании. Отправляются, когда есть запас по TPS, остаток — в очередь следующего окна. Если приоритетная очередь занимает больше 80% доступного TPS, маркетинговая автоматически встаёт на паузу. Это и есть graceful degradation: ничего не теряется, просто меняется порядок и скорость. Зачем нужен enquire_link и какие паузы реально опасны Параллельно с throttling у SMPP есть второй тихий враг — inactivity timeout. Сервер закрывает сессию, если за 120 секунд не пришёл ни один PDU, включая enquire_link (Mobile Text Alerts). Без keepalive клиент теряет соединение и долго восстанавливает его в пик нагрузки. Рабочий диапазон — отправлять enquire_link каждые 30–60 секунд. Если соединение рвётся чаще, чем раз в час, проверьте сетевой путь и таймауты на firewall: NAT любят «забывать» неактивные TCP-сессии. Типичные ошибки, которые ломают graceful degradation Сразу резать TPS в ноль при первом throttle-ответе. Сеть «качается», и через минуту вы уже недоиспользуете канал. Хранить очередь только в памяти процесса. При рестарте контейнера сообщения исчезают, и клиент думает, что они доставлены. Игнорировать разницу между Throttling error и просто ошибкой маршрутизации. Код 0x00000058 лечится паузой, остальные — нет. Забывать про enquire_link во время длительной паузы. SMSC закрывает сессию, а выясняется это только по следующей submit_sm. Повышать window size, не проверив TPS аккаунта. Получаете больше throttle-ответов и больше нагрузки на собственный retry-loop. 3 шага, которые можно сделать на этой неделе Поднять в логах отметку по коду 0x00000058 и собрать статистику — в какие часы и на каких маршрутах он срабатывает чаще. Внедрить очередь с приоритетами и экспоненциальную паузу на retry, чтобы маркетинг не вытеснял транзакционные сообщения. Настроить enquire_link каждые 30–60 секунд и проверить таймауты на NAT — иначе пауза сама убьёт соединение. Полезные ссылки: failover между SMPP-провайдерами, отказоустойчивая отправка транзакционных SMS, TLS для SMPP, RocketSMS как пример SMPP-шлюза с уже встроенной защитой от throttle. > Source: https://smpp.by/kak-nastroit-graceful-degradation-sms-rassylki-pri-prevyshenii-limitov-operatora --- # Как настроить failover между SMPP-провайдерами и не терять SMS Failover между SMPP-провайдерами — это автоматическое переключение потока SMS на резервный шлюз, если основной стал недоступен. Схема нужна компаниям, которые отправляют коды подтверждения, статусы заказов и другие транзакционные сообщения: такие SMS нельзя задержать или отправить повторно через час. Настроенная резервная маршрутизация позволяет интернет-магазинам и сервисам сохранять доставку важных уведомлений даже при сбое у одного оператора. В статье покажу, как собрать такую схему из двух подключений и проверить, что она реально работает. Что такое failover и когда он нужен? Failover — это механизм, который автоматически переключает отправку SMS с основного SMPP-подключения на резервное, если основное перестало отвечать. Такой сценарий критичен для транзакционных сообщений: кодов подтверждения, одноразовых паролей, уведомлений о статусе заказа. Если канал недоступен, клиент не получит SMS, а заказ может «зависнуть». В протоколе SMPP v3.4, который сейчас используют почти все шлюзы, нет встроенной команды «переключиться на резервный сервер». Логика failover ложится на отправителя: либо на сервис рассылок, либо на вашу систему. Для малого бизнеса это часто звучит сложнее, чем есть на самом деле. Первый вариант — использовать SMS-агрегатора, у которого уже настроено резервирование. Второй — организовать собственное резервное подключение. Ниже разберём второй вариант. Если хотите разобраться в деталях, почитайте отдельную статью о настройке резервного SMPP-канала. Как настроить failover между двумя SMPP-провайдерами? Самостоятельная настройка сводится к нескольким шагам. Даже без глубокого опыта с SMPP по ним можно пройти за день. Выберите двух провайдеров. У каждого должен быть собственный маршрут до операторов и независимая инфраструктура. Если оба подключения пойдут через одну компанию-агрегатора, смысл failover теряется. Получите параметры подключения у обоих: адрес сервера, порт, системный ID, пароль. Уточните версию протокола — желательно, чтобы оба поддерживали SMPP v3.4. Настройте основное и резервное соединения в вашей системе. Сделайте тестовую отправку через каждого провайдера по отдельности. Оба должны работать. Определите критерий отказа. Регулярно отправляйте команду enquire_link — это проверка связи с сервером. Если ответа нет несколько раз подряд (например, три попытки с интервалом 10 секунд), считайте соединение потерянным. Пропишите алгоритм переключения. При отправке пробуйте основной канал. Если в течение разумного времени нет подтверждения приёма, отправляйте то же сообщение через резервный. Уникальный идентификатор сообщения при этом должен сохраняться, чтобы не создать дубль. Протестируйте переключение. Временно заблокируйте основное соединение и отправьте тестовое SMS. Оно должно уйти через резервный шлюз. Помните одну особенность SMPP: статусы доставки (DLR) не всегда приходят на то же соединение, через которое было отправлено сообщение. При нескольких подключениях к одному логину или после переключения это случается регулярно. Поэтому всегда сопоставляйте DLR по внутреннему идентификатору сообщения, а не по номеру соединения. Почему возникают дубли и как их избежать? Дубли появляются, когда система не получила подтверждение приёма от первого шлюза и решила, что сообщение потеряно. Шлюз на самом деле мог принять и отправить его, но ответ потерялся. Повторная отправка через резервный канал приводит к тому, что клиент получает два одинаковых кода. Для транзакционных SMS это серьёзная проблема: повторный ввод кода часто воспринимается как ошибка и может заблокировать сессию. Чтобы этого не происходило, каждому сообщению присваивайте собственный message_id и храните его в базе. Перед повторной отправкой проверяйте, не уходило ли уже это сообщение. Если DLR о доставке не пришёл, но сообщение могло уйти, не отправляйте его повторно без явной необходимости. Лучше дождаться окончательного статуса — «доставлено» или «ошибка» — и уже по нему решать, что делать. Как проверить, что резервный канал действительно сработает? Настроенный failover без теста — это просто обещание. Чтобы убедиться, создайте сбой своими руками. Отправьте тестовое SMS через основного провайдера, получите DLR. Затем заблокируйте доступ к основному серверу или остановите SMPP-процесс в своей системе. Отправьте ещё одно SMS — оно должно автоматически уйти через резервный шлюз. Проверьте, что DLR корректно отобразился в вашей системе. Повторите сценарий в обратную сторону, чтобы убедиться, что основной канал тоже работает после возврата. Для контроля качества переключения важно понимать, как читать DLR-отчёты. Пять ключевых метрик разобраны в статье Как читать DLR-отчёт SMPP-шлюза. Если вы отправляете SMS через CRM, настройку соединений обычно делают один раз, а дальше система работает автоматически. Готовый сценарий описан в инструкции по интеграции CRM и SMPP для SMS-уведомлений. Типичные ошибки при настройке failover Выбор двух провайдеров, которые используют один и тот же вышестоящий маршрут. При сбое общего узла отключаются оба канала. Отсутствие мониторинга. Если соединение не проверяется, система продолжит отправлять на мёртвый шлюз до тех пор, пока не упадёт очередь. Повторная отправка без дедупликации. Дубль для кода подтверждения хуже, чем отсутствие SMS: клиент вводит второй код и получает ошибку. Игнорирование DLR. Если не обрабатывать статусы, вы не узнаете о недоставке, пока клиент не пожалуется. Нет тестирования переключения. Схема может отлично выглядеть в документации, но в первый реальный сбой окажется нерабочей. 3 шага, которые можно сделать сегодня: Определите, какие SMS критичны для бизнеса. Обычно это коды подтверждения, уведомления об оплате или изменении статуса заказа. Уточните у вашего SMS-провайдера, есть ли у него готовая услуга failover или возможность подключить второй независимый шлюз. Если технически готовы управлять подключениями сами, настройте тестовые соединения с двумя провайдерами и принудительно отключите основное. Так вы увидите, что происходит с отправкой в реальном сбое. > Source: https://smpp.by/kak-nastroit-failover-mezhdu-smpp-provayderami-i-ne-teryat-sms --- # Проблемы SMPP-шлюзов: как диагностировать задержки доставки в 2026 году Задержки доставки сообщений чаще всего возникают из-за разрыва между пропускной способностью вашего сервера и лимитами, установленными на стороне шлюза. Чтобы диагностировать причины задержек, нужно анализировать время отклика на уровне протокола, проверять настройки очереди сообщений и сравнивать скорость обработки в разные промежутки времени. В этой статье вы узнаете, на какие технические показатели стоит смотреть в первую очередь, чтобы понять, где именно теряются доли секунды при отправке уведомлений клиентам. Почему возникают задержки при использовании SMPP? Протокол SMPP позволяет передавать сообщения очень быстро, зачастую обработка одного пакета занимает менее 0,05 секунды. Однако общая скорость доставки складывается из нескольких факторов. Главный из них — размер окна и количество запросов в единицу времени, которые может обработать шлюз. Если ваша система отправляет больше сообщений, чем разрешено настройками TPS (Transactions Per Second), сообщения встают в очередь на стороне шлюза. Другой важный фактор — состояние магистральных каналов операторов связи. Даже при идеальной настройке вашего оборудования, задержки могут возникать на конечном этапе доставки сообщения абоненту. Проверку инфраструктуры стоит начать с анализа метрик здоровья SMPP-сессии. Если вы видите, что сессия постоянно обрывается или ответ на запрос bind_transmitter приходит с опозданием, проблема находится в сетевом взаимодействии. Как диагностировать узкие места в передаче трафика? Первым делом нужно понять, где именно задерживается сообщение: на вашем сервере, в канале связи или в очереди шлюза. Простой способ — сравнить метку времени отправки запроса с вашего сервера и метку времени получения DLR (отчета о доставке). Если разница велика, а статус сообщения долго остается в промежуточном состоянии, нужно анализировать логи. Полезно читать PDU-логи SMPP, чтобы видеть, какие параметры TLV возвращает система и нет ли там кодов ошибок, указывающих на перегрузку. Тип проблемы Где проявляется Способ диагностики Лимит TPS Очередь сообщений Анализ ответа command_status на submit_sm Сетевой лаг Время отклика (RTT) Тест ping и замеры времени ответа bind/enquire_link Каналы операторов Задержка DLR Сравнение времени отправки и времени доставки по операторам Какие ошибки чаще всего совершают при настройке? Технические специалисты нередко упускают из виду простые детали, которые влияют на стабильность потока. Ошибки при интеграции приводят к росту очереди и падению скорости доставки. Использование слишком маленького окна (window size) для высоконагруженных рассылок. Отсутствие обработки параметров TLV, которые содержат детальную информацию об ошибках доставки. Настройка слишком частых запросов enquire_link при низкой активности, что приводит к разрывам сессий. Игнорирование статусов ошибок, возвращаемых оператором, и повторная отправка сообщений, которые уже не будут доставлены. Слишком долгая обработка DLR на стороне клиента, что блокирует поток входящих пакетов. Как оптимизировать работу с очередями? Масштабирование отправки через SMPP часто требует настройки дополнительных каналов или сессий. Вместо попыток «протолкнуть» всё через одну сессию, эффективнее распределить нагрузку. При больших объемах сообщений проверьте, не упирается ли ваша текущая интеграция в технические требования к SMPP-шлюзу, которые были актуальны при старте проекта. Иногда для улучшения показателей достаточно просто увеличить TPS, согласовав это с поставщиком трафика. Не забывайте, что реальная скорость всегда зависит от текущей нагрузки на оборудование. Поэтому нагрузочное тестирование нужно проводить регулярно, а не только в момент запуска системы. Если вы сталкиваетесь с тем, что проблемы повторяются, ознакомьтесь с материалом о том, как выявить скрытые задержки доставки SMS при интеграции с CRM. 3 шага, которые можно сделать сегодня для проверки системы: Выгрузите логи за последний час и посчитайте среднее время ожидания ответа на submit_sm. Проверьте, установлены ли лимиты TPS в настройках вашей учетной записи SMPP и не превышаете ли вы их. Сравните время доставки сообщений для разных направлений, чтобы исключить влияние конкретных операторских магистралей. > Source: https://smpp.by/problemy-smpp-shlyuzov --- # Как оптимизировать PDU-очереди при пиковых рассылках в периоды акций? Оптимизация PDU-очередей при пиковых нагрузках сводится к контролю пропускной способности канала и правильной настройке параметров окна (window size) в сессии SMPP. Когда бизнес запускает массовую акцию, резкий всплеск запросов часто переполняет буферы, что приводит к отложенной доставке или сбросу соединений. Чтобы избежать задержек, необходимо настроить динамическое управление очередью сообщений и следить за состоянием ACK-ответов от шлюза. Это предотвращает критическое накопление данных и помогает сообщениям уходить к адресатам без потерь в моменты максимальной активности. Почему возникают задержки в PDU-очередях? Основная причина задержек — расхождение между скоростью отправки сообщений со стороны вашего сервера и скоростью обработки SMPP-шлюзом. Когда скрипт отправляет пакеты PDU (Protocol Data Unit) быстрее, чем шлюз подтверждает их прием, очередь на вашем стороне начинает расти. Если объем очереди превышает лимит оперативной памяти, система может начать принудительно закрывать соединения или возвращать ошибки таймаута. В распределенных IT-инфраструктурах проблема усугубляется сетевыми паузами между узлами. Если один из сервисов, формирующих PDU-пакет, работает медленнее остальных, он становится «бутылочным горлышком», тормозя всю рассылку. Для анализа подобных ситуаций полезно знать как читать PDU-логи SMPP и находить узкое место доставки без коммерческого софта, чтобы видеть реальную картину прохождения трафика. Как настроить параметры окна сессии? Параметр window_size определяет, сколько PDU-запросов можно отправить, не дожидаясь подтверждения от шлюза. Для малого бизнеса стандартным решением является установка умеренных значений в диапазоне от 5 до 20. Увеличение этого числа позволяет отправлять сообщения быстрее, но повышает риск того, что при кратковременном сбое шлюза в «подвешенном» состоянии окажется слишком много сообщений. При планировании акций в 2026 году стоит учитывать технические лимиты вашего соединения. Если вы планируете отправку нескольких тысяч сообщений за короткий промежуток времени, целесообразно заранее проверить технические требования к SMPP-шлюзу для доставки OTP в Беларуси, чтобы убедиться в соответствии параметров вашего оборудования регламентам операторов связи. Как предотвратить переполнение буфера? Эффективный метод контроля нагрузки — использование механизма очереди задач, например, RabbitMQ или Redis. Вместо прямой отправки сообщений в шлюз, приложение складывает их в очередь, из которой воркеры вытягивают данные с фиксированной скоростью (throttling). Такой подход позволяет сгладить пики и поддерживать стабильный поток, не перегружая SMPP-сессию. Метод Принцип действия Влияние на доставку Очередь задач Контроль скорости отправки (throttling) Стабильная доставка без рывков Увеличение window_size Отправка без ожидания ACK Высокая скорость, риск разрыва Асинхронный мониторинг Анализ ответов в реальном времени Быстрое выявление проблем Типичные ошибки при работе с SMPP Отсутствие контроля подтверждений (ACK) от шлюза, что приводит к «зависанию» отправки. Установка слишком большого окна сессии, при котором шлюз отключает клиента из-за превышения лимитов. Игнорирование ошибок типа «throttling error» при попытке превысить допустимый RPS. Отправка большого объема трафика через одну сессию без использования пула соединений. Ненастроенный механизм повторной отправки (retry) для сообщений с временными статусами ошибок. Если вы заметили, что даже при умеренных рассылках сообщения доходят с задержкой в несколько минут, стоит изучить вопрос как организовать мониторинг задержек в SMPP-шлюзе. Это поможет понять, на каком этапе происходит задержка: на этапе формирования пакетов в коде или непосредственно при передаче данных через интернет-соединение. 3 шага, которые помогут оптимизировать рассылку уже сегодня: Проверьте текущие логи на наличие ошибок 0x00000058 (throttling error), которые сигнализируют о превышении скорости. Ограничьте количество одновременных запросов (RPS) в настройках вашего API-клиента до значений, указанных оператором. Внедрите промежуточный сервис очередей, чтобы распределить нагрузку равномерно в течение часа, а не за одну минуту. > Source: https://smpp.by/kak-optimizirovat-pdu-ocheredi-pri-pikovykh-rassylkakh-v-periody-aktsiy --- # Как организовать мониторинг задержек в SMPP-шлюзе Мониторинг задержек в SMPP-шлюзе для малого бизнеса строится на отслеживании времени между отправкой запроса Submit_sm и получением ответного пакета Submit_sm_resp. В отличие от стандартных API, этот протокол требует прямого контроля за сессией. Вы можете фиксировать время доставки сообщения до SMS-центра (SMSC) и анализировать DLR-отчеты для понимания реальной скорости прохождения трафика через сеть оператора. Это позволяет вовремя обнаружить узкие места в инфраструктуре и избежать зависания очереди сообщений. Базовый мониторинг помогает разделить задержки на стороне вашего сервера и проблемы на магистральных каналах. Почему возникают задержки при использовании SMPP? Протокол SMPP обеспечивает прямое соединение с SMS-шлюзом, но это не гарантирует мгновенную доставку абоненту. После того как ваш сервер отправил сообщение, оно проходит через очередь шлюза, систему фильтров и инфраструктуру оператора. Высокая скорость отправки часто упирается в ограничения провайдера, который распределяет ресурсы для предотвращения перегрузок. Если вы превышаете разрешенный лимит сообщений в секунду, сервер начинает накапливать очередь, что неизбежно ведет к росту задержки. Важно понимать, что протокол подключения лишь определяет способ связи, но не отменяет этапы обработки сообщения в сети. Как выявить задержки с помощью базовых инструментов? Самый простой способ — проверка сетевого пути через ping до хоста провайдера, но он показывает лишь доступность канала, а не скорость обработки SMS. Для глубокого анализа используют сбор логов с параметрами времени прохождения каждого пакета. Если задержка растет при стабильном пинге, проблема кроется в перегрузке на стороне шлюза. Как настроить мониторинг SMPP через DLR и видеть сбои доставки — это первый шаг к прозрачности, который поможет отличить сетевые ошибки от долгой обработки на стороне SMSC. Метод мониторинга Что измеряет Для чего полезен Ping/ICMP Доступность узла Проверка связи с сервером Submit_sm_resp Скорость приема SMSC Выявление перегрузки шлюза DLR (Status Report) Время доставки абоненту Оценка качества маршрута Какие технические факторы влияют на стабильность сессии? Стабильность работы напрямую зависит от правильной настройки сессии и параметров окна передачи. Когда количество отправленных сообщений превышает возможности окна, SMPP-клиент принудительно ждет подтверждения. Регулярная проверка соединения через Enquire Link позволяет избежать внезапных разрывов, вызванных таймаутами на стороне провайдера. Как настроить Enquire Link на SMPP-шлюзе, чтобы поддерживать соединение активным даже при низкой интенсивности трафика, следует изучить каждому техническому специалисту, работающему с этой интеграцией. Типичные ошибки при настройке мониторинга Попытка измерять задержку только пингом, игнорируя время ответа от SMSC. Отсутствие логирования статусов DLR, что скрывает реальную скорость доставки до конечного получателя. Игнорирование ограничений на скорость отправки (TPS), установленных провайдером. Настройка параметров окна без учета пропускной способности вашего канала. Отсутствие алертов при потере сессии, что приводит к простою системы до ручного вмешательства. Для бизнеса, который строит коммуникации на надежности, критически важно контролировать не только момент отправки, но и финальный статус доставки сообщения. При выборе инфраструктуры для таких задач стоит учитывать технические требования к SMPP-шлюзу для доставки OTP в Беларуси, где требования к скорости и качеству доставки выше, чем при обычных массовых рассылках. 3 шага, которые можно сделать сегодня для улучшения контроля за трафиком: Настройте логирование времени ответа (Submit_sm_resp) для каждой отправки. Установите минимальный интервал проверки связи через Enquire Link. Настройте автоматические уведомления на почту или в мессенджер при увеличении времени ответа от шлюза выше критического порога. > Source: https://smpp.by/kak-organizovat-monitoring-zaderzhek-v-smpp-shlyuze --- # Технические требования к SMPP-шлюзу для доставки OTP в Беларуси Стабильная доставка одноразовых паролей (OTP) через SMPP-протокол требует прямой связи между сервером бизнеса и SMS-центром. В отличие от стандартных HTTP-запросов, этот протокол работает в режиме непрерывной сессии, что исключает задержки на установку соединения для каждого сообщения. Чтобы система работала бесперебойно, важно правильно настроить параметры пропускной способности, обеспечить поддержку отчетов о доставке (DLR) и следить за состоянием очереди на стороне оператора. Эти шаги минимизируют риск зависания кодов подтверждения в моменты пиковых нагрузок. Почему SMPP предпочтительнее для OTP-сообщений? OTP-сообщения критически зависят от времени доставки. Если пользователь ждет код для входа в личный кабинет, задержка даже в несколько секунд вынуждает его запрашивать повторную отправку. Протокол SMPP позволяет поддерживать постоянный канал связи с шлюзом. Бизнес-система не тратит время на рукопожатие TCP или аутентификацию при каждой отправке. При высоких объемах SMS, например, в периоды крупных распродаж или сезонного спроса, это дает значительный выигрыш в скорости. Для профессиональной интеграции полезно изучить тонкости выбора SMPP-шлюза и понять, где именно протокол эффективнее стандартного API. Какие технические параметры влияют на стабильность? Стабильность SMPP-соединения зависит от правильно настроенного параметра TPS (Transactions Per Second). Если вы отправляете сообщения быстрее, чем позволяет лимит вашего контракта, часть запросов попадает в очередь или отбрасывается. Проверьте размер окна (window size) — это количество сообщений, которые система отправила, но еще не получила подтверждение о приеме от шлюза. Небольшое окно при высокой скорости отправки приведет к тому, что система будет простаивать в ожидании DLR. Параметр За что отвечает Влияние на OTP TPS Количество сообщений в секунду Исключает задержки в очередях Window Size Очередь неподтвержденных запросов Влияет на пиковую скорость DLR Отчет о статусе доставки Позволяет отследить недоставленные коды Как избежать проблем при пиковых нагрузках? Пиковые нагрузки — главный враг OTP-сервисов. Когда база пользователей активно заходит в систему одновременно, нагрузка на шлюз возрастает. Если ваша инфраструктура не готова к таким скачкам, сообщения могут задерживаться или вовсе не уходить. Стоит заранее настроить мониторинг сессий, чтобы видеть, когда канал перестает отвечать. При необходимости оптимизации процесса отправки и предотвращения проблем, ознакомьтесь с тем, как избежать блокировок SMPP-сессий при резком росте объемов рассылки. Типичные ошибки при настройке SMPP Игнорирование DLR-отчетов: система не знает, дошло сообщение или нет, и не может повторно отправить код. Неправильная настройка таймаутов: при коротких таймаутах сессия обрывается раньше, чем придет подтверждение от оператора. Отсутствие резервного канала: при падении основного SMPP-соединения OTP-код не будет доставлен пользователю. Превышение лимита TPS без согласования с провайдером: это приводит к принудительному ограничению скорости со стороны шлюза. Чтобы наладить надежную систему доставки OTP, начните с аудита текущей нагрузки и проверки настроек соединения. Выполните эти три шага на этой неделе: Запросите у вашего провайдера актуальный лимит TPS и настройте систему отправки так, чтобы не превышать этот показатель. Проверьте логи на наличие ошибок 0x0000000B (Throttling Error), которые сигнализируют о превышении допустимой нагрузки. Убедитесь, что ваша система корректно обрабатывает DLR-отчеты и при необходимости автоматически переключается на резервный маршрут. Полезные ссылки: Интеграция LLM-агентов с SMPP через протокол MCP > Source: https://smpp.by/tekhnicheskie-trebovaniya-k-smpp-shlyuzu-dlya-dostavki-otp-v-belarusi --- # Как избежать блокировок SMPP-сессий при резком росте рассылок? Для бизнеса, отправляющего сообщения через SMPP, главной проблемой при скачках нагрузки становятся ошибки при обработке запросов и превышение лимитов скорости. Чтобы избежать блокировок со стороны SMS-центра, важно правильно распределять нагрузку на уровне инфраструктуры и следить за очередностью отправки. В этой статье разберем, почему сессии обрываются и как настроить взаимодействие с провайдером, чтобы сообщения уходили без задержек даже в периоды распродаж или массовых рассылок. Эти технические решения помогут сделать работу вашего шлюза стабильной без постоянного ручного контроля. Почему SMPP-соединение прерывается при высокой нагрузке? Чаще всего соединение с SMSC обрывается из-за неверной конфигурации или превышения лимитов, установленных провайдером. Если ваш сервер пытается отправить сообщений больше, чем позволяет текущий тариф или пропускная способность канала, сервер отправителя принудительно разрывает TCP-сессию. При нестабильном интернет-соединении или неправильной настройке тайм-аутов в SMPP v3.4 система не успевает подтвердить получение пакета, что приводит к зависанию биндов. В итоге сообщения встают в очередь, а потом массово уходят с ошибками, когда канал освобождается. Как правильно настроить масштабирование отправки? Масштабирование — это не просто увеличение мощности сервера, а способность системы динамически управлять потоками. При больших объемах сообщений в единицу времени стоит использовать несколько параллельных каналов. Работа через несколько независимых сессий позволяет разделить трафик: например, критичные сервисные уведомления отправлять через основной канал, а маркетинговые акции — через дополнительный. Если одна сессия будет перегружена, это не заблокирует доставку важных OTP-кодов. Понимание того, как устроена ваша интеграция шлюза, дает возможность настроить ретраи и избежать дублирования сообщений при сбоях. Какие показатели мониторить для стабильной работы? Основной индикатор здоровья системы — отчет о доставке, известный как DLR. По нему вы видите реальный статус: от принятия сообщения на сервер до доставки его абоненту или истечения срока жизни. Если процент статусов «expired» или «undeliverable» растет, это сигнал о проблемах на стороне провайдера или неверной маршрутизации. Важно настроить алерты на превышение времени обработки запроса. Если система «задумывается» дольше установленного лимита, это повод автоматически переключить нагрузку на резервный поток или притормозить отправку. Параметр Значение для стабильности Что влияет TPS (сообщений в сек) Согласно лимитам провайдера Пропускная способность шлюза DLR статусы Отслеживание в реальном времени Скорость смены маршрута TCP-тайм-аут Зависит от качества сети Стабильность соединения Типичные ошибки при работе с SMPP Попытка отправить весь объем рассылки в одну сессию без учета лимитов TPS. Отсутствие обработки отрицательных ответов от SMS-центра (кодов ошибок). Игнорирование статусов доставки в логах, что мешает вовремя заметить блокировку. Неверная настройка параметров Bind, когда сервер постоянно «переподключается», создавая лишнюю нагрузку. Использование одного канала для всех типов сообщений без приоритезации. 3 шага, которые можно сделать на этой неделе для стабилизации рассылок: Проверьте лог ошибок вашего шлюза за последние семь дней и выделите коды, связанные с превышением лимитов скорости. Установите лимит на количество сообщений в секунду согласно вашему текущему тарифу у провайдера, чтобы избежать принудительных разрывов сессий. Разделите потоки отправки: выделите сервисные уведомления в отдельный процесс с высоким приоритетом, а массовые рассылки — в фоновую очередь. Полезные ссылки: безопасность рассылок, холодные рассылки. > Source: https://smpp.by/kak-izbezhat-blokirovok-smpp-sessiy-pri-rezkom-roste-rassylok --- # Как настроить отказоустойчивую отправку транзакционных SMS Отказоустойчивость при отправке транзакционных SMS через SMPP-протокол — это способность системы гарантированно доставлять сообщения даже при сбоях на стороне агрегатора или нестабильном интернет-соединении. Чтобы бизнес не терял важные уведомления для клиентов, нужно реализовать очередь сообщений, настроить логирование ответов сервера и внедрить механизм автоматического переключения между маршрутами. Стабильная работа системы зависит от грамотной настройки API-интеграции и своевременной диагностики канала связи. Почему возникают потери сообщений при API-интеграции? Чаще всего сообщения пропадают из-за технических сбоев на стороне оператора связи или агрегатора. Операторы регулярно обновляют оборудование или проводят плановые работы, из-за чего SMPP-соединение может кратковременно обрываться. Если ваша система отправки не умеет «понимать» отсутствие подтверждения от сервера, SMS просто зависает в очереди или теряется без уведомления системы. Ошибки в содержании сообщений также влияют на доставку. Иногда фильтры операторов блокируют рассылку из-за специфических символов или несоответствия текста формальным требованиям. Когда скрипт отправки не анализирует коды ответов сервера, вы не видите реальную причину отказа. Важно всегда проверять статусы отправки через API-интерфейс поставщика услуг, чтобы понимать, на каком этапе цепочки возникла проблема. Как диагностировать проблемы с доставкой? Первым делом проанализируйте логи своего сервера. Каждый запрос к шлюзу должен сопровождаться записью ID сообщения и кода ответа. Если в логах появляются ошибки соединения или таймауты, значит, проблема в канале связи между вашим сервером и агрегатором. Если же сервер отвечает успешно, но SMS не доходит, вопрос может быть в фильтрации на стороне оператора. Проводите регулярные тестовые отправки. Если система работает стабильно, даже редкие сбои в рассылках станут заметны сразу. Полезно настроить интеграцию CRM и SMPP таким образом, чтобы при каждой неудачной попытке отправки система фиксировала код ошибки — это упростит дальнейшую настройку шлюза. Тип ошибки Признак Метод решения Ошибка соединения Таймаут или обрыв TCP Переподключение через резервный канал Ошибка валидации Код ошибки от агрегатора Проверка содержания и длины текста Задержка доставки Статус «отправлено» висит долго Оптимизация очереди SMPP-трафика Какие типичные ошибки допускают при отправке? Чаще всего предприниматели сталкиваются с этими проблемами при настройке автоматизированных рассылок: Отсутствие повторных попыток при неудачной отправке (ретраев). Использование одного канала без резервных путей. Отсутствие обработки кодов ошибок, возвращаемых сервером. Слишком большая очередь, которая переполняет память при сбое связи. Игнорирование статусов доставки в реальном времени. Как повысить надежность отправки? Реализуйте схему с очередью сообщений, где каждый запрос сначала попадает в базу данных и только потом отправляется на шлюз. Это позволит системе автоматически повторить попытку, если первый запрос завершился ошибкой из-за кратковременного разрыва соединения. Если вы планируете масштабировать бизнес, полезно знать, как рассчитать стоимость SMS через SMPP, чтобы контролировать бюджет при росте нагрузки. Используйте качественные инструменты для взаимодействия с клиентами. Если вам требуется надежный сервис для массовой рассылки, можно рассмотреть возможности RocketSMS, который специализируется на транзакционном трафике. Правильная настройка взаимодействия с агрегатором позволит свести потери сообщений к минимуму и сделать коммуникацию с покупателями в Минске или других городах Беларуси предсказуемой. 3 шага, которые можно сделать сегодня для улучшения отправки: Включите детальное логирование ответов от SMPP-шлюза в вашей системе управления рассылками. Проверьте, настроена ли автоматическая повторная отправка для сообщений, которые получили статус временной ошибки. Проведите аудит API-ключей и лимитов нагрузки, чтобы убедиться, что они соответствуют текущему объему вашего трафика. > Source: https://smpp.by/kak-nastroit-otkazoustoychivuyu-otpravku-tranzaktsionnykh-sms --- # Почему важно настроить корректный Bind Transceiver в SMPP v3.4 Работа SMPP-шлюза в 2026 году требует особого внимания к этапу установления соединения. Процедура Bind Transceiver — это фундамент, который позволяет отправлять и принимать сообщения через один канал связи без постоянных разрывов. Если ваш сервер или клиент некорректно обрабатывает этот запрос, рассылки начинают зависать, сообщения дублируются или теряются в очереди из-за ошибок авторизации. Понимание того, как система реагирует на Bind Transceiver, помогает избежать простоев и обеспечить стабильную доставку SMS вашим клиентам в Беларуси, будь то уведомления из CRM или маркетинговые сообщения. Как работает сессия Bind Transceiver? Протокол SMPP версии 3.4 использует постоянное соединение. В отличие от HTTP-запросов, где каждое сообщение требует отдельного «рукопожатия», сессия Transceiver позволяет системе отправлять трафик и тут же получать отчеты о доставке через тот же канал. Когда шлюз инициирует соединение, он отправляет PDU-пакет с командой bind_transceiver. Сервер проверяет логин и пароль, после чего отправляет ответ bind_transceiver_resp. Пока сессия активна, соединение остается открытым. Любой сбой на этом этапе превращает работу в цепочку бесконечных переподключений, что резко снижает скорость отправки. Какие типичные ошибки при настройке Bind Transceiver встречаются? Даже опытные системные администраторы совершают пропуски при конфигурировании сессий. Ошибки чаще всего возникают при попытке объединить разные типы трафика в одну сессию или при игнорировании таймаутов. Попытка отправить сообщение при не завершенной до конца процедуре Bind. Отсутствие обработки ответа bind_transceiver_resp перед отправкой первого пакета submit_sm. Неправильная настройка параметров системы при обрыве соединения, когда клиент не пытается восстановить сессию автоматически. Использование разных системных ID для трансивер-сессии и отдельной приемной сессии, что запутывает логирование. Отсутствие проверки флагов ошибок в ответе сервера, из-за чего система «думает», что отправила SMS, хотя сессия была отклонена. Почему важно контролировать статус соединения? Стабильность SMPP напрямую зависит от мониторинга. Если шлюз не получает подтверждение сессии, он должен мгновенно сигнализировать об этом. Важно понимать, что протокол не всегда сообщает об ошибке явно, если вы не настроили логирование ответов. Когда соединение постоянно обрывается и восстанавливается, нагрузка на сервер возрастает, а сообщения застревают в памяти приложения. Для контроля этих процессов рекомендуем изучить настройку SMPP-шлюза для предотвращения дублей, так как повторные попытки отправки при разрывах — самая частая причина двойных SMS. Таблица сравнения режимов соединения Режим Описание Сфера применения Transmitter Только отправка Односторонние уведомления Receiver Только прием отчетов Сбор входящих данных Transceiver Отправка и прием Высоконагруженные рассылки Как оптимизировать работу шлюза в условиях нагрузки? Для бесперебойной работы важно не просто «подключиться», а настроить правильный обмен пакетами enquire_link. Этот пакет проверяет, жива ли сессия. Если провайдер не получает от вас отклик в течение заданного времени, он принудительно разрывает соединение. Настройка интервала для enquire_link помогает держать канал «горячим» и готовым к отправке любого объема сообщений. Если вы планируете масштабировать бизнес, полезно ознакомиться с тем, как связать CRM и SMPP для надежной автоматизации. В сложных случаях интеграции также может помочь настройка отправки из 1С через SMPP, чтобы исключить человеческий фактор при формировании пакетов. 3 шага, которые можно сделать сегодня для проверки стабильности: Проверьте логи на наличие регулярных ошибок при выполнении bind_transceiver_resp. Установите интервал для пакетов enquire_link, чтобы исключить таймауты со стороны провайдера. Убедитесь, что система имеет встроенный механизм автоматического переподключения (rebind) без участия оператора. Полезные ссылки: Руководство по протоколу SMPP для бизнеса. > Source: https://smpp.by/pochemu-vazhno-nastroit-korrektnyy-bind-transceiver-v-smpp-v3-4 --- # Метрики здоровья SMPP-сессии: как отслеживать задержки до появления жалоб клиентов Здоровая SMPP-сессия — это не только «соединение поднято», а стабильный ритм отправки, предсказуемые задержки и честные статусы доставки. В этой статье разберём, какие метрики снимать с SMPP-шлюза и API, на какие пороги реагировать до того, как клиенты заметят задержку, и как собрать минимальный дашборд для ежедневного контроля. Всё на практике: без модных терминов, с конкретными шагами и типичными граблями, на которые наступают при росте нагрузки. С чего начинается «здоровье» SMPP-сессии SMPP v3.4 держит постоянное TCP-соединение между клиентом и шлюзом. Пока идёт bind_transceiver, окно keepalive, и шлюз отвечает на enquire_link, кажется, что всё работает. Но реальная картина появляется только тогда, когда смотришь на метрики трафика: скорость отправки, скорость приёма DLR, доли таймаутов и реконнектов. Просто «связь жива» — это necessary, но не sufficient. На smpp.by техническая сторона протокола разобрана подробно, поэтому дальше сосредоточимся на операционных метриках. Их удобно делить на три слоя: канал (сеть), сессия (обмен PDU), бизнес-результат (доставлено/не доставлено). Каждый слой ловит свою категорию проблем, и только вместе они дают цельную картину. Какие задержки измерять и в каких единицах Задержка в SMPP — понятие многогранное, и путать их между собой — самая частая ошибка при настройке мониторинга. Фиксируйте хотя бы эти четыре: submit_sm latency — от момента формирования PDU клиентом до получения submit_sm_resp от шлюза. Это «время постановки в очередь». delivery latency end-to-end — от submit_sm_resp до DLR с финальным статусом DELIVERED. Это то, что видит клиент. enquire_link RTT — пинг-понг между клиентом и шлюзом. Рост RTT часто предшествует разрыву сессии. PDU processing time на стороне шлюза — берётся из логов провайдера или собирается через https://smpp.by/kak-ispolzovat-protokol-mcp-dlya-integratsii-llm-agentov-s-smpp-v-2026-godu, если используется прослойка MCP-агента. Снимайте p50, p95 и p99 для каждой метрики, а не только среднее. Среднее по доставкам в SMS-рассылках обманчиво: основная масса уходит за 2–3 секунды, но хвост из 1–2% «тяжёлых» сообщений тянет p99 в десятки секунд. Именно хвост рождает жалобы «у меня SMS опоздало на полчаса». Минимальный набор порогов: что считать нормой, а что — алертом Универсальных цифр нет: у каждого шлюза и оператора связи своя топология и своя нагрузка. Но ориентиры, от которых отталкиваются, выглядят так. Дальше их подстраивают под собственную историю наблюдений. МетрикаНорма (p95)Жёлтая зонаКрасная зона submit_sm_resp≤ 200 мс200–800 мс> 800 мс или рост в 2 раза за час delivery latency end-to-end≤ 10 с10–30 с> 30 с или растёт тренд за сутки enquire_link RTT≤ 1 с1–3 с> 3 с или таймауты Доля DLR UNDELIVERABLE≤ 2–3%3–7%> 7% или резкий скачок Реконнекты в час01–2> 3, особенно кластерами Жёлтая зона — это не «всё плохо», это «пора смотреть глазами»: открыть графики нагрузки, сверить с плановыми рассылками, проверить, нет ли массовой отправки на проблемный префикс. Красная зона — повод писать провайдеру, потому что вы уже на грани пользовательских жалоб. Как собирать метрики на практике: API vs SMPP-канал Если у вас классический HTTP API для отправки и отдельный SMPP-канал для bulk-рассылок, метрики лучше собирать в двух местах и сводить в один дашборд. Из HTTP API возьмите время ответа и HTTP-коды. Из SMPP — submit_sm_resp, DLR, enquire_link. Склейка по message_id позволяет видеть весь путь конкретного сообщения. Это сильно упрощает разбор спорных случаев, когда клиент говорит «не получил», а система показывает DELIVERED. Очередь сообщений и rate limit — отдельная история, и про неё подробно написано в материале https://smpp.by/kak-postroit-ochered-sms-v-api-i-smpp. Главное правило: метрики очереди (глубина, время ожидания, процент отброшенных) живут рядом с метриками SMPP, потому что рост очереди напрямую бьёт по delivery latency. Вы не поймёте, почему вырос p99, пока не положите рядом график глубины очереди. DLR и «ложные» DELIVERED: как не обмануться Статус DELIVERED в DLR означает, что оператор связи подтвердил доставку на устройство. Но бывают сценарии, когда DELIVERED приходит, а клиент SMS не видел. Причины — устаревший HLR-кэш, буферизация на старых моделях телефонов, ошибки абонентской базы, глюки конкретного оператора. Сами по себе такие случаи редки, но при большом потоке даже 0,5% превращаются в десятки жалоб в день. Что делать: заведите отдельную метрику «жалобы на неполученные» (из CRM, чатов, звонков) и сравнивайте её с долей DELIVERED. Если жалоб больше, чем 0,3–0,5% от доставленных, это повод проверить HLR-запросы и настройки маршрутизации. Дубли и повторные отправки, которые тоже бьют по доверию клиентов, разобраны в статье https://smpp.by/pochemu-sms-otpravlyaetsya-dvazhdy. Типичные ошибки при мониторинге SMPP-сессии Считать только среднюю задержку и не смотреть на p95/p99. Средняя «зелёная» при растущем хвосте — иллюзия стабильности. Мониторить только канал, забывая про очередь. Рост очереди на 2–3 часа до отправки легко превращает 5-секундный latency в 5-минутный. Алертить по абсолютным порогам без учёта тренда. Резкий рост метрики за час важнее, чем её текущее числовое значение. Смешивать технические и бизнес-метрики в одном графике без комментариев. Команда видит скачок UNDELIVERABLE, но не понимает, что в этот час была разовая рассылка на старые номера. Игнорировать enquire_link RTT. Рост пинга до шлюза обычно на 10–15 минут предшествует разрыву соединения. Не фиксировать версию конфигурации шлюза и ПО клиента. Без этого потом не восстановить, что именно сломалось. Что положить в дашборд и как часто на него смотреть Минимальный дашборд для ежедневной работы: 4 графика задержек (p50, p95, p99), 2 графика долей (UNDELIVERABLE, EXPIRED), 1 график глубины очереди и 1 — реконнектов. Частота просмотра: утром — сводка за ночь, днём — при плановых рассылках и после них, вечером — контрольный взгляд. Алерты в Telegram или e-mail настраивайте только на красную зону, иначе команда быстро начнёт их игнорировать. Если у вас несколько SMPP-подключений к разным провайдерам, полезно вывести сравнительный график: какой провайдер даёт стабильнее delivery latency на конкретном направлении. Это основа для перераспределения трафика и переговоров о ценах. Параллельно можно следить за стоимостью доставленного сообщения: когда p95 растёт, растёт и удельная стоимость, потому что вы платите и за ретраи, и за повторные отправки. Не забывайте про нагрузочное тестирование. Метрики «в продакшене» показывают текущее состояние, а понять предел пропускной способности до пиков можно только на стенде. Здесь пригодится отдельный материал про нагрузочное тестирование SMPP-интеграции. Без него вы узнаете о пределе в худший момент — в разгар распродажи, когда трафик упрётся в потолок. 3 шага, которые можно сделать на этой неделе: 1. Снять текущие p50/p95/p99 по submit_sm_resp и delivery latency за последние 7 дней и записать как baseline. 2. Настроить алерты на красную зону по таблице выше, вывести дашборд на экран команды. 3. Сопоставить долю жалоб «не получил» с долей DELIVERED и при расхождении проверить HLR и маршрутизацию. Полезные ссылки: подробнее про очередь и приоритеты — https://smpp.by/kak-postroit-ochered-sms-v-api-i-smpp, про дубли и защиту от них — https://smpp.by/pochemu-sms-otpravlyaetsya-dvazhdy, про интеграцию LLM-агентов через MCP и расширенный мониторинг — https://smpp.by/kak-ispolzovat-protokol-mcp-dlya-integratsii-llm-agentov-s-smpp-v-2026-godu, про контроль потерянных звонков при пиковых нагрузках — Callbacky. > Source: https://smpp.by/metriki-zdorovya-smpp-sessii --- # Как читать PDU-логи SMPP и находить узкое место доставки без коммерческого софта PDU-лог SMPP — это сырой поток байтов между вашей системой и шлюзом: submit_sm, deliver_sm, enquire_link, ответы с кодами состояния. Если его разобрать вручную, можно увидеть, где именно сообщения застревают — на стороне клиента, канала связи или SMS-центра оператора. Ниже — практический путь: какие поля смотреть, какие ответы читать и как по логам находить узкое место доставки без платных анализаторов. С чего начать разбор PDU-лога PDU (Protocol Data Unit) в SMPP — это пакет фиксированного формата с заголовком и набором полей. В логе он выглядит как hex-строка или текстовая строка с полями через разделитель. Для диагностики хватает знания о пяти-шести полях: command_id, command_status, sequence_number, source_addr, destination_addr, short_message. Первое, что стоит сделать, — собрать чистый лог за один тестовый прогон. Отправьте 50–100 тестовых сообщений на разные номера и запишите весь обмен в файл. Чем короче окно наблюдения, тем проще потом сопоставить отправку и ответ. Включите логирование на уровне библиотеки, через которую идёт SMPP-клиент. Сохраните обе стороны обмена: исходящие PDU и входящие ответы. Подпишите каждый пакет меткой времени с миллисекундами. Отфильтруйте шум: служебные enquire_link и unbind обычно не нужны для анализа доставки. Какие коды ответов говорят о проблеме Поле command_status в PDU — главный индикатор. Ноль означает, что шлюз принял сообщение. Любое другое значение — это код ошибки или статуса, описанный в SMPP-спецификации. Для диагностики узких мест в доставке полезно знать хотя бы базовые диапазоны: 0x00000000 — принято шлюзом, дальнейшая судьба сообщения зависит от DLR. 0x00000001–0x00000063 — системные ошибки отправителя или канала (таймаут сессии, переполнение окна). 0x00000008 — превышено значение throttling, то есть шлюз не успевает обрабатывать ваш поток. 0x0000000B — некорректный адрес назначения, отправка дальше не пойдёт. 0x00000014 — destination address blocked, отказ на уровне шлюза или оператора. Если в логе массово появляется ошибка 0x08 — узкое место в вашем собственном потоке, шлюз физически не успевает. Если 0x14 — узкое место на стороне оператора или фильтра шлюза. Если нули идут подряд, а DLR не приходят — ищите проблему между шлюзом и SMSC. Как читать тайминги в логе Время между submit_sm и ответом — это первая задержка, которую видно. Время между submit_sm и первым DLR — это сквозная задержка доставки. Если первая задержка растёт, узкое место в канале или шлюзе. Если первая маленькая, а сквозная большая — узкое место у оператора или SMSC. Практический приём: посчитайте разницу между timestamp отправки submit_sm и timestamp ответа submit_sm_resp с command_status = 0. Потом посчитайте разницу между submit_sm_resp и пришедшим deliver_sm с DLR. Первая разница покажет, как быстро шлюз забирает пакет. Вторая — как быстро оператор доставляет абоненту. Какие поля показывают, где именно застряло сообщение Поле PDUЧто показывает command_idТип пакета: submit_sm, deliver_sm, enquire_link command_statusКод ошибки или подтверждение sequence_numberСвязывает запрос и ответ между собой source_addr / destination_addrКто и кому, помогает фильтровать по базе registered_deliveryЗапрошены ли DLR и какие именно short_messageТекст, помогает найти конкретную отправку По sequence_number легко склеить submit_sm и его submit_sm_resp, а затем найти соответствующий deliver_sm. Когда склейка собрана, видно полную цепочку одного сообщения: отправка — приём шлюзом — DLR о доставке. Если цепочка обрывается на одном из шагов — узкое место найдено. Как связать лог с конкретной базой клиентов Самый простой способ — добавить в каждое сообщение короткий тег в начале или в конце текста. По нему в логе вы найдёте конкретное submit_sm и поймёте, к какой рассылке или сегменту базы относится задержка. Альтернатива — вставить идентификатор клиента в поле source_addr или использовать нестандартное TLV-поле, если ваш шлюз поддерживает расширенные опции. Подробнее о работе с DLR-отчётами и привязке недоставок к базе — в материале Как отладить SMPP-сессию и читать PDU-логи без сложных платформ. Если тег не нужен клиенту, его можно отрезать на уровне шлюза, но в логе он останется. Так вы получите и чистые сообщения, и привязку к базе для диагностики. Типичные ошибки при ручном разборе лога Игнорировать поле registered_delivery. Без него DLR не приходят, и вы будете считать, что доставки нет. Смотреть только command_status и забыть про тайминги. Одинаковый ноль в статусе не означает одинаковую скорость доставки. Анализировать лог за сутки и путать всплески трафика с системной проблемой. Не отделять enquire_link от submit_sm. Служебные пакеты забивают лог и мешают увидеть реальную картину. Записывать только исходящий трафик и терять ответы шлюза, по которым видна основная диагностика. Менять параметры канала во время теста и не отмечать это в логе — потом невозможно понять, что повлияло. Что делать, когда узкое место найдено Когда в логах видно конкретное место задержки, дальнейшие шаги зависят от того, где оно возникло. Если шлюз возвращает ошибки 0x08, нужно снизить скорость отправки или запросить увеличение лимита. Если DLR не приходят вообще, проверьте registered_delivery и поддержку DLR на стороне оператора. Если задержка между submit_sm_resp и deliver_sm большая при нормальных кодах — это особенность сети оператора, и повлиять на неё с вашей стороны сложно. Приоритезация транзакционного и маркетингового трафика на уровне шлюза помогает в моменты пик: коды авторизации и уведомления об операциях уходят первыми, рассылки ждут. Подробнее о настройке приоритетов — в материале Как настроить приоритет SMS-кодов в SMPP. 3 шага, которые можно сделать на этой неделе: Включить логирование обеих сторон SMPP-сессии с миллисекундными метками времени. Прогнать 50–100 тестовых сообщений и собрать сквозную цепочку submit_sm — submit_sm_resp — deliver_sm. Посчитать две задержки (до ответа шлюза и до DLR) и сравнить их по разным сегментам базы. > Source: https://smpp.by/kak-chitat-pdu-logi-smpp-i-nakhodit-uzkoe-mesto-dostavki-bez-kommercheskogo-softa --- # Как настроить приоритеты SMPP-трафика для ИИ-агентов? ИИ-агенты и автоматизированные системы генерации сообщений часто работают рывками. В отличие от ручной отправки, скрипт может мгновенно «выстрелить» тысячей запросов, что для стандартного SMPP-соединения выглядит как DDoS-атака или сбой. Если у вас нет системы управления очередями, часть сообщений будет отброшена оператором или попадет в «черную дыру» из-за превышения лимитов пропускной способности (TPS). Чтобы обеспечить доставку критически важных уведомлений, необходимо разделить потоки данных на логические уровни и настроить приоритеты на стороне вашего клиента. Почему ИИ-трафик перегружает шлюз Протокол SMPP работает по принципу сессий, где каждое сообщение требует ответа (submit_sm_resp). При использовании ИИ-агентов поток запросов становится непредсказуемым. Если ваш сервер отправляет сообщения быстрее, чем шлюз успевает их обрабатывать, возникает переполнение «окна» (window size). В этот момент соединение может зависнуть или разорваться. Главная проблема не в количестве сообщений в день, а в их количестве в секунду. Операторы связи ограничивают TPS для каждого подключения. Если ваш агент пытается пробить этот лимит, вы получаете ошибку «throttling» или «congestion». Чтобы оптимизировать процесс отправки, стоит прочитать про методы оптимизации стоимости и пропускной способности, которые помогают сбалансировать нагрузку без потери качества доставки. Как распределить приоритеты для SMPP-очереди Разделите сообщения на три уровня приоритета. Это защитит бизнес-процессы от задержек, вызванных менее важными рассылками. Реализуйте этот механизм на стороне вашего ПО, до того как пакет попадет в TCP-сокет. Тип сообщения Приоритет Поведение очереди OTP, 2FA, подтверждение оплаты Высокий Отправка без очереди, bypass других потоков Транзакционные уведомления Средний Очередь с лимитом TPS, постепенная отправка Маркетинг, напоминания, акции Низкий Отправка только в моменты простоя основных потоков Настройка очереди позволяет «придерживать» рекламные рассылки, если в этот момент система отправляет коды доступа. Если вы строите сложные сценарии взаимодействия, полезно изучить правила настройки SMS-цепочек, где приоритетность сообщений является ключевым фактором успеха. Типичные ошибки при настройке SMPP-шлюза **Игнорирование `enquire_link`**: Если не настроить этот параметр, сервер не узнает, что соединение «умерло», и продолжит слать данные в пустоту. **Работа в одну сессию**: Создание единственного подключения для всех типов задач. При сбое одного процесса блокируются все остальные. **Отсутствие лимитов на стороне клиента**: Попытка отправить весь массив данных сразу, без учета TPS-ограничений оператора. **Необработанные коды ошибок**: Система не понимает, что сообщение не ушло, и не предпринимает попыток повторной отправки (retry). **Отсутствие мониторинга**: Вы узнаете о перегрузке только от клиентов, которые жалуются на отсутствие SMS, а не из логов системы. Как проверить готовность системы к нагрузкам Перед запуском ИИ-агента в продакшн проведите нагрузочное тестирование. Создайте скрипт, который имитирует всплеск активности, и посмотрите, как система справляется с очередями. Важно замерить не только общую скорость отправки, но и время доставки от момента генерации сообщения до получения delivery report. Если вы интегрируете рассылки в учетные системы, уделите внимание тому, как данные покидают сервер. Например, при работе с 1С процесс часто требует специфической настройки SMPP-шлюза для корректной обработки тяжелых пакетов данных. Убедитесь, что логирование ошибок включено: каждый отказ шлюза (nack) должен фиксироваться с кодом причины, чтобы вы могли понять, упираетесь ли вы в TPS или проблема в неверном формате номера. 3 шага, которые помогут настроить стабильную отправку уже на этой неделе: Проанализируйте логи за последний месяц: найдите периоды максимальной нагрузки и сопоставьте их с ошибками «throttling» или «connection lost». Внедрите менеджер очередей в программный код: настройте приоритизацию, чтобы транзакционные сообщения уходили первыми. Установите лимиты TPS в настройках клиента, соответствующие тарифам вашего провайдера, чтобы исключить риск принудительного разрыва сессии с его стороны. > Source: https://smpp.by/kak-nastroit-prioritety-smpp-trafika-dlya-ii-agentov --- # Как использовать протокол MCP для интеграции LLM-агентов с SMPP в 2026 году В 2026 году интеграция искусственного интеллекта с каналами связи стала стандартом автоматизации бизнес-процессов. Протокол MCP (Model Context Protocol) позволяет связывать большие языковые модели напрямую с внешними системами без разработки сложных программных прослоек. В этой статье вы узнаете, как использовать MCP для прямого подключения умных ИИ-агентов к производительному SMPP-шлюзу, чтобы нейросеть могла самостоятельно отправлять триггерные сообщения, проверять статусы доставки и поддерживать стабильное соединение с SMS-центром оператора. Что такое протокол MCP и почему его связывают с SMPP? Протокол MCP — это открытый стандарт взаимодействия между языковыми моделями (LLM) и внешними источниками данных или инструментами. Раньше для отправки сообщений роботу требовалось обращаться к промежуточному API, парсить ответы и вручную обрабатывать ошибки. Теперь ИИ-агент использует стандартные методы MCP для прямой отправки команд во внешние шлюзы. Когда дело касается высоких нагрузок и больших объемов отправки, обычные HTTP-запросы создают избыточную нагрузку на сервера. Здесь на сцену выходит протокол SMPP (Short Message Peer-to-Peer). Это промышленный стандарт, который базируется на двоичном формате сообщений, что существенно снижает нагрузку на канал передачи данных и ускоряет обработку запросов (по данным Exolve). Связка MCP и SMPP позволяет ИИ-агенту отправлять тысячи сервисных уведомлений в секунду с минимальной сетевой задержкой. Как устроен процесс передачи сообщений от нейросети в SMS-центр? Интеграция строится на трех звеньях: языковая модель, MCP-сервер и SMPP-клиент. Нейросеть генерирует текст сообщения и решает, кому и когда его отправить. Она передает эти данные MCP-серверу через стандартизированный JSON-интерфейс. MCP-сервер выступает переводчиком: он принимает запрос и преобразует его в бинарный формат, который понимает SMS-центр (SMSC). Через качественный SMS-шлюз по протоколу SMPP версии 3.4 можно отправлять не только обычные текстовые сообщения. Разработчикам доступна отправка различных видов трафика: MMS, HLR-запросы для проверки активности номеров в реальном времени, Ping-SMS и голосовые сообщения (по данным SMSC). Это дает умному агенту полноценный набор инструментов для коммуникации с клиентами. Для экономии бюджета при отправке длинных сообщений важно правильно настроить склейку частей. Если текст превышает стандартный лимит одного SMS, сообщение делится на несколько сегментов. Отправляющая сторона обязательно должна добавлять в заголовки UDH (User Data Header) или SAR параметры (по данным МТС Поддержка). Без этих параметров телефон получателя не сможет правильно собрать части воедино, и клиент получит обрывки фраз вместо связного текста. При интеграции критически важно отслеживать доставку сообщений на стороне ИИ-агента, чтобы модель знала, дошел ли важный код подтверждения до адресата. Детально о механизмах возврата статусов и работе с повторными отправками читайте в руководстве о том, как отправлять SMS о доставке через SMPP. Почему для интеграции ИИ-агентов выбирают SMPP, а не обычный HTTP? При выборе протокола для высоконагруженных систем разработчики часто колеблются между простым REST API и специализированным SMPP. Для простых разовых уведомлений возможностей API вполне достаточно. Однако, если ваш умный помощник должен обрабатывать поток сервисных сообщений для тысяч клиентов одновременно, бинарный протокол показывает себя гораздо эффективнее. Параметр сравнения Классический HTTP API SMPP (через MCP-сервер) Формат передачи данных Текстовый (JSON/XML), высокий оверхед Двоичный (бинарный), минимальный размер пакета Скорость обработки сообщений Средняя (зависит от оверхеда HTTP-сессии) Максимальная (постоянное TCP-соединение) Поддержание сессии Каждый запрос открывает новое соединение Постоянная активная сессия с проверкой связи Поддерживаемые типы трафика Преимущественно текстовые SMS SMS, MMS, HLR, Ping-SMS, USSD Высокая производительность SMPP объясняется его структурой. В отличие от текстового протокола HTTP, где каждая команда передается в виде громоздких текстовых заголовков и тела (часто в кодировке UTF-8, раздувающей объем данных), SMPP упаковывает всю системную информацию в компактные пакеты PDU (Protocol Data Units) фиксированной длины. Это снижает требования к пропускной способности интернет-канала и позволяет серверу обрабатывать сотни транзакций в секунду без задержек. Пошаговый алгоритм настройки стабильного SMPP-соединения Для стабильной работы интеграции недостаточно просто отправлять пакеты данных по мере их генерации нейросетью. SMPP требует постоянного контроля состояния сессии. Если ИИ-агент долго «думает» или на платформе временно нет активного трафика, принимающая сторона может разорвать соединение. При инициации сессии MCP-сервер должен отправить запрос на авторизацию (Bind). В зависимости от ваших задач выбирается тип подключения: передатчик (transmitter), приемник (receiver) или универсальный трансивер (transceiver). Трансивер удобен тем, что позволяет одновременно отправлять SMS-сообщения от ИИ и получать входящие ответы или отчеты о доставке (DLR) в рамках одной TCP-сессии. Настройка параметров подключения включает указание IP-адреса, порта, системного идентификатора (System ID) и пароля (по данным TargetSMS). Чтобы избежать внезапных обрывов связи, клиентское оборудование должно регулярно отправлять проверочные PDU-пакеты. Спецификация требует отправлять запрос enquire_link каждые 30 секунд, независимо от наличия или отсутствия реального трафика в канале (по данным МТС Поддержка). Если сервер не получит этот пакет в установленный интервал, он посчитает сессию неактивной и закроет порт. При развертывании MCP-сервера для автоматизации полезно заранее продумать архитектуру очередей. ИИ-агенты генерируют запросы неравномерно. Чтобы не перегрузить каналы операторов связи и избежать блокировок, на уровне MCP-сервера настраивается буферизация. Для локальных нужд бизнеса, таких как отправка коротких сервисных ссылок в сообщениях, разработчики часто используют надежные белорусские сервисы сокращения, например 8s.by, что помогает экономить символы в сегментах SMS. Типичные технические ошибки при интеграции При создании связки между искусственным интеллектом и SMS-шлюзом разработчики часто сталкиваются с типовыми проблемами проектирования. Большинство из них связаны с непониманием специфики телеком-протоколов. Отсутствие фоновой отправки пингов enquire_link, приводящее к регулярному закрытию сокетов со стороны SMS-центра. Игнорирование ограничений на пропускную способность (TPS) — нейросеть пытается выдать всю очередь сообщений одновременно, вызывая временную блокировку со стороны шлюза. Некорректная обработка многосегментных SMS, из-за чего длинные сообщения приходят клиентам в виде разрозненного набора символов. Отсутствие таймаутов на чтение сокета, что приводит к зависанию процессов MCP-сервера при сетевых сбоях. Попытка массовой отправки сообщений на неактивные номера без предварительной HLR-валидации базы. Для минимизации этих рисков рекомендуется использовать проверенные технические библиотеки и строго следовать официальной технической документации по интеграции (как в инструкциях Devino и TargetSMS). Если вы хотите построить не просто систему разовых уведомлений, а полноценную логику автоматических рассылок на базе ИИ, полезно изучить лучшие практики настройки сценариев. Подробнее о проектировании таких решений читайте в материале про то, как настроить SMS-цепочку через SMPP для малого бизнеса. 3 шага, которые помогут запустить интеграцию ИИ-агента с SMS-шлюзом уже на этой неделе: Получите тестовые доступы у вашего SMS-провайдера (System ID, пароль, IP-адрес шлюза, порт) и согласуйте альфанумерическое имя отправителя. Разверните легковесный MCP-сервер на базе Node.js или Python, реализующий методы отправки сообщений и фоновую отправку enquire_link каждые 30 секунд для удержания сессии. Протестируйте отправку длинных сообщений с поддержкой UDH-параметров на контрольную группу номеров, чтобы убедиться в корректной склейке текста на смартфонах пользователей. > Source: https://smpp.by/kak-ispolzovat-protokol-mcp-dlya-integratsii-llm-agentov-s-smpp-v-2026-godu --- # Как отладить SMPP-сессию и читать PDU-логи без сложных платформ? Разработчику в малом бизнесе не нужны дорогие enterprise-системы для отладки SMS-рассылок. Настроить стабильное SMPP-соединение и научиться самостоятельно читать PDU-логи можно с помощью простых бесплатных утилит и базовых библиотек. В этой статье мы разберем, как устроена сессия изнутри, как перехватывать и расшифровывать пакеты данных (PDU), контролировать статусы доставки и быстро находить причины обрывов связи без покупки тяжелого софта. Что происходит внутри SMPP-сессии? При использовании обычного HTTP API на каждый запрос тратится время на установку TCP-соединения и TLS-рукопожатие. Для отправки нескольких сообщений в секунду это терпимо, но если нужно регулярно отправлять сервисные уведомления или коды авторизации, HTTP начинает расходовать слишком много ресурсов сервера. SMPP работает как длительная протокольная сессия по TCP-соединению (код источника: quicktel.ru). В отличие от веб-запросов, здесь клиент (в терминологии протокола — ESME) один раз устанавливает связь со шлюзом провайдера и проходит авторизацию с помощью команды bind. После этого канал остается открытым. Все данные передаются в виде бинарных пакетов — PDU (Protocol Data Unit), а ответы и отчеты о доставке (Delivery Receipt) возвращаются через это же подключение (код источника: quicktel.ru). Существует три формы инициированной сессии (код источника: sms.su): Transmitter (передатчик) — используется только для отправки сообщений в сторону шлюза. Receiver (приемник) — служит только для получения входящих сообщений и отчетов о доставке. Transceiver (приемопередатчик) — универсальный режим, позволяющий одновременно отправлять и принимать данные в обе стороны. Для небольшого интернет-магазина или сервиса в Минске или Могилеве обычно выбирают режим Transceiver. Он позволяет обойтись одним открытым сокетом, что сильно упрощает код и снижает нагрузку на сервер разработки. Как настроить окружение для дебага на локальной машине? Прежде чем писать код интеграции, нужно настроить параметры на стороне SMS-провайдера. Для этого перейдите в личный кабинет. Интерфейсы у всех разные, но суть одна: вам нужно найти раздел настроек SMPP. Например, в зависимости от платформы, нужные опции находятся в меню вроде «Мои настройки / Персональные настройки / SMPP подключение» (код источника: sms-assistent.by) или «Настройки / SMPP» (код источника: redsms.ru). В этом разделе задаются произвольные логин и пароль, которые вы будете использовать для подключения (код источника: redsms.ru). Также обязательно укажите IP-адрес вашего сервера — большинство шлюзов блокируют любые попытки авторизации с неизвестных хостов ради безопасности. Соединение часто осуществляется через интернет. По умолчанию протокол SMPP использует стандартный TCP-порт, зарегистрированный в IANA, но агрегаторы могут выделять и другие порты для разных типов трафика или клиентов (код источника: sms.su). Для защиты конфиденциальной информации — ведь в сообщениях могут передаваться одноразовые пароли или персональные данные клиентов — настоятельно рекомендуется использовать шифрование SMPP через TLS или организовывать защищенное VPN-соединение (код источника: sms.su). Для локальной отладки вам понадобятся: Локальный симулятор SMPP-сервера (например, SMSC Simulator на Java или Node.js). Он имитирует работу реального шлюза провайдера, позволяя бесплатно тестировать отправку. Сетевой анализатор Wireshark для перехвата трафика. Простой скрипт-клиент на вашем языке программирования для отправки тестовых пакетов. Как читать PDU-логи и расшифровывать ошибки? Каждое действие в протоколе SMPP — это отправка структуры, которая называется PDU. Пакет состоит из заголовка (header) размером 16 байт и тела (body). В заголовке всегда передаются четыре важных поля: длина пакета, ID команды, статус команды (код ошибки) и порядковый номер (Sequence Number). Порядковый номер — это важнейший элемент для отладки асинхронных систем. Когда ваше приложение отправляет пакет, сервер обрабатывает его и возвращает ответ именно с этим номером. Так ваш код понимает, на какое конкретно сообщение пришел ответ, даже если они отправлялись параллельно. Давайте посмотрим на основные команды, с которыми вы столкнетесь при анализе логов: Команда (Command ID) Направление Что означает bind_transceiver Клиент → Сервер Запрос на открытие двусторонней сессии bind_transceiver_resp Сервер → Клиент Ответ на авторизацию (статус 0x00000000 означает успех) submit_sm Клиент → Сервер Отправка одного SMS-сообщения submit_sm_resp Сервер → Клиент Подтверждение приема сообщения с ID сообщения от шлюза deliver_sm Сервер → Клиент Передача входящего сообщения или отчета о доставке (DLR) enquire_link Клиент ⇄ Сервер Проверка активности соединения (аналог пинга) Если вы настраиваете интеграцию с внутренними учетными системами компании, например, хотите отправлять уведомления прямо из товароучетной программы, базовые принципы работы с сокетами остаются теми же. Подробнее о технической стороне этого процесса можно прочитать в статье о том, как настроить отправку SMS из 1С через SMPP-шлюз. Инструменты для перехвата и анализа трафика Если вы используете готовую библиотеку для своего языка программирования, обязательно включите максимальный уровень логирования (DEBUG). В логах вы увидите текстовое представление отправляемых байт. Но самый наглядный способ понять, что идет не так — использовать Wireshark. Это бесплатный инструмент для анализа сетевых пакетов, который умеет парсить протокол SMPP без дополнительных плагинов. Достаточно запустить его на сервере разработки или локальной машине, выбрать рабочий сетевой интерфейс и применить фильтр smpp. Wireshark автоматически разложит бинарный поток на понятные составляющие. Вы сможете раскрыть любой пакет и увидеть все его параметры: от типа кодировки до текста СМС и уникального идентификатора сообщения, который присвоил сервер. Это избавляет от необходимости вручную разбирать шестнадцатеричные дампы. Для автоматического контроля за состоянием подключения в продакшене ручной анализ в Wireshark > Source: https://smpp.by/kak-otladit-smpp-sessiyu-i-chitat-pdu-logi-bez-slozhnykh-platform --- # Как настроить обработку DLR-статусов SMS без перегрузки CRM Чтобы обрабатывать DLR-статусы доставки SMS без риска уронить CRM-систему во время массовых рассылок, откажитесь от синхронного приема вебхуков напрямую в базу данных. Оптимальная схема включает промежуточный легковесный буфер (брокер сообщений или очередь задач) между SMS-шлюзом и вашей CRM. Шлюз отправляет вебхук о смене статуса, сервер-приемник моментально отвечает кодом 200 OK и складывает событие в очередь, а фоновый воркер порционно обновляет карточки клиентов. В этой статье вы узнаете, как шаг за шагом настроить такую связку и сохранить стабильность системы. Почему прямая отправка DLR в CRM перегружает сервер? Когда бизнес запускает сервисную или маркетинговую рассылку на несколько тысяч клиентов, ответы от мобильных операторов начинают возвращаться практически одновременно. Отчет о доставке (Delivery Receipt или DLR) генерируется сетью оператора в момент изменения статуса сообщения: отправлено, доставлено абоненту, просрочено или отклонено. Если на каждую смену статуса SMS-шлюз дергает тяжелый эндпоинт CRM, в базе данных возникает лавина блокировок строк и таблиц. Большинство типовых CRM не рассчитаны на сотни входящих HTTP-запросов в секунду. Каждый такой запрос инициирует авторизацию, поиск сущности по номеру телефона или ID сообщения, проверку триггеров и запись в журнал. При пиковых нагрузках процессор сервера загружается до предела, пул соединений с базой данных исчерпывается, а менеджеры компании теряют возможность нормально открывать сделки и принимать звонки. Чтобы этого избежать, полезно разобрать, как настроить интеграцию CRM и SMPP для SMS-уведомлений с учетом ограничений корпоративного сервера. Как устроена правильная асинхронная архитектура обработки? Решение проблемы заключается в разделении двух процессов: быстрого подтверждения приема статуса от шлюза и отложенного обновления данных внутри CRM. Для этого между шлюзом и CRM размещают буферный микросервис. Схема взаимодействия состоит из трех последовательных шагов: Прием вебхука: Минималистичный веб-сервер принимает POST-запрос от провайдера, валидирует входящий payload (ID сообщения, статус, время события) и без обращения к основной базе сразу помещает JSON в очередь. Клиенту мгновенно возвращается ответ HTTP 200 OK. Буферизация: В качестве очереди задач используют Redis, RabbitMQ или PostgreSQL с быстрой вставкой. Очередь накапливает тысячи DLR-пакетов, выступая амортизатором при резких всплесках трафика. Фоновая обработка (воркеры): Отдельный фоновый скрипт забирает данные из очереди фиксированными пачками (батчами) и обновляет статусы в CRM с той скоростью, с которой система способна их переварить без задержек для пользователей. Если бизнес отправляет сервисные оповещения, например в сфере услуг, такой подход гарантирует непрерывность рабочих процессов. О том, как это работает на практике, мы подробно описывали в материале про то, как настроить SMPP-шлюз для статусов ремонта с DLR. Сравнение методов получения статусов доставки Выбор способа передачи DLR зависит от объема рассылок и архитектуры вашего программного обеспечения. В таблице ниже сопоставлены три основных подхода к синхронизации статусов. Метод интеграции Нагрузка на CRM Сложность настройки Скорость обновления Устойчивость к сбоям Периодический опрос (Polling через REST API) Высокая постоянная нагрузка Низкая Медленно (задержка до нескольких минут) Средняя Прямой вебхук в CRM без буфера Критические пиковые перегрузки Средняя Мгновенно Низкая (риск потери части пакетов) Асинхронные вебхуки через очередь задач Равномерная контролируемая нагрузка Средняя Секунды (по мере разбора очереди) Высокая На какие параметры шлюза и сессии обратить внимание? При настройке шлюза важно учитывать пропускную способность соединения (TPS — Transactions Per Second) и размер окна передачи (window size). Протокол SMPP версии 3.4 работает поверх TCP и позволяет отправлять сообщения и получать статусы в асинхронном режиме в рамках одной сессии (Хабр, 2024). Техническая команда со стороны провайдера контролирует состояние сессии, время ответа и отказы, сопоставляя принятые сообщения с итоговыми статусами доставки (Altcraft, 2024). Если ваш транспортный уровень упирается в лимиты HTTP-запросов, переход на бинарный протокол обеспечивает более стабильное управление потоком данных (QUICKTEL, 2024). Для отправки цепочек триггерных сообщений важно заранее согласовать с поставщиком достаточный TPS, чтобы DLR-отчеты возвращались без искусственных задержек на стороне операторских шлюзов. Подробнее об этом читайте в руководстве о том, как настроить SMS-цепочку через SMPP для малого бизнеса. Типичные ошибки при обработке DLR-отчетов Даже при использовании очередей инженеры нередко допускают архитектурные просчеты, которые приводят к рассинхронизации статусов или зависанию воркеров: Отсутствие идемпотентности обработчика: Оператор или шлюз могут повторно отправить один и тот же статус DLR из-за сетевого таймаута. Если обработчик не проверяет, был ли этот статус уже записан, в CRM могут повторно сработать триггерные действия. Блокировка потока долгим ответом вебхука: Если приемник вебхука тратит более 1–2 секунд на ответ, шлюз считает запрос неудавшимся и начинает повторять отправку, создавая лавинообразную перегрузку. Игнорирование промежуточных статусов: Сообщение проходит несколько состояний (ENROUTE, DELIVRD, EXPIRED, UNDELIV). Если перезаписывать финальный статус более ранним из-за рассинхронизации очереди по времени, данные в CRM станут неверными. Отсутствие механизма Dead Letter Queue (DLQ): Ошибочные пакеты с поврежденным телом запроса не должны блокировать всю очередь; их необходимо перемещать в отдельный список для ручного анализа. 3 шага, которые стоит сделать для запуска асинхронной обработки DLR: Создать отдельный легковесный эндпоинт, который валидирует входящие вебхуки от SMS-шлюза и сразу возвращает статус 200 OK. Подключить Redis или RabbitMQ для временного хранения входящих DLR-пакетов в виде очереди задач. Настроить фоновый воркер, который считывает события пачками по 50–100 записей и обновляет базу данных CRM с фиксированным интервалом. > Source: https://smpp.by/kak-nastroit-obrabotku-dlr-statusov-sms-bez-peregruzki-crm --- # Как снизить стоимость SMS через SMPP без потери доставки Стоимость SMS-рассылки снижается прежде всего на уровне настроек: кодировка определяет число символов в сегменте, конкатенация влияет на количество оплачиваемых частей, а DLR показывает реальный результат доставки. В статье разберём пять параметров SMPP, которые полезно проверить малому бизнесу в Беларуси. После настройки вы сможете точнее считать расходы в BYN, убрать лишние повторы и оставить контроль над недоставленными сообщениями. Из чего складывается стоимость SMS-рассылки? Итоговая сумма зависит от тарифа оператора или агрегатора, комиссии шлюза и дополнительных надбавок. На практике к этому добавляется число SMS-сегментов: одно длинное сообщение может тарифицироваться как несколько частей. Поэтому цена текста из 90 кириллических знаков и цена короткой фразы на латинице рассчитываются по-разному. В обзоре тарифов на 2026 год встречается диапазон от 0,01 ₽ до 0,03 ₽ за сообщение. Это ориентир из зарубежного сравнения, а не готовый тариф для Беларуси: при расчётах для бизнеса в Минске, Гомеле или другом городе нужно смотреть цену конкретного маршрута в белорусских рублях (IBZ Source: «Сравнение тарифов операторов для SMS-рассылок: выгодные предложения 2026»). ПараметрЧто меняетсяЧто проверить Кодировка Максимальная длина одного сегмента Используется ли GSM-7 или Unicode Конкатенация Количество частей длинного SMS Учитываются ли UDH-заголовки и порядок частей DLR Видимость статуса доставки Приходит ли отчёт с понятным идентификатором сообщения Rate limit Скорость отправки Соответствует ли поток ограничениям шлюза Повторная отправка Число дополнительных попыток Какие статусы запускают retry и сколько раз Как кодировка влияет на число SMS-сегментов? Для GSM-7 обычно используют до 160 знаков в одном SMS. При Unicode, куда попадает кириллица и многие специальные символы, лимит составляет до 70 знаков. В составном сообщении доступный объём каждой части уменьшается, поскольку система добавляет служебные данные для сборки текста на телефоне получателя (IBZ Source: «Оптимизация контента для SMS: длина, структура и призыв к действию»). Проверьте, как приложение формирует поле data_coding. Если бизнес отправляет текст на русском языке, принудительное переключение на GSM-7 не решит задачу: неподдерживаемые символы исказят сообщение. Зато можно убрать эмодзи, нестандартные кавычки, длинное тире и декоративные символы, если они не нужны клиенту. Перед запуском рассылки отправьте тестовые варианты на несколько устройств. В отчёте сравните текст, кодировку и число сегментов. Для регулярных уведомлений полезно завести шаблоны с ограниченной длиной: например, отдельно хранить короткий текст для статуса заказа и более подробный вариант для редкого информационного сообщения. Как настроить конкатенацию в SMPP? Конкатенация нужна, когда текст не помещается в один сегмент. Шлюз делит сообщение на части, добавляет служебный заголовок и передаёт их оператору. Телефон собирает части по ссылочному номеру. Если приложение само делит текст, а шлюз делает это повторно, клиент может получить дубликаты или несколько отдельных SMS. Выберите один уровень разбиения. Для интеграции через SMPP зафиксируйте правило: приложение передаёт готовые сегменты либо отправляет полный текст, а шлюз выполняет разбиение. После этого проверьте три поля в журнале: идентификатор сообщения, номер части и общее количество частей. В очереди храните связь между исходным текстом и всеми сегментами. Если одна часть получила ошибку, система должна показать её отдельно. Повторная отправка всего составного сообщения увеличивает расходы и создаёт риск повторного показа уже доставленных частей. Зачем нужен DLR и как он помогает экономить? DLR, или отчёт о состоянии доставки, возвращает результат обработки SMS: сообщение принято, доставлено, отклонено или завершилось ошибкой. Сам факт отправки по SMPP не означает, что клиент получил текст. Без DLR бизнес видит только очередь исходящих сообщений и не может отделить доставленные SMS от проблемных. Настройте сохранение message_id из ответа шлюза и свяжите его с заказом, клиентом или событием в вашей системе. Отдельно разберите статусы, которые означают временную ошибку, и статусы, после которых повторять отправку бессмысленно. Такой подход сокращает автоматические повторы и показывает, на каком участке возникла проблема. Для контроля используйте отчёт по четырём показателям: отправлено, доставлено, отклонено и повторено. Если нужен отдельный разбор статусов и автоматизации, пригодится материал как автоматизировать SMS-статусы доставки. Какие ещё настройки SMPP уменьшают лишние отправки? Ограничение скорости Rate limit задаёт допустимое число сообщений в секунду. Слишком быстрый поток вызывает ответы об ограничении или перегружает очередь. Слишком медленный поток растягивает кампанию и задерживает сервисные уведомления. Начните с лимита, который указан в параметрах подключения, затем сравните скорость очереди с фактическими DLR. Повторные попытки Retry нужен для временных сбоев сети или шлюза. Его нельзя запускать на любой отрицательный статус. Задайте ограниченное число попыток, интервал между ними и список статусов, которые разрешают повтор. В журнале должна оставаться причина каждой новой отправки. Приоритеты очереди Сервисное SMS о коде или заказе не стоит ставить в одну очередь с рекламной кампанией. Разделите потоки по приоритету. При пиковой нагрузке транзакционные сообщения пройдут первыми, а массовая рассылка продолжится после освобождения лимита. Принцип очередей и rate limit разобран в материале как построить очередь SMS в API и SMPP. Типичные ошибки при экономии на SMPP Убирают кириллицу из текста, но не проверяют отображение сообщения на телефоне получателя. Передают длинный текст в шлюз, который уже получил от приложения готовые сегменты. Считают принятие сообщения шлюзом подтверждением доставки. Повторяют отправку после каждого отрицательного ответа, включая постоянные ошибки. Запускают рекламный поток без ограничения скорости и получают задержку сервисных SMS. Сравнивают только цену одного SMS и не учитывают сегментацию, DLR и плату за дополнительные маршруты. Для малого бизнеса в Беларуси практичная последовательность выглядит так: Проверьте кодировку и длину шаблонов, затем посчитайте фактическое число сегментов. Настройте конкатенацию на одном уровне и сохраните связь между message_id и событием в системе. Разделите очереди по приоритету, ограничьте повторы и сверяйте расходы с отчётами DLR. Если отправка идёт через CRM или интернет-магазин, сначала описывают события и статусы, затем выбирают API или SMPP. Для больших объёмов и собственного контроля полезно заранее определить формат DLR, лимиты, правила повторов и обработку составных сообщений. Такой перечень можно использовать как техническое задание для настройки SMPP-шлюза и API-интеграции на площадке smpp.by. > Source: https://smpp.by/kak-snizit-stoimost-sms-cherez-smpp-bez-poteri-dostavki --- # Как настроить алерты о сбоях SMPP в Telegram в 2026 году Автоматические алерты о сбоях SMPP помогают быстро заметить проблему с соединением, ростом ошибок или доставкой SMS. Для этого нужны регулярная проверка состояния SMPP-сессии, обработка DLR-отчётов, вебхук и правило эскалации в Telegram. В статье разберём архитектуру такой схемы, набор событий для уведомлений и порядок запуска. В результате владелец бизнеса или технический специалист сможет отделить кратковременный сетевой сбой от ситуации, которая уже влияет на сервисные сообщения клиентам. Какие события нужно отслеживать в SMPP-интеграции? Мониторинг начинается с перечня событий. Одного признака «соединение открыто» мало: TCP-сессия может сохраняться, пока сообщения не проходят через шлюз или не возвращаются итоговые статусы. Поэтому система наблюдения должна собирать технические сигналы и связывать их с результатом отправки. потеря SMPP-сессии или повторное подключение; отсутствие ответов на enquire_link; ошибка bind, неверные учётные данные или отказ по IP; превышение лимита отправки, окна запросов или очереди; рост отрицательных ответов submit_sm; отсутствие DLR за заданный интервал; увеличение доли недоставленных SMS по сравнению с обычным уровнем; зависшие сообщения, для которых система не получила финальный статус. Для каждого события задайте уровень важности. Например, единичный повторный bind можно записать в журнал, а несколько разрывов подряд отправить ответственному сотруднику. Отдельный уровень нужен для ситуации, когда SMS приняты шлюзом, но DLR долго не приходит. Сам факт принятия сообщения шлюзом ещё не подтверждает доставку получателю: SMS проходит маршрутизацию через мобильную сеть, после чего приходит итоговый статус. При проектировании полезно заранее описать допустимую задержку для каждого типа сообщения. Для кода подтверждения и уведомления о срочной заявке интервал будет коротким. Для плановой информационной отправки он может быть больше. Такой подход снижает число бесполезных тревог и помогает правильно расставить приоритеты. Как связать SMPP, DLR, вебхук и Telegram? Рабочая схема обычно состоит из четырёх частей: SMPP-шлюза, сервиса мониторинга, обработчика вебхуков и Telegram-чата для уведомлений. SMPP-шлюз принимает сообщения и возвращает ответы, сервис мониторинга проверяет соединение и собирает события, а вебхук передаёт подготовленное уведомление в нужный канал. Сервис открывает SMPP-сессию и проверяет bind. Периодически отправляется enquire_link, чтобы подтвердить, что соединение отвечает. Каждому сообщению присваивается внутренний идентификатор. Ответ submit_sm сохраняется отдельно от DLR. При поступлении DLR система сопоставляет его с исходным идентификатором. При нарушении правила мониторинг формирует событие и передаёт его вебхуку. Обработчик вебхука отправляет сообщение в Telegram с уровнем критичности. В уведомлении лучше сразу показывать контекст: время, тип события, идентификатор SMPP-сессии, код ошибки, очередь и последнюю известную причину. Если проблема связана с конкретным трафиком, добавьте направление или внутренний код кампании. Номер получателя целиком для алерта обычно не нужен: достаточно технического идентификатора и сведений, которые помогают найти запись в журнале. При разрыве сети сервис должен закрыть старое соединение, выдержать заданную паузу и повторить подключение. Интервал повторов лучше увеличивать после каждой неудачи, чтобы не создавать поток бесполезных запросов. После успешного bind система отправляет отдельное событие о восстановлении, иначе оператор будет видеть только начало аварии. Практические детали поддержки соединения и повторного подключения разобраны в материале как поддерживать SMPP-сессию при сбоях сети. Для владельца небольшого бизнеса это полезно даже без глубокого знания протокола: по статье можно проверить, предусмотрено ли восстановление в текущей интеграции. Как использовать DLR, чтобы отличить сбой отправки от сбоя доставки? Система должна разделять как минимум три состояния: запрос ещё не принят шлюзом, сообщение принято в обработку и SMS получила итоговый статус. Если объединить их в один показатель, оператор не поймёт, где возникла проблема: в приложении, SMPP-соединении, маршрутизации или мобильной сети. Состояние Что означает Какой алерт отправлять Ошибка submit_sm Шлюз отклонил запрос или не принял его в обработку Срочный алерт при серии ошибок Принято шлюзом Сообщение передано на дальнейшую обработку Обычно запись в журнал Delivered Получен статус доставки Алерт не нужен Failed или недоставлено Сеть не доставила сообщение Алерт при росте доли таких статусов Нет DLR Итоговый статус не пришёл в установленный срок Предупреждение или срочный алерт по приоритетному трафику Порог для уведомления выбирайте по типу нагрузки. Единичная ошибка в длинной очереди не всегда требует вмешательства. Серия одинаковых кодов, повторяющаяся на протяжении нескольких интервалов, уже указывает на проблему, которую нужно проверить. Для сравнения полезно хранить историю статусов и смотреть изменения по часам, маршрутам и типам сообщений. Отдельно контролируйте задержку между submit_sm и DLR. Если запросы принимаются, но статусы приходят с заметным опозданием, причиной может быть перегрузка очереди или изменение маршрутизации. Аналитика трафика должна показывать не только количество отправленных SMS, но и распределение финальных статусов. Как построить эскалацию, чтобы Telegram не превратился в поток тревог? Алерт полезен тогда, когда из него понятны действие и срок реакции. Сообщение «SMPP error» почти ничего не даёт. Лучше использовать короткий шаблон: «Критично: bind не восстановлен, 4 попытки, очередь 126 сообщений, последняя ошибка — код шлюза, время — 14:35». Информационный уровень. Сессия восстановилась, очередь сократилась, DLR снова поступают. Предупреждение. Растёт очередь, появились повторные ошибки или увеличилась задержка DLR. Критический уровень. Сессия недоступна, приоритетные SMS не отправляются или финальные статусы не приходят. Для каждого критического события назначьте последовательность действий. Сначала уведомление получает ответственный за интеграцию. Если подтверждения нет, сообщение уходит второму сотруднику. При продолжении сбоя добавляется руководитель направления. Эскалация должна завершаться не только уведомлением, но и записью о результате: соединение восстановили, трафик перевели на другой маршрут или очередь отправили повторно. Чтобы не получить десятки одинаковых сообщений, объединяйте повторяющиеся события в один инцидент. В Telegram можно отправить первое уведомление, затем обновлять его при изменении числа попыток или состояния очереди. После восстановления отправляйте отдельное сообщение с длительностью сбоя и количеством затронутых сообщений. Если отправка проходит через очередь, правила приоритетов лучше описать заранее. Сервисные уведомления о заявке или записи могут идти раньше второстепенного трафика. О построении очереди, ограничении скорости и приоритетах полезно прочитать в материале как настроить очередь SMS в API и SMPP. Какие ошибки чаще всего мешают мониторингу SMPP? Проверяют только доступность TCP. Открытый порт не доказывает, что bind активен и сообщения проходят. Считают submit_sm подтверждением доставки. Этот ответ нужно отделять от итогового DLR. Не сохраняют идентификатор сообщения. Без него нельзя связать отправку с финальным статусом. Ставят слишком низкий порог. Одиночные ошибки создают шум и со временем перестают восприниматься. Не отправляют уведомление о восстановлении. Тогда непонятно, закончился ли инцидент. Не тестируют вебхук. SMPP может работать, а Telegram-уведомления не доходят из-за ошибки обработчика. Проверку лучше проводить на тестовом трафике: разорвать соединение в контролируемое время, вызвать повторный bind, проверить запись ошибки и убедиться, что после восстановления приходит закрывающий алерт. Для всей цепочки мониторинга, включая журналы, вебхуки и DLR, пригодится инструкция как настроить мониторинг SMS-интеграции в 2026 году. Для небольшой компании такая схема может начинаться с одного канала Telegram и нескольких правил, а затем расширяться по мере роста трафика. На технической площадке smpp.by подобный контур естественно связывается с SMPP-шлюзом, API-интеграцией и аналитикой трафика: отдельно проверяется соединение, отдельно доставка, отдельно реакция сотрудников. 3 шага, которые можно сделать на этой неделе: Составить список событий SMPP и разделить их на информационные, предупреждающие и критические. Сохранить связку «идентификатор сообщения — submit_sm — DLR» и проверить её на тестовой отправке. Настроить вебхук в Telegram, протестировать разрыв сессии и убедиться, что после восстановления приходит отдельное уведомление. > Source: https://smpp.by/kak-nastroit-alerty-o-sboyakh-smpp-v-telegram-v-2026-godu --- # Как настроить интеграцию CRM и SMPP для SMS-уведомлений в 2026 году Интеграция CRM с SMPP позволяет отправлять SMS автоматически: после оформления заказа, изменения статуса заявки, готовности товара или записи клиента. Для этого CRM передаёт событие в промежуточный сервис или напрямую в SMS-шлюз, а шлюз возвращает статус доставки. В статье разберём схему подключения, обязательные поля, обработку ошибок и контроль дублей. После настройки менеджеру не придётся копировать номера и тексты вручную. Как работает связка CRM, API и SMPP? CRM хранит карточку клиента и фиксирует событие. Например, заказ перешёл в статус «Передан в доставку». Интеграция превращает это событие в запрос на отправку SMS. Дальше сообщение попадает в SMPP-шлюз, который передаёт его оператору связи и возвращает технический результат. В небольшой компании CRM часто не подключают к SMPP напрямую. Между системами ставят интеграционный сервис. Он принимает вебхук или API-запрос от CRM, проверяет данные, ставит сообщение в очередь и передаёт его в SMPP-сессию. Такая схема упрощает повторную отправку после временного сбоя и не останавливает CRM, если шлюз кратковременно недоступен. Протокол SMPP поддерживает отправку сообщений, получение статусов доставки и работу с входящими SMS. В технической документации шлюзов часто используется версия SMPP 3.4, но перед настройкой нужно сверить версию, параметры подключения и список поддерживаемых статусов у конкретного провайдера (API /SMPP протокол, SMSC.ru). Для проекта на smpp.by логично разделить задачи: SMPP-шлюз передаёт трафик, API принимает события из CRM, а аналитика собирает статусы, ошибки и объём сообщений. При таком разделении проще понять, где возникла проблема: в CRM, очереди, соединении или доставке оператору. Какие данные подготовить до подключения? Сначала составьте список сценариев. Для малого бизнеса обычно достаточно нескольких автоматических уведомлений: подтверждение новой заявки; изменение статуса заказа; напоминание о записи или встрече; сообщение о готовности товара; уведомление менеджеру о важном событии в CRM. Для каждого сценария задайте одно условие запуска, один шаблон и ответственного за проверку результата. Например, SMS о готовности заказа отправляется после перехода карточки в статус «Готов к выдаче», но только один раз. Если клиент снова открыл карточку, повторной отправки не происходит. Подготовьте поля, которые интеграция будет брать из CRM. Минимальный набор выглядит так: Поле Зачем нужно Пример Номер телефона Адрес получателя Мобильный номер клиента Текст или код шаблона Содержание сообщения «Заказ №{{number}} готов» Идентификатор события Защита от повторной отправки order_ready_4821 Имя отправителя Отображение отправителя в SMS Название компании Время отправки Немедленная или отложенная доставка Сразу после смены статуса Текст лучше собирать из короткого шаблона и проверенных переменных. Если в SMS нужны номер заказа, имя клиента или дата, система должна подставлять их автоматически. До запуска проверьте длину сообщения: кириллица, латиница и эмодзи по-разному влияют на объём SMS и количество частей. Практические правила расчёта символов разобраны в материале «Сколько символов в SMS в 2026 году». Как настроить интеграцию CRM с SMPP по шагам? 1. Выберите точку запуска события В CRM найдите триггер, который меняет статус заявки или заказа. Для уведомления о доставке это может быть смена статуса, для напоминания о визите, дата и время записи. Триггер должен запускаться после сохранения карточки, иначе SMS уйдёт с неполными данными. 2. Создайте шаблон и проверьте переменные Сделайте отдельный шаблон для каждого сценария. Не передавайте в текст технические поля CRM, пустые переменные и длинные комментарии менеджера. Если номер заказа отсутствует, интеграция должна остановить отправку или использовать заранее заданный вариант без этого поля. Сервисное сообщение лучше строить в такой последовательности: кто отправляет, что произошло, что делать клиенту. Например: «Мастерская: заказ №{{number}} готов. Заберите его до {{date}}». Дополнительные рекомендации по структуре сервисных SMS есть в статье «Как составить сервисное SMS в 2026 году». 3. Настройте API-запрос или вебхук CRM передаёт в интеграционный слой номер, текст, имя отправителя, внешний идентификатор и признак срочности. Интеграционный слой отвечает CRM понятным результатом: запрос принят, отклонён из-за ошибки или поставлен в очередь. Секретный ключ и параметры SMPP-подключения хранят отдельно от текста сценария. Если CRM умеет работать только с вебхуками, используйте адрес приёма события. Если система поддерживает REST API, передавайте данные структурированным запросом. В обоих случаях задайте тайм-аут и правило повторной попытки, чтобы временный сбой не создавал несколько одинаковых сообщений. 4. Организуйте очередь сообщений Очередь принимает задания из CRM и отправляет их в SMPP с установленной скоростью. Для неё полезно задать приоритеты: коды подтверждения и сервисные уведомления идут раньше рекламных сценариев, если такие сообщения используются в рамках согласованной коммуникации. Очередь также защищает CRM от резкого всплеска запросов. При массовом изменении статусов система не пытается открыть новое соединение для каждого клиента, а обрабатывает задания последовательно. О rate limit, приоритетах и построении очереди можно прочитать в материале «Как построить очередь SMS в API и SMPP». 5. Настройте статусы доставки После отправки храните как минимум внешний идентификатор сообщения, номер, время запроса и итоговый статус. Статус «принято шлюзом» ещё не означает, что SMS доставлено телефону. Для анализа нужны отдельные состояния: принято, доставлено, просрочено, отклонено или неизвестно. Если сообщение не доставлено, CRM не должна бесконечно повторять отправку. Для каждого кода ошибки задайте действие: повторить через паузу, передать задачу менеджеру или завершить сценарий. Сетевые сбои, ошибки текста и фильтрация оператора требуют разной диагностики, поэтому технический журнал лучше вести отдельно от карточки клиента. Как избежать дублей и проверить результат? Главная защита от дублей — уникальный идентификатор события. Его можно составить из типа события и номера заказа: order_ready_4821. Перед постановкой в очередь система проверяет, отправлялось ли такое событие раньше. Повторный вебхук тогда не создаёт второе SMS. Добавьте в журнал четыре времени: событие в CRM, постановка в очередь, передача в SMPP и получение статуса. По этим отметкам видно, где задержалось сообщение. Для контроля интеграции полезны отдельные показатели: количество запросов, доля ошибок, число повторных попыток и распределение статусов доставки. Настройке такого контроля посвящён материал «Как настроить мониторинг SMS-интеграции в 2026 году». Тестирование проводите на нескольких номерах и сценариях. Проверьте обычный текст, кириллицу, переменные, пустой номер, недоступный шлюз и повторную отправку одного события. После этого выполните ограниченную рабочую отправку и сравните записи в CRM с журналом SMPP. Типичные ошибки при интеграции CRM и SMPP Отправка при каждом сохранении карточки. Триггер привязывают к конкретной смене статуса, а не к любому обновлению записи. Отсутствие внешнего идентификатора. Без него повторный вебхук может создать дубликат SMS. Проверка только факта принятия. Интеграция должна получать и разбирать финальный статус доставки. Одна очередь для всех событий. Срочные сервисные сообщения могут задержаться за большим объёмом второстепенных заданий. Длинный шаблон с большим числом переменных. Пустое поле или лишняя часть текста меняет содержание SMS и увеличивает число сегментов. Отсутствие журнала ошибок. Без кода ответа трудно определить, сбой произошёл в CRM, API, SMPP-сессии или при доставке. 3 шага, которые можно сделать на этой неделе: Выбрать один сценарий, например уведомление о статусе заказа, и описать его триггер. Подготовить шаблон, поля запроса и уникальный идентификатор события. Подключить тестовый маршрут через API и SMPP, затем проверить очередь, статусы доставки и защиту от дублей. > Source: https://smpp.by/kak-nastroit-integratsiyu-crm-i-smpp-dlya-sms-uvedomleniy-v-2026-godu --- # Как настроить SMS-цепочку через SMPP для малого бизнеса SMS-цепочка через SMPP помогает автоматически вести клиента от заявки до следующего действия: отправить подтверждение, напомнить о предложении и передать менеджеру сигнал о реакции. В статье разберём, как выбрать этапы воронки, связать CRM или сайт с API, настроить очередь сообщений, проверить статусы доставки и избежать дублей. В результате у бизнеса появится понятная схема, которую можно сначала запустить для одного сценария, а затем расширить. Из каких этапов состоит SMS-воронка? Начните с события, которое уже фиксирует ваша система. Это может быть заявка с сайта, создание заказа, смена статуса сделки или отсутствие ответа менеджеру. Каждому событию назначают одно сообщение и понятное следующее действие. Например, после заявки клиент получает подтверждение, затем менеджер связывается с ним, а через заданный интервал система отправляет напоминание. Для малого бизнеса лучше собрать короткую цепочку из двух-четырёх сообщений. Длинная серия требует большего числа условий и сложнее проверяется. Сначала опишите путь клиента на обычном листе: клиент оставил заявку; система отправила подтверждение; менеджер изменил статус сделки; клиент получил предложение или напоминание; сделка закрыта либо передана на повторный контакт. У каждого сообщения должен быть собственный триггер. Если один и тот же статус обновляется несколько раз, система обязана проверить, отправлялось ли уведомление раньше. Для защиты от повторов используют уникальный идентификатор события и журнал отправок. Отдельные рекомендации по защите API и SMPP от дублей собраны в материале «Почему SMS отправляется дважды». Как выбрать между API и SMPP? API подходит для первого подключения: сайт или CRM отправляет запрос с номером, текстом и идентификатором сообщения. SMPP используют, когда важны постоянное соединение, очередь сообщений и контроль большого потока. Для микробизнеса разумно начать с API, если отправок немного и они возникают по отдельным событиям. SMPP имеет смысл подключать, когда система отправляет сообщения регулярно или должна обрабатывать всплески без ручного вмешательства. Задача Подход Что настроить Подтвердить заявку или заказ API Запрос из сайта или CRM после создания события, проверка ответа шлюза Отправлять сообщения из очереди API с очередью или SMPP Приоритеты, лимиты, повторные попытки, журнал статусов Обрабатывать высокий или неравномерный поток SMPP Постоянную сессию, контроль соединения и распределение нагрузки Разбирать сбои доставки API и SMPP с отчётами Получение delivery receipt, хранение кода статуса и времени ответа При подключении через SMPP приложение открывает сессию с шлюзом и передаёт сообщения командами протокола. Система получает подтверждение приёма, а позже может получить отчёт о доставке. Эти события нельзя смешивать: подтверждение приёма шлюзом ещё не означает, что SMS дошло до телефона. Сетевые сбои требуют отдельной логики. Приложение должно распознавать разрыв сессии, выдерживать паузу перед повторным подключением и восстанавливать обмен без создания копий сообщений. Практические варианты поддержания SMPP-сессии при сбоях описаны в материале о работе SMPP-сессии при нестабильной сети. Как спроектировать триггеры и текст сообщений? Сначала запишите условие отправки, задержку и действие, после которого цепочка прекращается. Например: «после новой заявки отправить подтверждение сразу; если менеджер не сменил статус в течение рабочего интервала, отправить напоминание; после закрытия сделки остановить дальнейшие сообщения». Такая схема предотвращает ситуацию, когда клиент продолжает получать рекламный текст после покупки. Текст SMS должен отвечать на три вопроса: кто пишет, что произошло и что сделать дальше. В подтверждении заявки достаточно назвать компанию или сервис, зафиксировать факт обращения и указать следующий шаг. В напоминании нужен конкретный повод: ответить менеджеру, открыть страницу заказа или выбрать время связи. Длина влияет на число SMS-сегментов. Для GSM-7bit один сегмент обычно содержит до 160 знаков, а при использовании Unicode, например кириллицы, ориентир составляет до 70 знаков. Длинный текст разбивается на несколько частей и увеличивает объём отправки. Поэтому перед запуском проверьте кодировку, длину, ссылку и переменные. Отдельно о длине кириллических сообщений и стоимости сегментов рассказывает материал «Как не переплачивать за SMS с кириллицей и эмодзи». Событие Пример задачи Что передать в сообщение Когда остановить цепочку Новая заявка Подтвердить обращение Факт заявки и следующий шаг После отправки подтверждения Нет изменения статуса Напомнить клиенту Короткое напоминание и действие После ответа или контакта менеджера Сделка закрыта Подтвердить результат Информация о заказе или услуге Сразу после отправки Срок повторного обращения Напомнить о следующем заказе Причина сообщения и понятная ссылка После нового заказа или отказа Как настроить очередь, статусы и повторные попытки? Не отправляйте SMS прямо внутри обработчика заявки, если система должна выдерживать задержки шлюза. Сначала запишите сообщение в очередь. В записи очереди храните номер события, получателя, текст или шаблон, приоритет, время создания и число попыток. Отдельный обработчик забирает записи, отправляет их через API или SMPP и фиксирует ответ. Разделите сообщения по приоритету. Подтверждение заказа или изменения по доставке обычно важнее маркетингового напоминания. При ограничении пропускной способности сначала отправляйте сервисные уведомления, затем кампании с низким приоритетом. Очередь также защищает систему от резкого всплеска, когда несколько событий возникают одновременно. Повторная попытка нужна только для временной ошибки: разрыва соединения, тайм-аута или временной недоступности шлюза. Неверный номер, запрещённый формат или постоянная ошибка маршрута требуют статуса «не отправлять повторно». Иначе один сбой превратится в серию одинаковых запросов. Для очередей с ограничением скорости задайте интервал между отправками и отдельный лимит для каждого направления. Полезная техническая схема с rate limit и приоритетами разобрана в материале о построении очереди SMS в API и SMPP. Как проверить цепочку до запуска? Тестируйте каждый триггер отдельно. Создайте тестовую заявку, убедитесь, что SMS попало в очередь, проверьте запрос к шлюзу и сопоставьте его с отчётом доставки. Затем измените статус сделки и проверьте, остановилась ли старая ветка. Повторно отправьте одно и то же событие: система должна распознать его идентификатор и не создать второе сообщение. Проверка нужна для нескольких вариантов номера, текста и кодировки. Отдельно проверьте пустое имя клиента, длинный номер заказа, специальный символ и ссылку. Если переменная не подставилась, сообщение должно уйти по безопасному шаблону, а ошибка должна попасть в журнал. В рабочем режиме смотрите на четыре показателя: число сообщений в очереди, долю успешной передачи шлюзу, статусы доставки и количество повторных попыток. Если доставка ухудшилась, сначала сравните время отправки, код ошибки и направление. Технические сбои, ошибки в содержании и фильтрация операторами относятся к разным классам причин, поэтому и проверяют их по-разному (Проблемы с доставкой SMS: диагностика и решения, IBZ Source). Какие ошибки встречаются чаще всего? Цепочка запускается повторно при каждом обновлении одной и той же сделки. Приложение считает подтверждение шлюза доказательством доставки. Повторная попытка выполняется для постоянной ошибки номера или формата. Кириллический текст и эмодзи увеличивают число сегментов, но это не учтено в расчёте. В очередь попадают рекламные сообщения с более высоким приоритетом, чем подтверждения заказа. В журнале нет идентификатора события, поэтому невозможно найти источник дубля. 3 шага, которые можно сделать на этой неделе: Нарисовать одну цепочку: заявка, подтверждение, напоминание, завершение. Связать каждый этап с уникальным событием и настроить очередь через API или SMPP. Провести тестовые отправки, проверить статусы, повторы и длину SMS до запуска для клиентов. > Source: https://smpp.by/kak-nastroit-sms-tsepochku-cherez-smpp-dlya-malogo-biznesa --- # Как поддерживать SMPP-сессию при сбоях сети SMPP-сессия держится стабильно, если клиент регулярно отправляет enquire_link, контролирует ответ enquire_link_resp и умеет переподключаться после тайм-аута или разрыва TCP-соединения. В статье разберём, как настроить heartbeat, определить момент сбоя, восстановить bind-транзакцию и не потерять сообщения в очереди. Эти правила подходят для API-шлюза, собственной SMS-платформы и интеграции малого бизнеса с CRM или интернет-магазином. Зачем SMPP нужен enquire_link? SMPP работает поверх TCP, а TCP-соединение не всегда сразу сообщает приложению о проблеме. Кабель мог отключиться, сеть могла смениться, промежуточный firewall мог закрыть неактивное соединение. При этом программа продолжает считать сессию открытой и отправляет новые PDU в канал, который уже не доставляет данные. enquire_link — служебный PDU для проверки состояния SMPP-сессии. Клиент отправляет его SMSC, а SMSC отвечает enquire_link_resp. Если ответ пришёл, соединение отвечает на heartbeat. Если ответ не появился в установленный срок, клиент получает основание закрыть сессию и начать восстановление. Heartbeat не проверяет доставку SMS конечному абоненту. Он показывает только состояние соединения между вашей системой и SMPP-шлюзом. Статус доставки нужно отслеживать отдельно через DLR, то есть delivery receipt. Для сервисов, где важна история каждого сообщения, полезно заранее настроить мониторинг SMS-интеграции с отдельными сигналами для сети, SMPP-сессии и доставки. Как настроить heartbeat и тайм-ауты? Сначала зафиксируйте четыре параметра: интервал отправки enquire_link, время ожидания ответа, допустимое число пропущенных ответов и паузу перед повторным подключением. Конкретные значения зависят от требований SMPP-провайдера и сетевой инфраструктуры, поэтому их берут из технических условий подключения, а не выбирают случайно. Пример последовательности выглядит так: Клиент открывает TCP-соединение с SMPP-шлюзом. Клиент выполняет bind_transceiver либо другой согласованный тип bind. После успешного bind запускается отдельный таймер heartbeat. По таймеру клиент отправляет один enquire_link. До следующей отправки клиент ждёт enquire_link_resp. При ответе он сбрасывает счётчик пропущенных heartbeat. При превышении тайм-аута закрывает сокет и переводит сессию в состояние reconnecting. Поток heartbeat лучше отделить от потока отправки SMS. Если рабочая очередь занята большим объёмом сообщений, служебный PDU не должен ждать окончания массовой отправки. Иначе приложение может показывать активный трафик, хотя сервер уже считает соединение потерянным. Ещё одна практическая деталь — защита от параллельных heartbeat. Пока система ждёт ответ на предыдущий enquire_link, она не должна отправлять следующий. Иначе при задержке сети появится несколько незавершённых запросов, а диагностика станет неточной. Как понять, что сессию пора переподключать? Сбой определяется по совокупности признаков: TCP-сокет сообщил об ошибке, чтение из соединения завершилось, пришёл SMPP-ответ с ошибкой или истёк тайм-аут ожидания enquire_link_resp. Один медленный ответ ещё не всегда означает полную потерю канала. Решение принимают по правилам, согласованным с провайдером: например, после заданного числа последовательных пропусков. Состояние интеграции удобно хранить как простую машину состояний: DISCONNECTED — TCP-соединения нет; CONNECTING — приложение устанавливает TCP-соединение; BINDING — отправлен bind и ожидается ответ; BOUND — сессия готова к обмену PDU; RECONNECTING — старый канал закрывается, система готовит новое подключение. Новые SMS следует отправлять только в состоянии BOUND. При переходе в RECONNECTING очередь замораживает передачу, но сохраняет сообщения и их внутренние идентификаторы. После нового bind приложение продолжает работу с очередью, а не создаёт повторные записи для тех же запросов. Отдельно контролируйте sequence number. Он нужен для сопоставления запроса с ответом в рамках SMPP-сессии, но после переподключения нельзя считать старый канал действующим. Ответ, который пришёл от закрытой или уже заменённой сессии, не должен подтверждать операцию в новой сессии. Как реализовать переподключение без бесконечного цикла? После сбоя клиент закрывает старый сокет, отменяет таймеры и очищает состояние bind. Затем он ждёт перед новой попыткой. Постоянные подключения без паузы создают лишнюю нагрузку и затрудняют работу провайдера, особенно если проблема находится на сетевом участке, который ещё не восстановился. Для повторных попыток применяют возрастающую задержку: первая попытка идёт почти сразу, следующие выполняются через более длинные интервалы, а после установленного предела задержка перестаёт увеличиваться. К ней добавляют небольшой случайный разброс, чтобы несколько экземпляров приложения не подключались одновременно после общего сбоя. Событие Действие клиента Что проверить в журнале Нет ответа на enquire_link Зафиксировать тайм-аут; после заданного порога закрыть сессию Время отправки PDU и время последнего ответа Ошибка TCP Остановить отправку и перейти к переподключению Код сетевой ошибки, адрес шлюза, состояние сокета Ошибка bind Не отправлять SMS; повторить попытку по политике backoff Команда bind, код SMPP-ошибки, версия конфигурации Новый bind успешен Возобновить обработку очереди с контролем дублей Время bind_resp, идентификатор сессии, размер очереди При восстановлении соединения не отправляйте всю накопившуюся очередь одним рывком. Скорость передачи ограничивают параметрами провайдера, числом параллельных запросов и настройками окна SMPP. Для раздельной обработки срочных и обычных сообщений пригодится схема очереди SMS в API и SMPP с rate limit и приоритетами. Как не отправить SMS повторно после сбоя? Сложность появляется в момент, когда приложение отправило submit_sm, но не получило submit_sm_resp. Система не знает, принял ли шлюз сообщение до разрыва связи. Если автоматически повторить отправку, абонент может получить два одинаковых SMS. Для этого вводят внутренний идентификатор операции и сохраняют его до получения окончательного результата. Запись должна содержать текст сообщения, номер получателя, время постановки в очередь, состояние отправки и связанный message ID провайдера, если он был получен. После reconnect обработчик отдельно разбирает записи со статусами «ожидает ответа», «подтверждено» и «ошибка». У SMPP нет универсальной гарантии, которая во всех ситуациях исключает повторную доставку при потере ответа. Поэтому политику повторной отправки выбирают для каждого типа сообщения. Для одноразового кода повтор может привести к путанице, а для уведомления о заказе нужно оценить риск пропуска. Логику защиты от повторов удобно проверить по отдельному чек-листу защиты API и SMPP от дублей. Какие ошибки чаще всего ломают сессию? Heartbeat отправляют только при отсутствии SMS-трафика, хотя сетевой разрыв может произойти во время активной очереди. Приложение считает TCP-соединение живым без проверки enquire_link_resp. После reconnect сразу отправляют очередь, не дождавшись успешного bind_resp. Таймер heartbeat запускается повторно при каждом событии, поэтому одновременно работают несколько таймеров. Все сообщения повторно отправляют после тайм-аута без разборки неопределённых операций. В журнал пишут только текст ошибки без времени, sequence number и состояния сессии. Минимальный набор метрик включает число активных SMPP-сессий, время последнего успешного heartbeat, количество переподключений, длительность восстановления, размер очереди и число неопределённых submit_sm. Эти показатели помогают отличить краткий сетевой сбой от ошибки авторизации или превышения лимита шлюза. Три шага, которые можно сделать на этой неделе: Описать состояния соединения и записать, при каком событии система переходит между ними. Добавить отдельный heartbeat с тайм-аутом, журналом PDU и защитой от параллельных enquire_link. Проверить сценарий разрыва после submit_sm: очередь, повторную отправку, DLR и восстановление bind на тестовом подключении. > Source: https://smpp.by/kak-podderzhivat-smpp-sessiyu-pri-sboyakh-seti --- # Как построить очередь SMS в API и SMPP: rate limit и приоритеты Очередь SMS отделяет бизнес-систему от шлюза и помогает отправлять сообщения без перегрузки API или SMPP-сессии. В статье разберём, как устроить такую очередь, зачем нужен rate limit, что делать при временной ошибке и как расставлять приоритеты. После настройки вы сможете разделять срочные уведомления и обычные рассылки, повторять неудачные попытки без дублей и видеть, где сообщение задержалось: в приложении, очереди или у SMS-поставщика. Зачем бизнесу очередь SMS между приложением и шлюзом? Когда интернет-магазин, сервис записи или внутренняя система отправляет SMS, приложение часто формирует сразу много запросов. Например, после изменения статуса заказа десятки сообщений могут уйти почти одновременно. Если передавать их напрямую в API, приложение начнёт зависеть от скорости ответа шлюза. При работе через SMPP похожая проблема возникает, когда клиентская система пытается отправить больше сообщений, чем разрешает текущая сессия или канал. Очередь принимает задачу быстро, а отправку выполняет отдельный обработчик. В запись попадают номер получателя, текст, идентификатор сообщения, время создания и текущий статус. Рабочий процесс забирает задачи по одной или небольшими партиями, отправляет их через API или SMPP и сохраняет результат. Такой подход даёт несколько практических преимуществ: приложение не ждёт завершения каждой отправки; временный сбой шлюза не теряет уже созданные задачи; скорость отправки можно ограничить без изменения бизнес-логики; срочное уведомление можно поставить выше обычной кампании; статусы и ошибки остаются доступными для аналитики трафика. Для малого бизнеса достаточно начать с одной очереди и отдельного обработчика. Сложную систему с несколькими узлами имеет смысл добавлять после появления реальной нагрузки, а не на этапе первой интеграции. Как работает rate limit в API и SMPP? Rate limit ограничивает число запросов или сообщений за определённый промежуток времени. Лимит задаёт не только приложение: его могут устанавливать API-поставщик, SMS-шлюз, конкретный маршрут или параметры SMPP-подключения. Поэтому скорость нельзя выбирать «на глаз». Её берут из технических условий подключения и проверяют тестовой отправкой. В API обработчик обычно считает запросы за секунду или минуту. Если достигнут предел, новая задача остаётся в очереди и ждёт следующего окна. Ответ с временной ошибкой тоже не повод сразу повторять запрос: несколько параллельных повторов создадут дополнительную нагрузку. В SMPP отправитель поддерживает соединение и передаёт сообщения через операции протокола. Для интеграции нужно учитывать доступное количество параллельных запросов, подтверждения отправки и состояние bind-сессии. Документация SMPP-шлюза обычно описывает параметры подключения, отправку SMS и статусы доставки; например, при настройке важно сверить версию протокола, поля сообщения и формат DLR. Ситуация Действие очереди Что сохранить Лимит API достигнут Поставить задачу на короткую задержку Код ответа и время следующей попытки SMPP-сессия разорвана Приостановить отправку и восстановить соединение Статус сессии и идентификатор сообщения Временная ошибка шлюза Повторить по расписанию Количество попыток и последнюю ошибку Постоянная ошибка номера или параметров Завершить задачу без повторения Финальный статус и причину отказа Полезно разделить ограничение на два уровня. Первый действует на весь отправляющий процесс, второй задаёт безопасный предел для отдельного маршрута или соединения. Так очередь не ускоряет одну часть системы за счёт перегрузки другой. Как настроить повторы и backpressure без дублей? Backpressure, или обратное давление, означает, что система снижает подачу новых сообщений, когда отправляющий канал не успевает их обработать. Очередь при этом растёт, но обработчик не создаёт бесконечный поток запросов. Для бизнеса важнее предсказуемая задержка и сохранность задач, чем попытка отправить всё мгновенно. Каждая задача должна иметь внутренний идентификатор. Перед отправкой обработчик переводит её из статуса «ожидает» в «в работе», а после ответа сохраняет результат. Если процесс прервался между отправкой и записью статуса, повторный запуск должен проверить идентификатор операции и правила идемпотентности поставщика. Без этого одно уведомление может уйти дважды. Повторы делят на временные и постоянные. К временным относят недоступность соединения, превышение лимита и кратковременный сбой API. Для них задают ограниченное число попыток и увеличивающуюся паузу. Постоянные ошибки параметров, некорректного номера или формата сообщения отправлять заново бессмысленно. Состояния удобно описать явно: queued — задача ждёт обработки; processing — обработчик отправляет сообщение; accepted — шлюз принял запрос; delivered — получен статус доставки; retry — нужна следующая попытка; failed — повтор запрещён или исчерпан лимит попыток. Статус «accepted» не стоит считать доставкой. Он показывает, что запрос принят системой отправки. Фактический результат приходит позднее через DLR или webhook, поэтому его нужно связать с исходной задачей по идентификатору сообщения. Отдельно проверьте защиту от дублей при повторной обработке. Практические сценарии такой защиты разобраны в материале почему SMS отправляется дважды и как защитить API и SMPP от дублей. Как расставить приоритеты в очереди SMS? Одна общая очередь подходит для простого проекта, но обычная массовая отправка способна задержать критичное уведомление. Поэтому задачи распределяют по приоритетам. Срочными могут быть сообщения о готовности заказа, переносе записи или изменении времени доставки. Обычные информационные сообщения и плановые серии отправляют после них. Есть два понятных варианта. Первый, отдельные очереди для разных типов сообщений. Обработчик сначала проверяет срочную очередь, затем обычную. Второй, единая очередь с числовым приоритетом и временем создания. В обоих случаях добавляют ограничение, чтобы поток срочных задач не блокировал всё остальное. Приоритет Пример задачи Правило обработки Высокий Перенос визита или готовность заказа Отправлять при первой доступной попытке Обычный Подтверждение стандартного действия Обрабатывать в общей очереди Низкий Плановое информационное сообщение Отправлять после срочных задач и в пределах лимита Приоритет должен описывать бизнес-смысл, а не желание конкретного отдела отправить сообщение первым. Если все задачи получают высший приоритет, очередь фактически теряет управление. Для начала достаточно двух уровней: срочный и обычный. Какие показатели нужно контролировать? Без мониторинга очередь превращается в скрытое место задержек. На дашборде полезно показывать размер очереди, возраст самой старой задачи, скорость обработки и долю повторов. Отдельно отслеживают ошибки API, разрывы SMPP-сессии и разницу между принятыми сообщениями и полученными статусами доставки. Пороговые значения зависят от сценария, поэтому их фиксируют после тестов. Если очередь постоянно растёт, обработчик получает слишком много задач, лимит канала выбран неверно или ошибки повторяются без паузы. Если задачи быстро исчезают, но DLR не приходят, проверяют связь идентификаторов, формат статусов и обработку webhook. Для диагностики полезно хранить время постановки задачи, время каждой попытки, ответ шлюза и финальный статус. Эти данные помогают отличить перегрузку собственной системы от технического сбоя оператора. Общий подход к контролю интеграции описан в материале как настроить мониторинг SMS-интеграции в 2026 году. Типичные ошибки при построении очереди Отправка всех задач параллельно без ограничения скорости. Повтор любого отрицательного ответа, включая постоянные ошибки. Отсутствие уникального идентификатора сообщения. Смешивание срочных уведомлений с плановой массовой отправкой. Удаление задачи сразу после ответа API без ожидания статуса доставки. Контроль только размера очереди без проверки возраста самой старой задачи. 3 шага, которые можно сделать на этой неделе: Описать статусы задачи и разделить ошибки на временные и постоянные. Добавить rate limit, ограниченное число повторов и уникальный идентификатор операции. Разделить срочные и обычные сообщения, затем проверить очередь тестовыми отправками и DLR. Для проекта на API или SMPP этого набора достаточно, чтобы начать с управляемой схемы: приложение создаёт задачи, очередь регулирует скорость, шлюз возвращает результат, а аналитика показывает задержки и ошибки. Если интеграция требует отдельного SMPP-шлюза, подключения по API и контроля трафика, такую архитектуру можно собрать вокруг технической площадки smpp.by без изменения бизнес-системы. > Source: https://smpp.by/kak-postroit-ochered-sms-v-api-i-smpp --- # Как настроить мониторинг SMS-интеграции в 2026 году Для малого бизнеса мониторинг SMS-интеграции начинается с четырёх показателей: доли доставленных сообщений, времени ответа API или SMPP, числа ошибок и задержки получения статуса DLR. Такая схема помогает понять, где возник сбой: в приложении, очереди, соединении со шлюзом или на маршруте доставки. В статье разберём, какие метрики собирать, как установить SLO без сложной инфраструктуры и какие алерты действительно требуют реакции. Какие метрики показывают состояние SMS-интеграции? Одна цифра «отправлено» почти ничего не говорит о качестве сервиса. Приложение могло принять запрос, но не передать его в SMPP-шлюз. Шлюз мог принять сообщение, однако оператор вернул ошибку или не прислал статус вовремя. Поэтому мониторинг связывает несколько этапов одной отправки. МетрикаЧто показываетКак использовать Число запросов на отправкуСколько сообщений создаёт бизнес-системаСравнивать с объёмом принятых сообщений в шлюзе Доля принятых запросовПроходят ли сообщения проверку на стороне API или SMPPОтдельно учитывать ответы с ошибками Доля доставленных SMSКакой объём получил статус доставкиСчитать по транзакционным сообщениям и кампаниям отдельно Задержка DLRСколько времени проходит до статуса доставкиВыявлять задержки маршрута и проблемы с обработчиком статусов Ошибки SMPP и APIПочему отправка остановилась или отклониласьГруппировать по коду и не смешивать временные сбои с ошибками данных Длина очередиСколько сообщений ждёт отправкиПонимать, успевает ли система обработать входящий поток Для каждого сообщения полезно хранить технический идентификатор, время постановки в очередь, время передачи, ответ шлюза и итоговый статус. Такой журнал позволяет сопоставить событие в CRM с записью в SMS-системе. Если клиент сообщает, что не получил подтверждение заказа, оператор сможет проверить конкретную попытку, а не искать её среди всех отправок. Статусы лучше привести к единой схеме: «создано», «в очереди», «принято шлюзом», «доставлено», «не доставлено», «истёк срок ожидания». При этом исходный код ошибки SMPP или API нужно сохранять отдельно. Иначе команда увидит только общий статус «ошибка» и не поймёт, нужно ли повторить отправку. Как задать SLO для SMS без лишней математики? SLO — это рабочая цель для сервиса. Она описывает, какой уровень качества бизнес считает приемлемым за выбранный период. Для небольшой компании не требуется сразу строить сложную систему расчётов: достаточно определить цели для приёма запроса, передачи сообщения и получения конечного статуса. API или SMPP принимает корректный запрос без недоступности соединения. Сообщение покидает внутреннюю очередь за установленное для бизнеса время. Система фиксирует DLR и связывает его с исходным идентификатором. Ошибки получают понятную категорию и не исчезают из журнала. Для разных типов SMS нужны разные цели. Код подтверждения заказа и уведомление о переносе доставки требуют быстрой обработки. Рекламная кампания терпит задержку, если отправка идёт по расписанию. Поэтому одну общую метрику для всех сообщений лучше не использовать: разделите трафик по назначению и сравнивайте одинаковые сценарии. В отчёте за день достаточно показать объём отправки, процент сообщений с финальным статусом, распределение ошибок и максимальную задержку. Среднее значение часто скрывает проблему: несколько тысяч быстрых статусов могут замаскировать небольшую группу сообщений, которые застряли на часы. Добавьте перцентили или хотя бы отдельный список самых долгих отправок. Какие алерты нужны небольшой компании? Алерт должен сообщать о событии, на которое кто-то может отреагировать. Если уведомление приходит при каждом единичном сетевом сбое, сотрудники быстро перестают его читать. Для начала настройте несколько правил с временным окном и повторной проверкой. СитуацияЧто проверитьДействие Нет успешных отправок за рабочий интервалСоединение, доступность шлюза, очередьПроверить состояние сервиса и последнюю успешную попытку Очередь растёт несколько интервалов подрядЛимит скорости, зависший обработчик, всплеск запросовСравнить входящий поток с пропускной способностью Резко увеличились ошибкиКоды SMPP, ответы API, формат номера и текстаРазделить технические и пользовательские ошибки DLR не поступают вовремяВебхук, обработчик статусов, маршрут доставкиПроверить приём событий и повторную обработку Оборвалась SMPP-сессияАвторизацию, TCP-соединение, таймаутыПереподключить с ограничением числа повторов Для алерта задайте условие, интервал и адресата. Например, система отправляет уведомление, если очередь растёт пять минут, а не после одного неудачного запроса. Для критичного сбоя сообщение можно направить ответственному сотруднику, а для статистического отклонения оставить запись в ежедневном отчёте. Проверяйте также сам мониторинг. Если сервис отправляет тестовое SMS, но проверяет только факт ответа API, он не замечает проблемы с DLR. Контрольная проверка должна проходить весь путь: создать тестовое сообщение, получить ответ шлюза, дождаться статуса и сверить идентификатор. Как связать мониторинг с SMPP и HTTP API? SMPP и HTTP API дают разные технические события, поэтому их нельзя наблюдать одинаково. Для SMPP полезны состояние сессии, время подключения, ответы на команды и число переподключений. Для HTTP API отслеживают код ответа, время выполнения, таймауты и долю неуспешных запросов. На уровне приложения добавьте correlation ID, который проходит через CRM, очередь и шлюз. Он помогает найти одну отправку в нескольких журналах. Для SMPP отдельно сохраняйте message ID, полученный после принятия сообщения. Именно по нему обычно связывают отправку с DLR, а не по номеру телефона или тексту. Повторы требуют отдельного контроля. Если приложение не получило ответ из-за таймаута, оно не знает, принял ли шлюз сообщение. Без ключа идемпотентности повтор может создать дубль. Практика защиты от повторной отправки и ошибок на границе API и SMPP разобрана в материале почему SMS отправляется дважды. Временные ошибки можно повторять с увеличивающейся паузой, но лимит попыток задаётся заранее. Ошибка формата номера, запрещённого значения или неверного параметра не исправится от повторов. Логика должна различать такие случаи, иначе очередь заполнится бесполезными задачами. Подход к автоматической обработке SMPP-ошибок описан в статье как не терять SMS при ошибках SMPP. Какие типичные ошибки мешают мониторингу? Считать доставленными все сообщения, которые шлюз принял к обработке. Хранить только общий текст ошибки без кода, времени и идентификатора сообщения. Настроить алерт на любую ошибку и получать сотни уведомлений при коротком сбое. Повторять отправку после каждого таймаута без проверки риска дубля. Смешивать рекламный, сервисный и подтверждающий трафик в одном отчёте. Проверять только доступность API и не контролировать получение DLR. Для малого бизнеса разумно начать с одного дашборда и нескольких периодов: последний час, текущий день и предыдущая неделя. На первом экране разместите очередь, ошибки, долю финальных статусов и состояние SMPP-сессии. Такой набор уже показывает, нужна ли техническая реакция, проверка данных в CRM или обращение к провайдеру. Если мониторинг должен работать без ручного просмотра журналов, пригодится готовая схема контроля транзакционных SMS с метриками и уведомлениями: как настроить мониторинг SMS без программиста. Интеграцию можно строить вокруг API, SMPP или обоих каналов, если бизнесу нужен резервный маршрут. 3 шага, которые можно сделать на этой неделе: Составьте таблицу статусов и ошибок, добавив к каждой отправке собственный идентификатор. Выведите на один экран очередь, ошибки SMPP и API, задержку DLR и долю сообщений с финальным статусом. Настройте два алерта: на рост очереди и отсутствие успешных отправок, затем проверьте их контрольным сообщением. > Source: https://smpp.by/kak-nastroit-monitoring-sms-integratsii-v-2026-godu --- # Почему SMS отправляется дважды: защита API и SMPP от дублей Дубликаты SMS появляются, когда система не понимает, обработал ли шлюз предыдущую попытку. Приложение ждёт ответ, получает тайм-аут и повторяет запрос, хотя первое сообщение уже ушло оператору. Защитить интеграцию можно через идемпотентный ключ, очередь отправки, хранение статуса и корректную обработку DLR. В статье разберём схему, которую можно применить в интернет-магазине, сервисе записи или другой системе малого бизнеса. Почему API или SMPP отправляет одно SMS дважды? Самая частая причина — повтор после неопределённого результата. Приложение отправило запрос, но соединение оборвалось до получения ответа. Для бизнеса это выглядит как ошибка. На стороне SMS-шлюза запрос уже мог попасть в очередь, поэтому повторная отправка создаёт второй экземпляр сообщения. Похожая ситуация возникает при перезапуске сервиса. Очередь хранит задачу со статусом «в работе», процесс завершается, а после запуска считает её новой и отправляет повторно. Ещё один сценарий связан с вебхуками: система получает уведомление о событии дважды и дважды создаёт задачу на отправку. В SMPP нужно разделять несколько событий: приложение передало PDU, шлюз принял сообщение, оператор подтвердил доставку, а клиент получил DLR. Подтверждение приёма PDU не означает, что SMS уже доставлено абоненту. Состояние сообщения лучше менять по понятной схеме, а не по одному ответу соединения. Создано — бизнес-система сформировала уведомление. Поставлено в очередь — задача получила идентификатор и ждёт отправки. Принято шлюзом — SMPP-сессия вернула положительный ответ. Доставлено или отклонено — статус подтверждён через DLR либо код ошибки. Повтор разрешён — система решила, что повтор безопасен и действительно нужен. Для диагностики полезно сопоставить время запроса, внутренний идентификатор, message_id от шлюза, номер получателя и итоговый статус. Если в журнале нет такой связки, выяснить причину дубля после сбоя будет сложно. Для автоматической реакции на ошибки пригодится материал о обработке ошибок SMPP. Что такое идемпотентный ключ для SMS? Идемпотентный ключ — уникальный идентификатор бизнес-события. Он говорит системе: «это та же самая команда, даже если запрос пришёл повторно». Например, интернет-магазин создаёт ключ из номера заказа, типа события и версии уведомления: order-1842-status-shipped-v1. При повторном запросе сервис проверяет ключ и не создаёт новую SMS-задачу. Ключ нужно формировать до первого обращения к API или постановки сообщения в очередь. Если генерировать случайный UUID при каждой попытке, защита не сработает: каждый повтор будет выглядеть как новая команда. Один и тот же ключ должен сохраняться при тайм-ауте, повторном запуске приложения и повторной доставке вебхука. Для разных событий нужны разные ключи. Уведомление «заказ принят» не должно совпадать с сообщением «заказ передан в доставку». При этом повтор одного и того же события сохраняет прежний ключ. СитуацияКлючРезультат Повтор запроса после тайм-аутаТот же ключ событияНовая SMS-задача не создаётся Изменился статус заказаНовый ключ статусаСоздаётся отдельное уведомление Повтор вебхука от CRMИдентификатор события CRMПовторная команда игнорируется Ручная повторная отправка операторомНовый ключ с отметкой повтораОтправка фиксируется как отдельное действие Как построить очередь SMS без повторной отправки? Приложение, которое обслуживает заказ или запись клиента, лучше не отправляет SMS прямо внутри основного запроса. Оно записывает событие в очередь, а отдельный обработчик забирает задачу и передаёт её через API или SMPP. Такой подход позволяет пережить временный сбой связи и отдельно контролировать повторные попытки. Сформируйте идемпотентный ключ из идентификатора события. Проверьте, есть ли этот ключ в журнале отправок. Если ключ новый, сохраните задачу со статусом «поставлено в очередь». Передайте сообщение шлюзу и запишите ответ вместе с message_id. Получите DLR и обновите итоговый статус, не создавая новую задачу. Запись о ключе должна появляться атомарно. Иначе два параллельных процесса одновременно проверят пустую таблицу и оба начнут отправку. На уровне хранилища помогает уникальное ограничение на поле idempotency_key. Если второй процесс встретит конфликт, он перечитает существующую запись и продолжит работу с ней. Для каждой задачи задайте понятные границы повтора. При временной ошибке соединения повтор может быть оправдан, но перед ним система должна проверить, не появился ли уже message_id или итоговый DLR. При постоянной ошибке, например некорректном номере или содержании, повторять ту же команду бессмысленно. Как обрабатывать повторы в SMPP-сессии? SMPP работает через долгоживущее соединение, поэтому приложение следит не только за отправкой PDU, но и за состоянием сессии. Периодический enquire_link поддерживает соединение активным; в документации Exolve указано, что ESME нужно отправлять такой запрос каждые 15 минут независимо от наличия трафика. При разрыве сессии очередь должна продолжить работу после переподключения, но не создавать новые задачи для уже подтверждённых сообщений. Внутренний ключ события и message_id шлюза решают разные задачи. Первый защищает бизнес-логику от повторного создания SMS. Второй помогает сопоставить отправку с ответом шлюза и DLR. Поэтому в журнале стоит хранить оба значения, а также время попытки, код ответа SMPP и итоговый статус. Поле журналаЗачем оно нужно Идемпотентный ключПоказывает, к какому событию относится SMS Внутренний ID задачиСвязывает очередь с заказом или записью клиента message_idПомогает сопоставить ответ шлюза и DLR Код SMPPПоказывает результат конкретной попытки Количество попытокПозволяет найти зацикленные повторы Финальный статусОтделяет доставку от отказа и временного ожидания Если интеграция использует несколько обработчиков, каждому нужен общий журнал отправок. Отдельная локальная память процесса не защитит от дублей после перезапуска или при работе нескольких копий сервиса. Для проекта с небольшим объёмом сообщений достаточно начать с одной таблицы задач и уникального ключа, а затем добавить мониторинг. Какие ошибки чаще всего приводят к дублям? Приложение повторяет запрос после любого тайм-аута, не проверяя результат первой попытки. Новый ключ создаётся при каждом повторном обращении к API. Система считает положительный submit_sm_resp подтверждением доставки. Вебхук обрабатывается без проверки идентификатора события. После переподключения SMPP очередь отправляет все задачи со статусом «в работе». Логи хранят текст SMS, но не сохраняют message_id и код ответа. Отдельно проверьте сценарий параллельной обработки. Два воркера могут одновременно получить одну задачу, если очередь не использует блокировку или атомарную смену статуса. У задачи должен быть владелец, срок блокировки и правило возврата в очередь после сбоя процесса. Тестировать защиту нужно не только на успешной отправке. Имитируйте тайм-аут после передачи сообщения, разрыв SMPP-сессии, повтор вебхука, перезапуск обработчика и поздний DLR. Ожидаемый результат во всех случаях — одна бизнес-команда и одна связанная запись отправки. Для отдельной проверки канала можно использовать рекомендации по тестированию доставляемости SMS. Как внедрить идемпотентность в небольшой компании? Начните с одного критичного сценария: код входа, подтверждение заказа или уведомление о готовности ремонта. Опишите события и допустимые статусы, затем добавьте ключ и уникальное ограничение в журнал. После этого подключите очередь и только потом настройте автоматические повторы. На этапе интеграции заранее определите, кто отвечает за повтор: приложение, очередь или SMS-шлюз. Когда несколько компонентов повторяют отправку одновременно, система быстро теряет предсказуемость. В рабочем SMPP-шлюзе и API-интеграции полезно также вывести на мониторинг количество задач в очереди, ошибки соединения, повторные попытки и сообщения без финального статуса. Для малого бизнеса практичная схема выглядит так: CRM или сайт создаёт событие, интеграция присваивает ему ключ, очередь передаёт SMS, шлюз возвращает технический идентификатор, а DLR закрывает задачу итоговым статусом. Такая архитектура не требует сложной автоматизации, но её нужно заранее проверить на сбоях. Площадка smpp.by ориентирована именно на задачи SMPP, API-интеграции и аналитику трафика, поэтому эти компоненты можно проектировать как единую цепочку. 3 шага, которые можно сделать на этой неделе: Найдите в коде все места, где SMS повторяется после тайм-аута или ошибки. Добавьте постоянный ключ события и уникальную проверку перед постановкой задачи в очередь. Соберите журнал с message_id, кодом SMPP, количеством попыток и DLR, затем проведите тест с разрывом соединения. > Source: https://smpp.by/pochemu-sms-otpravlyaetsya-dvazhdy --- # Как тестировать доставляемость SMS перед массовой рассылкой Перед массовой SMS-рассылкой малому бизнесу в Беларуси стоит проверить не только текст, но и весь маршрут сообщения: API или SMPP-соединение, имя отправителя, статусы доставки и номера разных операторов. Такой тест помогает найти ошибки в интеграции, увидеть задержки и понять, какие сообщения операторская фильтрация принимает хуже. В статье разберём практический сценарий проверки, который можно выполнить до запуска основной кампании без сложной перестройки системы. Что именно нужно проверить до рассылки? Доставляемость складывается из нескольких этапов. Сначала ваша система формирует сообщение и передаёт его через API или SMPP-шлюз. Затем провайдер передаёт SMS оператору, оператор определяет маршрут, а телефон абонента возвращает статус. Сбой на любом участке изменит результат, поэтому одна тестовая отправка на один номер ничего не показывает. Для проверки подготовьте небольшую тестовую группу. В неё включите номера разных мобильных сетей, несколько устройств и разные типы телефонов. Если бизнес работает с клиентами в Минске, Бресте, Гомеле или небольших населённых пунктах, полезно проверить номера абонентов из разных регионов. Такой подход показывает, связана ли проблема с маршрутом, сетью или конкретной настройкой телефона. Зафиксируйте для каждого сообщения четыре момента: время отправки из вашей системы; время передачи сообщения шлюзу; статус доставки, который вернул провайдер; фактическое время получения SMS на телефоне. Сравнение этих данных помогает отделить техническую задержку от недоставки. Если система получила положительный ответ на запрос, это ещё не подтверждает, что абонент прочитал сообщение: нужен финальный статус доставки, или DLR. Как провести тест через API или SMPP? Начните с одного короткого сценария, который похож на будущую рассылку. Для магазина это может быть уведомление о готовности заказа, для салона или сервисной компании — напоминание о визите. Не используйте в тесте случайный текст: длина сообщения, кириллица, ссылка и специальные символы влияют на состав SMS и иногда приводят к разделению текста на несколько частей. Сначала отправьте сообщение на тестовый номер вручную. Затем повторите отправку через тот же API-метод или SMPP-сессию, который будет использовать рабочая система. Проверьте: корректность номера в международном формате; имя отправителя и его отображение на телефоне; кодировку кириллицы; длину текста и число сегментов; обработку ответа шлюза; приём DLR и связь статуса с конкретным сообщением. При работе по SMPP отдельно проверьте состояние соединения. Сессия должна корректно устанавливать bind, поддерживать соединение и обрабатывать ответы шлюза. Ошибка в команде или тайм-аут легко превращаются в очередь сообщений, которые приложение считает отправленными, хотя шлюз их не принял. Для небольшого проекта полезно заранее описать повторную отправку и исключить бесконечные повторы одного SMS. Практическая схема выглядит так: приложение создаёт уникальный идентификатор сообщения, отправляет SMS, сохраняет ответ шлюза, ждёт DLR и меняет итоговый статус только после получения результата. Если статус не пришёл за заданный интервал, запись попадает в отдельный список для проверки. Подход к обработке ошибок SMPP разобран в материале как автоматически обрабатывать ошибки SMPP и не терять SMS. Как понять результаты тестовой отправки? Разделите результаты на три группы. Первая — доставлено. Вторая — временная ошибка: телефон выключен, сеть недоступна или оператор ещё не завершил попытку доставки. Третья — постоянная ошибка: номер некорректен, маршрут запрещён или сообщение отклонено шлюзом. Не смешивайте эти статусы в один показатель, иначе вы не поймёте, что исправлять перед запуском. Результат проверки Что проверить Действие Сообщение не ушло из приложения Формат запроса, авторизацию, обязательные поля API или SMPP Исправить интеграцию и повторить тест Шлюз принял SMS, но DLR не пришёл Настройку DLR, идентификатор сообщения и обработчик статусов Проверить журнал событий и callback Есть задержка до телефона Время отправки, состояние сети и повторные попытки оператора Сравнить несколько тестовых номеров и интервалов Текст отображается неверно Кодировку, кириллицу, длину и специальные символы Сократить текст и привести кодировку к требованиям шлюза Сообщение не доставляется одному номеру Сам номер, состояние телефона и историю его статусов Проверить на другом устройстве и не делать вывод по одному абоненту Считайте отдельно долю успешной доставки и долю сообщений с неизвестным результатом. Последняя группа показывает качество мониторинга: если система не различает временную ошибку, постоянную ошибку и отсутствие DLR, управлять рассылкой будет трудно. В отчёте сохраните дату, текст, маршрут, тестовый номер и итоговый статус. Как проверить текст и имя отправителя? Одинаковое сообщение может выглядеть по-разному на устройствах. Проверьте переносы строк, ссылку, отображение кириллицы и наличие лишних символов. Если текст длинный, убедитесь, что телефон собирает сегменты в правильном порядке. Для теста отправьте короткую версию и вариант, близкий к максимальной длине будущего сообщения. Ссылка в SMS тоже требует отдельной проверки. Она должна открываться с мобильного устройства, вести на нужную страницу и сохранять понятный адрес. Сокращение ссылки иногда уменьшает длину сообщения, однако перед массовой отправкой протестируйте переход на нескольких телефонах. Не прячьте в коротком адресе критически важную информацию, если клиенту нужно сразу понять цель перехода. Имя отправителя проверяют отдельно от текста. Оно должно отображаться одинаково в тестовых сообщениях и в рабочем сценарии. Если при тесте используется один отправитель, а в массовой кампании будет другой, результат нельзя считать полным. Какие ошибки чаще всего портят тест? Проверка одного номера вместо группы с разными сетями и устройствами. Оценка доставки только по ответу API без финального DLR. Тест короткого текста, хотя в рассылке планируется длинное сообщение с кириллицей и ссылкой. Повторная отправка без ограничения количества попыток. Смешение тестовых и рабочих номеров в одном отчёте. Запуск всей базы сразу после первого удачного SMS. Для небольшой компании достаточно начать с контрольной партии, сохранить все статусы и только потом увеличивать объём. Если бизнесу нужен постоянный контроль, SMPP-шлюз и API-интеграция позволяют связать отправку с журналом сообщений, а аналитика трафика помогает видеть задержки, ошибки и качество маршрутов по периодам. Такая схема подходит и для напоминаний, и для уведомлений о заказах, когда результат доставки нужно проверять автоматически. 3 шага, которые можно сделать на этой неделе: Соберите тестовую группу номеров, подготовьте короткий и длинный вариант SMS. Отправьте сообщения через рабочий API или SMPP-сценарий и сохраните ответы вместе с DLR. Исправьте найденные ошибки, повторите проверку и запускайте массовую отправку только после сравнения результатов. > Source: https://smpp.by/kak-testirovat-dostavlyaemost-sms-pered-massovoy-rassylkoy --- # Как автоматически обрабатывать ошибки SMPP и не терять SMS Ошибки SMPP показывают, на каком участке сломалась отправка: приложение не прошло проверку, шлюз ограничил скорость, очередь переполнилась или оператор не принял сообщение. В статье разберём ESME_RTHROTTLED, ESME_RINVSRCADR и ESME_RMSGQFUL, покажем порядок диагностики и соберём схему автоматической обработки. После этого можно настроить повторные попытки, контроль очереди и уведомления так, чтобы сбой не превращался в потерю всей рассылки. Почему одного статуса «не доставлено» недостаточно? В SMPP результат состоит из нескольких событий. Сначала приложение отправляет запрос шлюзу и получает ответ на операцию. Затем система может принять сообщение в очередь, передать его оператору и вернуть финальный статус доставки через DLR. На каждом этапе возникают свои ошибки, поэтому запись «SMS не ушло» мало помогает разработчику. Начните с журнала, где для каждого сообщения сохраняются время отправки, идентификатор сообщения, команда SMPP, код ответа и текст ошибки. Идентификатор нужен для связи первоначального ответа с последующим DLR. Без него команда видит отдельные записи и не понимает, что произошло с конкретным SMS. Для быстрой проверки отправьте тестовое сообщение на несколько номеров и сравните результаты. Если ошибка появляется сразу при отправке, ищите проблему в сессии, адресах или параметрах запроса. Если запрос принят, но DLR сообщает отказ, проверяйте маршрут, содержимое сообщения и ограничения на стороне оператора. Такой подход соответствует базовой диагностике доставки SMS: анализу статусов через API, кодов ошибок и тестовых отправок (Проблемы с доставкой SMS: диагностика и решения). Что означает ESME_RTHROTTLED и как убрать ограничение скорости? ESME_RTHROTTLED обычно означает, что приложение отправляет сообщения быстрее, чем разрешает шлюз или текущая SMPP-сессия. Причина появляется при резком запуске рассылки, неправильном расчёте TPS или попытке отправить много сообщений параллельно через один bind. Повторять такой запрос сразу в плотном цикле не стоит. Приложение усилит нагрузку и получит ещё больше отказов. Сделайте паузу, уменьшите скорость и отправьте сообщение снова через отложенную очередь. Какая логика повторной отправки подходит для throttling? Зафиксируйте код ESME_RTHROTTLED и исходный message_id. Поставьте сообщение в очередь с задержкой, например на несколько секунд. Точный интервал выбирайте по правилам шлюза. Повторите отправку с увеличенным интервалом, если ограничение сохраняется. Остановите повтор после заданного числа попыток и передайте запись в журнал ошибок. Отдельно считайте принятые шлюзом сообщения и отклонённые запросы. Поток лучше ограничивать на стороне приложения. Для этого используют один планировщик, который выдаёт сообщения с заданной скоростью, а не каждый бизнес-процесс отправляет SMS напрямую. Если SMPP подключён к сайту, кассе или внутренней программе, между приложением и шлюзом полезно поставить единую очередь. Параметры скорости и число параллельных операций нужно согласовать с поставщиком SMPP. Для самостоятельной проверки соединения пригодится материал о скорости и стабильности SMPP-шлюза: там логично отделяются проблемы канала от ограничений отправки. Почему появляется ESME_RINVSRCADR? ESME_RINVSRCADR означает, что шлюз не принял адрес отправителя. В запросе может быть указан источник в неподдерживаемом формате, использовано незарегистрированное значение или передан адрес, который не соответствует настройкам соединения. Сначала сравните значение source_addr в рабочем и тестовом запросе. Проверьте пробелы, длину, кодировку и тип адреса. Для буквенного отправителя отдельно убедитесь, что система ожидает именно alphanumeric source address, а для цифрового источника проверьте формат номера. Распространённая ошибка возникает после переноса конфигурации: разработчик меняет отправителя в коде, но забывает обновить настройку шлюза. Ещё один вариант, когда поле заполняется автоматически из названия магазина и получает символы, которые маршрут не принимает. Что проверить по шагам? Посмотреть точное значение source_addr в журнале запроса. Сравнить его с параметрами учётной записи SMPP. Отправить тест с согласованным источником. Проверить, не меняет ли значение промежуточный API-адаптер. Если ошибка остаётся, запросить у поставщика допустимый формат source address для этого подключения. Не маскируйте ESME_RINVSRCADR повторной отправкой того же запроса. Код указывает на постоянную ошибку параметра, поэтому повтор лишь создаст лишние записи в очереди. Сначала исправьте конфигурацию, затем повторите сообщение один раз. Как исправить ESME_RMSGQFUL и контролировать очередь? ESME_RMSGQFUL сообщает, что очередь сообщений переполнена. Она может находиться на стороне шлюза или в вашем приложении. Различить эти варианты помогает момент возникновения ошибки: ответ сразу после submit_sm указывает на очередь шлюза, а задержка перед отправкой и рост локального backlog говорят о проблеме в приложении. Проверьте, сколько сообщений находится в локальной очереди, сколько обработчик отправляет за единицу времени и сколько запросов ждёт ответа. Затем сравните эти показатели с частотой появления ESME_RMSGQFUL. Если приложение складывает сообщения быстрее, чем шлюз их принимает, нужно снизить входной поток или увеличить число разрешённых каналов по согласованию с поставщиком. ПризнакВероятная причинаДействие Ошибка возникает сразуПереполнена очередь шлюзаПоставить отправку на паузу и уточнить состояние маршрута Локальная очередь постоянно растётПриложение принимает больше сообщений, чем отправляетОграничить входной поток и проверить обработчик После перезапуска появляются дублиПриложение не хранит состояние попыткиЗаписывать message_id и результат каждого запроса Ошибки приходят после массового запускаПиковая нагрузка превышает согласованную скоростьИспользовать планировщик и постепенный разгон Для очереди задайте предельный размер. Когда лимит достигнут, система должна временно остановить приём новых задач или сохранить их в устойчивом хранилище. Молчаливое удаление сообщений создаёт самый неприятный сценарий: бизнес считает рассылку запущенной, а часть клиентов не получает уведомление. Как построить автоматическую обработку кодов SMPP? Удобная схема начинается с классификатора ошибок. Приложение получает код, определяет его тип и выбирает действие. Временные ошибки отправляют на повтор, постоянные передают в журнал и уведомляют ответственного, а спорные статусы оставляют для ручной проверки по правилам конкретного шлюза. КодТип ошибкиАвтоматическое действие ESME_RTHROTTLEDВременное ограничение скоростиЗадержка, повтор с backoff, контроль TPS ESME_RINVSRCADRОшибка адреса отправителяОстановить повторы, проверить source_addr ESME_RMSGQFULПереполнение очередиПауза, ограничение входного потока, контроль backlog У каждой попытки должны быть статус, время, код ответа и причина следующего действия. Повторная отправка обязана иметь лимит. Если система не различает временный отказ и ошибку параметров, она либо перегружает шлюз, либо бесконечно отправляет заведомо некорректное сообщение. Для DLR используйте отдельный обработчик. Он принимает финальный статус, связывает его с message_id и обновляет запись сообщения. Если DLR не приходит в ожидаемый срок, создайте отдельное состояние «нет подтверждения» и проверьте канал, а не отправляйте SMS вслепую. Практическая схема работы с API, DLR и повторами описана в материале об отправке SMS о доставке через SMPP. Какие ошибки чаще всего мешают диагностике? Разработчик смотрит только на текст исключения и не сохраняет числовой код SMPP. Приложение повторяет ESME_RINVSRCADR без изменения параметров. После ESME_RTHROTTLED система делает мгновенные повторы в цикле. Локальная очередь не имеет лимита и занимает всё доступное место. В журнале нет message_id, поэтому ответ шлюза нельзя связать с SMS. Команда считает submit_sm подтверждением доставки и не обрабатывает DLR. Автоматизацию лучше вводить поэтапно. Сначала добавьте полный журнал и классификацию трёх кодов, затем подключите очередь с задержанными повторами, после этого настройте контроль DLR и уведомление о росте ошибок. На площадке smpp.by эти задачи можно связать с настройкой SMPP-шлюза, API-интеграцией и аналитикой трафика, чтобы причина сбоя была видна в данных, а не угадывалась по жалобам клиентов. 3 шага, которые можно сделать сегодня: Сохранить для каждого запроса message_id, код ответа, source_addr и время отправки. Разделить ESME_RTHROTTLED, ESME_RINVSRCADR и ESME_RMSGQFUL на временные и постоянные ошибки. Настроить очередь с задержанными повторами, лимитом попыток и отдельным контролем DLR. > Source: https://smpp.by/kak-avtomaticheski-obrabatyvat-oshibki-smpp-i-ne-teryat-sms --- # Как настроить SMPP-сессию с TLS для малого бизнеса SMPP-сессия с TLS шифрует соединение между вашим сервером и SMS-шлюзом. Это снижает риск перехвата логинов, паролей и текста сообщений во время передачи. В статье разберём, какие параметры проверить до подключения, как выбрать режим TLS, где разместить сертификат, как проверить bind и что делать при ошибке рукопожатия. После настройки вы сможете безопасно подключить интернет-магазин, CRM или внутреннюю систему к SMPP-шлюзу. Зачем малому бизнесу защищать SMPP-соединение? При обычном TCP-подключении приложение передаёт данные по сети без шифрования на уровне самого соединения. Если через SMPP уходят одноразовые коды, уведомления о заказах или платёжные сообщения, в трафике могут находиться и текст SMS, и параметры авторизации. TLS создаёт защищённый канал между двумя точками подключения. Для небольшого бизнеса это особенно важно, когда приложение работает на VPS, в офисной сети или через нестабильный интернет. Защищённая сессия не исправляет ошибки в коде приложения и не заменяет контроль доступа, но закрывает отдельный риск передачи данных по сети. SMPP и TLS решают разные задачи. SMPP определяет, как клиент отправляет сообщения, получает ответы и обрабатывает статусы. TLS защищает транспортное соединение, через которое идут эти команды. Подробная последовательность настройки сертификата и подключения разобрана в материале «Как настроить TLS для SMPP и защитить SMS-трафик». Какие параметры нужно согласовать до настройки TLS? Сначала запросите у провайдера технические параметры подключения. Одного логина и пароля недостаточно: клиенту нужно знать адрес шлюза, порт, разрешённый режим TLS и требования к сертификату. Зафиксируйте эти значения в отдельном файле конфигурации, чтобы разработчик и администратор использовали одну версию настроек. ПараметрЧто уточнить у провайдераЧто проверить на своей стороне Адрес SMPP-шлюзаDNS-имя или IP-адрес сервераДоступность адреса из сети приложения ПортПорт для TLS-подключенияРазрешён ли исходящий трафик в firewall Версия TLSПоддерживаемую версию протоколаПоддерживает ли её ОС и библиотека SMPP Проверка сертификатаНужна ли проверка цепочки или клиентский сертификатУстановлен ли доверенный CA-файл SMPP bindТип bind: transmitter, receiver или transceiverСовпадают ли system_id, password и system_type Ограничения соединенияЛимит сессий, скорость и тайм-аутыНе открывает ли приложение лишние подключения Не подставляйте порт из примера другого шлюза. У разных провайдеров TLS может работать на отдельном порту, а иногда его включают поверх уже согласованного SMPP-подключения. Если сервер принимает только соединения с разрешённых IP-адресов, добавьте IP вашего приложения в список доступа до первой проверки. Как проходит подключение SMPP через TLS? В типовой схеме приложение сначала устанавливает TCP-соединение с адресом и портом шлюза. Затем стороны выполняют TLS-рукопожатие: согласуют версию протокола, набор шифров и проверяют сертификат сервера. Только после успешного рукопожатия клиент отправляет SMPP-команду bind. Приложение разрешает DNS-имя шлюза и открывает TCP-соединение. TLS-клиент проверяет срок действия сертификата и имя сервера в сертификате. Клиент и сервер договариваются о параметрах защищённого канала. После рукопожатия приложение отправляет bind_transceiver или другой согласованный тип bind. Шлюз возвращает bind response с кодом результата. Приложение запускает Enquire Link и начинает отправку сообщений по установленной сессии. Проверяйте имя сервера именно так, как его указал провайдер. Подключение по IP при сертификате, выпущенном на DNS-имя, часто приводит к ошибке проверки имени. Отключать проверку сертификата ради быстрого запуска не стоит: соединение формально будет шифроваться, но приложение перестанет удостоверяться, с каким сервером оно связалось. Для рабочей системы задайте тайм-ауты отдельно для TCP, TLS и SMPP bind. Если один общий тайм-аут слишком большой, приложение будет долго ждать ответа при сбое. Если он слишком короткий, нестабильная сеть начнёт создавать лишние переподключения. Как проверить TLS и SMPP-bind без отправки клиентам? Начните с проверки сетевого доступа с того же сервера, где работает приложение. Затем проверьте TLS-рукопожатие штатными инструментами операционной системы или средствами библиотеки, которую использует SMPP-клиент. На этом этапе задача состоит в проверке сертификата и протокола, а не в отправке реального сообщения. После успешного TLS-теста выполните bind с тестовыми учётными данными. В журнале должны быть видны отдельные этапы: открытие TCP, успешное TLS-рукопожатие, отправка bind и положительный bind response. Не записывайте в лог пароль, полный текст одноразового кода и другие данные сообщения. СимптомВероятная причинаПроверка TCP-соединение не открываетсяFirewall, неверный адрес или портМаршрут, DNS и исходящие правила сети Ошибка сертификатаИстёк сертификат, не найден CA или не совпало имяСрок действия, цепочка доверия и hostname TLS установился, bind отклонёнНеверные SMPP-учётные данные или тип bindsystem_id, password, system_type и bind mode Сессия сразу закрываетсяНесовместимая версия TLS, тайм-аут или лимит сессийЛоги обеих сторон и параметры провайдера Сообщения не отправляются после bindОшибка в submit_sm или ограничение маршрутаcommand_status, message_id и DLR После тестового bind отправьте одно контрольное сообщение на внутренний номер, если такая проверка разрешена настройками шлюза. Затем проверьте submit_sm_resp и статус доставки. Для разбора причин недоставки пригодится материал «Почему SMS не доходит до клиента: разбор DLR в SMPP». Какие ошибки чаще всего ломают TLS-сессию? Приложение подключается к TLS-порту без включения TLS-клиента или, наоборот, пытается начать обычный SMPP-диалог на порту TLS. В конфигурации указан IP-адрес, хотя сертификат выпущен для DNS-имени шлюза. На сервере приложения отсутствует актуальная цепочка доверенных сертификатов. Разработчик отключил проверку сертификата и не заметил ошибку конфигурации. Пароль SMPP хранится в исходном коде или попадает в журнал при ошибке bind. Приложение создаёт новую сессию после каждого сбоя, не закрывая старую, и упирается в лимит подключений. Для защиты доступа ограничьте SMPP-соединения исходящими правилами firewall и разрешёнными IP-адресами, если это поддерживает инфраструктура провайдера. Данные доступа храните в переменных окружения или защищённом хранилище. При смене пароля сначала подготовьте новую конфигурацию, затем перезапустите одну тестовую копию приложения и только после проверки обновите рабочую. Если SMS отправляет несколько бизнес-систем, не копируйте настройки TLS вручную в каждой из них. Вынесите подключение в отдельный сервис или общий конфигурационный модуль. Так проще обновить сертификат, изменить порт и контролировать переподключения. Для резервного маршрута заранее описывают отдельную сессию и правила переключения, чтобы сбой основного шлюза не создавал дубли сообщений. Для практической проверки стабильности соединения можно использовать отдельный сценарий с периодическим Enquire Link и журналом bind, submit_sm_resp и DLR. Материал «Как проверить скорость и стабильность SMPP-шлюза» поможет отделить проблемы TLS от ограничений пропускной способности. 3 шага, которые можно сделать сегодня: Запросить у провайдера адрес, TLS-порт, версию протокола, требования к сертификатам и параметры bind. Проверить TCP и TLS с сервера приложения, не отключая проверку имени и цепочки сертификата. Выполнить тестовый bind, записать технические статусы без паролей и проверить одну отправку вместе с DLR. > Source: https://smpp.by/kak-nastroit-smpp-sessiyu-s-tls-dlya-malogo-biznesa --- # Как настроить SMPP-шлюз для статусов ремонта с DLR Для уведомлений о ремонте техники удобно связать учётную систему мастерской с SMPP-шлюзом и отправлять SMS после каждого изменения статуса заказа. В статье разберём схему интеграции, параметры подключения, формат сообщения, обработку DLR и повторную отправку. В результате разработчик сможет собрать понятный процесс: система фиксирует событие, шлюз принимает SMS, оператор возвращает статус доставки, а программа сохраняет результат рядом с заказом. Какие статусы ремонта стоит передавать клиенту? Сначала определите события, которые действительно требуют сообщения. Для небольшой мастерской обычно достаточно статусов «заказ принят», «диагностика завершена», «согласование стоимости», «ремонт завершён» и «техника готова к выдаче». Названия зависят от вашей учётной системы, но каждое событие должно иметь отдельный код или понятное условие запуска. Например, после смены статуса на «готово к выдаче» система формирует сообщение: «Заказ №482 готов. Заберите технику в рабочее время». Номер заказа помогает клиенту быстро объяснить ситуацию сотруднику, а короткий текст уменьшает риск обрезания сообщения на телефоне. Для каждого SMS сохраните минимум четыре значения: идентификатор заказа; номер телефона в международном формате; код события, например repair_ready или repair_approved; внутренний идентификатор сообщения. Внутренний идентификатор особенно нужен для DLR. По нему система связывает технический ответ шлюза с конкретным SMS и заказом клиента. Практический разбор автоматизации уведомлений о ремонте можно посмотреть в материале об автоматизации SMS о статусе ремонта техники. Как выглядит схема интеграции SMPP? В простом варианте участвуют три компонента: программа, где хранятся заказы, SMPP-клиент и SMS-шлюз. Система ремонта не обращается к шлюзу напрямую из каждого экрана. Она создаёт событие и передаёт задачу отдельному модулю отправки. Такой подход позволяет повторить отправку после временного сбоя и не задерживать работу оператора. Сотрудник меняет статус заказа. Система создаёт запись в очереди SMS. SMPP-клиент устанавливает соединение со шлюзом. Клиент отправляет сообщение командой submit_sm. Шлюз возвращает идентификатор принятого сообщения. После попытки доставки шлюз передаёт DLR через deliver_sm. Программа обновляет результат в журнале заказа. Отдельная очередь нужна даже при небольшом объёме. Если шлюз временно недоступен, заказ не потеряется: запись останется в базе со статусом pending или retry. После восстановления соединения отправитель продолжит обработку с последней незавершённой записи. При подключении провайдер обычно передаёт адрес SMPP-сервера, порт, логин, пароль, разрешённый источник SMS и параметры скорости отправки. Эти значения нельзя зашивать в код. Храните их в конфигурации, а пароль ограничьте доступом для процесса отправки. Какие параметры нужно настроить в SMPP-клиенте? Соединение начинают с команды bind_transceiver, если один канал должен и отправлять SMS, и принимать DLR. В настройках указывают system_id, пароль, тип bind и тайм-ауты. После подключения клиент должен отправить enquire_link. Эта служебная команда проверяет, что соединение ещё отвечает. Для каждого сообщения проверьте следующие поля: source_addr, то есть имя отправителя, согласованное со шлюзом; destination_addr, номер получателя; data_coding, кодировка текста; registered_delivery, запрос отчёта о доставке; short_message или message_payload, поле с текстом SMS; service_type и esm_class, если их требует конкретная конфигурация шлюза. Поле registered_delivery должно быть включено для сообщений, по которым нужен отчёт. Если его не передать или задать неверно, SMS может уйти клиенту, но приложение не получит ожидаемый DLR. Точные значения полей проверяют по документации выбранного SMPP-шлюза и тестируют на отдельном номере. Длина текста влияет на кодировку и количество частей. Кириллица часто переводит сообщение в Unicode, поэтому в одном SMS помещается меньше символов, чем при использовании GSM-алфавита. Перед отправкой полезно посчитать число сегментов и записать его в журнал: тогда бухгалтерия и технический специалист увидят, почему одна операция создала несколько SMS. Как обработать DLR и повторные попытки? DLR содержит технический результат доставки. В зависимости от шлюза и оператора в нём встречаются статусы DELIVERED, EXPIRED, UNDELIVERABLE, REJECTED или UNKNOWN. Программа должна сохранять исходную строку DLR, распознанный статус, время получения и идентификатор сообщения. РезультатЧто записать в системеДействие DELIVEREDSMS доставленоЗавершить обработку сообщения EXPIREDИстёк срок ожидания доставкиПроверить срок действия заказа и канал связи UNDELIVERABLEШлюз не доставил SMSЗафиксировать ошибку, повтор не запускать без правила REJECTEDСообщение отклоненоПроверить номер, отправителя и параметры запроса UNKNOWNРезультат не распознанСохранить DLR и передать запись на разбор Повторная отправка нужна только для временных ошибок. Например, приложение может повторить попытку после разрыва SMPP-соединения или временной недоступности шлюза. Повторять SMS после любого неуспешного DLR рискованно: клиент получит дубликат, если первый отчёт пришёл с задержкой. Для защиты от дублей добавьте ключ идемпотентности: order_id плюс event_code. Если статус «готово» уже породил отправленное сообщение, повторный запуск обработчика не должен создавать вторую запись. Для каждой попытки храните номер попытки и причину повторной отправки. Если DLR не приходит, это не всегда означает, что SMS не доставлено. Сначала проверьте флаг registered_delivery, обработчик deliver_sm, фильтр по message_id и журнал сетевого соединения. Отдельный разбор причин недоставки есть в материале почему SMS не доходит до клиента и как читать DLR в SMPP. Как проверить шлюз до запуска в рабочем режиме? Тестирование лучше разделить на несколько сценариев. Сначала отправьте короткое SMS на тестовый номер и проверьте submit_sm_resp. Затем убедитесь, что приложение принимает deliver_sm и связывает его с правильным message_id. После этого проверьте кириллицу, длинное сообщение, неверный номер и разрыв соединения во время отправки. В журнале должны быть видны время события, номер заказа, номер получателя в маскированном виде, результат submit_sm, message_id, текст DLR и итоговый статус. Логи помогают найти ошибку без ручного просмотра базы. Полный переход от отправки до отчёта лучше проверять на копии рабочего контура, чтобы тестовый SMS не изменил реальный статус ремонта. Типичные ошибки при настройке SMPP и DLR Система отправляет SMS прямо из интерфейса оператора и зависает при проблемах со шлюзом. Программа не сохраняет message_id, поэтому DLR нельзя связать с заказом. Флаг запроса доставки не включён в submit_sm. Обработчик принимает только один формат статуса и теряет неизвестные значения. Повторная отправка запускается без проверки предыдущей попытки. Текст статуса содержит слишком много деталей, из-за чего сообщение разбивается на несколько частей. 3 шага, которые можно сделать на этой неделе: Составить список событий ремонта и связать каждое событие с шаблоном SMS. Добавить очередь отправки, message_id и журнал DLR в техническое задание. Проверить submit_sm, deliver_sm, разрыв соединения и повторную попытку на тестовом заказе. Когда сценариев становится больше, мастерской нужен отдельный SMPP-модуль с очередью, контролем соединения и обработкой DLR. Такой контур можно подключить к существующей системе учёта, не меняя рабочий процесс сотрудников: оператор меняет статус заказа, а техническая часть сама отправляет SMS и сохраняет результат доставки. > Source: https://smpp.by/kak-nastroit-smpp-shlyuz-dlya-statusov-remonta-s-dlr --- # Как отправлять SMS о доставке через SMPP: API, DLR и повторы SMS-уведомления о заказах через SMPP строятся вокруг связки из трёх компонентов: API службы доставки, внутреннего обработчика статусов и SMS-шлюза. API передаёт событие, например создание отправления или готовность к выдаче, а SMPP доставляет текст на телефон клиента. В статье разберём архитектуру интеграции для служб доставки, настройку DLR, правила повторных попыток и контроль ошибок. Такой подход подходит интернет-магазину, пункту выдачи и сервису, который отправляет сообщения через Европочту, СДЭК или другую службу. Как связать API службы доставки с SMPP? Служба доставки обычно отдаёт статусы отправления через API. В зависимости от конкретной документации система может получать их по запросу или принимать через webhook. В обоих случаях бизнес-приложению нужен отдельный обработчик событий. Он сопоставляет номер заказа с телефоном клиента, выбирает шаблон SMS и передаёт сообщение в SMPP-шлюз. Логика выглядит так: заказ получает статус «создан», «принят перевозчиком», «прибыл в пункт выдачи» или «передан курьеру». Обработчик проверяет, отправлялось ли уведомление по этому статусу, и формирует задачу на отправку. После этого приложение открывает SMPP-сессию, выполняет bind и передаёт сообщение командой submit_sm. Для малого бизнеса лучше сразу хранить у события несколько полей: идентификатор заказа, код статуса, время получения, телефон, текст сообщения и состояние отправки. Это помогает не отправлять клиенту одно и то же SMS при повторной выдаче события API. Уникальным ключом может быть сочетание номера заказа и кода статуса. Если магазин уже отправляет SMS через HTTP API, переход на SMPP можно подготовить поэтапно: сначала вынести отправку в отдельный сервис, затем заменить транспорт, сохранив очередь и шаблоны. Практические вопросы такой миграции разобраны в материале как перейти с HTTP API на SMPP без потери SMS. Какие параметры SMPP нужны для уведомлений о заказе? До подключения разработчик получает от SMS-провайдера параметры SMPP-сессии: адрес шлюза, порт, логин, пароль, тип bind и допустимый sender. Приложение должно поддерживать соединение, обрабатывать ответы шлюза и восстанавливать сессию после разрыва. Пароль и настройки подключения хранят в конфигурации сервера, а не в исходном коде. Команда submit_sm подтверждает, что шлюз принял сообщение на обработку. Она сама по себе не доказывает доставку на телефон. Для контроля результата провайдер возвращает DLR, то есть отчёт о статусе сообщения. Поэтому в запросе нужно включить получение delivery receipt и передать собственный идентификатор сообщения. При кодировке текста учитывайте кириллицу. Длинное уведомление может разделиться на несколько SMS, а итоговое число частей зависит от выбранной кодировки и длины текста. В шаблоне оставляют только данные, которые нужны клиенту: статус, способ получения, ориентир по времени и номер заказа. Ссылку на страницу отслеживания лучше сокращать заранее, чтобы не расходовать длину сообщения на длинный адрес. КомпонентЧто делаетЧто проверить при тестировании API службы доставкиПередаёт изменение статуса отправленияЕсть ли идентификатор заказа, статус и время события Обработчик событийВыбирает шаблон и ставит SMS в очередьНе создаётся ли повторная задача для одного статуса SMPP-сессияПередаёт сообщение SMS-шлюзуОбрабатываются ли bind, submit_sm_resp и разрыв соединения DLR-обработчикФиксирует результат доставкиСопоставляется ли receipt с исходным message_id Как настроить DLR и отличить доставку от принятия? DLR нужно сохранять отдельно от ответа на submit_sm. В базе полезно иметь как минимум состояния «создано», «принято шлюзом», «доставлено», «не доставлено» и «истёк срок ожидания». Ответ шлюза подтверждает приём сообщения, а DLR позже показывает результат попытки доставки. Разбор этой разницы и кодов ошибок приведён в статье почему SMS не доходит до клиента: разбор DLR в SMPP. Обработчик DLR получает идентификатор сообщения, статус и технический текст ошибки, если оператор его передал. Идентификаторы иногда имеют разный формат: один шлюз возвращает число, другой добавляет префикс или меняет регистр. Поэтому при сопоставлении лучше нормализовать значение, но исходный DLR сохранять полностью для диагностики. Для клиента достаточно понятного результата. Внутри системы сохраняют технический код, время получения отчёта и номер попытки. Если сообщение не доставлено, оператор интернет-магазина видит причину в журнале, а покупатель не получает несколько одинаковых уведомлений подряд. Когда запускать повторную попытку отправки? Повтор нужен только для временных ошибок. Например, очередь можно вернуть на отправку после временного отказа шлюза, разрыва SMPP-сессии или недоступности сервиса. Постоянные ошибки, такие как некорректный номер или запрет доставки, повторной отправкой не исправляются. Для очереди задают ограничение по числу попыток и паузу между ними. Первая повторная отправка выполняется через короткий интервал, следующая через более длинный. Точное значение зависит от нагрузки и требований бизнеса, поэтому его проверяют на тестовом трафике. Одновременный запуск нескольких обработчиков не должен отправлять одну задачу дважды: помогает блокировка записи или уникальный идентификатор операции. После каждой попытки записывайте причину результата. Если приложение повторяет отправку при любой ошибке, временный сбой быстро превращается в дублирование SMS. Если оно никогда не повторяет задачу, клиент может не получить сообщение из-за краткого разрыва соединения. Как протестировать интеграцию до запуска? Начните с тестового заказа и одного номера. Проверьте, что событие из API создаёт одну задачу, SMPP возвращает ответ, а DLR связывает результат с правильным заказом. Затем отдельно смоделируйте повторное событие от службы доставки и убедитесь, что второе SMS не появляется. Проверьте четыре сценария: успешную доставку, временную ошибку, постоянную ошибку и разрыв SMPP-сессии. В журнале должны быть видны время события, идентификатор заказа, message_id, номер попытки и итоговый статус. Телефон клиента в технических логах лучше маскировать, чтобы оператор видел только необходимую часть номера. Шаблоны проверяют на коротком и длинном тексте, с латиницей и кириллицей. Отдельно смотрят, сколько частей SMS сформировал шлюз. Для автоматизации статусов интернет-магазина полезно сопоставить эту схему с материалом как автоматизировать SMS-статусы доставки интернет-магазина через SMPP. Типичные ошибки Считать ответ submit_sm_resp подтверждением доставки абоненту. Не сохранять message_id и потом не уметь связать DLR с заказом. Отправлять SMS при каждом повторном событии API без проверки предыдущего статуса. Повторять сообщение после постоянной ошибки номера. Не ограничивать длину шаблона и получать несколько частей SMS вместо одной. Перезапускать SMPP-сессию без контроля уже отправленных задач. 3 шага, которые можно сделать на этой неделе: Описать карту статусов службы доставки и выбрать, какие события действительно требуют SMS. Добавить очередь с message_id, номером попытки и отдельным обработчиком DLR. Провести тесты на успешной доставке, временной ошибке, постоянном отказе и повторном событии API. > Source: https://smpp.by/kak-otpravlyat-sms-o-dostavke-cherez-smpp --- # Как подключить LLM к SMPP для обработки входящих SMS LLM можно подключить к SMPP как отдельный слой обработки: шлюз принимает входящее MO-сообщение, передаёт его в приложение, а модель определяет намерение клиента и формирует черновик ответа. Затем бизнес-логика проверяет результат и отправляет SMS через SMPP. В статье разберём архитектуру, формат обмена, защиту от ошибочных ответов, обработку статусов доставки и порядок запуска такого сценария для малого бизнеса в Беларуси. Как связать входящее SMS, LLM и SMPP-шлюз? SMPP отвечает за транспорт сообщений между приложением и SMS-центром. Нейросеть не подключают к SMPP напрямую: между ними нужен небольшой сервис-посредник. Он принимает MO-сообщение от шлюза, передаёт текст в LLM и после проверки отправляет ответ как MT-сообщение. Типовая схема выглядит так: Клиент отправляет SMS на номер компании. SMPP-шлюз передаёт приложению PDU с MO-сообщением. Приложение извлекает номер отправителя, текст, идентификатор сообщения и время получения. Маршрутизатор выбирает сценарий: заявка, вопрос, отмена записи или неизвестная команда. LLM получает только необходимый контекст и предлагает классификацию либо текст ответа. Правила приложения проверяют результат. Шлюз отправляет ответ клиенту через submit_sm. Система сохраняет технический результат и связывает его с исходным сообщением. Для приёма SMS пригодится отдельная настройка MO-трафика. В SMPP это обычно означает корректный bind, обработку deliver_sm и разбор полей source_addr, destination_addr, short_message или message_payload. Практический разбор такого сценария есть в материале как принимать ответы на SMS через SMPP. LLM в этой цепочке лучше использовать как классификатор и генератор ограниченного ответа. Она не должна самостоятельно решать, кому отправлять сообщение, сколько раз повторять отправку или какой код ошибки считать успешным. Эти действия остаются в программном коде. Какие данные передавать языковой модели? Запрос к модели стоит собирать из коротких частей: текст входящего SMS, название сценария, допустимые действия и формат результата. Например, для магазина можно задать категории «статус заказа», «изменить время доставки», «отменить заявку» и «непонятный запрос». В ответ приложение получает структурированный результат, а не свободный текст. Пример формата ответа LLM: ПолеНазначениеПример intentОпределяет намерение клиентаorder_status confidenceПоказывает уверенность классификации0.86 reply_keyКлюч готового шаблонаstatus_received needs_operatorПередаёт диалог сотрудникуfalse Для малого бизнеса безопаснее отправлять клиенту заранее подготовленные шаблоны. Модель выбирает подходящий шаблон и подставляет разрешённые параметры, например номер заявки или время обратной связи. Свободный текст можно оставить для внутреннего черновика, который проверяет сотрудник. Если сообщение короткое и неоднозначное, приложение может ответить уточняющим вопросом. Например: «Напишите 1, чтобы узнать статус заказа, или 2, чтобы отменить заявку». Такой сценарий легче тестировать, чем длинный ответ, созданный моделью с нуля. Как настроить обработку MO-сообщений в приложении? Сначала определите формат события, которое шлюз передаёт приложению. В нём нужны технические поля: идентификатор сообщения, адрес отправителя, адрес получателя, текст, кодировка и время приёма. Если шлюз передаёт длинные SMS частями, приложение должно собрать их до передачи в LLM. Затем добавьте очередь входящих событий. Она отделяет приём SMS от обращения к модели и от отправки ответа. Если LLM временно не отвечает, SMPP-соединение продолжает принимать сообщения, а очередь повторяет обработку по заданному правилу. Для каждого сообщения полезно хранить отдельный технический статус: received — шлюз принял MO-сообщение; queued — событие поставлено в очередь; classified — модель определила сценарий; approved — ответ прошёл правила приложения; submitted — запрос на отправку передан в SMPP; delivered или failed — получен финальный статус доставки. Идентификатор исходного MO нужно связывать с идентификатором ответного MT. Тогда сотрудник увидит полную цепочку: что написал клиент, какой сценарий выбрала модель, какой ответ отправило приложение и чем закончилась доставка. После submit_sm не следует считать SMS доставленной. SMPP возвращает подтверждение приёма запроса шлюзом, а окончательный результат приходит через delivery receipt. Для диагностики недоставленных сообщений полезно разобрать DLR и коды ошибок по инструкции о том, почему SMS не доходит до клиента в SMPP. Какие правила ограничивают ответы LLM? Перед отправкой ответа приложение проверяет длину, язык, запрещённые конструкции и наличие обязательного шаблона. Если модель вернула пустой текст, лишние инструкции или неизвестный reply_key, сообщение не отправляется. Вместо него система выбирает нейтральный шаблон или передаёт обращение сотруднику. Набор правил можно оформить так: отправлять ответ только при известном intent; использовать только зарегистрированные шаблоны; ограничить число ответов на одно входящее сообщение; не повторять отправку без проверки submit_sm_resp; отдельно обрабатывать STOP, HELP и другие служебные команды; переводить диалог оператору после нескольких неудачных классификаций. Ограничение числа сообщений защищает клиента от зацикливания. Например, если ответ модели снова вызывает входящее SMS и запускает тот же сценарий, приложение должно определить повтор по идентификатору, тексту и времени события. Для заявок удобно разделить автоматические и ручные ответы. Модель распознаёт сообщение «нужен замер в субботу», создаёт карточку обращения и отправляет короткое подтверждение: «Заявка принята. Сотрудник уточнит время». Детали сотрудник обрабатывает в рабочем интерфейсе, а SMPP используется для обмена короткими уведомлениями. Как тестировать связку LLM и SMPP до запуска? Тестирование нужно проводить по слоям. Сначала проверяется сам SMPP-канал: bind, приём deliver_sm, submit_sm и delivery receipt. Затем тестируется очередь. После этого подключается модель, чтобы ошибка в LLM не маскировалась под проблему доставки SMS. ЭтапЧто проверитьОжидаемый результат MO-приёмКодировку, длинные сообщения, повторную доставкуТекст собирается один раз и без искажений КлассификацияПонятные и неоднозначные фразыСистема выбирает intent или передаёт диалог оператору ГенерацияПустой ответ, лишний текст, неизвестный ключПриложение блокирует неподходящий результат MT-отправкаsubmit_sm_resp, message_id, DLRОтвет получает технический статус СбойНедоступность LLM или SMPPСообщение попадает в очередь повторной обработки Для проверки берите реальные типы фраз, но не ограничивайтесь идеальными примерами. Добавьте опечатки, сокращения, смешение русского и белорусского языков, повторные SMS и сообщения без понятного вопроса. Отдельно проверьте, что ответ не превышает допустимый размер SMS и корректно учитывает кодировку. На этапе пилота полезно отправлять часть классификаций в журнал без автоматического ответа. Сотрудник сравнит решение модели с фактическим намерением клиента. После этого можно включить автоматическую отправку только для сценариев, где правила дают предсказуемый результат. Типичные ошибки при подключении LLM к SMPP Модель подключают прямо к SMPP без очереди и получают потерю событий при временном сбое. Приложение считает submit_sm_resp подтверждением доставки клиенту и не анализирует DLR. В запрос к LLM передают весь диалог, хотя для классификации достаточно последнего сообщения и короткого контекста. Свободный ответ модели отправляют без проверки длины, кодировки и допустимых шаблонов. Не обрабатывают составные SMS и получают обрезанный текст. Не связывают MO, MT и DLR по идентификаторам, поэтому сотрудник не может восстановить историю заявки. Если текущая система уже отправляет SMS через HTTP API, переход на SMPP лучше планировать отдельно от подключения LLM. Сначала проверьте приём, отправку и статусы в новом канале, а затем добавьте классификацию входящих сообщений. Такой порядок описан в материале как перейти с HTTP API на SMPP без потери SMS. 3 шага, которые можно сделать на этой неделе: Описать два или три сценария входящих SMS и подготовить для каждого короткий шаблон ответа. Собрать тестовый обработчик MO-сообщений с очередью, журналом событий и передачей структурированного запроса в LLM. Проверить связку на тестовых сообщениях, затем включить автоматический ответ только после контроля submit_sm_resp и DLR. > Source: https://smpp.by/kak-podklyuchit-llm-k-smpp-dlya-obrabotki-vkhodyaschikh-sms --- # Как перейти с HTTP API на SMPP без потери SMS Переход с HTTP API на SMPP требует поэтапной настройки: сначала сравните форматы сообщений, затем поднимите отдельное SMPP-подключение, проведите тестовые отправки и только после этого переключайте трафик. В статье разберём миграцию для малого бизнеса в Беларуси: какие параметры проверить, как обработать подтверждения доставки DLR, где оставить HTTP API на время перехода и как откатиться при ошибке. Когда бизнесу нужен переход с HTTP API на SMPP? HTTP API удобно подключить к сайту или внутренней программе: приложение отправляет HTTP-запрос, получает ответ сервера и продолжает работу. Такой вариант подходит для небольшого объёма сообщений и простого сценария уведомлений. Когда трафик растёт, появляется потребность в постоянном соединении, контроле очереди и более подробной работе со статусами, SMPP становится отдельным вариантом для интеграции. SMPP особенно уместен, если приложение отправляет большой поток транзакционных SMS: коды подтверждения, уведомления о заказе, напоминания о записи или сообщения о платеже. Протокол поддерживает двусторонний обмен с SMS-платформой. Через него можно отправлять сообщения и принимать отчёты о доставке, а при подходящей настройке также получать входящие SMS. Решение о миграции лучше принимать после проверки текущего HTTP API. Зафиксируйте, какие поля использует приложение: номер получателя, текст, имя отправителя, внутренний идентификатор сообщения, время отправки и статус. Если система сейчас считает успешным сам факт принятия HTTP-запроса, это ещё не подтверждает доставку SMS абоненту. Для понимания DLR полезен отдельный разбор статусов доставки SMS в SMPP. Критерий HTTP API SMPP Подключение Отдельный запрос на каждую операцию или группу операций Постоянная сессия между приложением и SMS-платформой Контроль обмена Результат приходит в HTTP-ответе Приложение получает ответы протокола и отдельные DLR Очередь сообщений Часто реализуется внутри приложения или API-поставщика Можно управлять отправкой через последовательность SMPP-операций Миграция Исходная схема уже работает Нужно настроить bind, кодировку, идентификаторы и обработчики статусов Как подготовить HTTP-интеграцию к миграции? Начните с карты текущего процесса. Для каждого типа SMS запишите, какое событие запускает отправку, откуда берётся номер, какой текст формируется и где система сохраняет результат. Отдельно отметьте повторные попытки. Без такой схемы после переключения трудно понять, потерялось ли сообщение в приложении, очереди или на этапе передачи провайдеру. Сохраните исходный идентификатор сообщения. В SMPP для сопоставления отправки и DLR используется message_id, который возвращает SMS-платформа. В базе данных удобно хранить его рядом с внутренним ID заказа или операции. Тогда обработчик отчёта сможет найти нужную запись даже при задержке доставки. Подготовьте единый внутренний статус. Например, приложение может различать «создано», «передано в SMPP», «доставлено», «не доставлено» и «истёк срок ожидания». Названия не принципиальны. Важно, чтобы временный ответ submit_sm не смешивался с финальным результатом доставки. До запуска запросите у SMPP-поставщика параметры подключения: адрес и порт, логин, пароль, тип bind, допустимое количество одновременных соединений, правила отправки имени отправителя, формат DLR и ограничения скорости. Эти данные нельзя угадывать по документации другого сервиса. От них зависит код подключения и обработка ошибок. Как настроить SMPP-подключение и кодировку? Для исходящей отправки приложение обычно открывает TCP-соединение и выполняет bind_transmitter либо bind_transceiver. В режиме transmitter система отправляет SMS, а в режиме transceiver может также принимать DLR и MO-сообщения через ту же сессию. Подходящий режим зависит от параметров поставщика и архитектуры приложения. После bind приложение должно поддерживать соединение. SMPP использует enquire_link для проверки доступности сессии, а на ответ сервера нужно реагировать в пределах настроенного тайм-аута. При разрыве соединение открывают заново с ограниченной задержкой между попытками. Бесконечный цикл мгновенных переподключений создаёт лишнюю нагрузку и затрудняет диагностику. Проверьте кодировку до отправки первой рабочей партии. Для латиницы и кириллицы применяются разные значения DCS: в документации МТС для интеграции по SMPP указаны DCS 0x03 для латинского текста и DCS 0x08 для кириллицы (МТС Поддержка для бизнеса). Если сообщение не помещается в один сегмент, приложению нужно корректно формировать составное SMS и учитывать длину текста в выбранной кодировке. Имя отправителя, номер назначения и текст передавайте в формате, который согласован с поставщиком. Ошибка в source_addr, неверный TON/NPI или неподдерживаемый формат номера приводит к отказу ещё до передачи SMS оператору. В журнале сохраняйте команду и код результата без паролей и других секретов подключения. Как провести тестовую отправку? Сначала отправьте тестовое сообщение на один разрешённый номер. Проверьте четыре результата: bind прошёл, submit_sm вернул успешный ответ, DLR пришёл в обработчик, а внутренний статус изменился. Затем повторите тест с кириллицей, длинным текстом и несколькими параллельными сообщениями. Тестируйте также отрицательные сценарии. Укажите некорректный номер, временно остановите обработчик DLR, разорвите соединение и проверьте повторную отправку. Система не должна создавать дубликат, если ответ на submit_sm потерялся, но сообщение уже принято платформой. Для этого нужен устойчивый идентификатор операции и понятное правило повторов. Как перенести трафик без потери сообщений? Безопаснее запускать SMPP параллельно с HTTP API. Сначала приложение формирует сообщение в общей очереди, затем отдельный отправитель выбирает канал. На тестовом этапе через SMPP проходит ограниченная доля очереди, а HTTP API остаётся резервом. Процент распределения выбирайте по объёму, который можно проверить вручную, без резкого переключения всего трафика. Во время параллельной работы сравнивайте не только количество принятых запросов. Сопоставляйте внутренние ID, ответы submit_sm, коды ошибок, время получения DLR и финальные статусы. Если HTTP API сообщает об успехе, а SMPP возвращает ошибку кодировки или адреса, причину нужно устранить до расширения доли SMPP-трафика. Для каждого сообщения определите владельца отправки. Если после тайм-аута приложение автоматически повторяет операцию через другой канал, оно рискует отправить SMS дважды. Надёжнее сначала проверить, сохранился ли message_id и был ли получен результат от платформы. При отсутствии такой возможности задайте отдельный флаг «результат неизвестен» и разберите его в журнале. После успешного теста переключите один сценарий, например уведомления о статусе заказа. Несколько рабочих дней собирайте технические логи и проверяйте обращения клиентов. Затем переносите остальные сценарии. HTTP API удаляйте только после того, как очередь, DLR и откат проверены на реальном потоке. Какие ошибки чаще всего мешают миграции? Считать ответ submit_sm доказательством доставки. Он подтверждает приём операции, а итоговый результат приходит через DLR. Перенести текст без проверки DCS. Кириллица и латиница могут использовать разные значения кодировки. Не сохранять message_id. Без него сложно связать отчёт доставки с заказом или другой операцией. Настроить повторную отправку после любого тайм-аута. При потерянном ответе сообщение могло уже попасть в очередь поставщика. Проверить только один короткий текст. Отдельно нужны тесты кириллицы, длинного сообщения, неверного номера и разрыва соединения. Сразу отключить HTTP API. Резервный канал нужен до завершения сверки статусов и проверки отката. Если приложение должно принимать ответы абонентов, заранее продумайте обработчик MO-сообщений: в SMPP входящие SMS приходят отдельно от DLR, поэтому их нельзя смешивать в одном статусе. Практическая схема такого обмена описана в материале «Как принимать ответы на SMS через SMPP». 3 шага, которые можно сделать на этой неделе: Составьте таблицу текущих HTTP-полей, внутренних ID, повторов и статусов. Поднимите тестовую SMPP-сессию, проверьте bind, DCS, submit_sm и получение DLR. Переведите один сценарий на общую очередь с резервом HTTP API и сравните результаты по каждому message_id. > Source: https://smpp.by/kak-pereyti-s-http-api-na-smpp-bez-poteri-sms --- # Как отправлять SMS о платежах через ЕРИП по SMPP Для автоматического SMS о поступлении оплаты через ЕРИП бизнесу нужны три компонента: источник события об оплате, промежуточный обработчик и SMPP-шлюз. Система получает подтверждение платежа, проверяет его и передаёт в шлюз команду на отправку сообщения. В статье разберём схему интеграции для малого бизнеса Беларуси, формат данных, статусы доставки и тестирование. Такой подход подходит интернет-магазину, сервису с регулярными платежами и компании, которая хочет уведомлять клиента сразу после оплаты. Как связать оплату через ЕРИП и SMPP? SMPP не подключается к ЕРИП напрямую по умолчанию. Протокол отвечает за обмен SMS между вашей программой и SMS-шлюзом, а сведения об оплате поступают из платёжной системы или программного интерфейса, который предоставляет ваш банк либо платёжный партнёр. Между ними нужен небольшой интеграционный слой. Логика выглядит так: Покупатель оплачивает счёт через ЕРИП. Платёжная сторона передаёт системе уведомление об успешной оплате. Обработчик проверяет идентификатор заказа, сумму и состояние операции. Система формирует текст SMS. SMPP-клиент отправляет сообщение в SMS-шлюз. Шлюз возвращает идентификатор сообщения и передаёт отчёт о доставке через DLR. Внутренний обработчик лучше отделить от сайта или кассовой программы. Тогда временная ошибка в одном компоненте не остановит весь процесс. Для каждого события сохраните внутренний идентификатор заказа и идентификатор SMS, который вернул SMPP-шлюз. Это позволит сопоставить оплату, команду на отправку и результат доставки. Если требуется разобраться именно с подключением уведомлений об оплате через ЕРИП к нескольким каналам, полезно изучить материал о подключении уведомлений об оплате через ЕРИП к SMS и Viber. Для проекта, где нужен только SMPP, из этой схемы оставляют источник платежного события и SMS-часть. Какие данные передавать в SMS после оплаты? Сообщение должно подтверждать конкретное действие и помогать клиенту понять, к чему относится платёж. В минимальном варианте достаточно статуса, номера заказа и суммы в BYN. Если бизнес не хочет показывать сумму в SMS, можно оставить только номер заказа и факт зачисления. Пример шаблона: «Оплата по заказу №4815 получена. Сумма: 42 BYN. Статус заказа: в обработке». Номер заказа берите из собственной системы, а не из произвольного текста уведомления. Сумму приводите к тому формату, который использует бухгалтерская или торговая программа. Отдельно обработайте ситуацию, когда платёж пришёл повторно: повторное событие не должно создавать второе одинаковое SMS. Событие Действие обработчика Пример сообщения Оплата подтверждена Создать одну задачу на отправку «Заказ №4815 оплачен. Сумма: 42 BYN» Платёж ожидает подтверждения Не отправлять сообщение об успешной оплате «Платёж по заказу №4815 проверяется» Повторное уведомление о той же оплате Проверить уникальность события и пропустить дубль Повторное SMS не создаётся Ошибка при отправке в SMPP Записать ошибку и повторить попытку по правилам очереди Клиенту не отправляется неподтверждённый статус Как настроить SMPP-клиент для уведомлений? Для работы по SMPP нужен клиент, который поддерживает постоянное соединение с SMS-шлюзом. В настройках указывают адрес и порт шлюза, логин, пароль, системный идентификатор, параметры bind и ограничения скорости. Точные значения выдаёт поставщик SMS-сервиса. Приложение должно уметь выполнять несколько операций: устанавливать соединение и повторно подключаться после разрыва; передавать текст и номер получателя в submit_sm; сохранять message_id из ответа шлюза; принимать delivery receipt; ограничивать число параллельных отправок; писать в журнал технические ошибки и время операции. При кириллическом тексте отдельно проверьте кодировку и длину сообщения. В документации некоторых SMPP-шлюзов указано, что UTF-8 при отправке SMS не используется, поэтому параметр data_coding и способ передачи Unicode нужно согласовать с провайдером. Неверная настройка превращает текст в набор символов или приводит к отклонению сообщения. Для небольшого проекта достаточно отдельного фонового процесса: он забирает задания из очереди и передаёт их в SMPP. Сайт при этом только создаёт задачу после подтверждения платежа. Такой вариант проще тестировать и контролировать, чем отправку SMS прямо внутри запроса, который принимает платёжное уведомление. Как проверять оплату, отправку и доставку? Тестирование разделите на три независимых этапа. Сначала проверьте, что система получает событие от платёжного источника и правильно связывает его с заказом. Затем отправьте тестовое SMS через SMPP и убедитесь, что шлюз вернул message_id. После этого проверьте DLR: один статус показывает принятие сообщения шлюзом, другой отражает результат доставки оператором. Не считайте SMS доставленным только потому, что SMPP-клиент получил положительный ответ на submit_sm. Это подтверждает приём команды, но не факт появления сообщения на телефоне. Для разбора статусов пригодится материал о причинах недоставки SMS и разборе DLR в SMPP. В журнале интеграции храните техническую цепочку: идентификатор заказа; идентификатор платёжного события; время получения подтверждения; время постановки SMS в очередь; ответ SMPP-шлюза; message_id; последний полученный статус доставки. Для проверки сценария подготовьте отдельные случаи: успешная оплата, повторное уведомление, неизвестный заказ, временно недоступный шлюз и некорректный номер. Отправляйте тестовые сообщения на номера, которыми вы вправе пользоваться для проверки, и фиксируйте результат каждого шага. Какие ошибки чаще всего ломают сценарий «оплата получена»? SMS отправляется до подтверждения платежа. Система реагирует на создание счёта, хотя ЕРИП ещё не подтвердил оплату. Отправляйте сообщение только после события об успешном зачислении. Повторная обработка одного события. При повторной доставке уведомления создаются дубли. Добавьте проверку уникального идентификатора платежа или заказа. Отсутствует очередь. Если SMPP-шлюз временно недоступен, сайт теряет задачу. Сохраняйте сообщение до получения результата отправки. Нет контроля DLR. Статус submit_sm принимают за доставку. Отдельно принимайте и анализируйте delivery receipt. Неправильная кодировка. Кириллица отображается некорректно из-за неверного data_coding или неподходящего формата поля. Слишком тесная связь с сайтом. Платёжная страница ждёт ответа SMS-шлюза. Отправку лучше выполнять отдельным процессом после записи события в очередь. Перед подключением уточните у поставщика SMPP технические параметры, поддержку DLR, правила повторной отправки и ограничения скорости. Если готового клиента нет, интеграцию можно построить через HTTP-сервис или библиотеку, но при большом объёме сообщений постоянное SMPP-соединение обычно требует отдельного контроля состояния и очереди. 3 шага, которые можно сделать на этой неделе: Описать, откуда система получает подтверждение оплаты через ЕРИП и какое поле связывает его с заказом. Собрать тестовый SMPP-клиент с журналом соединения, message_id и DLR. Проверить четыре сценария: успешная оплата, дубль, ошибка шлюза и недоставленное SMS. > Source: https://smpp.by/kak-otpravlyat-sms-o-platezhakh-cherez-erip-po-smpp --- # Как отправлять SMS о статусах заказов Wildberries через SMPP Чтобы отправлять покупателю SMS о выкупе и возврате товара Wildberries, интернет-магазину нужна связка из источника статусов, собственного обработчика событий и SMPP-шлюза. Сначала система получает изменение заказа из доступного интерфейса или внутреннего модуля, затем сопоставляет его с номером телефона, формирует текст и передаёт сообщение через SMPP. В статье разобраны схема интеграции, состав параметров, обработка DLR и типичные ошибки, из-за которых уведомления не доходят. Как устроена схема SMS-уведомлений для заказа Wildberries? Сам SMPP не подключает магазин к Wildberries. Это протокол обмена сообщениями между вашей системой и SMS-шлюзом. Источник статусов заказа находится отдельно: его предоставляет интеграционный модуль, личная система магазина или доступный для конкретного сценария интерфейс маркетплейса. Рабочая схема выглядит так: Система магазина получает событие о заказе, выкупе, отмене или возврате. Обработчик проверяет статус и находит связанный номер телефона. Модуль уведомлений выбирает шаблон SMS. SMPP-клиент открывает соединение с шлюзом и отправляет PDU submit_sm. Шлюз возвращает submit_sm_resp с результатом приёма сообщения. Позже приходит DLR, по которому система фиксирует доставку или ошибку. Для каждого события нужен отдельный внутренний идентификатор. Обычно это комбинация номера заказа, типа события и версии сообщения. Она не позволяет отправить два одинаковых уведомления, если источник повторно передал один и тот же статус. Связку лучше разделить на два процесса. Первый принимает события и складывает их в очередь. Второй отправляет SMS через SMPP. Если шлюз временно недоступен, очередь сохранит задания, а основной модуль не остановит обработку заказов. Какие статусы Wildberries стоит переводить в SMS? Состав событий зависит от задачи магазина и того, какие статусы доступны в выбранном интерфейсе. Для уведомлений о выкупе и возврате достаточно начать с двух сценариев, затем добавить отмену или изменение заказа после проверки логики. Событие Задача сообщения Что передать в обработчик Выкуп товара Сообщить, что покупка завершена Идентификатор заказа, дату события, номер телефона Возврат товара Уведомить об изменении результата заказа Идентификатор заказа, тип возврата, время события Отмена или изменение Показать покупателю новый статус Новый статус, заказ, причину при наличии Не отправляйте SMS на любое изменение записи. Сначала задайте список переходов, которые действительно требуют уведомления. Например, система может получить один и тот же статус несколько раз, а клиенту достаточно одного сообщения. Для возврата полезно предусмотреть отдельный шаблон и отдельный код события. Материалы о настройке уведомлений о возврате помогают разобрать этот сценарий по шагам: SMS-уведомления о возврате. Как подключить SMPP-шлюз к модулю магазина? В конфигурации SMPP-клиента обычно нужны host, port, system_id, пароль, тип bind и параметры TON/NPI. Точные значения выдаёт поставщик шлюза. Их нельзя подставлять из примера: неправильный bind или порт приведёт к отказу ещё до отправки первой SMS. Подключение удобно проверять по этапам: Открыть TCP-соединение с адресом и портом шлюза. Выполнить bind_transceiver, если система должна отправлять сообщения и принимать DLR. Проверить, что шлюз вернул bind_resp с успешным кодом. Отправить тестовую SMS на контрольный номер. Получить submit_sm_resp и сохранить message_id. Дождаться delivery receipt и связать его с исходным сообщением. Клиенту нужен механизм enquire_link. Он поддерживает сессию и помогает заметить разрыв соединения. При потере связи приложение закрывает старую сессию, подключается заново и повторяет отправку только тех заданий, для которых нет подтверждённого результата. Отдельно настройте ограничение скорости. Шлюз может принимать сообщения с определённой пропускной способностью, поэтому очередь должна выпускать SMS постепенно. Если отправлять все задания одновременно, приложение получит throttling, тайм-ауты или временные ошибки. Для начала интеграции подготовьте небольшой тестовый контур: один тип события, один шаблон, несколько контрольных номеров и подробный журнал SMPP-команд. Такой подход быстрее показывает, где возник сбой: в статусе заказа, в обработчике или в транспортном соединении. Как составить SMS о выкупе и возврате? Текст должен объяснять событие без лишних деталей. В шаблон обычно включают название магазина, тип изменения, короткий идентификатор заказа и инструкцию, если покупателю нужно выполнить действие. Не вставляйте в SMS длинные технические идентификаторы или полный состав заказа. Элемент Практическое правило Отправитель Используйте согласованное имя отправителя из настроек шлюза. Идентификатор Оставьте короткий номер заказа или его часть, если этого достаточно. Кодировка Заранее проверьте, как шлюз обрабатывает кириллицу и сегментацию длинных SMS. Ссылка Добавляйте её только при необходимости и проверяйте длину итогового сообщения. Для выкупа и возврата лучше хранить шаблоны в настройках, а не зашивать их в код. Тогда менеджер сможет изменить формулировку без выпуска новой версии интеграции. Перед отправкой система должна подставить значения и проверить, что обязательные поля заполнены. Если SMS состоит из нескольких частей, приложение должно корректно передать параметры esm_class, data_coding и UDH, когда это требуется конкретным шлюзом. Ошибки в этих полях приводят к повреждённому тексту или разделению сообщения на части. Поэтому тестируйте короткий текст и длинный текст отдельно. Как контролировать доставку SMS через DLR? Ответ submit_sm_resp означает, что шлюз принял запрос. Он не подтверждает, что телефон получил SMS. Для контроля нужен delivery receipt, который приходит отдельным сообщением SMPP и содержит идентификатор, статус доставки и иногда код ошибки. Система должна сохранять как минимум: внутренний идентификатор уведомления; message_id, который вернул шлюз; тип события заказа; время отправки; статус submit_sm_resp; последний статус DLR и текст ошибки. Если SMS не дошла, сначала сравните message_id в журнале отправки и в DLR. Затем проверьте код ошибки, формат номера, кодировку и состояние SMPP-сессии. При повторной отправке используйте ограниченное число попыток: бесконечный retry создаёт дубли и усложняет разбор заказов. Практическая диагностика DLR подробно разобрана в материале почему SMS не доходит до клиента. Для самого статуса доставки важно различать принятие сообщения шлюзом, передачу оператору и финальный результат на телефоне. Какие ошибки чаще всего ломают интеграцию? Повторная отправка одного события. Источник статусов повторяет уведомление, а приложение не проверяет уникальность заказа и события. Неверная связь message_id. Система принимает DLR, но не может найти исходную SMS, потому что идентификатор шлюза не сохранён. Отправка до появления номера. Обработчик запускает SMS сразу после события, хотя телефон ещё не загрузился в локальную запись заказа. Неправильная кодировка. Русский текст проходит тест на коротком сообщении, но ломается на длинном. Игнорирование очереди. Модуль отправляет пачку сообщений напрямую в SMPP и получает временные отказы. Одинаковый шаблон для всех статусов. Покупатель не понимает, что произошло: выкуп, отмена или возврат требуют разных формулировок. Отдельно проверьте журнал повторных подключений. В нём должны быть время разрыва, причина закрытия bind-сессии, результат reconnect и количество сообщений, оставшихся в очереди. Без этих записей техническая поддержка видит только жалобу «SMS не пришла», но не путь сообщения. Для интернет-магазина с небольшим потоком достаточно простого обработчика событий и очереди в базе. При большом объёме лучше вынести отправку в отдельный сервис, который поддерживает SMPP-сессию, принимает DLR и ограничивает скорость. Схема автоматизации SMS-статусов интернет-магазина описана в материале как автоматизировать SMS-статусы доставки. 3 шага, которые можно сделать на этой неделе: Составить карту событий Wildberries и выбрать для теста выкуп и возврат. Проверить SMPP bind, кодировку, submit_sm_resp и приём DLR на контрольных номерах. Добавить очередь, защиту от дублей и журнал с message_id для каждого уведомления. > Source: https://smpp.by/kak-otpravlyat-sms-o-statusakh-zakazov-wildberries-cherez-smpp --- # Почему SMS не доходит до клиента: разбор DLR в SMPP Недоставка SMS через SMPP чаще всего связана с неверными параметрами команды, ошибкой в номере, кодировкой, лимитом скорости или фильтрацией на стороне оператора. В этой статье разберём, как читать submit_sm, проверять PDU, сопоставлять message_id с DLR и отличать временный сбой от окончательного отказа. После проверки вы сможете собрать короткий технический отчёт для разработчика или поставщика SMS-шлюза, не ограничиваясь сообщением «SMS не пришло». С чего начать диагностику доставки SMS через SMPP? Сначала определите, на каком участке пропало сообщение. В цепочке участвуют ваша система, SMPP-шлюз, SMSC, сеть оператора и телефон получателя. Если в журнале нет ответа на submit_sm, проблема начинается с соединения или параметров bind. Если шлюз вернул ошибку, SMSC не принял сообщение. Если submit_sm прошёл, но пользователь ничего не получил, нужен DLR и его статус. Для каждой попытки отправки сохраните отдельную запись с временем, внутренним идентификатором сообщения, номером в нормализованном формате, текстом или его контрольной суммой, message_id от шлюза и итоговым статусом. Полный текст в техническом журнале хранить необязательно, если для расследования достаточно длины, кодировки и хеша. Главное, чтобы одну попытку можно было найти сразу в логах приложения, SMPP-клиента и поставщика. Проверьте также состояние bind. Для постоянной отправки обычно используют режим transceiver, который позволяет отправлять сообщения и получать отчёты в одном соединении. При нестабильной сети соединение с SMSC может прерываться, а неверный сервер, порт, логин или пароль не позволят пройти bind. Практические проверки соединения и его стабильности собраны в материале как проверить скорость и стабильность SMPP-шлюза. Что показывает submit_sm и где искать ошибку в PDU? Команда submit_sm передаёт SMS-шлюзу параметры сообщения. Для диагностики смотрите не только текст, но и service_type, source_addr_ton, source_addr_npi, source_addr, dest_addr_ton, dest_addr_npi, destination_addr, esm_class, data_coding, registered_delivery, short_message или message_payload. Ошибка в одном поле иногда выглядит как недоставка, хотя оператор вообще не получил корректную команду. Номер назначения сверяйте с исходным значением в бизнес-системе. Уберите пробелы, скобки и дефисы, затем проверьте международный формат, который ожидает ваш провайдер. Отдельно сравните TON и NPI с настройками подключения: при несовпадении шлюз может отклонить адрес ещё на этапе submit_sm. Кириллический текст требует особого контроля. В SMPP для него обычно применяют UCS2, data_coding 0x08, а данные передают в UTF-16BE. При такой кодировке длина одного SMS составляет 70 символов, поэтому длинный текст разбивается на части. Если приложение считает длину как для однобайтовой кодировки или неправильно формирует UDH, получатель может получить обрезанное сообщение, несколько частей в неверном порядке либо отказ при обработке. Для теста отправьте короткую фразу на один контрольный номер, затем отдельное сообщение на кириллице и длинный текст. В каждом случае сохраните исходный PDU в шестнадцатеричном виде и значения data_coding, esm_class, registered_delivery и sequence_number. Такой набор позволяет сравнить рабочую и проблемную отправку побайтно, а не искать причину по одному скриншоту из приложения. Как читать ответ submit_sm и ошибку ESME_RSUBMITFAIL? Ответ submit_sm содержит command_status и message_id. При успешном приёме команды статус обычно указывает на отсутствие ошибки, а message_id нужен для связи отправки с последующим DLR. Если система получила ESME_RSUBMITFAIL, SMS-шлюз не принял запрос на отправку. Искать причину доставки на телефоне в этот момент рано: сначала разберите параметры команды, текст ошибки и журнал шлюза. Запишите полный ответ, включая числовой код и текст, если поставщик его передаёт. Само название ESME_RSUBMITFAIL слишком общее. Внутри конкретного шлюза отказ может быть связан с неверным адресом, недоступным маршрутом, ограничением скорости, параметром сообщения или временной ошибкой SMSC. Сравните неудачный запрос с тем, который получил успешный message_id. Что видно в журналеГде искать причинуСледующая проверка Нет ответа на bind или submit_smСеть, сервер, порт, тайм-аут, состояние соединенияПроверить TCP-сессию, повторное подключение и журнал SMPP-клиента Пришёл ESME_RSUBMITFAILПоля submit_sm, лимиты, маршрут, состояние SMSCСравнить PDU с успешным запросом и уточнить код у поставщика Есть message_id, но DLR не приходитregistered_delivery, формат отчёта, канал получения DLRПроверить настройки отчётов и чтение deliver_sm DLR сообщает rejected или failedНомер, сеть оператора, фильтрация, срок действия сообщенияПровести повторный тест с другим номером и коротким текстом DLR сообщает delivered, но клиент не видит SMSТелефон, SIM, приложение сообщений или особенности отображенияПроверить время доставки, папку сообщений и другой аппарат Как использовать DLR, чтобы отделить сбой отправки от недоставки? DLR, или Delivery Receipt, приходит после submit_sm и сообщает, что произошло с конкретным message_id. Отчёт нужно связывать с исходной отправкой по идентификатору, а не по номеру телефона или времени. Один номер может получить несколько сообщений, а часы вашей системы и шлюза могут отличаться. В deliver_sm проверьте esm_class, source_addr, destination_addr и поле с текстом отчёта либо TLV, которое использует поставщик. Формат DLR различается: один шлюз передаёт строку с id и stat, другой добавляет err, submit date и done date. Поэтому парсер лучше строить по документированному формату конкретного подключения и сохранять исходный deliver_sm до разбора. Разделяйте статусы на группы. DELIVRD означает, что сеть передала сообщение на устройство или в конечный сегмент маршрута согласно правилам шлюза. EXPIRED указывает на истечение срока доставки. UNDELIV и REJECTD требуют анализа причины отказа. Статус ENROUTE ещё не подтверждает доставку: сообщение находится в обработке маршрута. Если DLR не приходит, проверьте registered_delivery в submit_sm. Затем убедитесь, что клиент принимает deliver_sm и не отвечает на него ошибкой. При режиме transceiver входящие отчёты должны обрабатываться тем же соединением; при раздельной схеме нужен отдельный bind_receiver. Полезно также проверить, не теряются ли сообщения после перезапуска приложения и не отбрасывает ли их очередь из-за неизвестного message_id. Какие причины недоставки встречаются чаще всего? Технический сбой оператора или SMSC может временно остановить доставку. Операторы проводят работы и обновляют оборудование, поэтому серия ошибок за короткий период требует проверки аварий и маршрута у поставщика. Повторная отправка без ограничения приведёт к дублям, если первая попытка уже принята и DLR задерживается. Отдельная причина — лимит скорости. При превышении throughput шлюз начинает отклонять submit_sm или возвращает ошибки, связанные с ограничением rate. Сопоставьте время отказов с числом запросов в секунду, очередью и настройкой submit_sm на одном bind. Для проверки снизьте скорость тестовой отправки и посмотрите, меняется ли command_status. Фильтрация операторами также влияет на результат. Повторяющийся текст, подозрительные конструкции, ошибочный отправитель или неподходящий маршрут могут привести к отказу. Сравните короткий нейтральный тест с рабочим шаблоном, но не делайте вывод по одному номеру: нужен небольшой набор контрольных отправок, согласованный с поставщиком. Какие типичные ошибки мешают найти причину? Система считает отправку успешной сразу после вызова API и не ждёт submit_sm_resp. message_id от шлюза не сохраняется, поэтому DLR невозможно связать с заказом или заявкой. Кириллица отправляется с data_coding 0x00 вместо UCS2 0x08. Приложение не принимает deliver_sm или отвечает на него с неверным sequence_number. Команда отправляется быстрее установленного лимита, а повторная попытка создаёт дубли. Разработчик проверяет только текст ошибки и не сохраняет полный PDU с параметрами. Для малого бизнеса в Беларуси практичная схема выглядит так: приложение ставит SMS в очередь, SMPP-клиент сохраняет submit_sm_resp, отдельный обработчик принимает DLR, а мониторинг показывает долю успешных, отложенных и отклонённых сообщений. Если собственный разработчик подключает новый шлюз, параметры сервера, порта, TON/NPI, режима transceiver и лимитов лучше зафиксировать в одной конфигурации, а тестовые SMS и DLR провести до запуска массового трафика. Подробный порядок такой интеграции описан в материале как автоматизировать SMS-статусы доставки интернет-магазина. 3 шага, которые можно сделать сегодня: Соберите для одной неудачной SMS полный submit_sm, submit_sm_resp, message_id и все связанные deliver_sm. Повторите тест с коротким текстом, кириллицей и длинным сообщением, меняя только один параметр за раз. Сопоставьте command_status и статус DLR с лимитом скорости, кодировкой и настройками registered_delivery, затем передайте поставщику точный набор логов. > Source: https://smpp.by/pochemu-sms-ne-dokhodit-do-klienta --- # Как автоматизировать SMS-напоминания о записи через SMPP SMS-напоминания о записи можно связать с системой бронирования через SMPP и отправлять автоматически: после создания визита ставить задачу на таймер, при отмене удалять её, а после отправки проверять DLR-статус. В статье разберём рабочую схему для малого бизнеса в Беларуси: какие данные передавать в очередь, как выбрать время отправки, чем отличаются повторная попытка и новое напоминание, а также как не допустить дублирования сообщений. Как устроена отправка напоминания через SMPP? Система записи хранит визит клиента: номер телефона, дату и время, идентификатор записи и её статус. Когда администратор или клиент создаёт запись, приложение рассчитывает время SMS и добавляет задачу в очередь. В назначенный момент воркер подключается к SMS-шлюзу по SMPP и передаёт сообщение командой submit_sm. Для каждой записи лучше создавать отдельную задачу с уникальным ключом. Например, ключ можно собрать из идентификатора записи и типа события: booking-1842-reminder-24h. Такой ключ помогает проверить, не поставила ли система одно и то же напоминание дважды после повторного нажатия кнопки или сбоя связи. Схема выглядит так: Клиент записывается на услугу. Приложение проверяет, что номер заполнен и запись имеет активный статус. Планировщик рассчитывает время отправки. Задача попадает в очередь с датой выполнения. SMPP-клиент устанавливает bind и передаёт SMS. Система сохраняет message_id и ждёт DLR. При отмене визита задача получает статус cancelled и больше не отправляется. В рабочей базе полезно разделять состояние записи и состояние SMS. Запись может быть подтверждена, отменена или перенесена. SMS при этом имеет собственный статус: queued, submitted, delivered, failed или expired. Такое разделение позволяет понять, почему клиент не получил уведомление, даже если сама запись в календаре сохранилась. Как выбрать время и поставить SMS в очередь? Время напоминания зависит от услуги. Для визита на следующий день подходит отправка за 24 часа. Если запись создана поздно вечером, задача всё равно должна учитывать часовой пояс бизнеса и клиента. В приложении лучше хранить время в UTC, а перед расчётом переводить его в локальное время, заданное настройками проекта. Не отправляйте SMS сразу после создания визита, если его смысл связан именно с предстоящим временем. Для мгновенного подтверждения создайте отдельное событие, например booking_created, а напоминание обозначьте как booking_reminder. Эти события имеют разные шаблоны и разные правила повторной отправки. Пример таблицы задач для базы данных: Поле Зачем нужно task_id Уникальный идентификатор задания booking_id Связь с записью клиента phone Номер получателя в международном формате send_at Планируемое время отправки status queued, submitted, delivered, failed или cancelled message_id Идентификатор SMS от шлюза attempts Количество попыток передачи Планировщик запускается с небольшим интервалом и выбирает задачи, у которых наступил send_at. Чтобы два процесса не взяли одну задачу, используйте блокировку строки или атомарную смену статуса с queued на processing. После этого воркер отправляет сообщение и записывает результат SMPP-операции. Если сайт работает на WordPress, отдельный cron-процесс часто надёжнее запуска WP-Cron по посещениям. Настройку сервера и проверку стабильности соединения полезно сверить с материалом как выбрать VPS под WordPress. Для проекта с постоянным потоком задач планировщик лучше запускать независимо от посещаемости сайта. Как обрабатывать DLR и отличать доставку от отправки? Ответ шлюза на submit_sm подтверждает приём запроса, но не означает, что абонент уже получил SMS. Для контроля нужен DLR, то есть отчёт о состоянии сообщения. SMPP-клиент должен сохранить message_id из ответа и сопоставить его с исходной задачей. DLR приходит отдельным сообщением или через предусмотренный интеграцией механизм. В нём могут передаваться идентификатор сообщения, статус и дополнительный код. Формат зависит от шлюза, поэтому обработчик нужно проверять на тестовых отправках, а не строить логику на одном фиксированном расположении полей. Состояние Действие системы submitted Сохранить идентификатор и ждать DLR delivered Закрыть задачу как доставленную failed Записать код ошибки и решить, нужна ли новая попытка expired Зафиксировать истечение срока доставки unknown Оставить задачу на контроле и проверить журнал Отдельно храните исходный ответ шлюза и нормализованный статус. Так разработчик видит техническую причину сбоя, а администратор получает понятную отметку в интерфейсе. Для систем, где SMS сопровождают заказ или другой процесс, похожий подход описан в материале автоматизация SMS-статусов доставки интернет-магазина. Для DLR нужен повторяемый обработчик. Если отчёт пришёл повторно, он не должен создавать новую SMS или менять delivered на failed без проверки времени и правил перехода. Практичная защита — уникальный ключ из message_id и статуса либо журнал уже обработанных событий. Когда нужна повторная отправка и как отменить SMS? Повторная попытка нужна после технической ошибки, отказа соединения или временной недоступности шлюза. Она не подходит для каждого failed-статуса. Если номер некорректен или оператор отклонил сообщение из-за параметров текста, повтор с теми же данными только создаст лишний трафик. Задайте ограничение попыток и задержку между ними. Например, после первой ошибки задача возвращается в очередь через несколько минут, после второй задержка увеличивается. Конкретные интервалы зависят от нагрузки и ответа шлюза. При этом зафиксируйте максимальное число попыток в конфигурации, чтобы сбой не превратился в бесконечную отправку. Отмена работает через проверку актуального статуса записи непосредственно перед передачей SMS. Даже если планировщик выбрал задачу час назад, воркер должен ещё раз запросить запись. Если визит отменён или перенесён, старую задачу нужно пометить cancelled, а для нового времени создать новую с другим ключом. При переносе записи не изменяйте старую задачу «на месте», если она уже получила message_id. Оставьте историю первой попытки и создайте новое задание. Это упрощает разбор ситуации, когда клиент получил напоминание о старом времени. Какие параметры SMPP проверить до запуска? Для теста подготовьте отдельную конфигурацию подключения: host, port, system_id, password, bind-режим, скорость отправки и параметры DLR. Логин и пароль храните в переменных окружения или закрытом хранилище, а не в файле плагина или открытом репозитории. Проверьте, как система кодирует кириллицу. Для кириллического SMS в SMPP обычно используют UTF-16BE и data_coding 0x08; длина одного сообщения при такой кодировке составляет 70 символов (Stream Telecom, «Протокол SMPP v.3.4 для рассылки СМС»). Если текст длиннее, приложение должно заранее учитывать сегментацию и корректно обрабатывать составное сообщение. Перед запуском отправьте тесты для нескольких сценариев: обычная доставка короткого сообщения; кириллический текст и длинное сообщение; отмена записи до наступления send_at; перенос визита на другую дату; ошибка соединения во время submit_sm; повторный DLR с тем же message_id. Измеряйте не только время ответа на submit_sm, но и задержку до получения DLR. Для этого подходят отдельные тестовые задачи и журнал с временными метками. Проверить скорость и стабильность SMPP-шлюза можно по методике, описанной в материале как проверить скорость и стабильность SMPP-шлюза. Типичные ошибки при автоматизации напоминаний Система считает успешным сам факт ответа submit_sm и не ждёт DLR. При переносе визита старая задача остаётся в очереди и отправляет устаревшее время. Два экземпляра планировщика выбирают одну задачу без блокировки. Приложение повторяет отправку после любой ошибки, включая некорректный номер. Кириллический текст передаётся с неверным data_coding и отображается неправильно. В журнале не сохраняются message_id и исходный ответ SMPP, поэтому сбой нельзя сопоставить с конкретной записью. Для небольшого проекта достаточно начать с одной очереди напоминаний, таблицы статусов и отдельного обработчика DLR. Затем добавьте отмену, перенос и повторные попытки, не смешивая их в одном условии. Если понадобится готовая логика SMS-напоминаний о визите, полезно сравнить её со схемой автоматических SMS-напоминаний о визите, а техническую передачу подключить через SMPP с учётом лимитов и формата отчётов. 3 шага, которые можно сделать на этой неделе: Описать события booking_created, booking_rescheduled и booking_cancelled и связать каждое с отдельным типом задачи. Добавить таблицу очереди с send_at, статусом, attempts и message_id. Провести тесты доставки, отмены и повторного DLR, после чего включить отправку для реальных записей. > Source: https://smpp.by/kak-avtomatizirovat-sms-napominaniya-o-zapisi-cherez-smpp --- # Как отправлять SMS о заказах Ozon через SMPP в 2026 году Если push-уведомления Ozon не приходят, продавец может добавить SMS-канал к своей системе заказов. Для этого интернет-магазин или внутренний сервис передаёт событие о заказе в приложение, приложение формирует текст и отправляет его через SMPP-шлюз. В статье разобраны схема интеграции, обязательные параметры сообщения, обработка статусов доставки и проверка соединения. Такой подход подходит бизнесу, которому нужно контролировать большой объём транзакционных SMS. Почему push-уведомления не стоит оставлять единственным каналом? Push зависит от установленного приложения, разрешений на уведомления, авторизации пользователя и доступа устройства к интернету. Если приложение удалено, отключено или работает нестабильно, клиент может не увидеть изменение статуса заказа. SMS приходит на номер телефона, который уже используется в заказе, поэтому его удобно применять как резервный канал для важных событий. Для продавца Ozon речь обычно идёт о коротких сообщениях: заказ принят, товар передан в доставку, заказ готов к выдаче, срок получения изменился. Внутренняя система продавца получает информацию о событии из доступного ему источника, после чего передаёт SMS-компоненту номер телефона, шаблон и идентификатор заказа. SMPP отвечает за связь этого компонента с SMS-шлюзом. Сначала полезно определить границы задачи. Если продавцу нужно уведомлять только о собственных действиях, достаточно связать учётную систему с сервисом отправки. Если требуется получать точные статусы площадки, понадобится источник данных, который эти статусы предоставляет. Сам SMPP не получает сведения о заказах: протокол доставляет уже подготовленное сообщение. Как выглядит схема SMS-уведомления через SMPP? Рабочая схема состоит из нескольких этапов. Событие о заказе поступает в приложение, приложение выбирает шаблон, подставляет номер заказа и отправляет сообщение через SMPP. Шлюз возвращает идентификатор сообщения, а затем присылает отчёт о доставке. По этому отчёту система меняет статус уведомления и фиксирует результат. Система продавца получает событие: заказ создан, изменён, передан в доставку или готов к выдаче. Модуль уведомлений проверяет, что для этого события ещё не отправлялось SMS. Программа собирает текст из шаблона и ограничивает его допустимой длиной. SMPP-клиент открывает bind-соединение и передаёт сообщение шлюзу. Система сохраняет message ID и связывает его с конкретным заказом. После delivery receipt приложение обновляет статус: доставлено, отклонено или неизвестно. Для транзакционных уведомлений лучше использовать отдельные шаблоны и коды событий. Например, «Заказ №12345 передан в доставку» и «Заказ №12345 готов к получению» должны считаться разными уведомлениями. Это упрощает повторную отправку и помогает оператору понять, на каком шаге возникла проблема. Если клиенту нужно отвечать на SMS, одной исходящей отправки мало. В этом случае проектируют обработку MO-сообщений, то есть входящих ответов абонента. Техническая схема описана в материале как принимать ответы на SMS через SMPP. Какие параметры нужны для подключения к SMPP? Провайдер SMS-шлюза выдаёт параметры подключения. Обычно приложению нужны адрес и порт шлюза, логин, пароль, тип bind, допустимый sender ID и правила кодировки. Эти данные хранят отдельно от исходного кода. Доступ к ним получают только сервисы, которым действительно нужно отправлять сообщения. ПараметрЧто проверитьПрактический результат Тип соединенияПодходит ли transmitter, receiver или transceiver для вашей схемыПриложение отправляет SMS и получает нужные отчёты КодировкаКорректно ли передаются кириллические символыТекст не превращается в нечитаемый набор знаков Sender IDКакое имя отправителя разрешено шлюзомКлиент видит ожидаемое обозначение отправителя Delivery receiptВключена ли передача статусов доставкиСистема отличает принятую шлюзом SMS от доставленной ReconnectЧто происходит после разрыва TCP-соединенияКлиент восстанавливает bind без ручного запуска Ограничения скоростиСколько сообщений в секунду принимает шлюзОчередь не перегружает соединение Кириллица влияет на размер SMS и число частей сообщения, поэтому текст лучше держать коротким. В уведомлении достаточно назвать событие, номер заказа и следующий шаг. Ссылки, длинные описания товара и рекламные фразы увеличивают объём и усложняют контроль отправки. При подключении через SMPP проверяют не только факт авторизации. Тестовая отправка должна пройти полный путь: submit, получение message ID, delivery receipt и запись результата в журнале. Для отдельной проверки канала пригодится инструкция о том, как проверить скорость и стабильность SMPP-шлюза. Как настроить очередь, повторы и статусы доставки? Магазин не должен отправлять SMS прямо из обработчика заказа без очереди. Если шлюз временно занят или соединение оборвалось, пользовательский запрос зависнет вместе с отправкой. Очередь отделяет бизнес-логику от SMPP-клиента: приложение добавляет задачу, а отдельный обработчик отправляет её и повторяет попытку по понятному правилу. У каждой задачи стоит хранить внутренний идентификатор заказа, тип события, номер телефона, текст после подстановки, время постановки в очередь, message ID и итоговый статус. Повторная отправка должна зависеть от причины сбоя. Временная ошибка соединения допускает повтор, а постоянная ошибка адресата требует отметки о невозможности доставки. СитуацияДействие приложения Шлюз принял submit_smСохранить message ID и ждать отчёт Соединение разорвано до ответаПроверить результат по журналу и не создавать дубликат без идемпотентного ключа Пришёл статус доставкиСвязать его с заказом и закрыть задачу Шлюз временно отклонил запросПоставить задачу в повторную очередь с ограничением попыток Текст превышает лимитСократить шаблон или явно разделить сообщение на части Идемпотентность особенно важна при повторной обработке событий. Если система дважды получила один и тот же статус Ozon, клиент не должен получить два одинаковых SMS. Для этого в базе создают уникальный ключ, например «номер заказа плюс тип события», и проверяют его до постановки задачи. Мониторинг нужен на уровне соединения и сообщений. В журнале фиксируют bind, reconnect, submit_sm, ответы шлюза, delivery receipt и ошибки кодировки. Отдельно считают сообщения в очереди: резкий рост покажет проблему раньше, чем её заметит клиент. Какие ошибки чаще всего ломают SMS-уведомления? Система считает сообщение доставленным после submit_sm. Принятие шлюзом и доставка на телефон — разные статусы, поэтому нужен delivery receipt. Один шаблон используется для всех событий. Из-за этого клиент не понимает, изменился ли статус заказа или повторилась старая отправка. Кириллица не проверена на тестовом номере. До запуска нужно проверить отображение текста и число частей SMS. После разрыва соединение не восстанавливается. SMPP-клиенту нужен таймер переподключения и корректное закрытие старой сессии. Повторы создают дубликаты. Очередь должна хранить ключ события и ограничивать повторные попытки. Статусы не связываются с заказом. message ID нужно записывать сразу после ответа шлюза, иначе отчёт доставки будет трудно сопоставить. Для небольшого бизнеса разумно начать с двух событий: «заказ принят» и «заказ готов к выдаче». После проверки шаблонов, кодировки и статусов можно добавить передачу в доставку или изменение срока. Если нужна отдельная схема уведомлений при выдаче заказа, полезно сравнить её с материалом о SMS-подтверждении выдачи заказа в пункте выдачи. 3 шага, которые можно сделать на этой неделе: Описать события заказа и для каждого подготовить короткий шаблон SMS. Подключить тестовый SMPP-bind, проверить кириллицу, message ID и delivery receipt. Добавить очередь с защитой от дублей, повторным подключением и журналом ошибок. Так продавец получает независимый технический канал для уведомлений, когда push в приложении Ozon недоступен. На сайте smpp.by можно подобрать архитектуру SMPP-подключения под объём сообщений, требования к статусам и способ интеграции с системой заказов. > Source: https://smpp.by/kak-otpravlyat-sms-o-zakazakh-ozon-cherez-smpp-v-2026-godu --- # Как принимать ответы на SMS через SMPP: MO-сообщения Принимать ответы на SMS через SMPP можно в режиме receiver или через двунаправленный bind_transceiver. Вы отправляете вопрос как обычное SMS, а ответ абонента приходит от SMS-центра в виде MO-сообщения, обычно внутри команды deliver_sm. В статье разберём схему подключения, параметры receiver-режима, разбор текста и защиту от повторной обработки. В результате разработчик сможет связать входящий ответ с клиентом, заказом или конкретным вопросом без HTTP API. Как работает двусторонняя SMS-связь через SMPP? В двусторонней схеме участвуют три элемента: ваше приложение, SMPP-шлюз и сеть мобильного оператора. Приложение отправляет исходящее сообщение командой submit_sm. Когда абонент отвечает, шлюз передаёт входящий текст приложению командой deliver_sm. Такой входящий пакет называют MO, то есть Mobile Originated. Для простого опроса можно отправить сообщение «Оцените обслуживание от 1 до 5. Ответьте одной цифрой». Абонент пишет SMS в ответ, шлюз передаёт номер отправителя и текст, а программа сохраняет результат. Если бизнесу нужно принять свободный комментарий, приложение может записать весь текст без классификации и передать его сотруднику на дальнейший разбор. Отдельно нужно учитывать DLR-сообщения. Они подтверждают состояние исходящей SMS и тоже приходят через deliver_sm, поэтому обработчик обязан отличать отчёт о доставке от ответа абонента. Иначе система может ошибочно записать технический статус как ответ на опрос. Тип сообщенияКоманда SMPPЧто делает приложение Исходящее SMSsubmit_smПередаёт вопрос, уведомление или код Ответ абонентаdeliver_smСохраняет текст MO и связывает его с диалогом Отчёт о доставкеdeliver_smОбновляет статус исходящего сообщения Проверка соединенияenquire_linkПоддерживает SMPP-сессию и контролирует доступность Как выбрать receiver или transceiver? Режим receiver подходит, когда приложение только принимает входящие SMS. Для полноценного диалога чаще используют bind_transceiver: одна SMPP-сессия позволяет отправлять вопросы через submit_sm и принимать ответы через deliver_sm. Выбор зависит от условий шлюза и того, как разделены исходящий и входящий трафик. При настройке receiver приложение открывает TCP-соединение с SMPP-шлюзом и передаёт параметры учётной записи. После успешной авторизации шлюз начинает направлять входящие PDU. Программа должна регулярно отправлять enquire_link и отвечать на служебные запросы шлюза, иначе соединение прервётся даже при отсутствии сообщений. Для малого бизнеса практичная схема выглядит так: отдельный процесс держит SMPP-сессию, отдельный обработчик разбирает входящие пакеты, а очередь сообщений временно хранит события до записи в рабочую систему. Если обработка текста занимает время, не стоит задерживать SMPP-ответ. Сначала подтвердите получение PDU, затем передайте содержимое в очередь. При нестабильном интернете в офисе пригодятся повторное подключение, задержка между попытками и контроль состояния bind. Особенности восстановления SMPP-сессии разобраны в материале как настроить SMPP-bind при нестабильном интернете. Какие поля нужно обработать в MO-сообщении? Минимальный набор данных включает адрес отправителя, адрес получателя, текст, идентификатор сообщения шлюза и время приёма. Названия полей зависят от библиотеки и реализации SMPP, но логика остаётся одинаковой. Перед записью проверьте, что сообщение действительно входящее, а текст декодирован в нужной кодировке. source_addr помогает определить абонента, который отправил ответ; destination_addr показывает номер или короткий номер, на который пришло SMS; short_message содержит текст, если сообщение передано в основном поле; message_payload может содержать текст длинного сообщения в дополнительном параметре; esm_class помогает определить тип сообщения и наличие признаков отчёта о доставке; data_coding подсказывает, как декодировать текст. Не ограничивайтесь чтением только short_message. Длинное SMS может прийти несколькими частями, а содержимое иногда передаётся через TLV или message_payload. Приложение собирает сегменты по идентификатору и порядковому номеру, после чего передаёт готовую строку в бизнес-обработчик. Кодировка требует отдельной проверки. Латинский текст часто передают в GSM 7-bit, а кириллица требует другой схемы кодирования и уменьшает доступную длину одного сегмента. Если приложение сохраняет «кракозябры», сначала проверьте data_coding, затем настройку декодера в SMPP-библиотеке. Как связать ответ с конкретным вопросом? Самый понятный способ для короткого опроса — использовать отдельный номер или короткий код в тексте исходящего SMS. Например, система отправляет вопрос с инструкцией «Ответьте 1, 2 или 3», а при отправке сохраняет запись с идентификатором кампании и номером получателя. Когда приходит MO, обработчик ищет активный диалог по отправителю и последнему ожидающему вопросу. Если один абонент может участвовать сразу в нескольких опросах, одного номера недостаточно. Добавьте в сообщение короткий маркер: «Ответьте 1, если готовы получить заказ. Код заказа A17». Входящий обработчик отделяет код от ответа, проверяет допустимое значение и передаёт результат в нужный сценарий. Маркер лучше делать коротким, чтобы не увеличивать число SMS-сегментов. Формат ответаПравило обработкиРезультат Одна цифраПринять только значения из заданного спискаАвтоматическая оценка или выбор варианта СловоПривести текст к единому регистру и сравнить с командамиЗапись действия клиента Код и ответРазделить строку по пробелу или другому маркеруСвязь ответа с заказом или опросом Свободный текстСохранить исходное сообщение без потери символовКомментарий для ручной обработки Для каждого исходящего вопроса сохраните внутренний идентификатор, время отправки и ожидаемый формат ответа. В базе данных полезно иметь поля «получено», «обработано» и «ошибка разбора». Такая структура позволяет повторно запустить обработку после сбоя, не отправляя человеку новый вопрос. Как защитить обработчик от повторов и ошибок? Сетевой сбой может привести к повторной доставке одного и того же PDU. Поэтому обработчик проверяет уникальный идентификатор сообщения или комбинацию полей, которую шлюз гарантирует как уникальную. Повторный пакет получает успешный технический ответ, но второй раз не меняет результат опроса. Разделяйте MO-сообщения и DLR по признакам SMPP и содержимому. Проверяйте обязательные поля до записи в рабочую базу. Сохраняйте исходный текст вместе с нормализованным значением ответа. Ограничивайте длину и набор допустимых команд для автоматических сценариев. Пишите в журнал bind, отключение, повторное подключение и ошибки декодирования. Не отправляйте автоматический ответ на каждое неизвестное слово без отдельного правила. Если клиент написал комментарий вместо цифры, система может сохранить его как свободный ответ или передать оператору. Для контроля качества SMPP-подключения полезно заранее проверить скорость и стабильность шлюза по отдельному сценарию тестирования: как проверить скорость и стабильность SMPP-шлюза. Как запустить SMS-опрос без HTTP API? HTTP API не требуется, если приложение умеет работать с SMPP-библиотекой и поддерживает постоянную сессию. Разработчик настраивает bind, создаёт отправку через submit_sm, принимает deliver_sm в receiver или transceiver-режиме и передаёт данные во внутреннюю очередь. Такой подход подходит для напоминаний, подтверждения заказа, оценки обслуживания и коротких команд. Перед запуском проверьте тестовый сценарий от начала до конца: отправка вопроса, ответ с телефона, приём MO, декодирование кириллицы, запись результата и повторная доставка того же сообщения. Для проекта с большим объёмом отдельно согласуйте пропускную способность, DLR, формат имени отправителя и правила маршрутизации с SMPP-шлюзом. Техническое подключение напрямую к SMS-шлюзу описывается как вариант для высокообъёмного трафика и управления доставкой на уровне инфраструктуры. 3 шага, которые можно сделать на этой неделе: Определить формат ответа и таблицу состояний диалога: вопрос отправлен, ответ получен, ответ обработан. Поднять тестовый bind_transceiver или receiver, вывести в журнал поля входящего deliver_sm и проверить кодировку. Добавить идемпотентность, обработку длинных SMS и отдельное распознавание DLR до подключения рабочего сценария. > Source: https://smpp.by/kak-prinimat-otvety-na-sms-cherez-smpp --- # Как отправлять курс доллара через SMPP в Беларуси Курс доллара можно превратить в автоматическое SMS-уведомление для сотрудников, закупщиков или клиентов: источник данных передаёт новое значение, сервис сравнивает его с заданным порогом, а приложение отправляет сообщение через SMPP-шлюз. В статье разберём схему от получения курса из API до DLR на телефоне, покажем структуру сообщения и разберём ошибки, из-за которых алерт приходит с задержкой или не доходит. Как устроен валютный SMS-алерт через SMPP? Схема состоит из четырёх частей. Первая получает курс из источника данных. Вторая хранит последнее обработанное значение и решает, нужно ли отправлять уведомление. Третья открывает SMPP-соединение и передаёт сообщение шлюзу. Четвёртая принимает DLR, то есть отчёт о статусе доставки SMS. Для малого бизнеса этого достаточно. Например, закупщик задаёт порог изменения курса доллара, а приложение проверяет его через выбранный интервал. Если условие выполнено, программа формирует текст и отправляет его на заранее подготовленный номер. После этого система сохраняет идентификатор сообщения и ждёт отчёт от шлюза. Автоматизация SMS-рассылок обычно включает планирование, отправку и обработку событий без ручной загрузки списков. Для валютного мониторинга особенно важен именно событийный сценарий: сообщение отправляется после изменения показателя, а не по календарю. Как подключить источник курса и задать условие отправки? Сначала определите, какое значение нужно отслеживать. Это может быть официальный курс доллара, курс покупки или продажи, значение из внутренней учётной системы либо цена, которую использует закупочный отдел. Название показателя должно быть закреплено в настройках, иначе разные сотрудники будут трактовать слово «курс» по-разному. Источник данных передаёт приложению дату, валюту и числовое значение. Программа проверяет, что ответ получен, значение относится к доллару и имеет корректный формат. Если API вернул пустой ответ, старое значение нельзя считать новым курсом. В таком случае система записывает ошибку и повторяет запрос по отдельному правилу. Порог лучше задавать одним из двух способов: изменение на заданную величину в белорусских рублях; изменение на заданную долю относительно последнего сохранённого значения. Для первого варианта условие выглядит так: если новый курс минус предыдущий курс больше порога, отправить сообщение. Для падения курса используется обратное сравнение. Если алерт должен срабатывать при каждом пересечении уровня, приложение хранит состояние «выше порога» или «ниже порога», чтобы не посылать одинаковое SMS при каждом опросе. Пример настройки без конкретных чисел: закупщик получает уведомление, когда курс поднимается выше установленного уровня. После отправки система запоминает событие и не повторяет его, пока курс не вернётся ниже контрольной отметки. Такой механизм защищает телефон от серии одинаковых сообщений при небольших колебаниях. Как передать валютное SMS через SMPP? Приложение подключается к SMPP-шлюзу с параметрами bind: адресом сервера, портом, логином, паролем и типом соединения. Для исходящих сообщений обычно используют transmitter либо transceiver, если тому же соединению нужны входящие ответы и статусы. Настройки зависят от шлюза, поэтому их берут из технической документации поставщика. В запросе submit_sm нужно передать адрес отправителя, номер получателя, текст, параметры кодировки и, при необходимости, срок действия сообщения. Для кириллицы выбирают кодировку, которую поддерживает конкретный шлюз. Если текст длинный, SMPP разбивает его на части, а телефон собирает их в одно сообщение. До запуска проверьте, как провайдер считает такие части и какие ограничения установлены для sender ID. Пример текста для внутреннего алерта: «Курс USD изменился: 3,2450 BYN. Проверьте закупочные цены.» В рабочем сообщении полезно указать валюту, новое значение, направление изменения и время обновления. Слишком короткая фраза вроде «Курс изменился» не помогает принять решение. При этом длинный комментарий увеличивает объём SMS и усложняет чтение на обычном телефоне. Если бизнес получает данные из 1С, отдельного скрипта или бота, SMPP можно оставить транспортным уровнем, а правила сравнения держать в приложении. Для примера интеграции учётной системы пригодится материал как настроить отправку SMS из 1С через SMPP-шлюз. Для Telegram-бота применяется похожая логика: бот показывает событие, а SMPP отправляет его на телефон через шлюз. Как использовать DLR и проверить доставку на телефон? Отправка через SMPP подтверждает приём сообщения шлюзом, но это ещё не означает, что SMS появилось на телефоне. Поэтому приложение должно обрабатывать DLR. В отчёте обычно передаются идентификатор сообщения и статус: оно принято, доставлено, отклонено или завершилось ошибкой. Для каждого SMS сохраните: внутренний идентификатор валютного события; message_id, который вернул шлюз; номер получателя в согласованном формате; курс и время, при которых сработало условие; финальный статус DLR. Эти записи позволяют отличить три ситуации: приложение не отправило запрос, шлюз не принял сообщение или SMS не дошло до телефона. Без message_id все сбои смешиваются, и разработчик видит только жалобу «уведомление не пришло». DLR нужно сопоставлять с конкретным message_id. Нельзя считать любое входящее уведомление доказательством доставки: в системе могут одновременно работать несколько алертов. Коды ошибок и трактовку статусов лучше сверить с документацией вашего SMPP-центра; справочный материал по этой теме есть в статье как проверить скорость и стабильность SMPP-шлюза. Для контроля работы задайте таймер ожидания статуса. Если отчёт не пришёл в установленный срок, приложение записывает событие в журнал и передаёт его на повторную обработку по правилам шлюза. Повтор нельзя запускать бесконечно: так одна проблема с соединением превращается в дубли SMS. Как сделать мониторинг устойчивым к сбоям? Проверку курса запускайте по расписанию, но сам SMPP-сеанс держите под контролем. При обрыве соединения приложение должно закрыть старый bind, выдержать паузу и открыть новый. Параметры переподключения задаются отдельно от логики валютного порога, чтобы временный сбой сети не создавал новое событие. До отправки проверьте четыре условия: источник вернул свежий ответ, курс прошёл проверку формата, порог действительно пересечён, а такое событие ещё не отправлялось. Последнее условие особенно важно после перезапуска сервиса. Для него сохраняют состояние в базе или другом постоянном хранилище, а не только в оперативной памяти. Если офисный интернет нестабилен, проверьте keepalive, таймауты и порядок повторного bind. Практическая инструкция по этой части собрана в материале как настроить SMPP-bind при нестабильном интернете в офисе. Журнал должен показывать не только ошибку, но и контекст: время запроса курса, полученное значение, предыдущее значение, причину срабатывания и ответ SMPP. Для малого проекта достаточно обычной таблицы событий. Она быстро показывает, где возникла задержка: на стороне источника курса, приложения, SMPP-шлюза или мобильной сети. Какие подходы к валютным SMS выбрать? Подход Когда подходит Что учесть Проверка по расписанию Курс нужен несколько раз в день Нужно выбрать интервал и хранить последнее значение Алерт при пересечении уровня Нужно реагировать на конкретный порог Нужно хранить состояние порога и защищаться от повторов Уведомление при любом изменении Изменения отслеживает небольшая группа сотрудников При частых обновлениях быстро растёт число SMS Запрос из внутренней системы Курс уже используется в учёте или закупках Нужно согласовать формат данных и права доступа приложения Для ИП или небольшой компании обычно начинают с проверки по расписанию и одного порога. Такой вариант проще проверить вручную: в журнале видны два значения, условие и отправленный текст. Когда появляется несколько валют, групп получателей или разных порогов, правила выносят в конфигурацию, чтобы не менять программный код при каждой настройке. Какие ошибки чаще всего ломают валютные SMPP-алерты? Сравнивают новое значение с предыдущим после перезапуска. Если последнее значение не сохранено, приложение принимает первый ответ за резкое изменение и отправляет лишнее SMS. Не учитывают дробную часть. Курс, пришедший строкой, нужно преобразовать в число с заданной точностью, иначе сравнение может работать непредсказуемо. Отправляют сообщение при каждом опросе. Для порогового алерта храните факт уже отправленного события и состояние пересечения уровня. Считают submit_sm подтверждением доставки. Для контроля результата нужен DLR и сопоставление по message_id. Не проверяют кодировку кириллицы. В итоге текст приходит с непонятными символами или разбивается на части иначе, чем ожидалось. Запускают бесконечные повторы после сбоя. Ограничьте число попыток и записывайте причину каждой повторной отправки. 3 шага, которые можно сделать на этой неделе: Определить источник курса, валюту, частоту проверки и точное условие срабатывания. Собрать тестовый SMPP-сценарий: получить значение, отправить одно кириллическое SMS и принять DLR. Добавить журнал событий, защиту от дублей и переподключение при разрыве bind. > Source: https://smpp.by/kak-otpravlyat-kurs-dollara-cherez-smpp-v-belarusi --- # Как отправлять SMS через SMPP из Telegram-бота Telegram-бот может принимать заявку, сообщать статус заказа и запускать отправку SMS через SMPP-шлюз. Для этого между ботом и шлюзом нужен небольшой сервис-посредник: он получает событие из Telegram, формирует текст, передаёт сообщение по SMPP и обрабатывает ответ. В статье разберём архитектуру, параметры подключения, формат номера, delivery receipt, повторные попытки и порядок тестирования. После настройки такой связки бизнес сможет отправлять технические уведомления из одного сценария без ручной работы менеджера. Зачем связывать Telegram-бота и SMPP-шлюз? Telegram подходит для диалога с клиентом: бот принимает команду, показывает варианты и уточняет данные. SMS нужен в момент, когда уведомление должно дойти вне зависимости от того, открыт ли мессенджер. Например, бот может сообщить сотруднику о новой заявке, клиенту — о готовности услуги, а администратору — о сбое в расписании. У Telegram-бота нет прямого встроенного подключения к SMPP. Между ними размещают приложение, которое принимает события от Telegram Bot API и открывает соединение с SMS-шлюзом. Приложение хранит очередь сообщений, следит за ответами шлюза и записывает технический результат отправки. Для малого бизнеса схема выглядит так: клиент или сотрудник отправляет команду Telegram-боту; бот передаёт событие в backend-приложение; backend проверяет данные и создаёт SMS-задачу; SMPP-клиент отправляет сообщение через submit_sm; шлюз возвращает идентификатор сообщения и, если включён delivery receipt, итог доставки; бот показывает статус или передаёт его оператору. Если SMS должны уходить большими сериями, подключение через SMPP удобнее строить как отдельный сервис, а не добавлять сетевую логику прямо в обработчик Telegram-команд. Тогда временный сбой шлюза не блокирует ответы бота. Какие параметры нужны для SMPP-подключения? До написания кода запросите у провайдера параметры подключения. Обычно приложение получает адрес шлюза, порт, логин, пароль, тип bind и ограничения по скорости. Для отправки сообщений используется bind_transmitter либо bind_transceiver. Второй вариант нужен, если приложение должно принимать delivery receipt по тому же соединению. ПараметрЧто проверитьГде использовать Адрес и портДоступен ли порт с сервера, где работает backendПри создании TCP-соединения Логин и парольСовпадают ли значения с настройками шлюзаВ команде bind Тип bindНужен ли только исходящий трафик или также приём статусовПри выборе transmitter или transceiver Source addressКакое имя отправителя разрешено использоватьВ submit_sm TON и NPIКакие значения принимает конкретный шлюзДля адреса отправителя и номера получателя КодировкаКакие символы поддерживает шлюз и как передавать кириллицуВ data_coding и тексте сообщения Delivery receiptКак включить отчёт и в каком поле приходит message IDДля обновления статуса SMS Кириллица требует отдельной проверки. Если текст содержит русские буквы, приложение должно выбрать корректную кодировку и рассчитать длину сообщения по правилам шлюза. Нельзя просто передать UTF-8-строку в data без согласования параметров: SMS может прийти с повреждёнными символами или разбиться иначе, чем ожидает разработчик. Для диагностики полезно заранее проверить скорость и стабильность SMPP-шлюза: в тесте фиксируйте время подключения, bind, submit_sm и получение ответа. Практический разбор такой проверки есть в материале как проверить скорость и стабильность SMPP-шлюза. Для офиса с нестабильным интернетом отдельно продумайте повторное подключение и параметры SMPP-bind, описанные в статье как настроить SMPP-bind при нестабильном интернете. Как построить обработчик Telegram-события? Telegram-обработчик не должен ждать, пока SMS-шлюз ответит окончательно. После проверки команды он создаёт запись в очереди и быстро возвращает пользователю подтверждение: например, «заявка принята». Отправка идёт отдельным worker-процессом, который подключается к SMPP и обрабатывает задачи последовательно или с согласованным ограничением скорости. Минимальная запись в очереди содержит номер получателя, текст, внутренний тип уведомления, время создания и число попыток. Для контроля результата добавьте поля message ID, статус SMPP и время последнего ответа. В Telegram храните только те данные, которые нужны конкретному сценарию бота, а технический журнал делайте понятным разработчику: по одной записи должно быть видно, когда задача создана и какой ответ дал шлюз. Логика worker-процесса может выглядеть так: получить из очереди задачу со статусом «новая»; проверить формат номера и наличие текста; установить SMPP-соединение или использовать уже активный bind; передать submit_sm с нужными параметрами; сохранить message ID и ответ шлюза; дождаться delivery receipt, если он предусмотрен подключением; назначить финальный статус либо запланировать повторную попытку по правилам проекта. Повторная отправка требует осторожности. Если приложение потеряло ответ после submit_sm, оно не знает, принял ли шлюз сообщение. Автоматический повтор может привести к двум SMS. Поэтому для критичных уведомлений задайте отдельный статус «результат неизвестен», сохраните исходный запрос и решите, когда повтор допустим. Простое правило «повторять всегда» для SMPP-сценария не подходит. Как настроить статусы и отчёты о доставке? Ответ submit_sm подтверждает приём запроса шлюзом, но сам по себе не доказывает, что SMS дошло до телефона. Для этого используют delivery receipt. Шлюз передаёт в отчёте идентификатор сообщения и статус, который backend сопоставляет с записью в очереди. В коде разделите как минимум четыре состояния: «создано» — задача появилась после события Telegram; «принято шлюзом» — приложение получило положительный ответ submit_sm; «доставлено» — пришёл соответствующий delivery receipt; «ошибка» или «не доставлено» — шлюз вернул отказ или финальный отрицательный статус. Такое разделение помогает правильно отвечать пользователю. Бот не должен писать клиенту «SMS доставлено», если приложение получило только подтверждение приёма запроса. В интерфейсе лучше показывать короткий статус, а полный текст ошибки оставлять в журнале для администратора. Проверьте, как шлюз передаёт message ID: в разных интеграциях встречаются различия в формате, длине и регистре символов. Сохраняйте значение без изменения, иначе входящий отчёт не сопоставится с исходной задачей. Как протестировать связку до запуска? Тестирование начинайте с одного тестового номера и короткого сообщения. Сначала проверьте bind, затем одну отправку, после этого delivery receipt. Каждый этап должен иметь отдельную запись в журнале. Такой порядок быстро показывает, где проблема: в Telegram, очереди, кодировке, SMPP-параметрах или обработке статуса. Проверьте несколько сценариев: бот принимает корректную команду и создаёт ровно одну SMS-задачу; пустой номер и пустой текст отклоняются до обращения к шлюзу; кириллица приходит без повреждения символов; длинное сообщение обрабатывается согласно правилам шлюза; разрыв соединения не останавливает worker навсегда; повторная доставка одного delivery receipt не меняет статус ошибочно; ошибка шлюза отображается оператору в понятном виде; после перезапуска приложения очередь продолжает обработку. Для технических уведомлений можно использовать отдельные шаблоны: «Заявка принята», «Заказ готов», «Код доступа: 4821». Содержимое шаблона храните отдельно от кода. Тогда сотрудник сможет изменить текст без переписывания обработчика, а разработчик сохранит единый формат параметров и логирования. Какие ошибки чаще всего ломают отправку? Отправка SMS прямо из Telegram-webhook. Долгий сетевой запрос задерживает ответ бота. Используйте очередь и отдельный worker. Неверная кодировка. Русский текст превращается в нечитаемые символы, если data_coding и фактическое содержимое не согласованы. Отсутствие контроля message ID. Без этого приложение не свяжет delivery receipt с конкретной задачей. Повтор после любого тайм-аута. Тайм-аут не всегда означает, что шлюз не принял сообщение. Сначала сохраняйте состояние «результат неизвестен». Один бесконечный bind без проверки. Соединение может разорваться, поэтому worker должен выявлять потерю связи и выполнять повторный bind с ограничением попыток. Смешение бизнес- и технических статусов. Статус «бот ответил» не равен статусу «SMS доставлено». Разделяйте эти события в базе. 3 шага для запуска связки на этой неделе: описать события Telegram, после которых действительно нужно отправлять SMS, и подготовить таблицу статусов; получить параметры SMPP, проверить bind, кодировку и delivery receipt на одном тестовом сообщении; вынести отправку в очередь, добавить журнал message ID и проверить восстановление после разрыва соединения. Если Telegram-бот уже работает, подключение SMPP обычно оформляют отдельным модулем: бот отвечает за сценарий, очередь — за задачи, SMPP-клиент — за транспорт. При таком разделении проще менять тексты и бизнес-логику, не затрагивая сетевое подключение. Для SMS-кодов восстановления доступа полезно сравнить архитектуру с материалом как настроить восстановление доступа по SMS. > Source: https://smpp.by/kak-otpravlyat-sms-cherez-smpp-iz-telegram-bota --- # Как проверить скорость и стабильность SMPP-шлюза Нагрузочное тестирование SMPP показывает, сколько сообщений в секунду выдерживает конкретное соединение, когда растёт очередь и как шлюз реагирует на ошибки. Для бизнеса в Беларуси этого достаточно, чтобы заранее найти узкое место перед массовой отправкой: в приложении, соединении, настройках SMPP или на стороне провайдера. Ниже приведён план проверки без догадок: подготовить стенд, провести несколько тестов, собрать ответы и определить безопасную скорость отправки. Что именно проверяет нагрузочный тест SMPP? Одна цифра «SMS в секунду» не описывает работу шлюза полностью. При тестировании проверяют скорость принятия сообщений, время ответа на submit_sm, рост очереди, разрывы bind-соединения и получение статусов доставки. Если приложение принимает запросы быстро, но очередь постоянно увеличивается, фактическая пропускная способность ниже скорости генерации сообщений. Для малого бизнеса полезно разделить тест на четыре показателя: скорость отправки сообщений из приложения в SMPP-шлюз; доля успешных ответов и коды ошибок; задержка между отправкой и получением DLR; стабильность соединения при длительной работе. Проверяйте каждый показатель отдельно. Например, DLR показывает результат обработки сообщения сетью, но не заменяет контроль ответа на сам запрос отправки. Для наблюдения за статусами пригодится материал о том, как настроить мониторинг SMPP через DLR. Как подготовить безопасный стенд для проверки? Тестовую отправку лучше отделить от рабочего потока. Создайте отдельную очередь, отдельный идентификатор отправителя и ограниченный набор номеров, которыми разрешено пользоваться для проверки. Если провайдер предлагает песочницу, сначала проведите тест там: в ней можно проверить DLR, ошибки и склейку длинных сообщений без запуска рабочей рассылки. Практическая инструкция по такому сценарию описана в статье о SMPP-песочнице для проверки SMS и DLR. Перед запуском зафиксируйте исходные параметры: версию SMPP и настройки bind; число параллельных соединений; лимит сообщений в секунду, согласованный со шлюзом; размер сообщения и кодировку; таймаут ответа; правило повторной постановки сообщения в очередь. Сравнивать результаты можно только при одинаковых условиях. SMS на кириллице и латинице может занимать разное количество частей, поэтому отдельно проверьте короткое сообщение и текст, который выходит за предел одного сегмента. Настройки кодировки и UCS-2 разобраны в материале о передаче кириллицы в SMPP. Как провести тест на скорость без перегрузки шлюза? Начните с небольшой скорости и постепенно увеличивайте её. На каждом уровне отправляйте одинаковую тестовую пачку и записывайте результат. Резкий старт на максимальном значении не показывает реальную производительность: он смешивает предел приложения, лимит соединения и реакцию шлюза на всплеск. Запустите отправку с одного соединения и небольшой скоростью. Проверьте, что приложение получает положительные ответы на запросы. Увеличьте скорость и повторите тест с тем же размером сообщения. После этого добавьте второе соединение, если такая схема разрешена настройками шлюза. Зафиксируйте значение, при котором очередь начинает расти или появляются ошибки. На каждом шаге измеряйте не только среднюю скорость. Запишите минимальное, среднее и максимальное время ответа. Если среднее значение выглядит нормально, но отдельные запросы регулярно получают длинную задержку, массовая отправка всё равно может остановиться из-за таймаутов. Этап проверкиЧто отправлятьЧто фиксировать БазовыйКороткое сообщение в одной частиОтвет шлюза и время ответа КодировкаТекст на русском языкеОшибки кодировки и длину сообщения ПиковыйПачку с постепенно растущей скоростьюОчередь, таймауты и throttling ДлительныйРовный поток в течение согласованного периодаРазрывы bind и стабильность DLR Как определить безопасную скорость для массовой отправки? Рабочий лимит выбирают по результатам стабильного теста, а не по кратковременному пику. Если при определённой скорости очередь остаётся управляемой, ответы приходят без таймаутов, а соединение не разрывается, это значение можно использовать как исходное. Затем оставляют запас для колебаний трафика и повторов. Отдельно обработайте ошибку Throttling. В документации Devino указано: после такой ошибки сообщение нужно вернуть в очередь и выдержать таймаут на этом соединении в одну секунду (Devino Documentation). Значит, обработчик не должен немедленно повторять запрос в том же потоке. Иначе приложение само создаст новый всплеск и увеличит очередь. Удобная схема выглядит так: успешные сообщения покидают очередь, временные ошибки возвращаются с задержкой, постоянные ошибки попадают в отдельный журнал. Для автоматической обработки кодов и DLR можно использовать чек-лист о том, как обрабатывать ошибки SMPP и статусы доставки. Сигнал во время тестаВероятная причинаДействие Растёт очередьПриложение отправляет быстрее допустимого лимитаСнизить скорость и добавить контроль очереди Появляется throttlingПревышен лимит шлюза или соединенияПоставить сообщение в очередь и выдержать задержку Растёт число таймаутовСлишком короткий таймаут или перегружен каналПроверить сеть, соединения и время ответа Разрывается bindСбой сети или неверная логика keepaliveПроверить Enquire Link и восстановление соединения DLR приходит с задержкойПроблема обработки статусов или внешний участок маршрутаРазделить время ответа шлюза и время доставки Какие ошибки чаще всего искажают результат? Тестируют только один короткий всплеск. Он показывает пиковую реакцию, но не стабильность очереди. Смешивают отправку и DLR в одном показателе. Ответ SMPP и статус доставки приходят на разных этапах. Не записывают коды ошибок. Без них невозможно отличить лимит скорости от проблем авторизации или формата сообщения. Повторяют ошибку сразу. Для throttling нужен контролируемый возврат в очередь и задержка. Проверяют только один bind. При нескольких соединениях меняется распределение нагрузки. Используют рабочую базу номеров без согласования. Для стенда нужен заранее определённый тестовый набор. После теста сохраните журнал с временем отправки, идентификатором сообщения, ответом SMPP, кодом ошибки и временем получения DLR. В нём должна быть видна граница: на какой скорости очередь ещё сокращается, а после какого значения начинает расти. Для подключения большого объёма трафика через SMPP можно отдельно проверить параметры версии 3.4 и поддерживаемые типы сообщений: такая возможность описана в справочных материалах по SMPP API. 3 шага, которые можно сделать на этой неделе: Собрать тестовый стенд с отдельной очередью и журналом всех ответов. Провести ступенчатый тест для короткого сообщения и текста на кириллице. Зафиксировать рабочий лимит, правила обработки throttling и порядок восстановления bind. > Source: https://smpp.by/kak-proverit-skorost-i-stabilnost-smpp-shlyuza --- # Как настроить SMPP-bind при нестабильном интернете в офисе Таймауты SMPP-bind при офисном подключении чаще всего возникают из-за обрыва TCP-сессии, смены внешнего IP-адреса, слишком долгого ожидания ответа или неверной логики повторного подключения. В статье разберём, как проверить соединение, настроить таймеры, Enquire Link и переподключение, а также какие журналы собирать для диагностики. Эти шаги помогут отделить проблему локальной сети от сбоя на стороне SMS-шлюза и подготовить понятное техническое задание для интеграции SMPP. Почему SMPP-bind завершается по таймауту? SMPP-соединение начинается с операции bind. Клиент отправляет запрос на шлюз, а шлюз возвращает ответ с результатом авторизации. Если TCP-соединение уже разорвано, пакет задержался или приложение не дождалось ответа за заданный интервал, клиент записывает ошибку таймаута. При этом причина может находиться не в логине и пароле, а в маршруте между офисным компьютером и SMS-шлюзом. Для начала нужно разделить два сценария. Если bind не устанавливается с самого запуска, проверяют адрес шлюза, порт, учётные данные, разрешённый IP и сетевой экран. Если соединение устанавливается, но через некоторое время перестаёт отвечать, ищут разрыв бездействующей TCP-сессии, смену маршрута или отсутствие служебных запросов. В журнале приложения полезно сохранять время отправки bind, время получения ответа, код результата, состояние TCP-соединения и номер попытки переподключения. Запись «таймаут» без этих полей мало помогает: по ней нельзя понять, завис ли сам клиент, пропал ли маршрут или шлюз не вернул ответ. Как проверить офисную сеть до настройки SMPP? Сначала проверьте, выходит ли сервер или рабочая станция в интернет через тот же маршрут, который использует SMPP-клиент. Если в офисе несколько каналов, балансировщик или VPN, TCP-сессия может начаться через один маршрут, а продолжиться через другой. Для SMPP это выглядит как внезапный обрыв уже созданного соединения. Проверьте правила исходящего трафика на нужный TCP-порт. Межсетевой экран должен разрешать соединение с адресом SMS-шлюза, а NAT должен сохранять сессию достаточно долго. Если провайдер выдаёт динамический внешний IP, заранее уточните, допускает ли шлюз подключение с такого адреса. Для отдельного сценария с динамическим IP полезен разбор подключения SMPP при динамическом IP. При диагностике фиксируйте сетевые события на двух уровнях: журнал SMPP-клиента: bind, ответы, enquire_link, submit_sm и disconnect; журнал операционной системы и сетевого оборудования: разрыв TCP, смена маршрута, блокировка порта; время на всех устройствах, чтобы сопоставить события по одной временной шкале. Обычная проверка доступности узла не заменяет проверку TCP-сессии. Узел может отвечать на сетевой запрос, пока конкретное SMPP-соединение уже закрыто. Поэтому тестируйте именно порт и смотрите состояние соединения во время отправки тестового сообщения. Как настроить таймеры и повторное подключение? Таймер ответа задаёт максимальное время ожидания ответа на конкретный запрос. Таймер бездействия контролирует период, в течение которого по сессии нет обмена. Эти параметры нельзя смешивать: увеличение времени ожидания ответа не восстановит соединение, которое уже закрыл маршрутизатор. Клиенту нужна отдельная логика переподключения. После таймаута он закрывает старый сокет, очищает состояние bind и создаёт новую TCP-сессию. Повторная отправка bind через тот же зависший сокет часто только увеличивает очередь ошибок. Для повторных попыток задайте паузу между подключениями. При кратком сбое достаточно небольшой задержки, при длительном отказе паузу увеличивают, чтобы клиент не создавал бесконечный поток запросов. После успешного bind счётчик ошибок обнуляют. Максимальное число попыток и интервал лучше хранить в конфигурации, а не зашивать в код. Событие Действие SMPP-клиента Что записать в журнал Нет ответа на bind Закрыть сокет и повторить подключение после паузы Время запроса, адрес шлюза, порт, номер попытки Соединение разорвано во время работы Остановить отправку новых запросов и восстановить bind Последняя успешная операция и причина закрытия TCP Получен отрицательный ответ bind Не повторять запрос без проверки параметров Код результата и текст ошибки шлюза Долгое отсутствие трафика Отправить служебный запрос и проверить ответ Время отправки и получения служебного ответа Отрицательный ответ bind и отсутствие ответа требуют разной реакции. В первом случае шлюз сообщил результат обработки запроса, поэтому нужно проверить параметры подключения. Во втором клиент не получил подтверждение на сетевом уровне или не дождался его в заданный срок. Зачем нужен Enquire Link при офисном подключении? Enquire Link помогает проверять, что SMPP-сессия остаётся рабочей даже при отсутствии сообщений. Клиент отправляет служебный запрос, а шлюз отвечает. Если ответа нет, приложение получает основание закрыть соединение и запустить процедуру переподключения, вместо того чтобы оставлять зависшую сессию в рабочем состоянии. Интервал служебной проверки выбирают с учётом таймера бездействия на маршрутизаторе и у провайдера связи. Слишком редкая проверка не обнаружит разрыв вовремя. Слишком частая создаёт лишний служебный обмен и затрудняет анализ журнала. Конкретный интервал согласуют с документацией шлюза и сетевой схемой офиса. При параллельной отправке сообщений нельзя запускать несколько независимых циклов Enquire Link для одной сессии. Один поток должен отвечать за состояние соединения, а очередь отправки должна получать от него сигнал, что bind снова активен. Так приложение не начнёт отправлять submit_sm в сокет, который уже закрыт. Настройку служебных проверок можно дополнить отдельным мониторингом. Практический разбор параметров и контроля Enquire Link на SMPP-шлюзе поможет сопоставить состояние сессии с событиями в журнале. Как не потерять сообщение после разрыва сессии? Разрыв SMPP-соединения не всегда означает, что шлюз не получил предыдущий submit_sm. Если клиент повторит отправку без проверки, одно сообщение может уйти дважды. Поэтому приложение хранит идентификатор сообщения, его состояние и момент передачи, а решение о повторе принимает по ответу шлюза и внутренним правилам очереди. Очередь отправки должна отделять подготовленные сообщения от тех, которые уже получили ответ. Пока bind не восстановлен, новые сообщения остаются в очереди. После переподключения приложение продолжает обработку с последней подтверждённой позиции, а не отправляет весь список заново. Для каждого сообщения полезно различать несколько состояний: подготовлено к отправке, передано в SMPP, получен ответ submit_sm, получен отчёт о доставке, обнаружена ошибка. Отчёт о доставке DLR приходит отдельным событием, поэтому его нельзя использовать как единственное подтверждение того, что запрос submit_sm был принят шлюзом. Если интеграция работает с большим объёмом SMS, требования к очереди, отчётам и скорости обработки лучше зафиксировать до подключения. SMPP используют именно для прямой передачи трафика к SMS-шлюзу, контроля отправки и получения DLR; такая модель описана в материалах об выборе SMPP-шлюза и сравнении SMPP с HTTP API. Какие ошибки чаще всего вызывают таймауты? Клиент повторяет bind по уже закрытому сокету, вместо того чтобы создать новое TCP-соединение. Сетевой экран разрешает первый запуск, но закрывает неактивную сессию раньше служебной проверки. Приложение не учитывает смену внешнего IP при работе через динамический адрес. Один поток отправляет SMS, а другой одновременно закрывает и пересоздаёт соединение. В журнале нет времени операций, кодов ответа и причины разрыва, поэтому диагностика строится на догадках. После таймаута клиент повторяет submit_sm, не проверяя состояние предыдущей попытки. Для малого бизнеса разумная схема выглядит так: отдельный сервер или стабильная рабочая станция, разрешённый исходящий маршрут, один менеджер SMPP-сессии, Enquire Link, очередь сообщений и подробный журнал. Если офисный интернет часто меняет адрес или маршрут, подключение можно вынести на инфраструктуру с постоянным сетевым профилем, а локальному приложению оставить безопасный канал обмена. 3 шага, которые можно сделать на этой неделе: Соберите журнал bind и TCP-событий за несколько рабочих циклов, отметив точное время каждого таймаута. Проверьте NAT, межсетевой экран, внешний IP и таймер бездействия, затем включите контроль Enquire Link. Проверьте сценарий разрыва на тестовой очереди: клиент должен закрыть старую сессию, восстановить bind и продолжить отправку без неконтролируемых дублей. > Source: https://smpp.by/kak-nastroit-smpp-bind-pri-nestabilnom-internete-v-ofise --- # Как настроить отправку SMS из 1С через SMPP-шлюз Отправку SMS из 1С в 2026 году можно настроить через промежуточный модуль или обработку, которая передаёт сообщения в SMPP-шлюз. В 1С формируется текст и номер получателя, шлюз принимает запрос и возвращает статус доставки. Такой вариант подходит для уведомлений о заказах, счетах, оплате и готовности услуги. В статье разберём архитектуру подключения, параметры SMPP, сценарий без ручной отправки и проверку результата на тестовой базе. Как устроена интеграция 1С с SMPP-шлюзом? 1С обычно не подключают к SMPP напрямую одной настройкой. Между учётной системой и шлюзом нужен программный слой: внешняя обработка, расширение конфигурации, отдельный коннектор или небольшой сервис. Он получает событие из 1С, собирает SMS и открывает соединение с SMPP-сервером. В базовом сценарии цепочка выглядит так: менеджер или бухгалтер меняет статус документа, 1С создаёт задание на отправку, интеграционный модуль передаёт сообщение в шлюз, а затем записывает ответ. Если шлюз прислал идентификатор сообщения, его можно сохранить в 1С вместе со временем отправки и текущим статусом. КомпонентЧто делаетЧто проверить 1СОпределяет событие и формирует текстЕсть ли номер телефона и нужный статус документа Интеграционный модульПередаёт данные по SMPPПоддерживает ли соединение, кодировку и повторную отправку SMPP-шлюзПринимает SMS и направляет её операторуЛогин, пароль, адрес, порт и разрешённое имя отправителя Отчёт или журнал 1СПоказывает результатСохраняются ли ответ шлюза и ошибка доставки Для малого бизнеса полезно разделить создание сообщения и его отправку. 1С сначала записывает задание в очередь, а модуль отправляет его по одному или небольшими партиями. При временном сбое соединения документ не зависает, а сообщение остаётся в очереди с понятным статусом. Какие параметры SMPP нужно получить до настройки? До работы с 1С запросите у провайдера параметры подключения. Обычно нужны адрес SMPP-сервера, порт, логин, пароль, тип подключения и допустимое имя отправителя. Для полноценной диагностики также уточните формат статусов, правила кодировки и лимит длины сообщения. Адрес сервера и порт для SMPP-соединения. Логин и пароль для bind-запроса. Режим подключения: transmitter, receiver или transceiver. Имя отправителя и требования к его регистрации у провайдера. Поддерживаемая кодировка, обычно GSM-7 или Unicode. Правила получения delivery receipt, то есть отчёта о доставке. Ограничения по числу одновременных соединений и скорости отправки. Режим transceiver удобен, когда один канал должен и отправлять сообщения, и принимать отчёты о доставке. Если 1С только передаёт SMS, провайдер может предложить transmitter, а статусы будут приходить через отдельный механизм. Выбранная схема должна совпадать с возможностями модуля. Кодировка влияет на длину текста. Кириллица обычно требует Unicode, поэтому длинное уведомление разбивается на несколько частей. Модуль должен корректно считать длину, передавать параметры esm_class и UDHI для составных SMS, а также не обрезать переменные из документа. Как пошагово подключить 1С к SMPP? Опишите события, которые должны запускать SMS. Например, проведение счёта, поступление оплаты, изменение статуса заказа или готовность услуги. Составьте шаблоны сообщений. Оставьте в них только данные, которые нужны получателю: номер заказа, сумму в BYN, срок оплаты или адрес получения. Создайте очередь отправки в 1С. Для каждой записи храните номер, текст, дату создания, число попыток и статус. Настройте модуль SMPP. Внесите адрес, порт, учётные данные, имя отправителя и кодировку. Добавьте защиту от дублей. Ключом может быть связка «документ плюс тип уведомления», чтобы повторный запуск обработки не отправил одинаковое SMS. Проверьте соединение на тестовом номере. Сначала отправьте короткий текст без переменных, затем сообщение с кириллицей и подстановкой данных. Сохраните ответ шлюза. Идентификатор сообщения пригодится для сопоставления с delivery receipt и поиска ошибки. Шаблон лучше хранить отдельно от кода обработки. Тогда бухгалтер сможет изменить формулировку без переписывания логики, а разработчику не придётся каждый раз менять модуль из-за новой подписи или срока оплаты. Для отложенных уведомлений используйте очередь с датой отправки. Например, 1С создаёт сообщение сразу после проведения документа, но модуль отправляет его в заданное время. Технические варианты такой схемы разобраны в материале как настроить отложенную отправку SMS через SMPP. Как связать SMS с заказами и счетами? Для заказов обычно задают несколько независимых событий. Сообщение можно создать после регистрации заказа, после подтверждения менеджером и после изменения статуса готовности. Каждое событие должно иметь собственный код, чтобы отмена или повторное проведение документа не создали лишнюю отправку. Пример шаблона для заказа: «Заказ №{{Номер}} принят. Сумма: {{Сумма}} BYN». Для счёта формулировка может содержать номер документа и дату оплаты: «Счёт №{{Номер}} на сумму {{Сумма}} BYN ожидает оплаты до {{Дата}}». Переменные нужно брать из реквизитов конкретного документа, а не вводить вручную. Перед отправкой проверьте три условия: в документе есть телефон, статус соответствует правилу, а сообщение ещё не отправлялось. Если хотя бы одно условие не выполнено, запись лучше поместить в журнал с причиной пропуска. Так бухгалтер видит, почему SMS не ушло, и не создаёт повторную задачу вручную. Событие в 1СЧто отправитьКогда не отправлять Заказ созданНомер заказа и факт принятияНет телефона или заказ создан как черновик Счёт проведёнНомер, сумма в BYN и срок оплатыДокумент отменён или уже отправлен ранее Оплата поступилаПодтверждение оплатыПлатёж не связан со счётом Услуга готоваСообщение о готовностиСтатус изменён обратно Если в компании несколько типов уведомлений, добавьте справочник шаблонов. В нём можно хранить код события, текст, разрешённые переменные и признак активности. Это упрощает контроль: отключение одного сценария не затрагивает остальные. Как проверять ошибки и стоимость отправки? Тестирование проводите в два этапа. Сначала проверьте bind и отправку одного сообщения, затем прогоните очередь из нескольких записей. В журнале должны быть видны время подключения, результат submit_sm, идентификатор сообщения и финальный статус. Ошибка авторизации означает неверные учётные данные или неподходящий режим bind. Ошибка кодировки указывает на неправильную обработку кириллицы или составных сообщений. Пустой статус часто связан с тем, что модуль не сохраняет delivery receipt. Повторная отправка после тайм-аута требует проверки, принял ли шлюз первое сообщение. Большая очередь при одном соединении может возникнуть из-за ограничения скорости отправки. Разделяйте техническую ошибку и отказ доставки. В первом случае 1С может повторить попытку по правилам очереди. Во втором повторная отправка не всегда нужна: номер может быть недоступен или оператор мог отклонить сообщение. Отчёт должен показывать эти ситуации раздельно. Расходы зависят от количества SMS, длины текста, кодировки и тарифа шлюза. Одно длинное кириллическое уведомление иногда превращается в несколько частей, поэтому перед запуском посчитайте размер типовых сообщений и заложите его в расчёт. Методика описана в материале как рассчитать стоимость SMS через SMPP в 2026 году. Типичные ошибки при подключении 1С к SMPP Отправка запускается при каждом открытии документа, поэтому одно уведомление дублируется. Модуль не учитывает Unicode и режет кириллический текст посередине переменной. 1С ждёт ответ шлюза в основном потоке и временно блокирует работу пользователя. В журнале сохраняется только отметка «отправлено», без текста ошибки и идентификатора сообщения. После разрыва соединения очередь запускает повторную отправку без проверки предыдущего результата. Шаблон содержит слишком много полей, поэтому сообщение разбивается на несколько частей. Перед запуском подготовьте один сценарий, например уведомление о поступлении оплаты. Проверьте его на тестовой базе, затем добавьте заказы и счета. Если нужен отдельный приоритет для коротких кодов подтверждения, полезно заранее изучить как настроить приоритет SMS-кодов в SMPP. 3 шага для запуска на этой неделе: Соберите параметры SMPP и опишите одно событие в 1С, которое должно создавать SMS. Настройте очередь, шаблон с переменными и журнал статусов. Проверьте короткое сообщение, кириллицу, повтор после сбоя и отчёт о доставке на тестовом номере. > Source: https://smpp.by/kak-nastroit-otpravku-sms-iz-1s-cherez-smpp-shlyuz --- # Как настроить отложенную отправку SMS через SMPP Отложенная отправка через SMPP позволяет передать SMS оператору заранее и указать время доставки в поле schedule_delivery_time. Такой подход подходит для напоминаний, уведомлений о начале смены, изменении статуса заказа и других сообщений, которые должны прийти по расписанию. В статье разберём формат времени, часовые пояса, контроль DLR и логику повторной отправки, чтобы малый бизнес мог собрать простой SMS-шедулер без ручной загрузки сообщений. Что делает schedule_delivery_time в SMPP? При обычной отправке приложение передаёт сообщение сразу. При отложенной отправке оно добавляет к запросу submit_sm значение schedule_delivery_time. SMS-центр или SMPP-шлюз принимает сообщение, сохраняет его до заданного момента и затем передаёт в сеть оператора. Поле задаёт момент, к которому нужно привязать обработку сообщения. Точный результат зависит от настроек SMPP-провайдера: один шлюз поддерживает отложенную доставку на своей стороне, другой передаёт запрос дальше оператору, а третий может игнорировать расписание, если функция не включена для подключения. Поэтому первый тест проводят на небольшом количестве номеров и проверяют время фактической передачи. Для приложения полезно разделить два события: шлюз принял сообщение и вернул message_id; оператор сообщил итог через DLR, то есть delivery receipt. Положительный ответ на submit_sm подтверждает приём запроса, но не означает, что абонент уже получил SMS. Именно поэтому планировщик должен сохранять идентификатор сообщения и связывать его с последующим DLR. Для технической схемы контроля статусов пригодится материал о настройке каскада для доставки SMS-кода и статуса. Как подготовить время отправки и часовой пояс? Самая частая ошибка появляется, когда бизнес хранит расписание по местному времени, а приложение формирует SMPP-поле в другом часовом поясе. Например, менеджер выбирает отправку на 09:00 по Минску, а сервер работает в UTC. Если приложение не преобразует время заранее, SMS уйдёт с ошибкой в несколько часов. Для каждого сообщения храните как минимум четыре значения: исходное время, которое выбрал пользователь; часовой пояс этого времени; рассчитанный момент отправки в едином формате; статус задачи: запланирована, передана, доставлена или завершилась ошибкой. Для клиентов в Беларуси можно установить единый часовой пояс в настройках проекта. Для зарубежных получателей часовой пояс лучше хранить у контакта или определять по правилам отдельного сегмента. Телефонный код страны не всегда достаточно надёжно показывает фактическое местное время: клиент может находиться в поездке, а корпоративный номер может обслуживать другой регион. Практичная схема выглядит так: пользователь выбирает дату и время в привычном виде, сервер переводит значение в единый внутренний формат, а перед отправкой формирует schedule_delivery_time согласно требованиям конкретного SMPP-шлюза. В интерфейсе рядом со временем полезно показывать его часовой пояс, чтобы оператор видел, к какому региону относится расписание. Какой формат передавать в schedule_delivery_time? Формат поля нужно сверить с документацией SMPP-подключения. Нельзя автоматически переносить в него строку из базы данных вроде «11.08.2026 09:00». SMPP использует специальное представление даты и времени, а отдельные шлюзы устанавливают дополнительные ограничения на точность, часовой пояс и допустимый горизонт планирования. Перед запуском проверьте четыре параметра: поддерживает ли соединение отложенную отправку; какой формат даты принимает шлюз; какую точность времени он использует: минуты или секунды; что происходит с сообщением, если указанное время уже прошло. В тестовой отправке задайте время на несколько минут вперёд и сравните три отметки: момент создания задачи, время приёма запроса шлюзом и время, указанное в DLR. Если шлюз возвращает ошибку, сохраните код и текст ответа. Он пригодится при разборе причины, особенно когда проблема связана с форматом поля или недоступностью функции. Текст сообщения тоже влияет на планирование. Кириллица и специальные символы меняют правила кодирования и длину SMS, поэтому перед передачей проверьте настройку кириллицы в SMPP, UCS-2 и длину SMS. Иначе планировщик отработает правильно, но приложение получит больше сегментов, чем рассчитывалось. Как не потерять DLR у запланированных сообщений? Шедулер должен считать задачу выполненной только после понятного результата. После вызова submit_sm сохраните внутренний идентификатор задачи, message_id от шлюза, номер получателя, запланированное время и содержимое сообщения или его безопасный идентификатор. DLR затем сопоставляется по message_id, а при необходимости дополнительно проверяется по номеру и времени отправки. Событие Что сохранить Действие приложения Задача создана Получатель, текст, время и часовой пояс Поставить статус «запланирована» submit_sm принят Код ответа и message_id Перевести задачу в «передана шлюзу» Пришёл DLR Статус доставки и время события Обновить итоговый статус Ответ с ошибкой Код ошибки и причина Отметить сбой и решить, нужна ли повторная попытка DLR не пришёл Время ожидания и историю проверок Передать задачу в контроль очереди Повторная отправка требует отдельного правила. Если приложение не получило DLR, это ещё не доказывает, что SMS не доставили: задержка могла возникнуть на стороне шлюза или оператора. Поэтому повторять сообщение сразу после тайм-аута рискованно. Для критичных уведомлений задайте ограниченное число проверок, храните историю попыток и не создавайте новый запрос без понятного основания. Для расчёта расходов учитывайте каждую фактически отправленную часть длинного сообщения, а не только одну запись в очереди. Подход к расчёту стоимости через SMPP разобран в материале о стоимости SMS через SMPP в 2026 году. Как устроить простой SMPP-шедулер для малого бизнеса? Минимальная архитектура состоит из очереди задач, воркера и обработчика DLR. Очередь хранит сообщения с будущим временем отправки. Воркер регулярно выбирает задачи, срок которых наступил, открывает или использует SMPP-сессию и отправляет их через submit_sm. Обработчик входящих уведомлений меняет статусы в базе. Не стоит отправлять все запланированные сообщения одним длинным циклом. Разделите работу на небольшие пачки и задайте ограничение скорости для конкретного соединения. Так проще пережить временный отказ, переподключение или рост очереди. Если бизнес отправляет объёмный трафик, отдельно контролируйте количество активных SMPP-сессий и доступный лимит на стороне провайдера. В таблице задач полезно иметь поля scheduled_at, timezone, status, attempt_count, provider_message_id и last_error. Перед отправкой воркер блокирует выбранную строку, чтобы два процесса не передали одно SMS одновременно. После перезапуска сервера задачи со статусом «в работе» возвращаются в контрольную выборку по понятному правилу. Какие ошибки чаще всего ломают отложенную отправку? Приложение передаёт локальное время сервера вместо времени клиента. В schedule_delivery_time попадает формат, который не поддерживает шлюз. Задача считается доставленной сразу после положительного ответа на submit_sm. Воркер повторяет отправку без проверки уже сохранённого message_id. После перезапуска сервера сообщения со статусом «в работе» остаются без владельца. Тест проводят только на одном времени и не проверяют переход между часовыми поясами. Для первого запуска достаточно взять один сценарий, например напоминание о записи, и проверить путь целиком: создание задачи, преобразование времени, передачу через SMPP, получение DLR и обработку сбоя. Затем добавьте часовые пояса и пакетную отправку. Если требуется подключить высокообъёмный трафик к конкретной системе, техническую часть можно заказать у специалиста по SMPP, сохранив собственную бизнес-логику расписаний. 3 шага, которые можно сделать на этой неделе: Уточнить у SMPP-провайдера поддержку schedule_delivery_time, формат поля и правила DLR. Добавить в очередь задачи часовой пояс, внутренний статус и provider_message_id. Провести тест на несколько минут вперёд и сверить плановое время с отметками передачи и доставки. > Source: https://smpp.by/kak-nastroit-otlozhennuyu-otpravku-sms-cherez-smpp --- # Как рассчитать стоимость SMS через SMPP в 2026 году Стоимость SMS через SMPP зависит от числа сегментов, кодировки текста и тарифа маршрута. Короткое сообщение на латинице часто занимает один сегмент, а кириллица и длинный текст быстро увеличивают расчётный объём. В статье разберём, как определить кодировку, посчитать сегменты, учесть конкатенацию и заложить результат в бюджет бизнеса в Беларуси. После этого разработчик сможет сверить расчёт с биллингом SMPP и заранее увидеть переплату. Из чего складывается стоимость SMS через SMPP? Провайдер обычно считает отправленные сегменты, а не количество вызовов команды submit_sm. Если приложение отправило одно длинное сообщение, в биллинге оно может превратиться в несколько SMS-частей. Поэтому формула выглядит так: Стоимость отправки = количество получателей × количество сегментов × цена одного сегмента. К этой формуле иногда добавляются отдельные условия маршрута: минимальный объём, разные цены для направлений или особый тариф для сервисных сообщений. Такие параметры зависят от договора и настроек SMS-провайдера. Их нужно сверять в тарифе, а технический расчёт сегментов делать самостоятельно. Для малого бизнеса в Беларуси удобно разделить расчёт на две части. Сначала программа определяет длину сообщения и кодировку. Затем биллинг умножает число сегментов на цену маршрута. Если эти этапы смешать, ошибка обнаружится уже после отправки счёта. Как кодировка влияет на число SMS-сегментов? Латинский текст может передаваться в GSM-7, если все символы входят в допустимый набор этой кодировки. Один такой сегмент вмещает до 160 знаков. При конкатенации часть места уходит на служебный заголовок, поэтому длинное сообщение обычно вмещает до 153 знаков в каждом сегменте. Кириллица, большинство эмодзи и ряд специальных символов переводят сообщение в UCS-2. В одном коротком UCS-2-сегменте помещается до 70 знаков. Для составного сообщения лимит снижается до 67 знаков на сегмент. ВариантЛимит одного сегментаЛимит составного сообщенияЧто проверить GSM-7До 160 знаковДо 153 знаков на частьВсе ли символы входят в GSM-7 UCS-2До 70 знаковДо 67 знаков на частьКириллицу, эмодзи и специальные знаки Например, фраза на русском языке длиной 120 знаков не считается одним SMS: она попадёт в два UCS-2-сегмента. Сообщение на латинице той же длины может занять один GSM-7-сегмент, если в нём нет символов, которые меняют кодировку. Символ иногда меняет расчёт неожиданно. Кавычки, длинное тире, буквы с диакритикой или эмодзи могут перевести весь текст в UCS-2. Поэтому проверять нужно не только язык сообщения, но и фактический набор знаков. Подробнее о передаче кириллицы рассказано в материале как отправлять кириллицу в SMPP и учитывать длину SMS. Как считать конкатенацию в SMPP? Конкатенация позволяет показать получателю несколько частей как одно длинное сообщение. SMPP передаёт части отдельно, а телефон собирает их по служебным параметрам. Для биллинга это всё равно несколько SMS-сегментов. При отправке через SMPP разработчик обычно задаёт текст, кодировку и параметры длинного сообщения. Провайдер или клиентская библиотека может сама разбить текст на части. Это удобно для интеграции, но не отменяет проверки: приложение должно получить корректный статус для каждой части, а система должна сохранять связь между ними. Расчёт можно сделать вручную: сообщение до 160 знаков в GSM-7 — один сегмент; сообщение от 161 до 306 знаков в GSM-7 — два сегмента при лимите 153 знака на часть; сообщение до 70 знаков в UCS-2 — один сегмент; сообщение от 71 до 134 знаков в UCS-2 — два сегмента при лимите 67 знаков на часть; для более длинного текста число частей округляют вверх от длины сообщения, делённой на лимит составного сегмента. Учитывайте и служебные данные SMPP. Для длинных сообщений применяются параметры User Data Header или механизм, который использует конкретная библиотека. Если приложение формирует части вручную и неправильно указывает номера сегментов, получатель увидит обрывки текста, а отчёты о доставке будет трудно сопоставить. Как заложить сегменты в бюджет бизнеса? Сначала составьте несколько реальных шаблонов: код подтверждения, уведомление о заказе, напоминание и сообщение со ссылкой. Для каждого шаблона зафиксируйте длину, кодировку и число сегментов. Один средний показатель для всех SMS даст искажённый прогноз, если в потоке есть и короткие OTP-коды, и длинные уведомления. Тип сообщенияЧто влияет на расчётПрактическое решение Код подтвержденияКороткий текст, язык, имя отправителяОграничить шаблон одной частью Статус заказаДлина текста, номер заказа, ссылкаПроверить длину после подстановки переменных Напоминание клиентуКириллица и дополнительные сведенияСократить шаблон или заложить несколько сегментов Техническое уведомлениеПовторная отправка и DLRРазделять стоимость попытки и сегмента Для планирования в BYN используйте фактическую цену сегмента из выбранного тарифа. Если за месяц система отправляет 12 000 сообщений, а среднее сообщение занимает 1,4 сегмента, расчётный объём составит 16 800 сегментов. Это уже тот показатель, который нужно умножать на цену, указанную для маршрута. Среднее значение следует считать по журналу отправок, а не по числу шаблонов. В одном шаблоне переменная с длинным названием товара может увеличить сообщение на несколько десятков знаков. Поэтому тестируйте реальные подстановки: имя клиента, номер заказа, сумму и ссылку. Какие ошибки увеличивают счёт за SMPP? Подсчёт сообщений вместо сегментов. Одно длинное SMS в биллинге может стать двумя или несколькими частями. Проверка длины до подстановки переменных. Итоговый текст часто длиннее шаблона. Случайный переход в UCS-2. Эмодзи или один специальный символ меняют доступный лимит. Ориентация на лимит короткого сообщения. Для конкатенации действуют другие пределы: 153 знака в GSM-7 и 67 в UCS-2. Отсутствие разбивки по статусам DLR. Без неё сложно отличить доставленные сегменты от повторных попыток отправки. Ручная сборка частей без теста. Ошибка в служебных параметрах нарушает порядок и склейку сообщения. Техническую проверку удобно проводить на тестовой группе номеров: отправить каждый шаблон с пограничной длиной, проверить отображение на телефоне и сравнить число сегментов в отчёте SMPP с данными биллинга. После такой сверки шаблоны можно подключать к рабочему потоку через SMPP, а расчёт стоимости вести по сегментам, кодировке и фактическим попыткам отправки. > Source: https://smpp.by/kak-rasschitat-stoimost-sms-cherez-smpp-v-2026-godu --- # SMPP для Интернета вещей: как отправлять SMS со счётчиков и датчиков SMPP подходит для систем, которые получают события от счётчиков, датчиков и терминалов и должны быстро передать уведомление по SMS. В статье разберём схему такой интеграции: как устройство передаёт событие на сервер, зачем нужен промежуточный сервис, какие параметры настроить в SMPP и как проверять доставку через DLR. После чтения можно составить техническое задание для разработчика и подготовить тестовое подключение к SMS-шлюзу. Какие задачи IoT-системы решают через SMPP? Счётчик или датчик обычно не отправляет SMS напрямую. Устройство передаёт показание или сигнал на сервер производителя, оператора оборудования либо внутреннее приложение. Сервер анализирует событие и решает, кому нужно отправить уведомление. SMPP подключает этот сервер к SMS-шлюзу и передаёт сообщение на мобильную сеть. Для малого бизнеса сценарий может выглядеть так: датчик фиксирует отключение питания, терминал сообщает об ошибке, а система контроля объекта получает превышение заданного значения. В каждом случае приложение формирует короткое SMS с типом события, временем и идентификатором оборудования. SMPP отвечает за передачу сообщения в шлюз, а отчёт DLR помогает понять, доставлено ли оно. Протокол особенно уместен, когда сообщения формирует программа, а не сотрудник в личном кабинете. Сервер может создавать отправки автоматически, задавать приоритет, обрабатывать ответы шлюза и принимать статусы доставки. При небольшом количестве уведомлений разработчику проще начать с API или готового конструктора, но при постоянном потоке событий SMPP даёт прямое подключение к SMS-шлюзу и позволяет контролировать обмен на уровне приложения. Как выглядит схема отправки SMS от датчика? Надёжная схема состоит из нескольких отдельных этапов. Датчик передаёт событие в систему мониторинга, система проверяет правила, очередь сообщений удерживает задания, а SMPP-клиент соединяется со шлюзом и отправляет SMS. Такое разделение помогает повторить отправку при временной ошибке и не связывать работу оборудования с состоянием одного сетевого соединения. Устройство передаёт событие на сервер мониторинга. Приложение определяет тип уведомления и получателя. Сообщение попадает в очередь отправки. SMPP-клиент открывает соединение со шлюзом и выполняет bind. Приложение отправляет сообщение командой submit_sm. Шлюз возвращает идентификатор сообщения и принимает его к обработке. Система получает DLR и сохраняет итоговый статус. Очередь нужна даже в простой системе. Если одновременно сработали несколько датчиков, приложение не теряет события из-за задержки сети и не пытается отправить всё одним запросом. Для каждого задания полезно хранить внутренний идентификатор события, время создания, адрес получателя, статус SMPP и текст ошибки. Связь с шлюзом лучше держать отдельным сервисом. Он следит за соединением, повторяет bind после разрыва, ограничивает скорость отправки и передаёт результат в основное приложение. Такая архитектура пригодится, если один сервер одновременно получает данные от терминалов, счётчиков и датчиков. Какие настройки SMPP нужны для IoT-уведомлений? До начала разработки согласуйте параметры подключения со шлюзом. В техническом задании обычно фиксируют адрес и порт, логин, пароль, тип bind, системный идентификатор, допустимую скорость, формат адресов и правила работы с отчётами. Без этого разработчик может подключиться к серверу, но не сможет корректно обработать полный цикл доставки. Параметр Зачем он нужен Что проверить Тип соединения Определяет режим работы SMPP-клиента Нужен ли bind_transceiver или отдельные соединения для отправки и приёма статусов System ID и пароль Позволяют шлюзу распознать подключение Совпадают ли значения с настройками провайдера Адрес и порт Определяют точку подключения Разрешён ли доступ с сервера и открыт ли нужный порт TON и NPI Описывают тип и план нумерации адресов Соответствуют ли настройки формату номеров Data coding Определяет кодировку текста Корректно ли передаётся кириллица и длинные сообщения DLR Возвращает статус обработки и доставки Приходит ли отчёт и связывается ли он с исходным сообщением Для текста на русском языке отдельно проверьте кодировку и длину сообщения. Ошибка в data_coding приводит к нечитаемым символам, а длинный текст может разделиться на несколько частей. Практические детали передачи кириллицы, UCS-2 и конкатенации разобраны в материале о кодировках SMS в SMPP. Отправитель тоже нужно согласовать заранее. Если система передаёт имя отправителя в source_addr, шлюз может применять свои правила к его формату. Для аварийных уведомлений лучше использовать короткий шаблон: название объекта, тип события и действие, которое нужно выполнить. Длинные пояснения оставьте интерфейсу мониторинга. Как обработать DLR и ошибки доставки? Для IoT-системы сам факт принятия команды submit_sm недостаточен. Он показывает, что шлюз получил сообщение, но не подтверждает доставку на телефон. Итоговый статус приходит отдельным отчётом DLR, который нужно связать с message_id из ответа шлюза. Приложение должно различать временные и окончательные ошибки. При временной проблеме соединения задание можно вернуть в очередь с ограниченным числом повторов. Если шлюз сообщает об окончательном отказе, повторная отправка того же текста без изменения причины только создаст лишний трафик. Статус и код ошибки лучше сохранить в журнале, чтобы оператор видел, какое событие не дошло. Проверяйте, что DLR включён в параметрах submit_sm. Сохраняйте исходный message_id в базе или очереди. Сопоставляйте статусы независимо от порядка их поступления. Разделяйте timeout, разрыв соединения и отказ шлюза. Ограничивайте число повторов для одного события. Показывайте оператору время последней попытки и текст ошибки. При работе с номерами Беларуси отдельный интерес представляют маршрутизация и DLR после переноса номера между сетями. Обработка MNP и отчётов доставки описана в материале о MNP и DLR для белорусских номеров. Это полезно проверить до запуска системы, если оборудование отправляет уведомления на номера разных операторов. Как протестировать SMPP до подключения реальных датчиков? Сначала тестируют сам канал, затем бизнес-логику и только после этого подключают оборудование. На первом этапе достаточно тестового SMPP-клиента. Он должен выполнить bind, отправить короткое сообщение, получить response и принять DLR. Если уже здесь возникают проблемы, датчик не поможет их скрыть. Проверьте подключение и корректность bind. Отправьте сообщение с латиницей и отдельное SMS на кириллице. Проверьте короткий и составной текст. Сымитируйте временный разрыв соединения. Убедитесь, что повтор не создаёт бесконечную очередь. Сопоставьте DLR с конкретным событием оборудования. Для отладки удобно заранее подготовить журнал с полями: время события, время постановки в очередь, message_id, адрес, команда SMPP, ответ шлюза и финальный статус. Не записывайте в журнал весь поток без ограничений: сервис должен уметь фильтровать записи по объекту и периоду, иначе поиск одной ошибки станет отдельной технической задачей. Если приложение ещё не умеет работать с SMPP, разработчику понадобится клиентская библиотека или собственный транспортный модуль. При выборе шлюза уточните поддержку DLR, пропускную способность и правила подключения. Профессиональные SMPP-интеграции обычно дают прямой доступ к SMS-шлюзу, что позволяет передавать большой поток уведомлений из собственной инфраструктуры. Типичные ошибки при отправке SMS от устройств Приложение считает SMS доставленным сразу после submit_sm. Система не хранит message_id и не может связать DLR с событием. При разрыве TCP-соединения очередь отправляет одно уведомление бесконечно. Кириллица передаётся с неверным data_coding и превращается в нечитаемый текст. Датчик отправляет повторные сигналы, а приложение не объединяет одинаковые события. В одном соединении смешаны логика мониторинга и транспорт SMPP, поэтому сбой канала останавливает обработку событий. Для проекта на smpp.by разумно начинать с описания потока: какое устройство создаёт событие, кто получает SMS, какой текст уходит, сколько попыток допускается и какой статус считается успешным. Затем разработчик проверяет SMPP в тестовом режиме, подключает DLR и только после этого связывает канал с рабочим мониторингом. Такой порядок оставляет техническую отправку отдельно от логики оборудования и упрощает дальнейшее расширение системы. > Source: https://smpp.by/smpp-dlya-interneta-veschey --- # Как отправлять SMS из Беларуси за границу через SMPP Для международной отправки SMS через SMPP нужно заранее согласовать формат номера, кодировку сообщения, значения TON/NPI и обработку DLR. Один и тот же запрос может дать разные результаты на разных направлениях: сообщение примут, отклонят или доставят без понятного статуса, если приложение неверно разобрало ответ. В статье разберём рабочую схему подключения, покажем порядок проверки и перечислим ошибки, которые чаще всего мешают доставке из Беларуси на зарубежные номера. Что нужно подготовить до подключения SMPP? Сначала составьте список направлений, на которые приложение будет отправлять сообщения. Страна назначения влияет на формат номера, доступные маршруты и содержание отчёта о доставке. Для одного проекта это могут быть только белорусские номера и несколько стран, для другого — пользователи из разных регионов. Не стоит начинать с абстрактного «международного трафика»: перечислите страны и назначение сообщений для каждой из них. Затем определите тип трафика. Код подтверждения входа, уведомление о статусе заказа и сервисное сообщение требуют разной логики повторной отправки. Для OTP важны короткий срок жизни и защита от повторов, для уведомления о заказе главным становится понятный статус доставки. На стороне SMPP это отражается в параметрах сообщения, обработке ответов и правилах повторной попытки. Проверьте технические параметры подключения: адрес и порт SMPP-сервера; логин и пароль для bind; тип подключения: transmitter, receiver или transceiver; разрешённые IP-адреса, если провайдер использует сетевое ограничение; лимит одновременных соединений и скорость отправки; формат source_addr и правила для имени отправителя; период отправки enquire_link и реакцию на разрыв соединения. Если сервер доступен только через динамический IP, способ подключения нужно согласовать отдельно. В таком случае пригодится разбор настройки SMPP при динамическом IP в инструкции по подключению SMPP при динамическом IP. Для постоянного высокообъёмного трафика лучше сначала получить тестовые параметры и проверить их на небольшом числе сообщений. Как выбрать TON и NPI для международного номера? TON и NPI описывают, как SMS-центр должен трактовать адрес. TON расшифровывается как Type of Number, NPI — Numbering Plan Identification. На практике разработчик задаёт эти поля для source_addr и destination_addr, а SMPP-провайдер использует их при маршрутизации сообщения. Для международного номера обычно требуется передавать destination_addr в формате E.164: знак «плюс» убирают, остаются код страны и номер абонента. Например, приложение может передать номер как последовательность цифр с кодом страны. Однако конкретное сочетание TON и NPI зависит от интерфейса провайдера. Поэтому нельзя без проверки копировать значения из примера для одного маршрута в другой. Частая схема выглядит так: для международного назначения используют international TON и ISDN-план нумерации. В библиотеке SMPP эти значения могут называться по-разному, поэтому смотрите не только на имя константы, но и на числовое значение. Для source_addr с буквенным именем отправителя настройки часто отличаются от настроек цифрового номера. Поле Что проверяет разработчик Типичная причина ошибки destination_addr Код страны, отсутствие лишних символов, полный номер Передача локального формата вместо международного dest_addr_ton Соответствие типа номера правилам маршрута Использование national вместо international dest_addr_npi План нумерации, согласованный с провайдером Значение по умолчанию не подходит для направления source_addr Разрешённый sender ID и его длина Передача имени, которое не разрешено на маршруте Полезно записывать в журнал не только исходный номер, но и нормализованное значение, которое приложение реально отправило в submit_sm. Тогда легко увидеть, где возникла ошибка: при вводе номера, преобразовании формата или сборке PDU. Как отправлять кириллицу и другие символы? Кириллица обычно требует отдельной настройки data_coding. Нельзя передавать русскоязычный текст в кодировке, которую получатель или маршрут не ожидает. В результате абонент увидит вопросительные знаки, обрезанное сообщение или набор непонятных символов. Для UCS-2 приложение формирует текст в нужном формате и передаёт соответствующее значение data_coding. UTF-8 нельзя выбирать автоматически только потому, что его использует веб-приложение: SMPP-маршрут может ожидать другой вариант. До запуска проверьте короткое кириллическое сообщение, латиницу, цифры и символы вроде кавычек или дефиса. Кодировка влияет и на длину SMS. Если сообщение превышает вместимость одного сегмента, библиотека должна корректно собрать составное SMS, добавить UDH и сохранить порядок частей. При ошибке в UDH получатель получит несколько отдельных сообщений или текст с повреждёнными символами. Практическая схема проверки кодировок и длины разобрана в материале «Как отправлять кириллицу в SMPP: UCS-2, UTF-8 и длина SMS». Для международного трафика задайте ограничение длины на уровне шаблона. Оставляйте запас под переменные: имя, номер заказа, код или ссылку. Перед отправкой приложение может выполнить тестовую оценку количества сегментов и записать результат в лог вместе с data_coding. Как обрабатывать DLR и ошибки доставки? DLR, или delivery receipt, — отчёт, который сообщает состояние сообщения после submit_sm. Ответ о принятии запроса SMPP ещё не означает, что абонент получил SMS. Приложение должно разделять как минимум принятие сообщения системой, попытку доставки и финальный статус. Сохраните для каждого сообщения собственный идентификатор message_id, который возвращает submit_sm_resp. Затем сопоставляйте его с идентификатором из deliver_sm или другого канала отчётов. На некоторых маршрутах формат идентификатора может отличаться, поэтому в базе и обработчике лучше предусмотреть нормализацию. Событие Что означает Действие приложения submit_sm принят Провайдер получил запрос Сохранить message_id и время отправки delivered Маршрут сообщил о доставке Закрыть попытку отправки expired Истёк срок действия сообщения Не повторять автоматически без правила сценария undeliverable Доставка невозможна Зафиксировать причину и проверить номер или маршрут rejected Запрос отклонён системой или маршрутом Проверить параметры, sender ID и ограничения Статусы DLR нельзя обрабатывать одной веткой «успех или ошибка». Для OTP повтор после временной сетевой ошибки отличается от повторной отправки при недоступном номере. При разборе DLR учитывайте stat, err, message_id и текстовый комментарий, если провайдер его передаёт. Автоматическую обработку SMPP-ошибок и DLR можно сверить с практической схемой обработки ошибок SMPP и DLR. Какие ошибки чаще всего мешают международной отправке? Приложение передаёт номер в локальном формате, хотя маршрут ожидает международную запись. TON и NPI заданы одинаково для всех стран без согласования с SMPP-провайдером. Кириллица отправляется с неверным data_coding, а тест проводят только на латинском тексте. Разработчик считает submit_sm_resp подтверждением доставки абоненту. Система повторяет сообщение после любого отрицательного DLR и создаёт дубли. Лог не сохраняет message_id, поэтому статус невозможно связать с исходной попыткой. Для белорусского бизнеса, который отправляет SMS за границу, настройку лучше проверять по отдельным направлениям: номер, TON/NPI, sender ID, кодировка и DLR. Сначала протестируйте один короткий текст и один сценарий, затем добавляйте страны и объём. На этой базе проще подключить технический канал через SMPP, сохранить контроль над статусами и быстро найти ошибку в журнале. > Source: https://smpp.by/kak-otpravlyat-sms-iz-belarusi-za-granitsu-cherez-smpp --- # Как настроить приоритет SMS-кодов в SMPP Приоритет SMS в SMPP помогает отделить OTP-коды и другие срочные уведомления от массовой отправки. Для этого задают значение priority_flag, разделяют очереди и заранее решают, как система будет обрабатывать повторные попытки. В статье разберём практическую схему для малого бизнеса: какие сообщения считать срочными, когда нужен отдельный SMPP-сеанс и почему одного поля приоритета недостаточно, если все сообщения уходят через одну перегруженную очередь. Что означает priority_flag в SMPP? priority_flag передаётся в команде submit_sm. Поле показывает шлюзу относительную важность сообщения: SMS с более высоким приоритетом можно поставить перед обычными сообщениями в очереди. Так OTP-код, уведомление о входе или сообщение об успешном платеже получает шанс уйти раньше рекламной или сервисной рассылки. При этом SMPP не гарантирует одинаковое поведение у всех операторов и шлюзов. Одни платформы учитывают несколько уровней приоритета, другие используют только деление на обычные и срочные сообщения, а третьи могут вообще не менять порядок доставки. Поэтому значение priority_flag нужно проверить в документации конкретного SMPP-провайдера и подтвердить тестовой отправкой. Команда submit_sm становится доступна после запуска SMPP-сессии. Сначала приложение устанавливает соединение и выполняет bind, затем передаёт SMS через submit_sm, получает идентификатор сообщения и отслеживает статус доставки. Такой порядок описан в документации МТС для бизнеса; там же указано, что сервис работает в синхронном и асинхронном режимах. Какие SMS нужно отправлять с высоким приоритетом? Срочную очередь лучше формировать по назначению сообщения, а не по отделу, который его создал. В неё обычно попадают сообщения, без которых пользователь не может продолжить действие в системе: одноразовый код для входа или подтверждения операции; уведомление о смене пароля или подозрительной попытке входа; сообщение о результате платежа; критическое уведомление, после которого клиенту нужно сразу выполнить действие; сервисный статус, который теряет смысл через несколько минут. В обычной очереди остаются массовые уведомления, напоминания и сообщения, для которых задержка в несколько минут не меняет сценарий. Если клиент получает несколько OTP подряд, приложение должно считать действительным только последний код или явно связывать код с конкретной попыткой. Обработку отправки OTP, DLR и повторов удобно проектировать как отдельный сценарий: как отправить OTP-код через SMPP и обработать DLR. Как разделить срочные и обычные очереди? Для небольшого проекта достаточно двух очередей в приложении: urgent для OTP и транзакционных сообщений и normal для остальных SMS. Перед постановкой в очередь программа присваивает сообщению тип, срок актуальности и приоритет. Затем отдельный отправитель выбирает срочную очередь первой, но оставляет обычной очереди гарантированное время обработки. Простая логика выглядит так: Приложение создаёт сообщение и указывает его тип: OTP, транзакционное или обычное. Очередь назначает срок актуальности. Просроченный код не нужно отправлять только ради закрытия задачи. Отправитель берёт сначала срочные сообщения и передаёт их через submit_sm с повышенным priority_flag. После ответа шлюза система сохраняет идентификатор сообщения и ждёт DLR. При временной ошибке приложение делает ограниченное число повторов, а при окончательной ошибке прекращает отправку. Приоритет лучше назначать на стороне приложения, а не пытаться угадывать назначение SMS по тексту. Так система не перепутает рекламное сообщение со срочным уведомлением, даже если в тексте есть слова «код» или «подтверждение». Для ошибок SMPP и статусов доставки полезно заранее описать отдельные правила автоматической обработки: как обрабатывать ошибки SMPP и DLR. Когда нужны отдельные SMPP-соединения? Одна SMPP-сессия подходит для небольшого объёма, если приложение умеет управлять очередями. Отдельное соединение для OTP стоит рассмотреть, когда массовая отправка регулярно занимает весь доступный поток или когда провайдер позволяет закрепить разные лимиты за разными подключениями. Схема Когда подходит Что проверить Одна сессия, две очереди Небольшой и средний объём, единая точка контроля Порядок обработки, значение priority_flag, лимит запросов Две SMPP-сессии OTP должно сохранять отдельный канал при массовой отправке Лимиты каждой сессии, bind-параметры, правила маршрутизации Два независимых канала Нужна резервная отправка при недоступности основного подключения Повторы, защита от дублей, обработка DLR Отдельная сессия сама по себе не ускоряет доставку. Если оператор или шлюз ограничивает скорость на уровне аккаунта, два подключения не обойдут этот лимит. Кроме того, два канала усложняют контроль дублей: приложение должно знать, было ли сообщение принято первым маршрутом и нужно ли отправлять его повторно. В документации МТС для бизнеса приведён пример окна размером 99 и пропускной способности 10 SMS в секунду. Эти параметры нельзя переносить на любой SMPP-шлюз без проверки: размер окна, скорость и режим подтверждений задаёт конкретная платформа. Перед запуском уточните допустимое число незавершённых запросов и порядок обработки ответов. Как проверить приоритет до запуска? Тест проводят на двух потоках. В первый одновременно отправляют небольшую серию обычных сообщений, во второй помещают OTP с высоким приоритетом. В журнале фиксируют время постановки в очередь, время отправки submit_sm, ответ шлюза и DLR. Тест показывает, влияет ли приоритет на порядок постановки и насколько быстро система освобождает срочную очередь. Проверяйте не только успешную доставку. Нужны сценарии временной ошибки, недоступного номера, задержанного DLR и повторной отправки. Для каждой попытки сохраняйте уникальный внутренний идентификатор, чтобы один код не ушёл дважды из-за потерянного ответа. Кириллица тоже влияет на расчёт очереди: длина сообщения и способ кодирования меняют число SMS-сегментов. Поэтому в тест включают короткий латинский OTP, русский текст и сообщение на несколько частей. Отдельно разобрать кодировки и длину SMS можно в материале как отправлять кириллицу в SMPP. Типичные ошибки при настройке приоритетов Повышают приоритет всем сообщениям, после чего срочная очередь перестаёт выделяться. Считают, что priority_flag гарантирует мгновенную доставку при ограничении скорости у шлюза. Повторяют SMS после тайм-аута, не проверив, принял ли шлюз предыдущий submit_sm. Не задают срок действия OTP и отправляют просроченный код после длительной задержки. Не учитывают многосоставные SMS, хотя длинный текст занимает несколько единиц отправки. Разделяют очереди, но оставляют один общий блокировщик, который всё равно задерживает OTP за массовой пачкой. 3 шага, которые можно сделать на этой неделе: Разделить сообщения на OTP, транзакционные и обычные, затем назначить им разные очереди. Проверить в документации SMPP-провайдера, как он трактует priority_flag, окно запросов и лимит скорости. Провести параллельный тест с обычными SMS и OTP, записывая submit_sm, ответы шлюза и DLR. Если приоритет не даёт ожидаемого результата, причина обычно находится в очереди приложения, лимите соединения или правилах самого шлюза. Тогда схему уточняют на уровне интеграции: задают отдельные SMPP-соединения, ограничивают массовую отправку и оставляют OTP отдельный маршрут с понятной обработкой повторов. > Source: https://smpp.by/kak-nastroit-prioritet-sms-kodov-v-smpp --- # Как отправлять кириллицу в SMPP: UCS-2, UTF-8 и длина SMS Для кириллицы в SMS через SMPP обычно используют UCS-2, а не UTF-8. UTF-8 подходит для обмена данными между приложениями, но операторская SMS-платформа может не интерпретировать его как текст сообщения. В статье разберём, что передавать в поле short_message, какое значение data_coding выбрать, почему меняется лимит длины и как проверить кодировку до подключения рабочего трафика. Почему UTF-8 не подходит для обычного SMS через SMPP? UTF-8 кодирует символы переменным числом байтов. Кириллическая буква в UTF-8 занимает несколько байтов, а SMS-центр ожидает данные в формате, который указан параметром data_coding. Если приложение отправит UTF-8, но сообщит платформе, что это другая кодировка, получатель увидит набор нечитаемых символов или сообщение не пройдёт проверку. SMPP передаёт не «текст вообще», а последовательность байтов с описанием их кодировки. Поэтому мало записать русскую строку в переменную и отправить её через submit_sm. Нужно сначала выбрать кодировку на уровне приложения, затем указать соответствующее значение data_coding и проверить результат на тестовом номере. Для обмена между вашим сайтом и программой UTF-8 оставляют без изменений. Например, веб-приложение получает строку в UTF-8, после чего перед отправкой SMS преобразует её в UCS-2. Обратное преобразование выполняют при необходимости только внутри приложения, а в SMPP передают уже подготовленные байты. Когда для кириллицы используют UCS-2? UCS-2 подходит для SMS с русскими буквами, украинскими буквами, символами валюты и другими знаками, которых нет в базовом GSM-алфавите. В SMPP для UCS-2 обычно указывают data_coding 0x08. Точное имя параметра зависит от библиотеки, но смысл остаётся тем же: шлюз должен знать, что short_message содержит двухбайтовые символы. В распространённой реализации каждый символ UCS-2 занимает два байта. Поэтому одно SMS без разбиения вмещает до 70 символов. Если текст длиннее, его делят на несколько частей и добавляют заголовок конкатенации. На одну часть тогда приходится до 67 символов, поскольку несколько байтов уходят на служебный заголовок. Разбиение должно происходить до отправки submit_sm. Программа формирует отдельные части, добавляет каждой части одинаковый идентификатор сообщения, номер части и общее количество частей. Если библиотека SMPP умеет работать с concatenated SMS, эту функцию нужно включить и проверить на реальном устройстве. Чем GSM-7 отличается от UCS-2 по длине сообщения? GSM-7 использует компактный набор символов и позволяет передать до 160 символов в одном SMS. После добавления заголовка для склейки частей лимит снижается до 153 символов на часть. Кириллица в стандартный GSM-7 обычно не входит, поэтому русская строка переключает сообщение на UCS-2 и уменьшает доступную длину. Параметр GSM-7 UCS-2 Типичные тексты Латиница и символы GSM-алфавита Кириллица и расширенный набор символов data_coding Обычно 0x00 Обычно 0x08 Одна часть без склейки До 160 символов До 70 символов Одна часть при склейке До 153 символов До 67 символов Лимит рассчитывается по кодированным данным, а не по количеству знаков, которое показывает редактор. Один спецсимвол способен изменить выбранный алфавит. Поэтому перед подсчётом частей нужно определить кодировку всей строки, включая пробелы, кавычки, тире и знаки валюты. Как настроить отправку кириллицы в приложении? Сначала зафиксируйте строку в UTF-8 внутри приложения. Затем передайте её в функцию кодирования UCS-2 и получите массив байтов. В поле short_message положите именно этот массив, а в data_coding установите значение UCS-2. Не передавайте шестнадцатеричное представление как обычный текст: строка вида «041F0440...» не заменяет двоичные данные. Перед отправкой проверьте ещё несколько параметров submit_sm: длина short_message не превышает ограничение SMPP-запроса; data_coding совпадает с фактической кодировкой байтов; esm_class и параметры конкатенации соответствуют требованиям подключённого шлюза; source_addr и destination_addr передаются в формате, который принимает операторский маршрут; для длинного сообщения приложение сохраняет порядок частей и обрабатывает delivery receipt. Если библиотека сама перекодирует строку, настройку нужно проверить отдельно. Одни SDK принимают Unicode-строку и формируют UCS-2 автоматически, другие ждут уже закодированный byte array. Нельзя полагаться только на название функции вроде send_sms: откройте документацию библиотеки и посмотрите, что именно попадает в short_message. Для первичной проверки удобно использовать SMPP-песочницу: SMPP-песочница для проверки SMS, DLR и конкатенации. Там следует отправить короткую кириллическую строку, текст на границе лимита и длинное сообщение с несколькими частями, а затем сравнить фактический результат на телефоне с delivery receipt. Какие ошибки возникают при отправке кириллицы? Ниже перечислены ошибки, которые чаще всего находят при подключении высокообъёмного SMS-трафика через SMPP. UTF-8 отправляют с data_coding для GSM-7. Шлюз читает байты по другой таблице, поэтому появляются «кракозябры». В data_coding указывают UCS-2, но передают UTF-8. Само значение параметра не перекодирует содержимое short_message. Считают длину до кодирования. В строке 70 символов, но после добавления служебных данных сообщение уже требует нескольких частей. Разрезают строку посередине байтов. Часть UCS-2 должна содержать целые двухбайтовые символы. Удаляют заголовок конкатенации. Части доходят отдельно или телефон не собирает их в одно сообщение. Тестируют только короткий текст. Ошибка часто проявляется на длинном сообщении, где появляются UDH, несколько submit_sm и отдельные статусы доставки. Ошибки доставки лучше отделять от ошибок кодировки. DLR подтверждает состояние сообщения на маршруте, но сам по себе не доказывает, что телефон показал правильный текст. Поэтому проверка должна включать и статус SMPP, и просмотр сообщения на устройстве. Для автоматического разбора таких ответов пригодится материал о обработке ошибок SMPP и DLR. 3 шага, которые можно сделать перед запуском рабочего трафика: Зафиксировать правило: кириллица кодируется в UCS-2, а в submit_sm передаются байты этой кодировки с data_coding 0x08. Протестировать короткое и длинное сообщение, включая конкатенацию и delivery receipt. Проверить код отправки на границах 70 и 67 символов, чтобы приложение правильно считало части и не обрезало текст. > Source: https://smpp.by/kak-otpravlyat-kirillitsu-v-smpp --- # Как SMPP обрабатывает MNP и DLR для номеров Беларуси При переносе номера между операторами Беларуси приложение продолжает работать с тем же номером, но маршрут доставки и статус SMS нужно проверять по данным оператора связи. Для SMPP-подключения это означает три задачи: передавать номер в корректном формате, не выбирать маршрут только по коду и правильно разбирать DLR. В статье показано, как построить такую обработку, чтобы сообщения для OTP и уведомлений не зависели от старой принадлежности номера. Почему код номера не показывает текущего оператора? Первые цифры мобильного номера описывают исходный диапазон нумерации. После переноса абонент сохраняет номер, поэтому его код уже не подтверждает, через какую сеть нужно доставить SMS. Если приложение связывает код с конкретным оператором и выбирает SMPP-маршрут по этой таблице, для портированного номера оно получает устаревший результат. Практическое правило простое: код страны и формат номера используйте для нормализации, а оператора и маршрут определяйте на стороне SMS-провайдера. Внутри приложения номер лучше хранить в одном стандарте, например с международным кодом страны и без пробелов, скобок и дефисов. Для Беларуси это означает единообразную запись с кодом страны, а не смесь локального и международного формата. Не стоит удалять ведущий плюс без проверки требований конкретного SMPP-соединения. Один провайдер принимает номер в формате E.164, другой описывает собственные правила передачи TON и NPI. Эти параметры должны быть согласованы в настройках bind и проверены на тестовом номере. Как передать сообщение на портированный номер через SMPP? Приложение отправляет SMS на SMPP-соединение так же, как на обычный мобильный номер. Проверка MNP обычно скрыта внутри маршрутизации провайдера: система определяет актуальную сеть назначения и передаёт сообщение дальше. Поэтому разработчик не должен подменять операторский код или строить отдельную логику только для номеров, которые могли быть перенесены. Полезно разделить процесс на четыре этапа: Привести номер к единому формату до постановки сообщения в очередь. Присвоить SMS внутренний идентификатор и сохранить связь с бизнес-событием. Передать сообщение через SMPP, указав подходящий тип сообщения и параметры доставки. Принять submit response и позднее обработать DLR, который относится к этому сообщению. Если система отправляет OTP, номер и идентификатор попытки должны оставаться связанными между всеми повторными отправками. Иначе приложение не различит первый код, повтор после тайм-аута и сообщение, которое фактически доставили позже. Для разбора такой схемы пригодится материал как отправить OTP-код через SMPP с DLR и повторами. Какие статусы DLR нужно учитывать? DLR, или Delivery Receipt, сообщает результат обработки SMS на маршруте. Это отдельное SMPP-сообщение, которое приходит после submit response. Положительный ответ на submit означает, что SMS-протокол принял запрос, но он не подтверждает доставку на телефон. Финальный результат нужно искать в DLR. Система должна извлекать из DLR как минимум идентификатор сообщения, статус, код ошибки при его наличии и время события. Формат текстового DLR зависит от подключения, поэтому парсер нельзя строить на одной фиксированной строке. Надёжнее сначала определить набор полей, затем привести значения к внутреннему справочнику статусов. СобытиеЧто означает для приложенияДействие Принятие submit-запросаПровайдер получил сообщение и вернул идентификаторСохранить ID и не считать SMS доставленной Промежуточный статусСообщение ещё проходит маршрутОставить запись открытой и ждать финального результата ДоставкаМаршрут сообщил о доставке SMSЗакрыть попытку как успешную Ошибка доставкиСообщение не дошло или маршрут завершил попытку с ошибкойЗаписать код, решить вопрос с повтором Истёк срок ожиданияФинальный DLR не пришёл в установленное окноОтделить тайм-аут от подтверждённой недоставки Повтор нельзя запускать при любой ошибке автоматически. Для OTP это может привести к нескольким действующим кодам, а для уведомления создать дубликаты. Политику повторов задают по типу сообщения и причине сбоя. Автоматизацию обработки ошибок и DLR можно сверить с практической схемой обработки ошибок SMPP и DLR. Как проверить MNP-логику до подключения к боевой отправке? Тестирование нужно проводить на нескольких сценариях: обычный номер, номер с разными вариантами записи, недоступный телефон и номер, для которого провайдер возвращает ошибку маршрута. Если есть тестовый номер с перенесённой принадлежностью, его добавляют отдельно. Сам факт успешной отправки на один номер не доказывает, что приложение корректно разбирает все DLR. В тестовом журнале зафиксируйте исходный номер, нормализованное значение, SMPP message ID, время submit, полученный ответ и каждый DLR. Сверьте, что идентификатор из DLR находится в записи именно той попытки, которая создала сообщение. Это особенно важно при параллельной отправке: ответы могут приходить в другом порядке. До запуска полезно проверить кодировку и длину SMS. Кириллица меняет правила сегментации сообщения, а конкатенированные SMS получают дополнительные параметры, которые также нужно контролировать в SMPP. Для такой проверки подойдёт SMPP-песочница с тестами SMS, DLR и конкатенации. Как хранить результат доставки в бизнес-системе? В базе лучше разделить сущность сообщения и сущность попытки отправки. Одно уведомление может получить несколько попыток, если приложение повторило отправку после временной ошибки. У каждой попытки должны быть собственные SMPP message ID, время и финальный статус. Минимальная схема может выглядеть так: внутренний ID уведомления; номер в нормализованном формате; тип сообщения: OTP, статус заказа или другое уведомление; внутренний номер попытки; SMPP message ID; последний полученный статус DLR; код и текст ошибки, если провайдер их передал; время отправки и время последнего обновления. Такой журнал помогает отделить проблему приложения от проблемы маршрута. Если submit проходит, но DLR содержит ошибку, разработчик смотрит параметры маршрутизации и ответ провайдера. Если DLR пришёл, но система не изменила статус, проблема уже в приёме, сопоставлении или парсинге сообщения. Типичные ошибки при работе с MNP и DLR Выбор оператора по коду номера без учёта переноса. Смешивание локального и международного формата номера. Счёт submit response подтверждением доставки. Поиск сообщения только по номеру телефона вместо SMPP message ID. Повтор OTP после любого тайм-аута без ограничения числа попыток. Удаление исходного DLR после записи короткого статуса без сохранения кода ошибки. Для технической отправки SMS в Беларуси MNP лучше воспринимать как задачу маршрута провайдера, а DLR — как источник финального результата, который приложение обязано разобрать и связать с конкретной попыткой. На этой основе можно собрать устойчивое SMPP-подключение без таблицы устаревающих операторских кодов. 3 шага, которые можно сделать на этой неделе: Привести все номера в базе к одному формату и убрать выбор маршрута по коду. Сохранить SMPP message ID для каждой отправки и написать отдельный обработчик DLR. Проверить на стенде успешную доставку, ошибку, тайм-аут и конкатенацию SMS. > Source: https://smpp.by/kak-smpp-obrabatyvaet-mnp-i-dlr-dlya-nomerov-belarusi --- # Как настроить резервный SMPP-канал через 4G-модем Резервный SMPP-канал через 4G-модем помогает продолжить отправку SMS, если основной проводной интернет временно недоступен. Для этого нужен модем с SIM-картой, устройство или сервер с программой SMS-шлюза и логика переключения маршрута. В статье разберём схему подключения, проверку SMPP-сессии, контроль доставки и возврат на основной канал. Такой вариант подходит малому бизнесу, который отправляет коды, статусы заказов или служебные уведомления из собственного приложения. Как устроен SMPP-failover через 4G-модем? SMPP сам по себе не подключает компьютер к мобильной сети. Это открытый телекоммуникационный протокол одноранговой передачи коротких сообщений, по которому приложение обменивается сообщениями с SMS-центром или шлюзом. 4G-модем здесь даёт сетевой доступ либо принимает SMS через AT-команды, а отдельная программа связывает этот канал с SMPP. Для небольшого проекта встречаются две схемы. В первой приложение подключается по SMPP к внешнему провайдеру, а 4G-маршрутизатор становится резервным интернет-выходом. При обрыве проводной линии маршрутизатор переводит трафик через мобильную сеть, и SMPP-соединение устанавливается заново. Во второй схеме модем подключён непосредственно к серверу. Программа отправляет SMS через SIM-карту, а приложение обращается к локальному SMPP-шлюзу. Такой вариант требует больше настройки: нужно следить за AT-портом, состоянием SIM-карты, очередью сообщений и форматом отчётов о доставке. СхемаЧто меняется при сбоеЧто проверить заранее 4G как резервный интернетМаршрут до SMPP-провайдера переходит на мобильную сетьАвтоматическое переключение, внешний адрес или туннель, повторное подключение Модем как локальный SMS-шлюзПриложение продолжает работать через другой SMPP endpointAT-команды, очередь, DLR, кодировка и лимиты SIM-карты Перед выбором схемы проверьте, что именно считается резервом. Если при отключении проводного интернета модем только получает IP-адрес, но приложение продолжает использовать старый маршрут, SMS не уйдут. Для соединения через сеть с динамическим адресом пригодится отдельная проверка параметров SMPP при динамическом IP: подключение SMPP при динамическом IP. Как подготовить 4G-модем и сервер? Начните с отдельной SIM-карты для резервного канала. На ней должна работать передача данных, если модем используется как интернет-шлюз. Если SMS отправляет сам модем, проверьте поддержку исходящих сообщений, доступность AT-команд и возможность читать ответ устройства после каждой операции. Подключите модем к маршрутизатору или серверу, затем проверьте четыре состояния: устройство определяется операционной системой и не исчезает после переподключения; модем регистрируется в мобильной сети; появляется мобильный IP-маршрут или доступен локальный последовательный порт; тестовое SMS проходит через тот же программный путь, который будет использовать бизнес-приложение. Не смешивайте в одной проверке доступность интернета и доступность SMPP. Команда ping показывает только маршрут до узла. Она не подтверждает, что сервер принимает bind-запрос, разрешает отправку и возвращает delivery receipt. Если 4G используется как резервный интернет, задайте приоритеты маршрутов: проводной интерфейс должен быть основным, мобильный — резервным. После смены маршрута старая TCP-сессия SMPP обычно уже непригодна. Программа должна закрыть её, очистить зависшее состояние и открыть новую сессию через 4G. Если провайдер разрешает подключения только с определённого IP-адреса, мобильная сеть может потребовать отдельной настройки. В таком случае применяют VPN, постоянный туннель или другой согласованный способ доступа. Эти параметры лучше уточнить до аварийного теста, пока основной канал работает. Как настроить переподключение SMPP после сбоя? Логика failover должна реагировать не только на отключение кабеля. Сессия может остаться формально открытой, хотя сеть уже не передаёт данные. Поэтому приложение проверяет TCP-соединение, ответы на SMPP-команды и тайм-аут ожидания. Практическая последовательность выглядит так: Приложение фиксирует сетевую ошибку, тайм-аут или отсутствие ответа от SMPP-сервера. Текущая сессия закрывается, а сообщения с неясным статусом переходят в контролируемую очередь. Система проверяет основной маршрут и пробует установить SMPP-сессию через него. Если основной маршрут недоступен, активируется 4G-интерфейс или локальный модемный шлюз. Программа выполняет bind с теми параметрами, которые разрешены для резервного подключения. После успешной авторизации очередь отправляет сообщения с защитой от повторной передачи. Повторная отправка требует аккуратности. Если приложение не знает, принял ли шлюз сообщение до разрыва соединения, без идентификатора операции оно может отправить SMS дважды. Храните внутренний ID сообщения, SMPP message_id и состояние обработки. Отчёт о доставке анализируйте отдельно от факта принятия сообщения шлюзом. Для обработки ошибок и delivery receipt полезно заранее определить таблицу статусов: временный сбой, отклонённый запрос, истёкший срок, доставлено, не доставлено. Подход к автоматической обработке ошибок SMPP и DLR разобран в материале как обрабатывать ошибки SMPP и DLR. Не делайте бесконечные попытки подключения. Установите паузу между повторами и увеличивайте её при продолжительном сбое. Иначе приложение создаст лишнюю нагрузку, а журнал заполнится одинаковыми ошибками. После восстановления основного интернета верните трафик на него только после успешной проверки SMPP-сессии, а не сразу после появления сетевого интерфейса. Что проверить в SMS и DLR на резервном канале? Проверка должна проходить в тестовой среде или на ограниченном наборе номеров, которые принадлежат вашей компании. Сначала отправьте короткое сообщение, затем текст с национальными символами, после этого проверьте длинное сообщение, если система использует сегментацию. Убедитесь, что приложение правильно собирает части и не меняет кодировку при переходе на другой маршрут. Для каждого теста зафиксируйте: время постановки сообщения в очередь; идентификатор, который вернул SMPP-шлюз; статус submit_sm или эквивалентной операции; время получения DLR; финальный статус доставки; маршрут, через который ушло сообщение. Отдельно испытайте обрыв во время отправки. Отключите проводной канал после постановки сообщения в очередь и проверьте, не появилось ли две одинаковые SMS. Затем включите основной интернет и убедитесь, что система возвращается на него без ручного запуска сервиса. Перед рабочим запуском удобно использовать SMPP-песочницу: в ней можно проверить SMS, DLR и конкатенацию без риска отправить тестовое сообщение реальному клиенту. Важен сам сценарий переключения, поэтому тестируйте его теми же настройками тайм-аутов и повторов, которые будут использоваться в рабочей системе. Какие ошибки чаще всего ломают 4G-failover? Резервный маршрут включают вручную. При сбое приложение продолжает ждать старую SMPP-сессию. Переключение должно быть частью сетевой или прикладной логики. Проверяют только наличие мобильного интернета. Доступ к сети ещё не означает, что порт SMPP открыт и bind разрешён. Используют один и тот же порт модема для разных программ. Драйвер, SMS-шлюз и диагностический скрипт начинают конкурировать за AT-интерфейс. Повторяют SMS после любого тайм-аута. Сначала определите, получил ли шлюз сообщение. Иначе после обрыва появятся дубликаты. Не контролируют баланс и состояние SIM-карты. Модем может быть зарегистрирован в сети, но отправка окажется недоступной. Возвращают трафик на проводной канал сразу. Если линия ещё нестабильна, система начнёт постоянно переключаться между двумя маршрутами. Надёжность резервного канала проверяют не обещаниями, а журналом событий: какой маршрут был активен, когда оборвалась сессия, сколько сообщений попало в очередь и какой DLR пришёл после восстановления. Для малого бизнеса достаточно начать с одного контролируемого сценария, затем добавить тест отключения и автоматический возврат на основной канал. 3 шага, которые можно сделать на этой неделе: Описать текущую SMPP-схему и выбрать роль 4G-модема: резервный интернет или локальный SMS-шлюз. Настроить очередь, повторное подключение и сохранение ID сообщений до получения финального статуса. Провести тест с отключением проводного интернета, проверить дубликаты, DLR и возврат на основной маршрут. > Source: https://smpp.by/kak-nastroit-rezervnyy-smpp-kanal-cherez-4g-modem --- # Как подключить SMPP при динамическом IP Динамический IP не мешает подключить SMPP к SMS-шлюзу, если вынести доступ из схемы «шлюз разрешает один адрес» и заранее продумать маршрут. Для офиса или домашнего интернета в Беларуси обычно используют VPN с постоянной точкой входа, исходящий туннель либо промежуточный сервер. В статье разберём, как выбрать схему, настроить IP-фильтры, проверить DLR и подготовить резервный канал без привязки к конкретному провайдеру. Почему динамический IP мешает прямому SMPP-подключению? SMPP-сессия работает поверх TCP. При подключении к SMS-шлюзу система обычно проверяет логин, пароль и сетевой адрес клиента. Если провайдер разрешил доступ только с одного IP, после смены адреса домашнего или офисного роутера соединение перестанет проходить, даже когда остальные параметры указаны верно. Проблема проявляется по-разному. TCP-соединение не устанавливается вовсе, сервер закрывает его сразу после попытки авторизации или приложение бесконечно повторяет подключение. В последнем случае журнал быстро заполняется одинаковыми ошибками, а причина остаётся неясной. Сначала нужно определить, что именно фильтрует SMS-шлюз. Если он принимает подключения по логину и паролю с любого разрешённого маршрута, достаточно стабильного VPN-выхода. Если используется строгий IP allowlist, в список добавляют адрес VPN-сервера или другого постоянного узла, через который будет идти SMPP-трафик. Как выбрать схему подключения через VPN? Для небольшого бизнеса подходят три базовые схемы. Выбор зависит от того, где работает SMPP-клиент: на сервере, в офисной сети или на рабочем компьютере. Схема Как проходит трафик Когда использовать Что проверить VPN-клиент в офисе Программа подключается к VPN, а роутер направляет SMPP через туннель Приложение работает внутри офиса Маршруты, DNS, правила firewall и переподключение VPN Исходящий туннель с сервера Сервер в офисе сам устанавливает соединение с узлом с постоянным адресом Входящие подключения к офису закрыты или адрес часто меняется Автозапуск туннеля, контроль процесса и доступ к порту SMPP Промежуточный сервер SMPP-клиент подключается к постоянному узлу, который передаёт трафик в офис Нужно скрыть динамический адрес и централизовать доступ Задержку, журналирование, отказоустойчивость и правила доступа В первой схеме внешний SMS-шлюз видит адрес VPN-выхода, а не текущий адрес офиса. Это упрощает IP-фильтрацию. Для исходящего туннеля важнее другое: офисная сторона должна сама восстановить канал после разрыва интернета или перезагрузки роутера. Не стоит открывать SMPP-порт в интернет только ради обхода динамического IP. Открытый порт увеличивает число попыток подключения к сервису и усложняет контроль. Безопаснее разрешить доступ по VPN и ограничить его конкретным адресом или подсетью. Для дополнительной защиты передачи можно рассмотреть TLS для SMPP: как настроить TLS для SMPP и защитить SMS-трафик. Как настроить IP-фильтры и маршрутизацию? Настройку удобнее разделить на два уровня. На уровне VPN определяется, какой адрес получит офисный клиент. На уровне SMS-шлюза в allowlist добавляется именно этот внешний адрес. Текущий адрес домашнего роутера туда вносить бессмысленно: после следующего переподключения он может измениться. Зафиксируйте адрес VPN-выхода или другого узла, который видит SMS-шлюз. Разрешите на шлюзе только нужный TCP-порт и выбранный адрес. Укажите в SMPP-клиенте адрес шлюза, порт, system_id и пароль. Проверьте, что маршрут к SMS-шлюзу идёт через VPN, а обычный интернет не изменился без необходимости. Сохраните логи подключения, команды bind и ответы сервера. Для офиса с несколькими компьютерами лучше направлять через VPN только сервер или машину, которая отправляет SMS. Полный прогон всей сети через туннель создаёт лишнюю зависимость от VPN: при его сбое одновременно перестанут открываться рабочие сайты, обновляться программы и отправляться сообщения. Если приложение поддерживает bind_transceiver, используйте режим, в котором оно может отправлять сообщения и получать события доставки. Раздельные соединения для отправки и приёма тоже допустимы, но тогда каждому соединению нужны собственные настройки восстановления. В документации SMPP-шлюза заранее уточните допустимый режим bind, окно неподтверждённых сообщений и правила heartbeat. Для проверки самого протокола удобно сначала отправить тестовое сообщение в песочнице, где можно увидеть SMS, DLR и работу конкатенации: SMPP-песочница для проверки SMS и DLR. Это помогает отделить сетевую ошибку от неверного PDU или параметров сообщения. Как проверить DLR после смены IP или VPN? Установленная SMPP-сессия ещё не доказывает, что цепочка работает полностью. Клиент может успешно выполнить bind, но не принимать deliver_sm с отчётом о доставке. Поэтому тест нужно проводить в несколько этапов: соединение, отправка, приём DLR и повторное подключение после разрыва. Проверьте TCP-доступ до SMS-шлюза через VPN. Выполните bind и убедитесь, что сервер не закрывает сессию после авторизации. Отправьте тестовое SMS и запишите message_id из ответа submit_sm_resp. Дождитесь DLR и сопоставьте его с исходным message_id. Разорвите VPN или перезапустите роутер, затем убедитесь, что клиент восстановил bind. DLR нельзя считать обычным текстовым уведомлением. Приложение должно разобрать его поля, определить статус и сохранить связь с исходным сообщением. Если DLR пришёл после переподключения, обработчик должен принять его в новой сессии и не создать дубль отправки. Практический подход к разбору ошибок и статусов описан в материале об автоматической обработке ошибок SMPP и DLR. Проверьте также кодировку, короткий номер или sender, TON/NPI и время ожидания ответа. Эти параметры не исправляют проблему динамического IP, но часто маскируются под сетевую ошибку, когда клиент показывает только общий текст «ошибка отправки». Как подготовить резервный интернет-канал? Для SMS-сервиса резервирование имеет смысл только тогда, когда новый маршрут сохраняет доступ к VPN и SMS-шлюзу. Простое переключение роутера на другой канал не поможет, если резервный адрес не разрешён в IP-фильтре или туннель не запускается автоматически. Определите основной и резервный каналы заранее. Для каждого проверьте выдаваемый внешний адрес, доступность VPN, маршрут к SMPP-порту и восстановление сессии. Если резервный канал использует другой адрес, его добавляют в разрешённый список до аварийной ситуации. На уровне приложения задайте ограниченное число повторных попыток с увеличивающимся интервалом. Бесконечные мгновенные повторы создают нагрузку и затрудняют диагностику. После восстановления связи клиент должен проверить состояние bind и только потом продолжить очередь сообщений. Типичные ошибки при SMPP через динамический IP В allowlist добавляют домашний или офисный IP, хотя шлюз видит адрес VPN. VPN запускается вручную и не восстанавливается после перезагрузки компьютера. Через туннель отправляют весь офисный трафик, хотя SMPP работает на одном сервере. Открывают SMPP-порт для всего интернета вместо ограничения по VPN-адресу. Проверяют только bind и не тестируют submit_sm, DLR и повторное подключение. После смены маршрута приложение повторно отправляет сообщение, не проверив его исходный статус. Перед запуском в рабочем режиме полезно составить короткую схему: где работает SMPP-клиент, какой адрес видит SMS-шлюз, через какой VPN идёт трафик и что произойдёт при его отключении. Затем разрешите два маршрута, проверьте DLR и зафиксируйте логи. Для микро- и малого бизнеса этого набора достаточно, чтобы динамический IP не стал причиной остановки SMS-уведомлений. > Source: https://smpp.by/kak-podklyuchit-smpp-pri-dinamicheskom-ip --- # Как автоматически обрабатывать ошибки SMPP и DLR Ошибки SMPP показывают, на каком этапе остановилась отправка SMS: шлюз отклонил запрос, сеть временно ограничила скорость или абонент не получил сообщение. В статье разберём коды ESME_RTHROTTLED, ESME_RINVSRCADR и другие ответы, свяжем их с DLR и разделим ошибки на временные и окончательные. После этого разработчик сможет настроить повторы, журналирование и уведомления так, чтобы система не отправляла один и тот же SMS бесконечно. Что именно сообщает SMPP-ответ? При передаче submit_sm приложение получает от SMPP-шлюза командный статус. Он отвечает на вопрос, принял ли шлюз запрос в обработку. Успешный ответ ещё не означает, что SMS дошло до телефона: окончательный результат обычно приходит позже в delivery receipt, или DLR. Удобно разделять два события. SMPP-ответ описывает приём команды шлюзом, а DLR сообщает результат дальнейшей доставки. Если приложение проверяет только submit_sm, оно видит лишь начало цепочки и может ошибочно считать сообщение доставленным. ЭтапЧто проверятьКакой вывод сделать Подключениеbind_resp и состояние сессииМожно ли передавать команды через текущую SMPP-сессию Приём сообщенияcommand_status в submit_sm_respПринял ли шлюз запрос и выдал ли message_id ДоставкаDLR и его delivery statusДошло ли SMS до абонента или оператор вернул отказ Контроль каналаenquire_link, тайм-ауты, disconnectЖива ли сессия и можно ли продолжать отправку При разборе DLR полезно сохранять исходный текст receipt, message_id, время отправки и внутренний идентификатор операции. Без этой связи трудно понять, какой именно запрос завершился ошибкой, особенно когда система отправляет большой поток SMS. Почему возникает ESME_RTHROTTLED? ESME_RTHROTTLED означает, что шлюз ограничил скорость запросов. Приложение передаёт команды быстрее, чем разрешает текущая настройка соединения или маршрута. Повторить такой запрос сразу в том же темпе значит получить следующий отказ. Обработчик должен поставить сообщение в очередь и повторить попытку после паузы. Размер паузы лучше вынести в настройки, чтобы менять его без новой сборки приложения. При повторных отказах интервал увеличивают, а число попыток ограничивают. Получить ответ ESME_RTHROTTLED. Вернуть сообщение в очередь с новым временем попытки. Увеличить задержку по выбранной схеме. После установленного числа неудач передать событие в журнал или мониторинг. Один worker не должен бесконтрольно создавать новые потоки при ограничении скорости. Надёжнее использовать общий планировщик очереди: он видит число активных запросов и равномерно распределяет отправку между доступными SMPP-сессиями. Параметры TON и NPI тоже влияют на принятие сообщения. Если проблема связана с адресацией отправителя или получателя в белорусском направлении, проверьте настройку TON/NPI в SMPP для SMS в Беларуси, а не увеличивайте количество повторов. Как исправить ESME_RINVSRCADR? ESME_RINVSRCADR сообщает, что адрес источника некорректен или не разрешён для этого подключения. Причина часто связана с полем source_addr: приложение передало значение в неподходящем формате, использовало неверный TON/NPI или выбрало отправителя, которого шлюз не принимает. Такой отказ обычно относится к окончательным для конкретного запроса. Повтор с теми же параметрами результата не изменит. Сначала нужно исправить данные отправителя, проверить разрешённый формат и только потом создать новую попытку. В конфигурации полезно хранить отправителя отдельно от текста SMS. Перед отправкой приложение проверяет, что значение заполнено, соответствует выбранному типу адреса и доступно этому SMPP-аккаунту. Ошибка должна попадать в журнал вместе с source_addr, TON, NPI и идентификатором маршрута. СитуацияДействие приложенияНужен повтор? ESME_RTHROTTLEDПауза, возврат в очередь, ограничение скоростиДа, с задержкой ESME_RINVSRCADRОстановить запрос, проверить source_addr и TON/NPIНет, пока параметры не исправлены Недействительная сессияЗакрыть соединение и выполнить повторный bindДа, после восстановления канала Отказ доставки в DLRСохранить финальный статус и причинуТолько по отдельному правилу для временных причин Как строить обработчик SMPP-ошибок? Система обработки должна работать по таблице правил, а не по набору разрозненных условий в коде. Для каждого статуса задайте тип ошибки, допустимость повтора, максимальное число попыток и действие после окончательного отказа. Минимальная запись в очереди может содержать message_id, номер получателя, текст или его ссылку, время следующей попытки, число повторов и последний код ошибки. Текст SMS не стоит менять при каждом повторе: иначе DLR и внутренний журнал будет сложнее сопоставить. Для временных ошибок используйте отложенную очередь. Для окончательных отказов сразу фиксируйте результат и не возвращайте сообщение в обычный поток. Отдельный статус «требует проверки» пригодится для неизвестных кодов: приложение не потеряет событие и не начнёт бесконечный цикл. При большом объёме трафика проверьте обработчик в тестовой среде. SMPP-песочница для проверки SMS, DLR и конкатенации помогает отделить ошибку бизнес-логики от особенностей реального маршрута. Для OTP отдельно проверьте повторы и связь результата с кодом подтверждения: полезен материал о передаче OTP-кода через SMPP с DLR и повторами. Какие данные записывать в журнал? время отправки и время получения ответа; тип SMPP-команды и command_status; message_id, если шлюз его вернул; source_addr, TON и NPI; номер получателя в нормализованном формате; текст или безопасный идентификатор шаблона; DLR и финальный статус доставки; номер попытки и причина следующего повтора. Логи должны позволять найти одну операцию по message_id и внутреннему идентификатору заказа. Если в журнале есть только общий текст «SMS не отправлено», разработчик не отличит ограничение скорости от неверного адреса отправителя. Какие ошибки чаще всего ломают автоматическую отправку? Приложение считает успешный submit_sm_resp доказательством доставки. ESME_RTHROTTLED повторяется без паузы и перегружает очередь. ESME_RINVSRCADR отправляется повторно с тем же source_addr. Программа теряет message_id и не может связать DLR с исходным SMS. Неизвестный код автоматически трактуется как временный, поэтому очередь растёт бесконечно. После разрыва соединения приложение повторяет запрос, не проверив состояние сессии и риск дубликата. Перед запуском проверьте несколько сценариев: успешную передачу, отказ из-за ограничения скорости, неверный адрес источника, разрыв SMPP-сессии и финальный отрицательный DLR. Для каждого сценария заранее задайте ожидаемый статус, число повторов и запись в журнале. Если трафик уже проходит через SMPP, настройку такого обработчика можно вынести в отдельный технический проект и проверить на тестовом подключении. 3 шага, которые можно сделать на этой неделе: Составьте таблицу кодов с колонками «временная ошибка», «повтор», «максимум попыток» и «действие после отказа». Свяжите submit_sm_resp, message_id и DLR в одном журнале операций. Прогоните тесты для ESME_RTHROTTLED и ESME_RINVSRCADR, чтобы система ставила паузу в первом случае и исправляла параметры во втором. > Source: https://smpp.by/kak-avtomaticheski-obrabatyvat-oshibki-smpp-i-dlr --- # SMPP-песочница: как проверить SMS, DLR и конкатенацию SMPP-песочница позволяет проверить подключение клиента, отправку SMS, получение DLR и сборку длинных сообщений до выхода в реальный трафик. В статье разберём, какие тесты подготовить, как читать ответы сервера, где проверять конкатенацию и какие ошибки отделять от проблем номера получателя. Такой сценарий подходит разработчику малого бизнеса, который подключает алерты, уведомления о заказах или одноразовые коды через SMPP 3.4. Зачем проверять SMPP-подключение в отдельной среде? При прямом запуске в рабочем контуре одна ошибка затрагивает реальные номера и усложняет поиск причины. Песочница даёт отдельный маршрут: клиент устанавливает сессию, отправляет тестовое сообщение, получает ответ сервера и проверяет обработку статуса доставки. SMPP работает через команды протокола. Клиент открывает соединение, выполняет bind, передаёт сообщение командой submit_sm, а сервер возвращает ответ с идентификатором сообщения. Статус доставки приходит отдельным событием deliver_sm, если маршрут передаёт DLR. Поэтому тест нужно строить вокруг всей цепочки, а не только вокруг факта подключения. Перед началом зафиксируйте параметры тестовой среды: адрес и порт, логин, пароль, тип bind, TON/NPI, кодировку, формат идентификатора сообщения и правила DLR. Если один параметр отличается от рабочего подключения, результат нельзя переносить на production. Для SMS в Беларуси отдельно проверьте настройки TON/NPI: разбор этих полей вынесен в материал о настройке TON/NPI в SMPP для SMS в Беларуси. Какой сценарий отправки SMS проверить первым? Начните с короткого сообщения в однократной сессии. Клиент должен последовательно выполнить такие действия: Открыть TCP-соединение с тестовым SMPP-сервером. Отправить bind_transceiver и дождаться положительного ответа. Передать короткий текст через submit_sm. Сохранить message_id, который вернул сервер. Ожидать DLR и сопоставить его с сохранённым идентификатором. Корректно закрыть сессию через unbind. В журнале должны остаться время подключения, результат bind, команда отправки, код ответа, идентификатор сообщения и содержание DLR. Текст SMS лучше сделать узнаваемым, например «SMPP TEST 001», чтобы его не перепутать с рабочим уведомлением. Номер получателя используйте только тот, который разрешён условиями песочницы. На этом этапе проверяют транспорт и базовый обмен. Если сервер принял submit_sm, это ещё не означает доставку: сервер мог принять запрос на обработку, а итоговый статус придёт позже. Клиенту нужно хранить связь между внутренним идентификатором события и SMPP message_id. Как проверить DLR и правильно прочитать его статус? DLR, или delivery receipt, сообщает результат обработки сообщения. В нём могут присутствовать идентификатор исходной SMS, статус, код ошибки и текстовое описание. Формат зависит от шлюза, поэтому обработчик нельзя жёстко привязывать к одной строке: сначала выделяйте поля, затем нормализуйте статус во внутренний справочник. Что проверяетсяЧто записать в журналКакой результат нужен Приём DLRВремя события и тип PDUКлиент принимает deliver_sm и отвечает серверу Связь с исходной SMSПолученный и внутренний идентификаторыDLR относится к правильной отправке Статус доставкиИсходный статус и нормализованное значениеСтатус сохраняется без потери деталей Ошибка маршрутаКод ошибки и описаниеОшибка доступна для повторной обработки или отчёта Обработчик входящего DLR должен вернуть подтверждение получения. Если клиент принимает событие, но не отвечает на него, сервер может повторять доставку одного и того же отчёта. Это создаёт дубликаты в журнале и мешает считать фактические результаты. Для проверки подготовьте отдельные тесты на успешную доставку, временную ошибку и невозможность доставки. В песочнице эти события обычно вызываются тестовыми номерами или специальными командами. Если такой режим не предусмотрен, попросите у поставщика описание тестовых статусов и формата DLR, а не подменяйте их догадками. Когда SMS используется для кода входа, логика повторов особенно чувствительна к статусу. Практическая схема разбора OTP, DLR и повторных отправок описана в материале как отправить OTP-код через SMPP: DLR и повторы. Как протестировать конкатенацию длинного сообщения? Длинная SMS передаётся несколькими частями. Чтобы телефон собрал их в одно сообщение, клиент добавляет служебные параметры конкатенации, обычно через User Data Header. В тесте нужно проверить не только число отправленных частей, но и их порядок, общий идентификатор и корректность кодировки. Создайте текст, который превышает лимит одной части в выбранной кодировке. Передайте его через тот же путь, который будет использовать рабочее приложение. Проверьте, сколько частей сформировал клиент. Убедитесь, что каждая часть получила ответ на submit_sm. Сопоставьте DLR отдельных частей с исходным сообщением. Проверьте сборку на тестовом устройстве или в предусмотренном эмуляторе. Кодировка влияет на размер части. Символы кириллицы и специальные знаки могут изменить способ кодирования, поэтому тестовая строка должна содержать реальные символы будущего уведомления. Для белорусского бизнеса это особенно заметно в сообщениях на русском и белорусском языках: строка, которая выглядит короткой, после кодирования может занять несколько частей. В рабочем журнале храните общий идентификатор логического сообщения и идентификаторы его частей. Тогда ошибка одной части не потеряется среди успешных ответов остальных. Для алерта о сбое сервера это также помогает понять, дошло ли уведомление целиком. Какие типичные ошибки возникают в SMPP-песочнице? Клиент считает принятие submit_sm доставкой. Ответ на команду показывает приём запроса сервером, а итог нужно брать из DLR. DLR не связывается с отправкой. Причина часто в разном формате идентификатора: ведущие нули, регистр букв или дополнительные символы нужно нормализовать. Клиент не подтверждает deliver_sm. Входящий PDU следует обработать и подтвердить, иначе сервер может повторить событие. Длинный текст приходит с повреждёнными символами. Проверьте data_coding, кодировку строки и параметры UDH на каждой части. Повтор запускается для неверного номера. Постоянную ошибку адреса нельзя обрабатывать так же, как временный сбой маршрута. Тестовый конфиг отличается от рабочего. Сравните bind, TON/NPI, формат DLR и правила поддержания сессии перед переносом настроек. Для рабочего подключения полезно разделить тесты на три уровня: соединение и bind, передача SMS, обработка DLR и конкатенации. Такой набор можно запускать после изменения библиотеки, конфигурации или SMPP-шлюза. Описание интеграции по SMPP 3.4 также включает обмен сообщениями и поддержание сессии (SevenTech docs). 3 шага для проверки на этой неделе: Подключите клиента к песочнице и сохраните полный журнал bind, submit_sm и deliver_sm. Проверьте короткую SMS, успешный и ошибочный DLR, затем сопоставьте каждый статус с message_id. Отправьте длинное сообщение с кириллицей и убедитесь, что части собираются в исходный текст без дубликатов. > Source: https://smpp.by/smpp-pesochnitsa --- # Как отправить OTP-код через SMPP: DLR и повторы OTP-код через SMPP отправляют так: приложение создаёт одноразовый код, передаёт его в SMS-шлюз по постоянному SMPP-соединению, а шлюз возвращает отчёт о доставке через DLR. В статье разберём схему интеграции, обязательные параметры SubmitSM, обработку статусов, повторные попытки и защиту соединения. После чтения разработчик сможет составить минимальный сценарий для регистрации, входа или подтверждения операции в сервисе малого бизнеса. Как выглядит отправка OTP через SMPP? В типовой схеме участвуют четыре компонента: приложение, OTP-сервис, SMPP-шлюз и мобильная сеть. Пользователь вводит номер телефона, приложение создаёт код и передаёт сообщение OTP-сервису. Тот формирует SMPP-запрос SubmitSM и отправляет его через установленное соединение. Шлюз возвращает приложению message_id. Это значение нужно сохранить вместе с внутренним идентификатором операции: по нему позже связывают ответ шлюза с конкретной попыткой отправки. Отдельно приходит DLR, то есть Delivery Receipt. Он показывает, доставлено сообщение, отклонено, просрочено или ещё находится в обработке. Для малого бизнеса удобнее начинать с одной простой операции: приложение создаёт код, отправляет его через отдельный сервисный модуль, а модуль возвращает результат постановки сообщения в очередь. Проверка кода должна происходить в приложении, потому что SMPP-шлюз отвечает за передачу SMS, а не за бизнес-логику авторизации. Если соединение разрывается, модуль не должен автоматически считать OTP недоставленным. Сначала проверьте, был ли получен ответ на SubmitSM и сохранился ли идентификатор сообщения. Для наблюдения за реальной доставкой пригодится отдельный материал о мониторинге SMPP через DLR. Какие параметры SubmitSM нужны для OTP? Минимальный запрос содержит адресата, текст сообщения и параметры адресации. На практике разработчик также задаёт тип адреса отправителя, кодировку, срок действия и флаг запроса DLR. Точные значения зависят от настроек шлюза, поэтому их фиксируют в технической спецификации до начала тестов. Параметр Зачем нужен Что проверить source_addr Имя или номер отправителя Разрешён ли такой Sender ID для маршрута destination_addr Номер получателя Формат номера и отсутствие лишних символов short_message Текст с одноразовым кодом Кодировка и длина сообщения data_coding Указывает кодировку текста Совпадает ли значение с фактическим текстом registered_delivery Запрашивает отчёт о доставке Возвращает ли шлюз DLR и в каком формате validity_period Ограничивает время жизни SMS Не остаётся ли устаревший код в очереди service_type Передаёт назначение сообщения, если это поддерживает шлюз Соответствует ли значение договорённой схеме Отдельно проверьте TON и NPI. Эти поля определяют тип и план нумерации адреса. Ошибка в них иногда выглядит как проблема маршрута: соединение установлено, SubmitSM принят, но сообщение не уходит дальше. Для белорусских номеров полезно заранее проверить параметры в руководстве по настройке TON/NPI в SMPP. Текст OTP лучше сделать коротким: название сервиса, код и краткое ограничение по использованию. Не добавляйте в одно сообщение несколько действий. Например, приложение может сформировать строку вида: «Код для входа: 481927». Сам код должен быть связан с конкретной попыткой и иметь ограниченный срок действия. Как обрабатывать ответ шлюза и DLR? Ответ на SubmitSM подтверждает приём запроса шлюзом. Он не равен подтверждению доставки на телефон. Поэтому в базе или журнале интеграции нужны как минимум два события: результат постановки SMS в шлюз и итоговый статус из DLR. Событие Что оно означает Действие приложения SubmitSM accepted Шлюз принял запрос и вернул идентификатор Сохранить message_id и ждать DLR Delivery success Шлюз получил подтверждение доставки Закрыть попытку как доставленную Temporary failure Временная ошибка маршрута или сети Запланировать повтор по правилам Permanent failure Шлюз отклонил сообщение окончательно Остановить повторы и показать понятную ошибку Expired SMS не доставили до окончания срока жизни Не отправлять устаревший код без нового запроса Формат DLR различается у шлюзов. Один провайдер передаёт отдельные поля, другой возвращает строку с кодом статуса, идентификатором и текстовым описанием. Поэтому обработчик должен сначала разобрать формат конкретного шлюза, затем привести статусы к единому внутреннему набору: delivered, temporary_failure, permanent_failure, expired и unknown. Статус unknown нельзя автоматически считать успешным. Его лучше отправить в журнал для проверки. Если DLR пришёл с другим написанием идентификатора, система не найдёт сообщение и начнёт повторять отправку без необходимости. На тестовом стенде проверьте регистр символов, длину message_id и наличие дополнительных пробелов. Для контроля соединения используйте Enquire Link. Этот служебный обмен помогает понять, отвечает ли SMPP-сессия, пока в очереди нет сообщений. Практическая настройка описана в материале про Enquire Link на SMPP-шлюзе. Как настроить повторные попытки без дублирования? Повтор нужен только при временной ошибке. Если шлюз вернул окончательный отказ или срок действия сообщения истёк, повтор того же OTP ухудшит сценарий: пользователь может получить несколько кодов и не понять, какой из них вводить. Каждая попытка должна иметь свой внутренний идентификатор, время создания и причину повтора. При повторной отправке приложение обычно создаёт новую запись попытки, но связывает её с одной OTP-сессией. Так в журнале видно, сколько раз система обращалась к шлюзу и чем закончилась каждая попытка. Получите ответ SubmitSM и сохраните message_id. Дождитесь DLR в течение заданного приложением срока. Если статус временный, поставьте повтор в очередь с паузой. Перед повтором проверьте, не подтвердил ли шлюз доставку по первой попытке. После лимита повторов завершите OTP-сессию и предложите пользователю запросить новый код. Пауза между попытками нужна для того, чтобы не отправлять одинаковые SMS подряд при кратковременном сбое. Её длительность задают в конфигурации, а не зашивают в код. Лимит также должен быть отдельным параметром. Это упрощает настройку для разных маршрутов и позволяет быстро остановить повторы при неполадках. Если приложение не получило ответ на SubmitSM, ситуация неоднозначна: запрос мог не дойти до шлюза или шлюз мог принять его, но ответ потерялся. В таком случае повторная отправка создаёт риск двух одинаковых SMS. Для решения используют корреляцию запросов, журнал соединения и правила провайдера для повторной передачи. Без этих данных безопаснее завершить попытку технической ошибкой и попросить пользователя запросить новый код. Как защитить SMPP-соединение и проверить интеграцию? Учётные данные SMPP не стоит хранить в исходном коде. Их выносят в настройки окружения или защищённое хранилище конфигурации. Доступ к шлюзу ограничивают адресами сервера приложения, а журнал не должен содержать полный OTP-код. Для соединения с внешним шлюзом настройте TLS, если его поддерживает согласованная конфигурация. Проверьте сертификат, имя узла и реакцию приложения на разрыв защищённой сессии. Отдельная инструкция по этой части собрана в материале о настройке TLS для SMPP. Тестирование проводите по сценариям, а не одной успешной отправкой. Нужны минимум: успешная доставка, недоступный шлюз, временный отказ, окончательный отказ, истечение срока SMS, задержанный DLR и разрыв TCP-соединения. Для каждого сценария зафиксируйте ожидаемый статус, действие очереди и сообщение, которое увидит пользователь. Какие ошибки чаще всего ломают OTP? Приложение считает ответ SubmitSM подтверждением доставки и не ждёт DLR. Обработчик не умеет сопоставлять DLR с message_id. Повтор запускается после любого сбоя, включая окончательный отказ. Для текста на кириллице выбрана неподходящая кодировка. Срок жизни SMS больше срока действия OTP, поэтому старый код приходит поздно. При переподключении система создаёт несколько SMPP-сессий и дублирует отправку. Начните с небольшой тестовой очереди и подробного журнала событий. Когда SubmitSM, DLR, переподключение и повторы проходят проверку, вынесите параметры шлюза в конфигурацию и добавьте мониторинг задержек. Для бизнеса в Беларуси такой подход позволяет подключить техническую отправку OTP через SMPP без лишней логики внутри самого шлюза: приложение отвечает за код, SMPP — за передачу, DLR — за контроль результата. > Source: https://smpp.by/kak-otpravit-otp-kod-cherez-smpp --- # Миграция с HTTP API на SMPP без потери SMS Переход с HTTP API на SMPP нужен, когда SMS-трафик вырос, а приложению стало важно управлять соединением, скоростью отправки и статусами доставки. В статье разобран пошаговый план миграции для малого бизнеса: как сравнить текущую интеграцию, подготовить SMPP-подключение, провести тесты, перенести отправку и проверить DLR-отчёты. Такой порядок помогает сохранить контроль над очередью сообщений и не переключать рабочую систему вслепую. Когда бизнесу пора переходить с HTTP API на SMPP? HTTP API удобно подключить к сайту, интернет-магазину или внутренней программе: приложение отправляет HTTP-запрос, получает ответ и продолжает работу. Для умеренного потока этого обычно достаточно. Сложности появляются, когда отправка становится постоянной частью операционного процесса, а системе приходится учитывать очереди, ограничения скорости и повторные попытки. О переходе на SMPP говорят несколько технических признаков: приложение регулярно отправляет большой поток SMS и упирается в лимиты HTTP-запросов; очередь сообщений живёт отдельно от отправляющего кода, из-за чего сложно понять, что уже принято шлюзом; бизнесу нужны детальные статусы доставки, а не только ответ API о принятии запроса; система должна поддерживать постоянное соединение с SMS-шлюзом; разработчику нужно управлять скоростью отправки и реакцией на ответы шлюза. SMPP не решает проблему автоматически. Он переносит больше ответственности в вашу систему: нужно поддерживать соединение, обрабатывать ответы на команды, отслеживать тайм-ауты и корректно закрывать зависшие сессии. Поэтому решение принимают по нагрузке и требованиям к контролю, а не по самому названию протокола. Чем SMPP отличается от HTTP API при большом потоке SMS? HTTP API работает по модели «запрос — ответ». SMPP использует команды протокола и постоянную сессию между приложением и SMS-шлюзом. В распространённой реализации применяют SMPP версии 3.4. Каждая команда получает подтверждение с command_status, а результат доставки приходит отдельным отчётом DLR через deliver_sm PDU. Критерий HTTP API SMPP Подключение HTTP-запросы к API Постоянная SMPP-сессия Управление потоком Зависит от логики API и очереди приложения Настраивается через параметры соединения и обработку ответов шлюза Статус сообщения Обычно приложение получает ответ о принятии запроса Можно принимать подтверждения команд и DLR о состоянии доставки Сложность разработки Ниже на старте Выше: нужны bind, heartbeat, очередь и обработчики ошибок Подходящий сценарий Небольшой или эпизодический поток Постоянная отправка и собственный контроль очереди Для DLR провайдер может передавать идентификатор сообщения, даты отправки и завершения, число доставленных сообщений, итоговый статус и код ошибки. Формат нужно согласовать с конкретным шлюзом, потому что названия полей и набор статусов могут отличаться. В документации Infobip, например, DLR описывается через поля id, sub, dlvrd, submit date, done date, stat и err (Infobip Docs). Если в системе уже есть отдельная логика статусов, заранее определите соответствие между HTTP-ответами и SMPP-событиями. Для этого полезно изучить практику выгрузки статусов SMPP в 1С и отдельно решить, какие статусы считать промежуточными, а какие финальными. Как подготовить миграцию до изменения рабочего кода? Сначала опишите текущий путь сообщения: где приложение создаёт SMS, где формируется очередь, где хранится идентификатор и что происходит после ответа API. Не начинайте с замены библиотеки. Сначала составьте таблицу соответствий: поле HTTP-запроса, поле SMPP-команды, значение в вашей базе и обработчик ошибки. У провайдера SMPP запросите параметры подключения. Обычно для теста нужны сервер, порт, логин, пароль, режим transceiver, TON/NPI и лимиты отправки. Эти значения нельзя подбирать случайно: TON и NPI влияют на интерпретацию адресов, а лимит определяет допустимую скорость submit_sm. Практическую последовательность получения доступа, тестовой отправки и проверки DLR описывает инструкция как определить нужный SMPP-throughput. В приложении подготовьте отдельный SMPP-адаптер. Бизнес-логика должна передавать ему номер, текст, имя отправителя и внутренний идентификатор, но не зависеть от конкретного протокола. Тогда HTTP API и SMPP можно временно держать параллельно, направляя тестовую группу сообщений через новый канал. Очередь лучше разделить на несколько состояний: «создано», «передано в SMPP», «принято шлюзом», «доставляется», «доставлено» и «ошибка». Идентификатор сообщения из submit_sm сохраняйте рядом с внутренним ID. Без этой связи DLR придёт, но система не поймёт, к какой операции его отнести. Как провести технический тест SMPP-подключения? Тест начинайте с установки TCP-соединения и команды bind_transceiver. После подтверждения проверьте, что приложение принимает ответы шлюза и поддерживает сессию. Затем отправьте короткое тестовое SMS на разрешённый номер, получите message_id и дождитесь DLR. Во время проверки записывайте в журнал время команды, sequence_number, command_status и текст ошибки. Проверьте доступность сервера и порта с тестового окружения. Установите bind_transceiver с выданными логином и паролем. Отправьте сообщение с простым текстом и сохраните ответ submit_sm. Проверьте, что DLR поступил через deliver_sm и связался с исходным message_id. Проверьте отправку кириллического текста и длинного сообщения. Отключите соединение во время теста и убедитесь, что очередь не теряет сообщение. Кириллица требует отдельной проверки кодировки. Если текст не помещается в один SMS, приложение должно корректно разбивать его на части и передавать параметры, по которым телефон соберёт сообщение. Для такого сценария пригодится разбор конкатенированных SMS через SMPP. На этом этапе тестируют и ошибки. Например, шлюз может вернуть состояние, связанное с заполненной очередью или ограничением скорости. Приложение не должно бесконечно повторять запрос с той же скоростью. Для отдельных ситуаций нужна задержка, для других — перевод сообщения в ошибочную очередь и уведомление технического ответственного. Как переключить отправку на SMPP без потери сообщений? Безопаснее использовать поэтапное переключение. Сначала включите SMPP только в тестовой среде, затем направьте через него ограниченную долю рабочих сообщений и сравните результаты с HTTP API. Смотрите не только на факт принятия команды, но и на сопоставление message_id, DLR, ошибки и время обработки очереди. Перед переключением зафиксируйте момент смены канала и правило маршрутизации. У каждого сообщения должен быть один владелец отправки. Если после тайм-аута приложение не знает, принял ли шлюз SMS, повторная отправка может создать дубль. Поэтому повторять нужно по понятному правилу: например, только для сообщений, которые точно не получили подтверждение, либо после проверки состояния по доступному идентификатору. На время миграции оставьте HTTP API как резервный путь, но не включайте автоматический повтор через оба канала одновременно. Резервный SMPP-канал и правила переключения лучше проектировать отдельно; полезный ориентир даёт материал о резервном SMPP-канале при сбое провайдера. После переключения сохраните старую интеграцию в режиме наблюдения на согласованный внутренний период. Проверьте отчёты по очереди, ошибки bind, разрывы соединения, превышение throughput и задержки DLR. Только после этого удаляйте старый код отправки. Какие ошибки чаще всего ломают миграцию? Смешение принятия и доставки. Ответ submit_sm означает обработку команды шлюзом, а не доставку SMS получателю. Финальный результат нужно брать из DLR. Потеря связи между ID. В базе сохраняют внутренний номер заказа, но не message_id SMPP. Тогда отчёт доставки невозможно корректно обработать. Неверные TON/NPI. Эти параметры копируют из чужого примера, хотя провайдер выдал другие значения для конкретного сценария. Отсутствие heartbeat. Сессия выглядит открытой, но фактически соединение уже не работает. Нужны регулярные проверки и повторное подключение. Повтор после любого тайм-аута. Тайм-аут не всегда означает, что шлюз не принял сообщение. Перед повтором проверьте логику идемпотентности и правила провайдера. Тест только короткого текста. Кириллица и длинные SMS проходят другой путь кодирования, поэтому их проверяют до запуска. 3 шага, которые можно сделать на этой неделе: Составить карту текущего HTTP API: очередь, идентификаторы, ответы и повторы. Запросить SMPP-параметры и собрать тестовый адаптер с bind_transceiver, submit_sm и обработкой DLR. Провести поэтапное переключение на тестовых сообщениях, сохранив связь внутреннего ID с message_id. > Source: https://smpp.by/migratsiya-s-http-api-na-smpp-bez-poteri-sms --- # Как настроить TLS для SMPP и защитить SMS-трафик TLS защищает соединение между вашим приложением и SMPP-шлюзом: данные передаются в зашифрованном виде, а приложение может проверить сертификат сервера. В статье разберём, что уточнить у провайдера, как проверить порт и сертификат, какие параметры задать в Python и как убедиться, что после включения шифрования не сломались bind, отправка и DLR. Примеры подойдут разработчику малого бизнеса, который подключает высокообъёмный SMS-трафик из Беларуси. Что именно защищает TLS в SMPP? SMPP передаёт команды между ESME, то есть вашим приложением, и SMS-центром или шлюзом. Через соединение проходят логин SMPP, служебные команды, текст сообщения, номер получателя и ответы сервера. Если соединение идёт без шифрования, содержимое сетевого обмена можно перехватить на одном из участков маршрута. TLS создаёт защищённый транспортный слой поверх TCP. После установки соединения стороны договариваются о версии протокола и шифрах, затем приложение проверяет сертификат сервера. SMPP-команды при этом остаются теми же: bind_transmitter, bind_receiver или bind_transceiver, submit_sm, enquire_link и ответы на них. У SMPP-шлюза TLS встречается в двух вариантах. Провайдер может выделить отдельный TLS-порт, на который приложение подключается сразу через защищённый сокет. Другой вариант — отдельная настройка TLS поверх обычного TCP-сеанса, если это поддерживает конкретная реализация. Название режима и номер порта нужно получить из технической документации шлюза, а не подбирать по аналогии. До настройки запросите у провайдера пять параметров: адрес SMPP-шлюза и порт TLS; нужна ли проверка сертификата по имени хоста; требуется ли сертификат клиента, то есть взаимная аутентификация; допустимые версии TLS и наборы шифров; ограничения по bind, DLR, кодировкам и тайм-аутам. Для высокообъёмного трафика TLS не заменяет настройку самого SMPP-сеанса. После защищённого подключения всё равно нужно контролировать ответы submit_sm, delivery receipt и состояние bind. Отдельно проверьте heartbeat: настройка Enquire Link на SMPP-шлюзе помогает не держать в пуле соединение, которое сеть уже разорвала. Как подготовить TLS-соединение на сервере? Начните с окружения, где приложение будет работать постоянно. На сервере должны быть актуальные корневые сертификаты операционной системы и библиотека SMPP, которая умеет принимать готовый TLS-сокет либо включать TLS собственным параметром. Если библиотека поддерживает только обычный TCP, понадобится обёртка над сокетом или другой SMPP-клиент. Сертификат сервера нужно проверять по цепочке доверия. Для рабочей системы не подходит режим, который принимает любой сертификат и отключает проверку имени хоста. Такой флаг иногда используют для локальной диагностики, но его нельзя переносить в конфигурацию продакшена: приложение тогда подтвердит шифрование, но не удостоверится, с каким сервером оно установило связь. Ниже приведён общий пример на Python. Названия методов у SMPP-библиотек отличаются, поэтому функцию создания клиента и вызов bind нужно сверить с документацией выбранного пакета. Ключевая часть примера — контекст SSL, включённая проверка сертификата и подключение к TLS-порту. import sslimport smpp_clientcontext = ssl.create_default_context()context.minimum_version = ssl.TLSVersion.TLSv1_2context.check_hostname = Truecontext.verify_mode = ssl.CERT_REQUIREDclient = smpp_client.Client(    host="smpp.example",    port=TLS_PORT,    ssl_context=context,    system_id=SMPP_LOGIN,    password=SMPP_PASSWORD)client.connect()client.bind_transceiver()client.submit_sm(destination_addr=PHONE, short_message=TEXT) В этом фрагменте smpp.example, TLS_PORT, SMPP_LOGIN и другие значения обозначают параметры из договора или кабинета провайдера. Их нельзя копировать буквально. Если шлюз требует сертификат клиента, добавьте в SSL-контекст загрузку файла сертификата и закрытого ключа, которые вы получили от провайдера: context.load_cert_chain(    certfile="/etc/smpp/client.crt",    keyfile="/etc/smpp/client.key") Закрытый ключ храните вне репозитория и не передавайте в логах. Доступ к файлу ограничивают правами пользователя, от имени которого работает SMS-сервис. В конфигурации приложения оставляют путь к секрету или ссылку на хранилище секретов, а не сам ключ в открытом виде. Как проверить сертификат и сам SMPP-сеанс? Проверка состоит из двух частей. Сначала убедитесь, что TCP-соединение действительно устанавливается с нужным портом и TLS-сервер отдаёт сертификат. Затем выполните полноценный SMPP-сценарий: bind, тестовый submit_sm, получение ответа и проверку DLR, если шлюз его возвращает. Для первичной диагностики администратор может использовать TLS-клиент командной строки из окружения сервера. Команда должна обращаться к имени хоста, которое указал провайдер, потому что проверка сертификата зависит от совпадения имени. Если подключаться по IP-адресу, сертификат часто не пройдёт проверку даже при исправной настройке. В журнал приложения добавьте технические события: время начала и завершения TLS-handshake; результат проверки сертификата; успешный bind и тип bind; исходящий идентификатор сообщения; код ответа submit_sm; статус DLR и причина ошибки, если шлюз её передал; разрыв соединения и повторное подключение. Текст SMS и пароль SMPP в журнал не записывают. Для поиска проблемы достаточно идентификатора сообщения, времени, номера порта и кода ответа. Если сообщения не отправляются после включения TLS, сначала отделите транспортную ошибку от ошибки SMPP: при проблеме сертификата приложение обычно не доходит до bind, а при неверных учётных данных TLS завершается, но bind получает отказ. DLR проверяйте отдельно для каждого тестового сообщения. Сам факт успешного submit_sm означает, что шлюз принял запрос приложения, но не подтверждает доставку абоненту. Для контроля этого участка пригодится мониторинг SMPP через DLR. Как настроить кодировки, heartbeat и повторные подключения? TLS шифрует канал, но не исправляет ошибки в формате SMS. Для кириллицы обычно используют UCS2, а для латинского алфавита GSM7, если текст укладывается в поддерживаемый набор символов. Такая рекомендация указана в требованиях к отправке SMS SMPP в документации Exolve. Перед запуском проверьте, как ваша библиотека формирует data_coding и short_message. Сделайте отдельные тесты для латинского текста, кириллицы и сообщения, в котором встречается специальный символ. Проверяйте не только отображение у получателя, но и длину сообщения, разбиение длинного текста и значение esm_class для составных SMS. Эти параметры зависят от шлюза и библиотеки, поэтому их фиксируют в рабочей конфигурации после теста. Поддерживайте соединение через enquire_link и отвечайте на enquire_link от шлюза. В документации Exolve для SMPP указано, что ESME должно отправлять PDU enquire_link каждые 15 минут независимо от наличия трафика. В конкретном подключении интервал может быть иным, если это установлено провайдером. Таймер должен работать независимо от очереди отправки. После сетевого разрыва приложение закрывает старый сокет, создаёт новый TLS-контекст или повторно использует безопасный объект согласно документации библиотеки, затем выполняет bind заново. Нельзя без проверки повторно отправлять последний submit_sm: при разрыве ответа приложение не знает, принял ли шлюз сообщение. Нужны собственный message ID, идемпотентная логика и сверка DLR. СитуацияЧто проверить первымЧто записать в журнал Не проходит TLS-handshakeПорт, имя хоста, срок действия и цепочку сертификатаКод ошибки TLS и время подключения TLS установлен, bind отклонёнsystem_id, пароль, тип bind и права учётной записиКод ответа bind без пароля submit_sm принят, DLR нетПараметры DLR и маршрут статусов у провайдераИдентификатор сообщения и статус ответа Соединение разрывается в простоеEnquire Link, тайм-ауты и сетевой firewallВремя последнего heartbeat Кириллица отображается неправильноUCS2, data_coding и длину поля сообщенияТип кодировки и размер текста Какие ошибки встречаются при включении TLS? Проверку сертификата отключают навсегда. Так можно найти причину сбоя в тестовой среде, но рабочее подключение должно проверять цепочку доверия и имя сервера. На TLS-порт отправляют обычный SMPP без TLS. Сервер ждёт начало TLS-сеанса и не понимает первые байты SMPP-пакета. Имя сервера заменяют IP-адресом. При включённой проверке hostname сертификат может не совпасть с адресом подключения. Сертификат клиента и сертификат сервера путают. Для взаимной аутентификации нужны отдельные файлы и требования провайдера. После включения TLS не тестируют DLR. Принятый submit_sm показывает только ответ шлюза на запрос, поэтому доставку проверяют отдельным сценарием. Heartbeat смешивают с очередью SMS. Enquire Link должен отправляться даже тогда, когда новых сообщений нет. Перед переносом настройки в рабочую среду сохраните параметры TLS, тип bind, кодировки, интервал enquire_link и правила повторного подключения в одном техническом описании. Затем проведите небольшой тестовый прогон с кириллицей, проверкой ответа submit_sm и DLR. Если собственная SMPP-библиотека не умеет надёжно работать с TLS-сокетом, сначала выберите шлюз и клиентскую реализацию с такой поддержкой; сравнить варианты подключения помогает материал как выбрать SMPP-шлюз в 2026 году: SMPP или HTTP API. 3 шага, которые можно сделать сегодня: Запросить у провайдера TLS-порт, требования к сертификатам, имя хоста и интервал heartbeat. Собрать SSL-контекст с проверкой сертификата и прогнать bind в тестовой среде. Отправить тестовую SMS, проверить код submit_sm, DLR, кириллицу и поведение после разрыва соединения. > Source: https://smpp.by/kak-nastroit-tls-dlya-smpp-i-zaschitit-sms-trafik --- # Как выбрать SMPP-шлюз в 2026 году: SMPP или HTTP API Для малого бизнеса Беларуси выбор между «голым» SMPP и HTTP API зависит от объёма отправки, требований к контролю доставки и готовности заниматься технической интеграцией. HTTP API проще запустить, когда SMS отправляются из сайта или CRM небольшими партиями. SMPP оправдан, когда нужен постоянный поток сообщений, несколько соединений, управление скоростью и подробный контроль статусов. Ниже разберём различия, критерии выбора и порядок подключения, чтобы оценить задачу до разговора с провайдером. Чем SMPP отличается от HTTP API? HTTP API обычно работает как веб-запрос: приложение передаёт текст, номер и дополнительные параметры, а сервис возвращает ответ о принятии запроса. Такой способ понятен разработчику, который уже работает с REST, JSON и веб-сервисами. Для разовой отправки уведомления после заказа достаточно вызвать один метод API и обработать ответ. SMPP устанавливает постоянное соединение между приложением и SMS-шлюзом. Программа подключается с учётными данными, отправляет команды протокола и получает ответы по тому же соединению. Для этого нужно учитывать bind, sequence number, скорость передачи, повторные подключения, тайм-ауты и входящие delivery receipts, или DLR. Разница заметна в контроле. HTTP API скрывает часть работы внутри сервиса, а SMPP даёт разработчику больше параметров: количество соединений, режим отправки, обработку ответов и маршрутизацию трафика. Цена такой свободы — отдельная настройка приложения и постоянный мониторинг соединения. КритерийHTTP APISMPP Старт интеграцииОбычно проще для небольшого проектаТребует понимания протокола и состояний соединения Тип соединенияОтдельные HTTP-запросыПостоянная сессия с SMS-шлюзом Контроль нагрузкиЧасто задаётся параметрами API или ограничениями сервисаНастраивается через окна сообщений, соединения и лимиты Статусы доставкиЗависят от формата API и реализации провайдераПередаются через DLR при поддержке со стороны шлюза Массовая отправкаПодходит при корректной очереди запросовУдобна для постоянного высокообъёмного трафика ПоддержкаМеньше протокольных деталей на стороне бизнесаНужно обслуживать соединение и разбирать ответы SMPP Таблица показывает принцип, а не универсальное правило. Один и тот же бизнес может оставить HTTP API для редких административных уведомлений, а поток заказов перевести на SMPP. При выборе смотрите на архитектуру приложения, а не только на название протокола. Когда малому бизнесу достаточно HTTP API? HTTP API разумно выбрать, если SMS уходят из одного приложения и отправка начинается после конкретного события: оформления заказа, изменения статуса или запроса кода. В этом сценарии важны короткая интеграция и понятная обработка ошибок. Приложение формирует запрос, записывает идентификатор сообщения и передаёт его в очередь. Такой вариант подходит и для небольшого интернет-магазина, если количество сообщений меняется в течение дня и нет задачи управлять несколькими SMPP-сессиями. Но даже при API не стоит отправлять SMS прямо из пользовательского HTTP-запроса. Если внешний сервис временно не отвечает, страница заказа зависнет или клиент увидит ошибку, хотя сам заказ уже создан. Надёжнее разделить процесс на этапы: бизнес-система создаёт событие, очередь сохраняет задание, отдельный обработчик отправляет SMS, а журнал фиксирует ответ шлюза. Для каждой попытки сохраняйте время, номер сообщения, код ответа и причину повторной отправки. Это пригодится при разборе пропущенного уведомления. Если проект уже работает через HTTP API, переход на SMPP не обязательно делать одномоментно. Практический план миграции с сохранением очереди и контроля отправки разобран в материале о миграции с HTTP API на SMPP без потери SMS. Когда SMPP оправдан для бизнеса в Беларуси? SMPP выбирают, когда SMS становятся постоянной частью внутренней системы: сайт создаёт поток уведомлений, CRM запускает сообщения по событиям, а несколько сервисов используют один шлюз. Постоянная сессия уменьшает число служебных HTTP-запросов и позволяет приложению работать с очередью сообщений напрямую через протокол. До подключения нужно определить предполагаемый поток и ограничения. Под «объёмом» стоит понимать не только количество SMS за месяц, но и пиковую скорость: сколько сообщений приложение отправляет за секунду или минуту. Если утром одновременно формируются заказы, рассылка и напоминания, именно пик создаёт нагрузку на соединение. У SMPP есть параметр window size, который ограничивает число неподтверждённых операций. При слишком большом окне приложение начнёт получать ошибки перегрузки или будет сложнее сопоставлять ответы с исходными сообщениями. При слишком маленьком окне канал будет простаивать. Значение подбирают тестом, учитывая лимит провайдера и скорость обработки ответов. Для постоянного соединения нужен контроль состояния канала. Команда Enquire Link помогает проверить, что соединение доступно, а таймеры позволяют вовремя закрыть зависшую сессию и подключиться заново. Настройку этого механизма можно сверить с отдельным руководством об Enquire Link на SMPP-шлюзе. Какие параметры проверить у SMPP-шлюза? До разработки запросите техническое описание подключения. В нём должны быть указаны версия SMPP, адрес и порт, тип bind, логин, пароль, разрешённый source address, лимиты скорости и правила работы с DLR. Если провайдер сообщает только адрес и пароль, этого недостаточно для предсказуемой интеграции. Отдельно уточните кодировку. В SMPP не используется UTF-8 как универсальная кодировка текста. Для кириллицы применяют DCS 0x08, для латинского текста часто используют DCS 0x03 в соответствии со спецификациями SMPP и 3GPP TS 23.038 (документация МТС для бизнеса). Неправильный DCS приводит к кракозябрам, ошибочной длине сообщения или неожиданному разбиению текста. Протестируйте минимум четыре варианта: короткое сообщение на латинице, кириллический текст, сообщение на границе допустимой длины и длинный текст с несколькими сегментами. Проверяйте не только отображение на телефоне, но и значение esm_class, data_coding, registered_delivery и идентификатор сообщения в ответе submit_sm_resp. DLR нужен для понимания дальнейшего состояния SMS. Ответ шлюза о принятии submit_sm означает, что сообщение принято на обработку, но не подтверждает доставку абоненту. Для анализа проверьте формат delivery receipt, соответствие message_id и итоговый статус. Мониторинг через DLR описан в материале о контроле сбоев доставки SMPP. Как сравнить варианты до подключения? Составьте короткую техническую таблицу по своему проекту. Запишите источник сообщений, пиковую скорость, нужный sender ID, языки текста, количество систем-отправителей, требования к DLR и допустимую задержку повторной попытки. Такой список помогает отличить реальную потребность в SMPP от желания выбрать более сложный протокол «на будущее». Если SMS отправляет один сайт и очередь небольшая, начните с HTTP API, но сохраните в программе отдельный слой отправки. Тогда транспорт можно заменить без переписывания логики заказов. Если сообщений много, источников несколько, а статусы должны поступать в собственную систему, проектируйте SMPP-соединение сразу. Уточните, как провайдер обрабатывает временные ошибки, повторные bind-запросы, дубликаты и недоступность маршрута. Попросите тестовые параметры и проверьте их в отдельном окружении. Рабочие логины лучше не использовать для первых экспериментов: ошибка в цикле отправки создаёт поток сообщений, который сложно остановить вручную. Типичные ошибки при выборе и настройке Сравнивать SMPP и HTTP API только по числу методов, не учитывая очередь, пиковую скорость и DLR. Передавать кириллицу с неверным data_coding и проверять результат только на одном коротком сообщении. Считать ответ submit_sm_resp подтверждением доставки абоненту. Запускать постоянное SMPP-соединение без Enquire Link, тайм-аутов и повторного подключения. Не сохранять message_id, из-за чего невозможно связать DLR с исходной SMS. Отправлять длинный текст без теста сегментации и последующего объединения частей на телефоне. 3 шага, которые можно сделать на этой неделе: Опишите поток SMS: какие события создают сообщения, сколько их бывает в обычный и пиковый период, какие статусы нужны бизнесу. Проверьте у провайдера версию SMPP, DCS для кириллицы и латиницы, лимит скорости, формат DLR и правила восстановления соединения. Проведите тест в отдельном окружении: отправьте короткие и длинные сообщения, отключите соединение, восстановите его и сверьте каждый DLR с исходным message_id. > Source: https://smpp.by/kak-vybrat-smpp-shlyuz-v-2026-godu --- # Как настроить TON/NPI в SMPP для SMS в Беларуси TON и NPI в SMPP описывают, как шлюз должен воспринимать адрес отправителя или получателя. Ошибка в этих полях иногда приводит к отклонению сообщения, неверной маршрутизации или неполному DLR. Для МТС, A1 и life:) нельзя без проверки подставлять универсальные значения: итоговая настройка зависит от требований конкретного SMPP-шлюза, формата номера и имени отправителя. В статье разберём поля, порядок проверки и действия при недоставке SMS. Что означают TON и NPI в SMPP? TON расшифровывается как Type of Number, то есть тип номера. Поле помогает определить, что передано в адресе: международный номер, национальный номер, короткий код, буквенное имя отправителя или другой формат. NPI — Numbering Plan Indicator, признак плана нумерации. В большинстве интеграций он связан с тем, по какому плану шлюз должен разобрать адрес. Ошибка появляется, когда приложение отправляет один формат номера, а в параметрах PDU указывает другой тип или план. Эти поля передаются отдельно для source_addr_ton, source_addr_npi, dest_addr_ton и dest_addr_npi. Первые два относятся к отправителю, вторые два — к получателю. Поэтому одна и та же SMS может иметь корректный TON/NPI для номера клиента, но неверный набор для имени отправителя. ПолеЧто описываетЧто проверить source_addr_tonТип адреса отправителяЭто номер, короткий код или буквенное имя source_addr_npiПлан нумерации отправителяСоответствует ли значение требованиям шлюза dest_addr_tonТип номера получателяПередаётся ли номер в согласованном формате dest_addr_npiПлан нумерации получателяСовпадает ли план с настройками маршрута Название оператора само по себе не определяет значения TON и NPI. Для МТС, A1 и life:) нужно учитывать формат, в котором шлюз принимает номера, а также правила конкретного подключения. Поэтому техническое задание провайдера важнее примера из чужой конфигурации. Как выбрать TON/NPI для номеров МТС, A1 и life:)? Начните с единого формата телефонных номеров. Если приложение хранит номера по-разному, например часть с плюсом, часть без него, сначала приведите их к согласованному виду. Иначе одна и та же настройка даст разные результаты для разных записей. Затем запросите у SMPP-провайдера таблицу параметров подключения. В ней должны быть указаны сервер, порт, режим bind, TON/NPI и лимиты отправки. Такая последовательность описана в практической инструкции по SMPP-интеграции от SMSp.by: после подключения рекомендуется отправить тестовые SMS и проверить DLR. Для теста возьмите номера абонентов разных сетей, включая МТС, A1 и life:), если ваш трафик направляется во все эти сети. Отправьте одинаковое сообщение с одним набором параметров, зафиксируйте submit_sm_resp и итоговый delivery receipt. Затем меняйте только один параметр за раз. Так будет понятно, повлиял ли TON, NPI, формат номера или маршрут. Не переносите значения из документации другого шлюза. Один провайдер может принимать международный формат номера с определённым TON, а другой требовать собственную комбинацию или рекомендовать значения по умолчанию. Если документация допускает значение «unknown», это тоже следует воспринимать как часть спецификации конкретного подключения, а не как универсальное правило для Беларуси. Почему ошибка TON/NPI влияет на доставку и DLR? При отправке приложение сначала передаёт PDU SMPP шлюзу. Шлюз проверяет структуру сообщения, адреса и доступность маршрута. Если адрес не соответствует указанному типу, система может вернуть ошибку сразу на этапе submit_sm. В таком случае SMS до оператора не уйдёт. Другой сценарий выглядит сложнее: шлюз принимает сообщение, но не может правильно обработать адрес на последующем участке маршрута. Тогда приложение получает принятие от SMPP-сессии, а в DLR приходит статус ошибки или недоставки. Поэтому одного положительного submit_sm_resp недостаточно для проверки результата. DLR нужно сопоставлять с исходным message_id. Проверьте, что приложение сохраняет идентификатор, разбирает delivery_receipt и не считает сообщение доставленным только потому, что шлюз его принял. Практические правила чтения SMPP-статусов и контроля недоставки разобраны в материале «SMPP-статусы: как читать DLR». TON/NPI не исправят недоступный телефон, временную перегрузку сети или ограничение маршрута. Если часть SMS доходит, а часть получает одинаковую ошибку, сравните формат адресов и параметры PDU. Если ошибка возникает только у одного направления, передайте провайдеру message_id, время отправки и полный текст статуса. Как диагностировать ошибку TON/NPI в рабочем подключении? Диагностику удобнее проводить от уровня приложения к уровню маршрута. Сначала сохраните исходные поля submit_sm: source_addr, destination_addr, source_addr_ton, source_addr_npi, dest_addr_ton и dest_addr_npi. Без этих данных провайдеру трудно отличить ошибку формата от сбоя доставки. Проверьте длину и запись номера получателя. Уберите пробелы, скобки и лишние символы, если такой формат не разрешён спецификацией подключения. Сравните TON/NPI с таблицей провайдера. Отдельно проверьте отправителя и получателя, потому что у них разные поля. Отправьте тест на номера МТС, A1 и life:) с одинаковым текстом и одинаковым sender ID. Сопоставьте submit_sm_resp, message_id и DLR. Запишите, на каком этапе появляется ошибка. После изменения параметров повторите тест на новом сообщении, чтобы не спутать старый DLR с новой попыткой. Если используется несколько SMPP-подключений под одним логином, заранее уточните правила возврата статусов. В документации одного из провайдеров отмечено, что DLR для сообщений от одного подключения иногда могут прийти на другое. Для бизнеса это выглядит как проблема TON/NPI, хотя причина находится в распределении сессий и обработке идентификаторов. Типичные ошибки Приложение передаёт номер в одном формате, а TON указывает для другого формата. Разработчик меняет сразу TON, NPI и sender ID, поэтому не может определить причину сбоя. Положительный submit_sm_resp принимают за подтверждение доставки. Значения копируют из примера другого SMS-шлюза без сверки с настройками текущего провайдера. DLR не связывают с message_id или разбирают только текстовый статус. Несколько SMPP-сессий используют общий логин без проверки маршрутизации delivery receipt. Как оформить настройки для разработчика? Передайте разработчику не фразу «настроить SMPP для Беларуси», а таблицу параметров. В ней укажите формат номера, допустимый sender ID, значения TON/NPI для source и destination, режим bind, лимит сообщений и правила обработки DLR. Что описатьПример формулировки в техническом задании ПолучательНомер передаётся в формате, указанном провайдером ОтправительБуквенное имя или номер, согласованный для подключения TON/NPIОтдельные значения для source и destination из таблицы шлюза СтатусыСохранять message_id и обрабатывать DLR ТестированиеПроверить отправку и статусы на направлениях МТС, A1 и life:) Если система уже отправляет SMS через HTTP API, при переходе на SMPP нельзя просто перенести старые поля без проверки. Меняются формат запроса, управление сессией, обработка ошибок и получение DLR. Для такого сценария полезен разбор миграции с HTTP API на SMPP без потери SMS. 3 шага для проверки TON/NPI на этой неделе: Получите у провайдера актуальную таблицу параметров SMPP и зафиксируйте отдельные значения для отправителя и получателя. Проверьте единый формат номеров и отправьте тесты на МТС, A1 и life:) с одним изменением за раз. Сопоставьте submit_sm_resp с DLR по message_id, а затем сохраните рабочие параметры в конфигурации и документации проекта. > Source: https://smpp.by/kak-nastroit-ton-npi-v-smpp-dlya-sms-v-belarusi --- # От нового заказа на Ozon до SMS-клиенту через SMPP Чтобы отправить покупателю SMS после заказа на Ozon, продавцу нужен связующий сервис: он получает событие о заказе через вебхук, проверяет данные и передаёт сообщение в SMS-шлюз по SMPP. В статье разберём практическую схему для бизнеса в Беларуси: какие компоненты подготовить, как обработать повторные события, где использовать статусы доставки и что проверить до запуска. Техническое описание SMPP доступно в инструкции по мониторингу SMPP через DLR. Как выглядит цепочка от заказа до SMS? Схема состоит из четырёх частей: площадка с заказом, ваш сервер, SMPP-шлюз и сеть оператора. Площадка передаёт вашему серверу событие через вебхук. Сервер извлекает номер телефона и нужный статус заказа, формирует текст, затем открывает SMPP-сессию и отправляет сообщение. Для небольшого магазина удобно начать с одного сценария: уведомлять клиента после подтверждения заказа. Позже к нему можно добавить сообщения о передаче отправления, готовности к выдаче или задержке. Каждый сценарий лучше связывать с отдельным событием, чтобы покупатель не получил два одинаковых SMS. ЭтапЧто происходитЧто проверяет разработчик Событие заказа Площадка сообщает об изменении заказа Тип события и его идентификатор Обработка вебхука Ваш сервер принимает запрос Формат данных, подпись или другой способ проверки запроса Подготовка SMS Сервер выбирает текст и номер получателя Наличие телефона, длину и код страны Отправка по SMPP Сервис передаёт сообщение шлюзу Соединение, лимит скорости и ответ шлюза Статус доставки Шлюз возвращает результат доставки Связь статуса с конкретным сообщением и заказом Какие данные передавать из вебхука? Внутри системы достаточно хранить технический идентификатор заказа, его статус, номер телефона, текст сообщения и идентификатор SMS. Идентификатор заказа нужен для защиты от повторной отправки. Идентификатор SMS связывает ответ шлюза с записью в вашей системе. Вебхук не стоит обрабатывать прямо в том же запросе, в котором вы отправляете SMS. Сначала сервер принимает событие и быстро отвечает площадке, затем кладёт задачу в очередь. Отдельный обработчик берёт задачу из очереди и работает со SMPP. Если шлюз временно занят, заказ не теряется, а задача остаётся в очереди. Полезное правило для разработчика: одно событие заказа должно иметь один ключ идемпотентности. Например, ключ можно собрать из идентификатора заказа и типа статуса. При повторной доставке вебхука сервер увидит уже обработанный ключ и не создаст второе SMS. Как настроить SMPP-соединение для уведомлений? Шлюз обычно предоставляет параметры подключения: адрес, порт, логин, пароль, системный тип, режим передачи и допустимую скорость. Эти значения задаёт провайдер SMS-шлюза. Их переносят в конфигурацию приложения, а не записывают в исходный код. Приложение устанавливает SMPP-сессию, проходит bind и отправляет сообщения через submit_sm. После отправки шлюз возвращает идентификатор сообщения. Его нужно сохранить рядом с заказом, иначе последующий статус доставки будет трудно сопоставить с конкретным клиентом. Соединение проверяют через Enquire Link. Если сервер перестал отвечать, приложение закрывает старую сессию и создаёт новую по правилам, заданным шлюзом. Практические настройки этого механизма разобраны в материале про Enquire Link на SMPP-шлюзе. Очередь также защищает от слишком быстрой отправки. Если шлюз возвращает Throttling или Message Queue Full, приложение не должно бесконечно повторять запросы сразу же. Задачу переводят в состояние ожидания и повторяют по возрастающему интервалу. Отдельно фиксируют число попыток и последний ответ шлюза. Пример такой логики описан в статье о повторной отправке при ошибках Throttling и Message Queue Full. Как связать DLR со статусом заказа? Ответ о принятии сообщения шлюзом ещё не означает, что SMS дошло до телефона. Для контроля нужен DLR, то есть отчёт о доставке. Сервис получает такой отчёт и обновляет запись SMS: сообщение доставлено, отклонено, просрочено или получен другой статус, предусмотренный шлюзом. В карточке заказа полезно хранить два разных результата: «SMS принято шлюзом» и «SMS доставлено». Это помогает отделить ошибку приложения от проблемы доставки. Если сообщение не принято сразу, разработчик проверяет код ответа SMPP. Если сообщение принято, но DLR сообщает об ошибке, анализируют номер, маршрут и итоговый статус. Для уведомлений о заказах важна также повторная отправка вебхука со стороны площадки. Система должна повторно вернуть успешный ответ после того, как событие сохранено, но не создавать новую SMS-задачу при каждом повторе. Проверку делают по ключу события, а не по времени получения запроса. Что проверить перед запуском? Тестирование лучше проводить на отдельном тестовом заказе и на номере, доступном разработчику. Сначала проверяют приём вебхука, затем постановку задачи в очередь, отправку через SMPP и получение DLR. После этого отдельно моделируют повторное событие и временную недоступность шлюза. Типичные ошибки Система отправляет SMS при каждом повторе одного и того же вебхука. Разработчик считает ответ submit_sm подтверждением доставки. Идентификатор сообщения шлюза не сохраняется в базе. При обрыве соединения приложение продолжает использовать старую SMPP-сессию. Ошибки Throttling и Message Queue Full повторяются без паузы. Текст сообщения формируется из отсутствующего поля, поэтому клиент получает пустое или неполное уведомление. Для малого бизнеса в Беларуси рабочая схема выглядит так: вебхук сообщает о событии, очередь защищает от повторов и перегрузки, SMPP-шлюз принимает SMS, а DLR показывает результат доставки. Начать можно с одного статуса заказа и одного шаблона, затем добавить остальные этапы после проверки логов. Перед подключением подготовьте карту событий, таблицу сопоставления статусов и тестовый сценарий с повторной доставкой вебхука. > Source: https://smpp.by/ot-novogo-zakaza-na-ozon-do-sms-klientu-cherez-smpp --- # Как настроить мониторинг SMPP через DLR и видеть сбои доставки Мониторинг SMPP через DLR помогает понять, что произошло с каждым SMS после отправки: сообщение доставили, отклонили, поставили в очередь или не удалось передать оператору. В статье разберём, какие статусы сохранять, как считать успешность доставки, когда отправлять алерты и как отличить сбой канала от проблем с номерами. Эти правила подходят небольшому интернет-магазину, сервисному центру и другому бизнесу, который отправляет уведомления через SMPP. Что такое DLR и почему одного ответа submit_sm недостаточно? При отправке SMS приложение передаёт шлюзу сообщение через SMPP-команду submit_sm. Ответ шлюза подтверждает, что запрос принят на этом участке. Такой ответ ещё не означает, что абонент получил SMS. Сообщение может попасть в очередь, завершиться ошибкой маршрутизации или не дойти до телефона. DLR, или Delivery Receipt, приходит позже и описывает результат обработки сообщения. Шлюз связывает отчёт с исходным SMS через идентификатор сообщения. Приложение получает этот отчёт по отдельному SMPP-соединению или в рамках transceiver-сессии, затем меняет статус отправки в своей базе. Для мониторинга нужно хранить как минимум: идентификатор сообщения, который вернул SMPP-шлюз; внутренний идентификатор заказа или операции; время отправки запроса и время получения DLR; номер назначения в безопасном для логов виде; исходный статус доставки и текст диагностической причины, если шлюз её передаёт; счётчик повторных попыток и последний результат. Отдельно полезно зафиксировать состояние, когда приложение отправило SMS, но DLR ещё не пришёл. Такой статус нельзя сразу считать ошибкой: задержка отчёта и окончательный отказ — разные события. Для понимания формата статусов пригодится материал о выгрузке статусов SMPP в 1С: принцип одинаков, даже если вместо 1С используется собственная система. Какие статусы DLR нужно учитывать? Названия статусов зависят от шлюза и маршрута, поэтому приложение не должно проверять только одно строковое значение. Надёжнее привести ответы к внутренней группе: «доставлено», «окончательная ошибка», «в обработке» и «неизвестно». Исходный код при этом нужно сохранить, чтобы инженер мог разобрать спорный случай. ГруппаПримеры смыслаДействие системы ДоставленоСообщение принято сетью назначения и доставлено абонентуЗакрыть отправку как успешную, записать время доставки В обработкеСообщение ожидает обработки или отчёт ещё не завершёнОставить отправку открытой и контролировать срок ожидания Окончательная ошибкаНомер недоступен по маршруту, сообщение отклонено или истёк срок доставкиЗафиксировать причину и решить, нужен ли повтор Временная ошибкаВременная перегрузка, очередь или кратковременная недоступностьПовторить по ограниченной политике, не создавая бесконечный цикл НеизвестноШлюз прислал код, которого нет в таблице приложенияСохранить исходные данные и отправить технический алерт Статус «доставлено» тоже стоит проверять аккуратно. DLR сообщает результат, который вернул маршрут, а не подтверждает, что человек прочитал текст. Поэтому в отчётах бизнеса лучше писать «доставлено» и «не доставлено», не подменяя эти понятия открытием сообщения или фактом получения заказа. Как считать успешность доставки по DLR? Для малого бизнеса достаточно начать с простой раздельной статистики. За выбранный интервал посчитайте количество сообщений в каждой группе и отдельно покажите отправки без финального DLR. Если смешать ожидающие сообщения с отказами, показатель будет трудно интерпретировать: задержка отчётов начнёт выглядеть как падение доставки. Минимальный набор метрик выглядит так: число принятых шлюзом SMS; доля сообщений с финальным статусом «доставлено»; доля окончательных ошибок; число временных ошибок; количество сообщений без DLR после заданного срока ожидания; время от submit_sm до получения DLR; распределение ошибок по кодам, маршрутам и типам уведомлений. Считайте показатели по короткому временному окну и сравнивайте их с обычным уровнем именно для этого канала. Авторизация, уведомление о готовности заказа и код подтверждения могут иметь разный объём и разные требования к скорости, поэтому единый порог для всех сообщений часто даёт ложные тревоги. Для каждой отправки полезно хранить два времени: момент принятия запроса шлюзом и момент получения финального DLR. Так инженер увидит, где возникла задержка. Если submit_sm проходит, а отчёты перестают приходить, нужно проверять приём DLR, идентификаторы сообщений и соединение. Если уже submit_sm возвращает ошибки, искать проблему следует раньше, на этапе передачи. Какие алерты поставить на SMPP-канал? Алерт должен сообщать о событии, на которое можно ответить. Сообщение «доставка снизилась» бесполезно без периода, выборки и причины. Уведомление для владельца бизнеса и уведомление для разработчика тоже лучше разделить: первому нужен факт влияния на заказы, второму — технические детали. Практический набор сигналов: нет новых DLR за заданный интервал при наличии отправленных сообщений; доля финальных ошибок заметно выше обычного уровня; один код ошибки повторяется у большого числа сообщений; растёт очередь сообщений со статусом «в обработке»; DLR приходят с неизвестным идентификатором; SMPP-сессия разорвана или перестала отвечать на служебные проверки; приложение не успевает обрабатывать входящие отчёты. Порог выбирают по объёму трафика. При небольшом количестве SMS процент может резко измениться из-за одной ошибки, поэтому полезно сочетать относительное условие с минимальным числом сообщений. Например, алерт запускают только при заметной доле ошибок и при достаточном объёме отправок за интервал. Конкретные значения лучше подобрать после периода наблюдения, а не брать из чужой конфигурации. В сообщение об ошибке добавьте время, идентификатор канала, группу статуса, код DLR, число затронутых SMS и ссылку на технический журнал внутри вашей системы. Сам текст SMS и полный номер получателя в уведомление о сбое обычно не нужны. Для повторной отправки пригодятся правила, описанные в материале о повторе SMS при Throttling и Message Queue Full. Как связать DLR с healthcheck SMPP? DLR показывает путь конкретного сообщения, а healthcheck проверяет, живо ли само соединение. Эти механизмы дополняют друг друга. Канал может отвечать на служебные запросы, но не передавать отчёты в приложение. Бывает и обратная ситуация: DLR для старых сообщений ещё приходят, а новая отправка уже получает отказ. В healthcheck обычно проверяют: состояние bind-сессии и роль соединения: transmitter, receiver или transceiver; ответ на Enquire Link и время ответа; возможность принять входящий DLR; величину очереди исходящих SMS и очередь необработанных отчётов; долю submit_sm с ошибкой; наличие DLR за контрольный период, если за это время были отправки. Служебная проверка соединения сама по себе не заменяет тестовую отправку. Для настройки механизма поддержания SMPP-сессии можно обратиться к инструкции как настроить Enquire Link на SMPP-шлюзе. В рабочей системе Enquire Link должен иметь тайм-аут, журнал событий и понятное действие при разрыве: переподключение, перевод трафика в резерв или остановка повторов. Типичные ошибки при мониторинге DLR Считать ответ submit_sm доставкой. Принятие запроса шлюзом и доставка абоненту фиксируются на разных этапах. Удалять исходный код DLR после нормализации. Внутренняя группа удобна для отчёта, но технический код нужен для расследования. Повторять каждую ошибку. Для недействительного номера повтор не поможет и создаст лишний трафик. Повторы оставляют для временных причин. Проверять только процент доставки. При малом объёме один отказ сильно меняет процент, поэтому смотрят ещё на абсолютное число, очередь и коды ошибок. Игнорировать сообщения без DLR. Их нужно выделять отдельно и контролировать срок ожидания. Не тестировать переподключение. Система должна корректно восстановить bind, не потерять входящие отчёты и не отправить одно сообщение повторно без контроля идентификатора. 3 шага, которые можно сделать на этой неделе: Составить таблицу соответствия кодов DLR внутренним группам и сохранить исходные значения. Добавить метрики по доставленным, ошибочным, ожидающим и неизвестным статусам, а также по задержке получения отчёта. Настроить два алерта: на отсутствие DLR при активной отправке и на всплеск окончательных ошибок, после чего проверить сценарий разрыва SMPP-сессии. > Source: https://smpp.by/kak-nastroit-monitoring-smpp-cherez-dlr-i-videt-sboi-dostavki --- # Как настроить Enquire Link на SMPP-шлюзе Enquire Link поддерживает контроль соединения между вашим SMPP-клиентом и SMSC. Если шлюз отправляет этот запрос через согласованный интервал, а система отвечает Enquire Link Response, обе стороны видят, что TCP-сессия жива. В статье разберём, как выбрать интервал, настроить таймаут, отличить потерю связи от ошибки отправки и проверить результат по логам. Эти шаги подходят небольшому бизнесу, который передаёт SMS через собственное приложение или промежуточную платформу. Что делает Enquire Link в соединении SMPP? После установки SMPP-сессии приложение и SMSC обмениваются командами поверх TCP. Когда в канале есть обычный трафик, состояние соединения видно по SubmitSM, SubmitSMResp и другим пакетам. Но если сообщений некоторое время нет, одна сторона может не узнать о разрыве сразу. TCP-соединение иногда выглядит открытым, хотя удалённый сервер уже недоступен. Enquire Link решает эту задачу контрольным запросом. SMPP-клиент отправляет PDU enquire_link, SMSC возвращает enquire_link_resp. В ответе должен совпадать sequence_number исходного запроса. Это позволяет связать запрос с конкретным ответом и измерить задержку. Команда не отправляет SMS и не создаёт сообщение для абонента. Она проверяет состояние SMPP-сессии. Если ответ не пришёл за отведённое время, приложение закрывает сессию и запускает повторное подключение по своей логике. Как выбрать интервал Enquire Link? Интервал задают между отправками контрольных запросов, когда соединение не получает другой трафик. Его нельзя выбирать отдельно от таймаута ответа и политики SMSC. Сначала запросите у поставщика SMPP параметры keep-alive: допустимую частоту, время ожидания ответа и требования к повторному подключению. Практическая схема выглядит так: Запустите таймер после успешного подключения и авторизации в SMPP. Сбрасывайте таймер при любом входящем или исходящем PDU, если шлюз считает обычный трафик признаком активности. Отправляйте enquire_link, когда канал простаивает дольше заданного интервала. Записывайте время отправки и номер последовательности. После enquire_link_resp фиксируйте задержку и снова запускайте отсчёт. Слишком редкий запрос оставляет разрыв незамеченным надолго. Слишком частый создаёт лишний служебный обмен и иногда нарушает ограничения SMSC. Поэтому интервал берут из договора или технической инструкции поставщика, а не копируют из случайного примера для другого шлюза. Если в приложении уже есть отдельный TCP keep-alive, не считайте его полной заменой SMPP-команды. TCP проверяет состояние сетевого соединения на своём уровне, а Enquire Link подтверждает, что удалённая сторона отвечает как SMPP-система. Как настроить таймаут ответа и переподключение? Таймаут Enquire Link начинается после отправки PDU. Он должен быть меньше периода, после которого бизнес считает канал потерянным, но достаточно длинным для реальной задержки сети и обработки на стороне SMSC. Один пропущенный пакет ещё не всегда означает окончательный сбой: сеть могла потерять пакет, а сервер мог кратковременно задержать ответ. Поэтому в коде разделите три события: ответ получен — сессия остаётся активной; таймаут одного запроса — событие попадает в журнал, счётчик пропусков увеличивается; порог пропусков достигнут — приложение закрывает старый сокет и начинает новый bind. При переподключении сначала остановите таймеры старой сессии. Иначе старый поток может отправить Enquire Link уже в закрытый сокет или обработать ответ от другой сессии. Затем корректно закройте соединение, создайте новый TCP-сеанс, выполните bind и только после успешной авторизации включите keep-alive. Повторное подключение не должно запускаться бесконечно без паузы. Используйте возрастающую задержку между попытками и записывайте причину каждой попытки: таймаут, закрытие TCP, отказ bind или ошибка протокола. Такая запись помогает отделить проблему сети от неверных учётных данных. После восстановления сессии проверьте очередь исходящих сообщений. Нельзя автоматически считать каждое SMS из старой очереди доставленным только потому, что новый bind прошёл успешно. Статусы SubmitSM и DLR обрабатывайте по своим правилам. Для разбора подтверждений доставки пригодится материал о SMPP-статусах и чтении DLR. Какие пакеты нужно видеть в логах? Минимальный лог для диагностики хранит направление пакета, команду, sequence number, время отправки и время ответа. Текст SMS и другие чувствительные поля для проверки keep-alive не нужны. По журналу должно быть понятно, какая команда ушла последней и когда приложение решило считать соединение недоступным. СобытиеЧто проверитьЧто делать enquire_link отправленСоединение авторизовано, sequence number уникаленЗапустить ожидание ответа enquire_link_resp полученКоманда и sequence number соответствуют запросуСбросить таймер и записать задержку Ответ не полученНе истёк ли таймаут, не закрыт ли сокетЗафиксировать пропуск по выбранной политике Соединение закрытоКто закрыл канал и какой был последний PDUОстановить старые таймеры и переподключиться Bind отклонёнЛогин, пароль, system type и лимиты SMSCНе отправлять очередь до успешной авторизации Полезно отдельно считать время между запросом и ответом. Редкие пики покажут сетевые задержки, а одинаковые таймауты после простоя укажут на закрытие неактивных соединений. Если Enquire Link отвечает, но SubmitSM возвращает ошибки, проблема находится уже в параметрах отправки, маршрутизации или лимитах, а не в keep-alive. Какие ошибки встречаются при настройке? Один общий таймер на все соединения. Если приложение держит несколько SMPP-сессий, каждая должна иметь собственное состояние и свой sequence number. Проверка только TCP-сокета. Открытый сокет не подтверждает, что SMSC отвечает на SMPP-команды. Игнорирование sequence number. Ответ нельзя принимать как подтверждение запроса, если его номер не совпадает. Отправка Enquire Link во время остановки. При завершении процесса сначала выключайте таймер, затем закрывайте соединение. Мгновенное переподключение после любого сбоя. Такая логика создаёт поток новых соединений и усложняет диагностику. Отсутствие наблюдения за DLR. Живой keep-alive подтверждает канал, но не доставку конкретного SMS. Для малого проекта настройку лучше проверять на тестовом трафике: сначала убедиться, что bind проходит, затем искусственно разорвать TCP-соединение и посмотреть, как приложение обнаружит сбой. После этого проверьте восстановление очереди и соответствие статусов. Если бизнес переходит с HTTP API на постоянное SMPP-соединение, заранее составьте отдельный сценарий миграции, чтобы не смешать проблемы keep-alive с изменением формата отправки. Практический разбор есть в материале о миграции с HTTP API на SMPP без потери SMS. 3 шага для проверки настройки: Уточните у поставщика SMSC допустимый интервал Enquire Link и таймаут ответа. Включите журнал PDU с временем, направлением и sequence number, затем проверьте пару enquire_link и enquire_link_resp. Разорвите тестовое соединение, убедитесь в остановке старого таймера, корректном переподключении и сохранении контроля над очередью SMS. > Source: https://smpp.by/kak-nastroit-enquire-link-na-smpp-shlyuze --- # Как повторять SMS при ошибках Throttling и Message Queue Full Ошибки Throttling и Message Queue Full означают, что SMPP-соединение временно не успевает принять новый объём сообщений. В такой момент нельзя просто удалить SMS или бесконечно повторять отправку без паузы. В статье разберём, как распознать коды ESME_RTHROTTLED и ESME_RMSGQFUL, вернуть сообщение в очередь, выбрать таймаут и ограничить число попыток, чтобы система не создавала дополнительную нагрузку. Почему SMPP возвращает Throttling Error и Message Queue Full? SMPP-шлюз обменивается с вашим приложением командами и ответами. При отправке большого потока сообщений провайдер или само соединение может временно ограничить скорость обработки. В ответ приложение получает ошибку throttling, которую часто связывают с кодом ESME_RTHROTTLED. Причина ESME_RTHROTTLED обычно связана с превышением допустимой скорости запросов. Например, приложение отправляет новые submit_sm, пока сервер ещё обрабатывает предыдущие команды. Сервер отклоняет текущую операцию, потому что канал нужно разгрузить. Ошибка ESME_RMSGQFUL, или Message Queue Full, указывает на заполнение очереди сообщений. Сервер временно не может принять ещё одну запись. В этом случае повторная попытка сразу после отказа часто приводит к следующему отказу и увеличивает очередь невыполненных задач на стороне приложения. Для бизнеса в Беларуси такой сценарий встречается при пакетной отправке кодов подтверждения, уведомлений о заказе или сообщений о статусе заявки. Проблема касается технической доставки: текст SMS уже сформирован, но SMPP-соединение не смогло принять его в текущий момент. Как обработать ESME_RTHROTTLED с правильной паузой? При получении ошибки ESME_RTHROTTLED сообщение нужно вернуть в очередь. Перед следующей попыткой выдерживают таймаут на этом соединении, равный одной секунде. Это конкретное правило указано в документации Devino по протоколу SMPP. Пауза относится к соединению, которое вернуло ошибку. Если приложение держит несколько SMPP-сессий, не стоит блокировать все каналы из-за одного отказа. Для каждой сессии нужен собственный счётчик состояния и собственный момент следующей попытки. Пример последовательности: Приложение отправляет SMS через выбранное SMPP-соединение. Сервер возвращает ESME_RTHROTTLED. Приложение сохраняет сообщение в очереди с исходным идентификатором задачи. На этом соединении запускается таймер на 1 секунду. После таймера приложение повторяет отправку. Сообщение лучше возвращать в конец очереди, а не ставить перед всеми остальными задачами. Тогда одна проблемная запись не блокирует остальные SMS и система сохраняет порядок обработки общего потока. Что делать при Message Queue Full? При ошибке ESME_RMSGQFUL SMS также возвращают в конец очереди. Документация Devino рекомендует сделать ещё от 3 до 5 попыток доставки, каждый раз повторяя постановку сообщения в конец очереди при той же ошибке. Важна именно ограниченная серия повторов. Если сообщение возвращается бесконечно, очередь растёт, рабочие процессы заняты повторной обработкой, а новые SMS получают меньше ресурсов. После исчерпания лимита приложение должно перевести запись в отдельный список ошибок и сохранить причину отказа. Ошибка Что означает Действие приложения Пауза и лимит ESME_RTHROTTLED Скорость отправки ограничена Вернуть SMS в очередь и повторить через таймаут 1 секунда на этом соединении ESME_RMSGQFUL Очередь сообщений на стороне шлюза заполнена Поставить SMS в конец очереди От 3 до 5 повторных попыток Для Message Queue Full в передаче данных полезно хранить номер попытки, время последней ошибки и текст ответа сервера. Эти поля позволяют отличить временную перегрузку от постоянной технической проблемы, например ошибки авторизации или отключённой сессии. Как построить очередь и ретраи в SMPP-приложении? Очередь должна отделять подготовку SMS от её отправки. Бизнес-система создаёт задачу с текстом, номером получателя и внутренним идентификатором. Отдельный отправитель забирает задачу, передаёт её через SMPP и ждёт результата. Если сервер вернул временную ошибку, задача меняет статус на «ожидает повтора». Для каждой задачи удобно хранить следующие значения: уникальный идентификатор сообщения; номер попытки отправки; код последней SMPP-ошибки; время, после которого разрешён новый запуск; идентификатор SMPP-соединения; финальный статус доставки или причина остановки. Не удаляйте SMS из основной очереди до получения результата отправки. При временной ошибке запись должна остаться доступной для повторной обработки. При успешном ответе её можно перевести в статус принятой сервером, а при достижении лимита повторов, в журнал неуспешных задач. Полезно разделить очереди по приоритету. Коды подтверждения и уведомления о состоянии заказа обычно требуют более быстрой обработки, а массовые информационные сообщения могут подождать. Такое разделение снижает риск, что большой пакет второстепенных SMS задержит транзакционные сообщения. Как избежать повторной отправки одного и того же SMS? Ретрай запускается только после временной ошибки. Если сервер уже принял команду, а приложение не получило ответ из-за разрыва соединения, повторная отправка может создать дубль. Поэтому система должна различать отрицательный SMPP-ответ и отсутствие ответа. Для контроля дублей сохраните внутренний ключ сообщения и результат каждой попытки. При восстановлении соединения сначала проверьте состояние сессии и доступные статусы, а потом продолжайте отправку. Нельзя считать отсутствие ответа подтверждением отказа. Если поток SMS постоянно упирается в ограничения, проверьте настройки скорости и количество параллельных запросов. Для резервного сценария пригодится отдельная инструкция о том, как настроить резервный SMPP-канал и не терять SMS при сбое провайдера. Какие ошибки чаще всего ломают повторную отправку? Повтор без паузы. Приложение получает throttling и тут же отправляет ту же команду снова. Сервер отвечает повторной ошибкой, а очередь растёт. Бесконечный ретрай. У задачи нет максимального числа попыток, поэтому одна проблемная запись постоянно занимает обработчик. Возврат в начало очереди. Одно SMS блокирует все следующие сообщения. При перегрузке это быстро увеличивает задержку. Общий таймер для всех соединений. Ошибка на одной SMPP-сессии останавливает отправку по каналам, которые продолжают работать. Удаление исходной задачи. После временного отказа приложение теряет возможность повторить отправку и не может объяснить, куда исчезло SMS. Отсутствие журнала попыток. Без кода ошибки и времени повтора нельзя понять, что произошло с конкретным сообщением. 3 шага, которые можно сделать сегодня: Добавьте обработчики для ESME_RTHROTTLED и ESME_RMSGQFUL, чтобы временные ошибки возвращали SMS в очередь. Для throttling установите паузу 1 секунду на проблемном соединении, а для Message Queue Full ограничьте серию 3–5 повторными попытками. Сохраните код ошибки, номер попытки и итоговый статус в журнале, затем отдельно проверьте сценарии разрыва SMPP-сессии и отсутствия ответа. > Source: https://smpp.by/kak-povtoryat-sms-pri-oshibkakh-throttling-i-message-queue-full --- # Прием SMS через SMPP: настройка входящих сообщений Приём SMS через SMPP — это способ получать ответы клиентов прямо в свою систему или CRM. Вместо того чтобы просто рассылать сообщения, вы даёте абоненту возможность ответить: подтвердить заказ, отправить код, отписаться от рассылки. В этой статье — как настроить двусторонний канал, что для этого нужно и какие ошибки чаще всего мешают. Зачем принимать SMS через SMPP? Каждое исходящее SMS — это потенциальный диалог. Клиент может написать «ДА» в ответ на подтверждение заказа, отправить номер карты или уточнить детали. Если у вас настроен только исходящий канал, эти ответы уходят в пустоту. С помощью SMPP вы принимаете сообщения на тот же номер, с которого шлёте рассылки. Это удобно для: подтверждения заказов и доставки; опросов и голосований; приёма команд отписки (например, слово «STOP»); получения кодов от клиентов. Входящие сообщения можно автоматически передавать в CRM, базу данных или мессенджер. Тогда оператору не нужно вручную переписывать ответы. Как работает входящее SMS через SMPP? Технически схема выглядит так. Абонент отправляет SMS на ваш номер (короткий или городской). Мобильный оператор Беларуси передаёт сообщение вашему SMPP-провайдеру. Провайдер по протоколу SMPP открывает соединение с вашим сервером и отправляет текст сообщения и номер отправителя. Вам нужно: получить у провайдера номер, который поддерживает приём SMS; настроить SMPP-соединение (адрес, порт, логин, пароль); обработать входящее сообщение — сохранить в базу, переслать на email или запустить сценарий. Соединение должно быть постоянным. Если сервер недоступен, сообщения будут накапливаться на стороне провайдера или теряться. Поэтому стоит настроить резервный канал и защиту от несанкционированного доступа. Мы уже рассказывали, как настроить резервный SMPP-канал, и отдельно — как защитить SMPP-шлюз с помощью IP-фильтров и контроля доступа. СпособЧто нужноУровень автоматизации Личный кабинет провайдераТолько браузерНет Email-уведомленияНастройка пересылкиЧастичная SMPP-соединениеСервер и небольшая программаПолная Как настроить приём SMS через SMPP? Порядок действий зависит от того, какой сервис вы используете, но общий алгоритм такой. Выберите SMS-провайдера с поддержкой входящих SMPP. Убедитесь, что он даёт номер не только для рассылок, но и для приёма ответов. Получите параметры SMPP-сервера: IP, порт, логин и пароль. Обычно их присылают после активации тарифа. Подключите свой сервер к SMPP-шлюзу. Если своей инфраструктуры нет, ищите готовые интеграции с CRM или 1С. Например, можно настроить выгрузку статусов SMPP в 1С для интернет-магазина — входящие ответы будут автоматически попадать в заказы. Напишите скрипт или настройте вебхук, который принимает текст и номер, сохраняет их в базу или отправляет нужному сотруднику. Проверьте, что логируются и входящие сообщения, и статусы доставки. Это поможет при спорах с клиентами и отладке. Не забудьте про безопасность: используйте IP-фильтры, меняйте пароли и ограничьте доступ к панели. Подробнее — в статье о защите SMPP-шлюза. Какие ошибки мешают настроить приём SMS? Не проверен номер отправителя. Входящие SMS могут приходить с разных номеров, и нужно правильно определять телефон клиента. Нет автоматической обработки. Ответы приходят, но никто их не читает, потому что они не попадают в CRM. Используется один канал без резервирования. Если сервер лёг, сообщения теряются. Не настроены статусы доставки. Вы не знаете, дошёл ли запрос до клиента и получили ли вы ответ. Забывают про длину сообщений. Если ответ клиента содержит несколько SMS, они могут прийти по частям. Как обрабатывать ответы клиентов без программиста? Если писать скрипт некому, используйте готовые решения. Многие сервисы позволяют пересылать входящие SMS на email или в Telegram-чат. Достаточно указать адрес получателя. Подойдёт и связка с CRM через вебхуки. Для простого бизнеса достаточно настроить уведомление на почту: менеджер увидит ответ и обработает его. Если нужно автоматически отправлять подтверждение клиенту, уже нужна небольшая интеграция. Начните с малого — подключите пересылку ответов на email или в мессенджер. Как собирать такие цепочки без участия программиста, показано в статье о настройке автоматических SMS-уведомлений. 3 шага, которые можно сделать сегодня: Позвоните своему SMS-провайдеру и уточните, поддерживает ли он входящие SMPP-сообщения. Если да — попросите настроить тестовый режим. Настройте пересылку входящих на email (это можно сделать в личном кабинете). Так вы начнёте видеть ответы клиентов, не написав ни строчки кода. Подумайте, какие сценарии ответов хотите автоматизировать: подтверждение заказа, отписка, команды. Это покажет, нужен ли вам полноценный двусторонний SMPP-канал. > Source: https://smpp.by/priem-sms-cherez-smpp --- # Как проверять номера по HLR до отправки SMS? HLR-запрос показывает, существует ли номер и может ли он принять SMS, еще до рассылки. DLR-статус рассказывает о судьбе сообщения после отправки. Через SMPP-шлюз подключаются оба механизма: сначала вы отсеиваете несуществующие номера, затем анализируете доставку. Разберем, как это работает, как настроить фильтрацию и что делать со статусами, чтобы не платить за сообщения, которые не могут быть доставлены. Что такое HLR и зачем он нужен? HLR — это база данных оператора связи. В ней хранится информация об абоненте: активен ли номер, подключен ли к сети, поддерживает ли SMS. По запросу оператор отвечает, существует номер или нет. Это быстрая проверка перед отправкой — вы заранее видите, какие номера «мертвые». SMPP — открытый протокол для передачи коротких сообщений в телеком-отрасли. Через SMPP-шлюз вы отправляете SMS оператору, и через него же можно отправлять HLR-запросы. Шлюз принимает список номеров, запрашивает данные у оператора и возвращает ответ по каждому. Такой запрос обходится дешевле, чем отправка полноценного SMS на несуществующий номер, хотя точная цена зависит от провайдера. Если вы только настраиваете свой шлюз, обратите внимание на материал о том, как защитить SMPP-шлюз от взлома. Проверка номеров не должна открывать доступ посторонним. Как настроить HLR-фильтрацию через SMPP-шлюз Схема простая: сначала очищаете базу, потом отправляете сообщения. Вот пошаговый порядок для малого бизнеса без привлечения программиста. Проверьте, что ваш SMPP-провайдер поддерживает HLR-запросы. Обычно это отдельная опция в личном кабинете или дополнительная услуга. Выгрузите номера в формате MSISDN. Для Беларуси код страны — 375, номер начинается с операторского кода, плюс в начале не нужен. Например, 375291234567. Отправьте HLR-запрос. Способ зависит от шлюза: один провайдер использует специальный service_type, другой принимает обычный submit_sm с префиксом. Точную команду смотрите в документации. Получите ответ по каждому номеру. Шлюз вернет статус: номер существует, не существует, не в сети. Исключите из выборки номера со статусом «не существует». Запустите SMS-рассылку только по подтвержденным номерам. Последний шаг можно автоматизировать. Если шлюз умеет работать по правилам, настройте фильтр: при получении отрицательного HLR-ответа номер автоматически помечается в вашей базе как невалидный. Тогда каждая новая рассылка будет собирать только чистый список. Для надежности настройте резервный канал: если основной шлюз недоступен, HLR-запросы не пропадут. Инструкция — в статье как настроить резервный SMPP-канал и не терять SMS при сбое провайдера. Что отвечает HLR и что с этим делать Ответы HLR различаются в деталях у каждого оператора, но основные статусы одни и те же. Разберем их в таблице. Ответ HLRЧто означаетЧто делать Номер существует, в сетиАбонент активен, телефон включенОтправлять SMS Номер существует, не в сетиТелефон выключен или временно вне зоныОтправлять, но доставка может задержаться Номер не существуетОператор не нашел номер / номер не обслуживаетсяИсключить из рассылки Абонент в роумингеНомер активен, но тарификация может отличатьсяУчитывать при расчете бюджета Если в ответе «номер не существует», отправлять сообщение бессмысленно. Оператор все равно не доставит его, а деньги за отправку могут списаться. Чем DLR-аналитика дополняет HLR HLR работает до отправки, DLR — после. DLR (delivery report) — это уведомление о статусе доставки сообщения. Когда SMS уходит через SMPP-шлюз, оператор возвращает ответ: доставлено, просрочено, ошибка. DLR позволяет увидеть, сколько сообщений реально дошло. Если большая часть статусов — «просрочено», значит номера были вне сети или абоненты находились в роуминге. Если DLR постоянно возвращает ошибку после положительного HLR-ответа, стоит проверить, не блокирует ли оператор рассылку. Для интернет-магазинов и сервисов полезно настроить автоматическую выгрузку DLR-статусов в свою систему учета. Например, в 1С можно отмечать, что заказ доставлен или что клиент не получил уведомление. Пошаговую настройку смотрите в инструкции как настроить выгрузку статусов SMPP в 1С. Типичные ошибки при работе с HLR Проверять номера после того, как часть SMS уже отправлена. HLR нужно запускать до старта кампании, иначе часть бюджета уходит впустую. Не обновлять базу после получения статуса «не существует». Если вы один раз проверили номер и ничего не сделали с ним, в следующей рассылке он снова попадет в список. Отправлять HLR-запросы на номера, которые недавно подтверждались успешными доставками. Это лишние расходы и лишняя нагрузка на оператора. Игнорировать статус «не в сети» при срочных рассылках. Если сообщение должно прийти за минуты, а телефон выключен, оно задержится. Не сравнивать HLR и DLR. Если HLR говорит «номер живой», а DLR показывает ошибку доставки, значит, с номером что-то не так. Без сравнения вы не заметите проблему. HLR и DLR — это не разовые действия, а цикл. Один раз очистили базу, проверили доставку, через месяц повторили. Тогда расходы на SMS остаются контролируемыми. 3 шага, которые можно сделать на этой неделе: Запросите HLR-статусы для всех номеров в вашей базе и удалите те, которые получили ответ «не существует». Настройте автоматическое проставление HLR-статуса в вашей CRM или Excel-таблице, чтобы видеть актуальное состояние базы. После ближайшей рассылки откройте DLR и по каждому недоставленному сообщению решите, оставить номер для будущих кампаний или удалить. Такой подход сокращает количество сообщений, которые не доходят до адресата, и позволяет строить рассылки на реально работающих номерах. > Source: https://smpp.by/kak-proveryat-nomera-po-hlr-do-otpravki-sms --- # Работает ли RCS в Беларуси? Нет, не работает RCS (Rich Communication Services) в Беларуси не работает: операторы не подключили эту технологию, а Google не активировал её для нашей страны. Пользователи Android жалуются на неработающий RCS-чат, и это подтверждает, что надеяться на него не стоит. Если вы планировали использовать RCS для уведомлений — это пока невозможно. Для бизнеса это значит: остаётся проверенный канал SMS, который подключается через протокол SMPP. В статье разберём, почему RCS недоступен и как настроить альтернативу. Что такое RCS и почему он не работает? RCS — это протокол, который приходит на смену SMS. Он позволяет передавать изображения, видео, видеть статус доставки и подтверждения прочтения. Выглядит это как современный мессенджер, встроенный в стандартное приложение «Сообщения». Но в отличие от SMS, RCS требует поддержки оператора связи и серверов Google. Без них сообщения просто не уходят. В Беларуси ни один оператор — ни А1, ни МТС, ни Белтелеком — не разворачивал RCS-инфраструктуру. Поэтому функция отключена на уровне сети. Даже если на вашем смартфоне в настройках есть RCS, он не активируется. Почему в Беларуси не работает RCS? Для запуска RCS оператору нужно заключить соглашение с Google, установить специальное оборудование и настроить маршрутизацию. Это дорого и требует времени. В Беларуси операторы сконцентрировались на развитии собственных мессенджеров и банковских приложений, а RCS остался без внимания. Показательна мировая практика: даже там, где RCS запущен, пользователи регулярно жалуются на его работу. Например, в официальном сообществе Android есть темы «Не работает RCS-чат» — люди пишут о проблемах с подключением, недоставленных сообщениях и сброшенных сессиях. Значит, технология пока сырая, и в Беларуси её отсутствие не стоит считать критичной потерей. Что это значит для бизнеса? Если вы собирались использовать RCS-рассылки для акций или уведомлений, эту идею придётся отложить. RCS не работает, а значит, нет смысла вкладываться в его настройку. Зато есть работающая альтернатива — SMS. Она доставляется на любой телефон, не требует интернета и поддерживается всеми операторами. Для отправки больших объёмов сообщений есть протокол SMPP — он позволяет подключаться к SMS-центру напрямую и отправлять тысячи сообщений в минуту. Если вы уже используете SMS, обратите внимание на надёжность канала. При сбоях интернета или проблемах у одного из операторов сообщения могут теряться. Чтобы этого избежать, настройте резервный SMPP-канал — тогда система автоматически переключится на запасного провайдера. Пошаговая инструкция есть в этой статье: как настроить резервный SMPP-канал и не терять SMS при сбое провайдера. Сравнение RCS и SMS через SMPP КритерийRCSSMS через SMPP Работает в БеларусиНетДа Требуется интернет у получателяДаНет Поддержка операторовНетВсе Статусы доставкиЕсть, но нестабильноЕсть Как подключить SMPP Для подключения SMPP обычно нужно получить от провайдера логин, пароль и адрес сервера. Затем настроить соединение в вашей CRM или скрипте. Это стандартная процедура, с которой справится разработчик. Если у вас нет своего программиста, можно использовать готовые модули для популярных CMS и систем. При выборе провайдера обратите внимание на скорость доставки, наличие резервных серверов и стоимость. Для небольших объёмов подойдёт любой сервис, для крупных рассылок лучше выбирать того, кто специализируется на SMPP-трафике. Типичные ошибки Пытаться включить RCS на телефоне и ждать, что он заработает — в Беларуси это невозможно. Рассчитывать на RCS как на канал для бизнес-уведомлений в 2026 году — технология не запущена. Переводить все рассылки в мессенджеры, забывая, что не все клиенты ими пользуются. Не настраивать резервный канал SMPP — при сбое одного провайдера SMS перестают доходить. Что делать сегодня Если вы задумывались о каналах связи с клиентами, вот три шага, которые можно сделать прямо сейчас: Проверьте, поддерживает ли ваш оператор RCS (не поддерживает, но убедиться стоит). Выберите SMS-провайдера с SMPP-подключением и протестируйте отправку. Настройте резервный канал, чтобы не терять сообщения при сбоях. RCS в ближайшее время вряд ли появится в Беларуси, поэтому не тратьте время на эксперименты. Используйте то, что работает, — SMS и SMPP. > Source: https://smpp.by/rabotaet-li-rcs-v-belarusi-net-ne-rabotaet --- # Как защитить SMPP-шлюз от взлома: IP-фильтры и контроль доступа SMPP-шлюз — это техническая точка, через которую ваш сервер обменивается SMS с провайдером. Через него проходят коды подтверждения, уведомления о статусе заказа и служебные сообщения. Если шлюз взломают, злоумышленник сможет отправлять SMS от вашего имени или читать входящие. В статье — что сделать, чтобы этого не случилось: IP-фильтры, TLS, контроль доступа и проверка DLR-отчетов. Что такое SMPP-шлюз и почему он на виду? SMPP (Short Message Peer-to-Peer) — протокол для обмена SMS между вашей системой и сервером провайдера. Интернет-магазины используют его, чтобы мгновенно отправлять коды подтверждения при регистрации или оформлении заказа (источник 4). Протокол поддерживает одиночные и групповые сообщения, а также запросы на статус доставки (источник 4). Для бизнеса это значит, что через один шлюз идут и транзакционные SMS, и маркетинговые рассылки. Шлюз становится привлекательной целью: через него можно подписывать людей на платные сервисы или рассылать спам. Какие угрозы для SMPP-соединения стоит закрыть в первую очередь? Злоумышленнику не нужно взламывать ваш сервер. Достаточно узнать IP-адрес, порт и пароль от SMPP-аккаунта. Дальше он подключается как легитимный клиент и делает что хочет. Основные риски такие: Перехват трафика. Если соединение не зашифровано, логин и пароль можно вытащить из сетевого трафика. Подключение с постороннего IP. Если не ограничить список адресов, к шлюзу обратится кто угодно. Слабая аутентификация. Один общий пароль на всю компанию — это дыра, через которую проходят и бывшие сотрудники, и случайные подрядчики. Отсутствие контроля. Без DLR-отчетов и логов вы не узнаете, что SMS отправляются не вами, пока не придет счет. Как настроить IP-фильтры для SMPP-доступа? Первый шаг защиты — закрыть шлюз по IP. У каждого провайдера есть личный кабинет, где можно указать список разрешенных адресов. Внесите туда только те IP, с которых ваш сервер реально подключается к SMPP. Если у вас несколько офисов и статический IP не везде, используйте VPN или промежуточный сервер — главное, чтобы список был коротким и контролируемым. Как это выглядит на практике: Запросите у провайдера возможность задать белый список IP. Внесите IP вашего сервера (или диапазон, если используете облако). Проверьте, что с других адресов соединение отклоняется. Если провайдер не поддерживает IP-фильтры, это повод задуматься: возможно, стоит сменить поставщика. Базовая защита должна быть встроена, а не активироваться по вашему запросу. TLS-шифрование: как защитить SMS-трафик от перехвата? Протокол SMPP сам по себе не шифрует данные. Логин, пароль и текст сообщений идут в открытом виде, если не используется TLS. В 2026 году это недопустимо. Любой, кто имеет доступ к сети между вашим сервером и провайдером, может прочитать трафик. Поэтому при подключении обязательно выбирайте SMPP поверх TLS (обычно порт 8443 или другой, зависит от провайдера). Проверьте, поддерживает ли ваш провайдер TLS. Если да — настройте клиентское подключение с проверкой сертификата. Не отключайте проверку ради простоты: так вы теряете весь смысл шифрования. Особенно важно защищать OTP-коды — одноразовые пароли для входа. Перехваченный код позволяет злоумышленнику войти в аккаунт пользователя. Подробнее о том, как защитить OTP-коды, читайте в отдельной инструкции: как защитить OTP-коды от перехвата. Контроль доступа и DLR-отчеты: как заметить взлом Даже с IP-фильтрами и TLS нужно контролировать, что происходит со шлюзом. Используйте отдельные учетные записи для разных сервисов — например, для интернет-магазина и для маркетинговой платформы. Тогда, если одну учетку скомпрометируют, злоумышленник не получит доступ ко всем SMS. Регулярно проверяйте DLR-отчеты — статусы доставки. Если вы не отправляли SMS, а статусы появляются, это тревожный сигнал. У большинства провайдеров есть тестовый период, когда можно отправить тестовые SMS и проверить корректность статусов доставки в вашей системе (источник 1). Используйте его, чтобы настроить мониторинг. Настройте алерты: например, уведомление на почту, если количество отправленных SMS резко выросло. Это не требует программиста — достаточно стандартных функций в личном кабинете провайдера. МетодЧто даетСложность IP-фильтрыОграничивает список адресов, с которых разрешено подключениеНизкая: настраивается в кабинете провайдера TLSШифрует трафик, защищает логин, пароль и текст SMS от перехватаСредняя: нужно настроить клиент и проверить сертификаты Раздельные паролиОграничивает ущерб, если одна учетка скомпрометированаНизкая: создать отдельную учетку для каждого сервиса Мониторинг DLRПозволяет заметить несанкционированную отправку по статусамСредняя: потребуется настроить алерты или проверять логи Типичные ошибки при настройке SMPP-безопасности Общий пароль для всех сотрудников и сервисов. Смените на индивидуальные. Отключенный TLS ради экономии времени. Перехват пароля обойдется дороже. IP-фильтры не настроены, потому что «провайдер заботится». Не заботится. DLR-отчеты не проверяются. Взлом выглядит как обычный рост отправлений. Отсутствие ротации паролей. Меняйте их хотя бы раз в квартал. 3 шага, которые можно сделать сегодня: Проверьте, поддерживает ли ваш провайдер TLS. Если да — переведите подключение на зашифрованный порт. Задайте в личном кабинете белый список IP-адресов, с которых разрешено подключение к SMPP. Создайте отдельные учетные записи для каждого сервиса и настройте алерты на аномальный рост отправки SMS. > Source: https://smpp.by/kak-zaschitit-smpp-shlyuz-ot-vzloma --- # Как настроить резервный SMPP-канал и не терять SMS при сбое провайдера? Резервный SMPP-канал — это второе соединение с другим поставщиком SMS. Если основной шлюз перестанет отвечать, ваша система автоматически отправит сообщения через резервного. Так вы сохраните доставку кодов, заказов и уведомлений. В статье расскажу, как подключить второго SMPP-провайдера в Беларуси, настроить переключение и проверить, что схема действительно работает. Почему одного SMPP-провайдера мало? У любого онлайн-сервиса случаются сбои: сетевые проблемы, рост нагрузки, технические работы. Если бизнес зависит от SMS — коды подтверждения, уведомления о заказах, — простой канала означает потерянные сообщения и недовольных клиентов. Резервное подключение решает эту проблему без больших вложений. Многие провайдеры дают бесплатный тестовый доступ, а платите вы только за реальную отправку. Дополнительный канал нужен не только для критичных транзакций. Он выручает при массовых рассылках: если основной провайдер не справляется с объемом, вы переносите часть трафика на резервного. Как устроена схема резервирования SMPP? У вас два SMPP-соединения: основное и резервное. Приложение отправляет через основное, но следит за его состоянием. Если соединение рвется или шлюз не отвечает на enquire_link, система перенаправляет трафик на резервное. Переключение реализуют двумя способами: На стороне вашего кода: программа держит два подключения и сама выбирает активный канал. Через агрегатора: сервис принимает сообщения и распределяет их по нескольким провайдерам, выполняя failover за вас. Для малого бизнеса проще первый вариант, если есть разработчик или CRM с поддержкой нескольких SMPP-аккаунтов. Если нет — агрегатор снимает заботы по маршрутизации. Как подключить второго SMPP-провайдера: пошаговый план Выберите второго провайдера. Убедитесь, что он поддерживает SMPP и может обеспечить нужный вам объем отправки. Если сложно оценить, посмотрите статью о выборе SMPP-throughput для бизнеса в Беларуси. Запросите параметры подключения: сервер, порт, режим transceiver, TON/NPI и лимиты отправки. Обычно их присылают вместе с логином и паролем. Добавьте резервное соединение в вашу систему. В большинстве SMPP-библиотек это второй объект клиента. Настройте автоматическое переключение. Проверяйте соединение через регулярный интервал, например, отправкой enquire_link. Если ответа нет или при отправке возникает ошибка — меняйте активный канал. Проведите тест: отправьте SMS через основной канал, затем заблокируйте его и убедитесь, что сообщение уходит через резервный. Проверьте DLR-отчеты — статусы доставки должны корректно возвращаться. Как проверить, что резервный канал сработает? Настроить резервное соединение недостаточно. Нужно регулярно тестировать сценарий переключения. Раз в месяц вручную отключайте основной канал — в панели провайдера или на своей стороне. Отправляйте тестовое SMS на свой номер и проверяйте, что оно приходит. Настройте алерты в Telegram или на почту, чтобы узнавать о сбое основного канала. Проверяйте DLR-статусы для обоих провайдеров. Если резервный не отдает DLR, вы не увидите проблемы с доставкой. Типичные ошибки Настроили резервный канал, но не проверили его реальной отправкой. В момент сбоя выясняется, что доступы не работают. Подключили двух провайдеров, но через один и тот же шлюз. Сбой общего узла останавливает оба канала. Не настроили автоматическое переключение. Если сбой случился ночью, до утра клиенты не получат SMS. Не учли лимиты резервного провайдера. У него throughput ниже, и массовая рассылка встанет в очередь. Игнорируют DLR. Без статусов доставки невозможно понять, что сообщение не ушло. Если самостоятельная настройка кажется сложной, используйте платформы, которые берут на себя маршрутизацию через резервные каналы. Примеры и частые ошибки разобраны в обзоре автоматизации транзакционных SMS в 2026 году. 3 шага, которые можно сделать сегодня: Запросите у вашего провайдера тестовый доступ к SMPP, если еще не работаете по этому протоколу. Напишите второму провайдеру, чтобы получить параметры подключения: сервер, порт, режим transceiver, TON/NPI. Подключите резервное соединение и отправьте контрольное SMS, чтобы убедиться, что схема работает. > Source: https://smpp.by/kak-nastroit-rezervnyy-smpp-kanal-i-ne-teryat-sms-pri-sboe-provaydera --- # Как настроить выгрузку статусов SMPP в 1С для интернет-магазина После отправки SMS через SMPP-шлюз протокол возвращает статусы доставки (DLR). Если выгружать их в систему учёта 1С, можно автоматически отмечать оплаченные заказы, фиксировать неверные номера и не звонить клиенту с вопросом «пришло ли сообщение?». Статья объясняет, как построить такую схему для небольшого магазина без программиста в штате. Почему статусы доставки важны для учёта заказов? Когда интернет-магазин отправляет клиенту уведомление о статусе заказа, важно знать, дошло ли оно. SMPP-шлюз возвращает коды: DELIVRD (доставлено), EXPIRED (просрочено), UNDELIV (не доставлено), REJECTD (отклонено оператором). Если эти данные попадают в 1С, менеджер видит, что SMS получена, и не тратит время на ручную проверку. Для магазина с 20–50 заказами в день это экономит 2–3 часа в неделю. Протокол SMPP версий 3.4 и 5.0 поддерживает подробные коды ошибок (источник dev.sms-assistent.by). В SMPP 5.0, если команда SUBMIT_SM_RESP возвращает ошибку, длина PDU составляет 16 октетов (источник BSG). Это значит, что парсер должен уметь обрабатывать разную длину пакетов. Но для малого бизнеса чаще используют SMPP 3.4 — с ним совместимы почти все белорусские операторы. Что нужно для интеграции SMPP и 1С? Минимальный набор: SMPP-шлюз с возможностью отправки и получения DLR (обычно провайдер SMS даёт доступ к шлюзу); скрипт-посредник (например, на PHP или Python), который забирает статусы из шлюза и передаёт их в 1С через HTTP-запросы; обработка в 1С, принимающая POST-запросы и обновляющая документы (заказы, счета). Если у вас нет возможности писать скрипт, можно использовать готовые модули обмена, которые некоторые SMS-провайдеры предлагают для 1С. Но чаще нужен простой посредник. Вот как он работает. Схема работы: от отправки до отметки в 1С Отправка. Вы создаёте документ «Отправка SMS» в 1С. Обработка вызывает скрипт, который через SMPP отправляет сообщение и запоминает message_id. Получение DLR. SMPP-шлюз асинхронно отправляет скрипту уведомление о доставке (или ошибке) с тем же message_id. Передача в 1С. Скрипт передаёт в 1С POST-запрос с JSON: {"message_id":"...","status":"DELIVRD","timestamp":"..."}. Обновление статуса. В 1С обработчик находит заказ по message_id (или по номеру телефона+времени) и проставляет флаг «SMS доставлена» или «Ошибка доставки». Всё это происходит за 1–3 секунды после фактической доставки. Для интернет-магазина такой подход позволяет сразу видеть, что клиент получил уведомление об оплате или отгрузке. Какие статусы стоит обрабатывать? Не все коды нужны в учёте. Вот таблица статусов, которые имеют практический смысл для магазина. Код статусаЗначениеЧто делать в 1С DELIVRDСообщение доставленоОтметить заказ как «Уведомление отправлено» UNDELIVНе доставлено (номер неверный, абонент недоступен)Пометить контакт для проверки; предложить другой способ связи EXPIREDИстекло время жизни SMSПохоже на UNDELIV — обновить телефон клиента REJECTDОтклонено оператором (спам, блокировка)Проверить текст сообщения или имя отправителя ACCEPTDПринято шлюзом, но ещё не доставленоНичего не делать; ждать финального статуса Для автоматизации достаточно обрабатывать только DELIVRD, UNDELIV и REJECTD. Остальные можно логировать, но не влиять на учёт. Типичные ошибки при настройке выгрузки Не сопоставлен message_id. Если скрипт не сохраняет связь между отправленным сообщением и заказом, пришедший DLR не к чему привязать. Решение — передавать в SMPP дополнительный параметр (TLV), например номер заказа. Дубликаты при повторной отправке. Если скрипт не проверяет, был ли уже обработан статус, 1С получит два одинаковых запроса. В обработчике 1С стоит проверять по уникальному message_id. Игнорирование кодов ошибок SMPP. Протокол возвращает не только финальный статус, но и промежуточные ошибки (см. источник dev.sms-assistent.by). Не учитывая их, можно потерять сообщения. Слишком высокая частота запросов к 1С. Если отправка идёт потоком, скрипт может завалить 1С HTTP-запросами. Лучше буферизовать статусы по 10–20 штук и передавать пачкой раз в минуту. Нет обработки таймаутов. Если скрипт не получил DLR в течение 24 часов, стоит считать сообщение недоставленным и повторять попытку. 3 шага, которые можно сделать сегодня Проверьте, возвращает ли ваш SMS-провайдер DLR и какие коды он использует. Большинство поддерживают стандарт SMPP 3.4 с кодами, описанными выше. Настройте простой скрипт-посредник, который забирает DLR из шлюза и складывает их в файл или базу данных. Это можно сделать за 2–3 часа на любом доступном языке. Добавьте в 1С обработчик HTTP-запроса, который принимает статусы и обновляет нужные документы. Пример кода для 1С:Предприятие 8.3 есть в типовых конфигурациях. Полезные ссылки: SMPP-статусы: как читать DLR и не тратить деньги на мёртвые номера, Как настроить транзакционные уведомления и избежать дублей сообщений. > Source: https://smpp.by/kak-nastroit-vygruzku-statusov-smpp-v-1s-dlya-internet-magazina --- # Конкатенированные SMS через SMPP: настройка без потери целостности Если текст SMS превышает 160 символов (или 70 для кириллицы), оператор разбивает его на части. Но без правильного заголовка в протоколе SMPP получатель увидит отдельные фрагменты вместо одного сообщения. В статье — как настроить конкатенацию через UDH, проверить сборку и не потерять смысл. Материал для разработчиков и бизнеса, которые подключают SMS-трафик через SMPP. Что такое конкатенированное SMS и зачем оно бизнесу Обычное SMS — 140 байт на сообщение. В кодировке GSM 7-bit это 160 знаков, в UCS-2 (кириллица) — 70. Длинный текст оператор режет на сегменты по 153 байта (134 для кириллицы). Без служебного заголовка UDH (User Data Header) каждый сегмент — самостоятельное SMS. Получатель видит несколько сообщений, а не одно цельное. Конкатенированные SMS решают эту проблему. В UDH прописывается идентификатор сборки, номер сегмента и общее количество частей. Телефон склеивает их в один текст. Для бизнеса это значит: полное описание акции, инструкция на 4–6 сегментов, юридический дисклеймер — всё в одном сообщении. Как работает конкатенация в SMPP В команде submit_sm есть поле data_coding (кодировка) и необязательное поле message_payload. Но для конкатенации используется именно short_message с префиксом в виде UDH. UDH — это байты в начале сообщения, которые оператор не показывает пользователю. Структура UDH для конкатенации: длина заголовка (обычно 5 байт); идентификатор элемента информации (0x00 — конкатенация 8-битная, 0x08 — 16-битная); длина данных (3 байта для 8-бит, 4 для 16-бит); идентификатор сообщения (1 байт для 8-бит, 2 для 16-бит); общее количество сегментов (1 байт); номер текущего сегмента (1 байт, начиная с 1). Пример: для 8-битной конкатенации (обычно достаточно для большинства операторов Беларуси) UDH выглядит так: 05 00 03 XX MM NN, где XX — идентификатор сообщения, MM — число сегментов, NN — номер сегмента. Весь short_message = UDH + полезный текст. Практические советы по настройке Выбор кодировки: GSM 7-bit или UCS-2 Если текст содержит только латиницу, цифры и спецсимволы GSM 7-bit — экономьте. Один сегмент — до 153 символа (160 минус 7 байт UDH). Для кириллицы нужен UCS-2: один сегмент — 67 символов (70 минус 3 байта UDH). Разница в стоимости — каждый сегмент тарифицируется как отдельное SMS. Подробнее о выборе кодировки — в статье UCS-2 или GSM 7-bit: что выгоднее для SMS через SMPP. Идентификатор сообщения при 16-битной конкатенации Если ваш трафик превышает 256 уникальных сборок в секунду, используйте 16-битный UDH (0x08). Это важно для высокообъёмных рассылок. Большинство SMPP-провайдеров поддерживают оба варианта. Уточните в документации вашего сервиса. Проверка целостности на тестовом номере Отправьте себе SMS с текстом, заведомо длиннее 5–6 сегментов. Проверьте: приходит ли одно сообщение? Порядок сегментов? Не дублируются ли части? Если видите разбивку — перепроверьте UDH: правильная ли нумерация сегментов, не пересекаются ли идентификаторы с другими сообщениями. Типичные ошибки при конкатенации через SMPP Пропущен UDH — оператор не знает, что нужно склеивать. Получатель видит «куски». Неправильный номер сегмента — например, начинается с 0. По стандарту — с 1. Разная кодировка в сегментах — один сегмент в GSM 7-bit, другой в UCS-2. Телефон не сможет собрать. Превышение лимита сегментов — большинство операторов поддерживают до 7–10 сегментов. Длиннее — риск, что сообщение не дойдёт целиком. Игнорирование поля message_payload — некоторые SMPP-библиотеки пытаются упаковать длинный текст в message_payload, но не все операторы его поддерживают. Надёжнее использовать UDH в short_message. Дублирование идентификатора — если отправить два разных сообщения с одинаковым ID, сегменты перемешаются. Сколько сегментов можно отправить и как это влияет на стоимость Кодировка Макс. символов в 1 сегменте (с UDH) Макс. сегментов (рекомендуется) Пример: текст 300 знаков (кириллица) GSM 7-bit 153 7 2 сегмента UCS-2 (кириллица) 67 5 5 сегментов Каждый сегмент тарифицируется как отдельное SMS. Для кириллического текста в 300 знаков выйдет 5 SMS по цене одной короткой. Если бюджет ограничен — перепишите текст короче или используйте латиницу (где это уместно). 3 шага, которые можно сделать сегодня: Соберите UDH-заголовок в вашей SMPP-библиотеке (вручную или через готовый класс). Отправьте тестовое сообщение длиной 400–500 символов на свой номер. Проверьте DLR: пришёл ли финальный статус DELIVERED и не было ли ошибок сегментации. Полезные ссылки: UCS-2 или GSM 7-bit: что выгоднее для SMS через SMPP. > Source: https://smpp.by/konkatenirovannye-sms-cherez-smpp --- # Проверка имени отправителя через SMPP: что делать, если регистрация не проходит Если ваш шлюз настроен, тестовое SMS уходит, а боевой трафик блокируется — проблема чаще всего в имени отправителя. Провайдеры сверяют его с заявкой: несоответствие формата, отсутствие регистрации или конфликт с чужим брендом — и сообщение не дойдёт. В статье разберём, почему регистрация не проходит и как исправить ситуацию без долгих переписок с техподдержкой. Зачем нужна регистрация имени отправителя при SMPP‑подключении? Протокол SMPP сам по себе не проверяет, кому принадлежит номер или буквенное имя. Эту проверку делает SMS-центр (SMSC) провайдера. Если вы шлёте трафик с незарегистрированным именем, SMSC его отклоняет — вы получаете статус «rejected» или ошибку в DLR отчёте. Регистрация закрывает три риска: отправка под чужим брендом (кто-то может представиться вашим названием), блокировка из-за дубликата (то же имя уже занято) и несоответствие стандартам спецификации SMPP версии 3.4 (Quicktel, smsp.by). Какие ошибки возникают при проверке имени? Чаще всего отказ приходит с кодом, который расшифровывается в спецификации SMPP 3.4 как «invalid source address» или «source address ton/npi mismatch». В ответах от SMSC встречаются коды 0x0000000A (INVSRCADR) и 0x0000000B (INVDSTADR). Причина может быть в формате: буквенное имя длиннее 11 символов или номер начинается не с той цифры. Иногда провайдер требует, чтобы имя совпадало с договором — одна лишняя точка или заглавная буква, и регистрация не пройдёт. Как проверить регистрацию имени отправителя? Процедура обычно включает три шага. Сначала вы подаёте заявку в личном кабинете провайдера или через API, указывая имя (до 11 символов латиницей или кириллицей в UTF-8). Затем провайдер проверяет его через SMSC — часто это занимает от нескольких минут до суток. Наконец, вы получаете подтверждение: на некоторые платформы приходит ответное SMS на указанный номер верификации. Если у вас интеграция через SMPP-шлюз, можно отправить тестовое сообщение на свой номер и проверить DLR — статус «DELIVRD» означает, что имя принято. Подробнее о контроле статусов доставки читайте в статье про настройку SMPP-шлюза. Типичные ошибки при регистрации имени отправителя Имя длиннее 11 символов (латиница) или 7 символов (кириллица в UTF-8). Использование пробелов, дефисов или спецсимволов, кроме подчёркивания. Имя уже занято другим клиентом провайдера или зарезервировано оператором. Несовпадение TON (Type of Number) — для буквенного имени обычно TON=5, для номера TON=1. Отсутствие верификационного SMS — на некоторых шлюзах нужно ответить на тестовое сообщение. Ошибка в параметре source_addr_ton/npi в SMPP-пакете: если вы указали «альфа» (буквы), а в системе числовой формат, SMSC отклонит пакет. Что делать, если регистрация не проходит: пошаговая инструкция Проверьте формат имени: латиница до 11 символов, без пробелов. Кириллица в UTF-8 — до 7 символов. Уточните TON и NPI: для буквенного отправителя установите source_addr_ton=5, source_addr_npi=0. Для короткого номера — TON=1, NPI=1. Запросите лог ошибок у провайдера или в SMPP-клиенте. Код ошибки указан в PDU-пакете (например, command_status). Расшифровку кодов ищите в спецификации SMPP версии 3.4 или в документации вашего шлюза. Попробуйте другое имя: если ваше брендовое название занято, используйте вариант без торговой марки (например, «MAGAZ» вместо «MAGAZIN»). Свяжитесь с техподдержкой — провайдер может зарезервировать имя вручную или убрать дубль. Как избежать отказа при регистрации на этапе интеграции Лучший способ — заранее договориться с провайдером о доступных форматах. Некоторые SMS-центры поддерживают только цифровые имена (короткие номера), другие — только буквенные. Уточните это перед подачей заявки. Также сразу проверьте, есть ли у вашего шлюза функция динамического выбора source_addr_ton: некоторые SMPP-библиотеки по умолчанию ставят TON=1 (номер), а вам нужно TON=5 (альфа). Если вы используете готовое решение для отправки SMS, в документации обычно описан параметр «source address type». После успешной регистрации протестируйте сценарий с отправкой на 2-3 номера разных операторов и проверьте DLR — это позволит выявить проблемы с доставляемостью не только из-за имени, но и из-за маршрутизации. Для оптимизации маршрутизации и throughput можно обратиться к провайдеру — он предложит настройку под ваш трафик (smsp.by). 3 шага, которые можно сделать сегодня: Проверьте в своих SMPP-логах последние 10-20 пакетов с ошибкой «INVSRCADR» — выпишите source_addr_ton и source_addr_npi. Сверьте длину имени отправителя с требованиями вашего провайдера (обычно до 11 символов латиницей). Отправьте тестовое SMS на свой номер через тот же шлюз — если DLR вернет «DELIVRD», регистрация корректна; если статус отличается, перепроверьте формат имени. > Source: https://smpp.by/proverka-imeni-otpravitelya-cherez-smpp --- # Персонализация SMS без CRM: подстановка параметров через SMPP Чтобы отправлять клиентам сообщения, где подставляются имя, номер заказа или сумма, необязательно покупать CRM. Достаточно прямого SMPP-соединения и файла с переменными. Эта статья — инструкция для микро-, малого и среднего бизнеса Беларуси: как за час настроить подстановку параметров через SMPP и не переплачивать за лишние системы. Вы сможете сделать это самостоятельно, без программистов и дорогих сервисов. Как работает подстановка параметров в SMS через SMPP? SMPP — это протокол, по которому ваш софт или скрипт напрямую общается с SMS-центром оператора. Вместо того чтобы записывать каждое сообщение вручную, вы передаёте шаблон текста с «метками» — например {name} или {order_id}. Отдельно прикладываете список значений: для каждого номера — своя строка с данными. Сервер на ходу заменяет метки на реальные цифры и слова. Никакой CRM не нужно. Данные можно брать из обычного CSV-файла, Google Sheets или простого скрипта на PHP/Python. Для малого бизнеса это означает: сделали заказ → выгрузили строки из учётной системы → отправили SMS с именем клиента и составом заказа. Пример: шаблон «{first_name}, ваш заказ №{order_id} готов к выдаче». Для Ивана и заказа 1234 получается «Иван, ваш заказ №1234 готов к выдаче». Для Ольги и заказа 5678 — «Ольга, ваш заказ №5678 готов к выдаче». Всё. Что нужно настроить на стороне SMPP, чтобы подстановка работала? Для персонализации через SMPP потребуется три вещи: соединение, правильная кодировка и контроль доставки. 1. Получить SMPP-доступ и уложиться в таймаут Вы заключаете договор с поставщиком SMPP-услуг (агрегатором). Вам выдаются логин, пароль и IP-адрес сервера. При подключении сервер даёт 10 секунд, чтобы отправить команду BIND_TRANSMITTER или BIND_TRANSCEIVER. Если опоздать — соединение разрывают. Это стандартное требование, оно указано в документации к SMPP-серверу. 2. Выбрать кодировку: кириллица требует UCS-2 Если ваши SMS содержат белорусские или русские буквы, нужно указывать кодировку UCS-2 (data_coding=8). Латинские цифры и символы укладываются в GSM 7-bit (data_coding=0), что даёт до 160 знаков на одно SMS. Кириллица в UCS-2 занимает 70 знаков на сегмент, поэтому длинное сообщение может разбиться на несколько — это влияет на стоимость. Детально разница разобрана в статье UCS-2 или GSM 7-bit: что выгоднее для SMS через SMPP. Если ошибиться с кодировкой, вместо «Прывітанне» клиент увидит «?????????». 3. Настроить обработку DLR, чтобы не платить за мёртвые номера DLR (Delivery Report) — это статус доставки. Вы получаете отчёт: доставлено, не доставлено, просрочено, отклонено. Без анализа DLR вы будете платить за SMS на несуществующие или неактивные номера. Как читать DLR и экономить — в материале SMPP-статусы: как читать DLR и не тратить деньги на мёртвые номера. Пример настройки для микробизнеса в Беларуси Допустим, вы — мастер по ремонту обуви в Витебске. Ведёте учёт заказов в Excel. Клиент сдал пару, вы записали его имя «Сяргей» и номер заказа «В-45». Хотите отправить SMS: «Сяргей, заказ №В-45 готов. Забрать до 20:00». Без CRM это делается так: Экспортируете из Excel два столбца: телефон, имя, номер заказа, например в CSV. Пишете скрипт (или используете готовую утилиту), который читает CSV и шлёт каждую строку через SMPP с текстом {name}, заказ №{order} готов. Указываете кодировку UCS-2, так как имена и город — кириллица. После отправки проверяете DLR: если статус «DELIVRD» — всё ок, если «UNDELIV» — номер недоступен, не платите за повтор. Всё это без дорогих CRM-систем, только SMPP-доступ и пара строк кода. Для тех, кто хочет автоматизировать цепочки (напоминание, благодарность, повтор), есть пошаговая настройка триггерных SMS-цепочек без CRM для сервисного бизнеса. Типичные ошибки при подстановке параметров через SMPP Неправильная кодировка. Кириллица в GSM 7-bit превращается в знаки вопроса. Проверяйте data_coding=8. Слишком длинные SMS. Одно кириллическое сообщение — 70 символов. Если текст больше, он режется на части, каждая оплачивается отдельно. Укладывайтесь в лимит или используйте латиницу. Игнорирование DLR. Вы платите за отправку, даже если номер мёртвый. Без анализа DLR бюджет утекает впустую. Пропуск таймаута BIND. 10 секунд на подключение — стандарт. Если ваш скрипт делает долгую инициализацию, соединение рвётся. Передача пустых значений. Если в CSV вместо имени стоит пустая ячейка, клиент получит «, ваш заказ...». Добавьте проверку на пустоту. Тестирование на живых номерах. Всегда сначала пробуйте на свой собственный номер, проверяйте подстановку и кодировку. 3 шага, которые можно сделать сегодня: Получить SMPP-логин у SMS-агрегатора. Если ещё нет — заключите договор и настройте соединение с учётом таймаута 10 секунд. Подготовить файл с параметрами (имя, номер заказа, сумма) в формате CSV. Убедитесь, что кодировка файла — UTF-8. Отправить тестовое SMS с подстановкой на свой мобильный. Проверьте отображение кириллицы и корректность переменных. После этого можно внедрять персонализированные рассылки для напоминаний, подтверждений заказов и акций — без CRM и лишних затрат. > Source: https://smpp.by/personalizatsiya-sms-bez-crm --- # UCS-2 или GSM 7-bit: что выгоднее для SMS через SMPP Выбор кодировки напрямую влияет на количество SMS-сообщений, которое вы отправляете, и, соответственно, на бюджет. Если вы используете SMPP-подключение для рассылок, то разница между GSM 7-bit и UCS-2 может составлять до 40–50% стоимости трафика. В этой статье разберём, как кодировка работает, когда экономия реальна, а когда лучше переплатить, чтобы не потерять клиента. Как кодировки SMPP влияют на длину SMS и цену? Протокол SMPP передаёт текст сообщения в разных форматах. Базовый — GSM 7-bit, он поддерживает латиницу, цифры и ограниченный набор символов (вроде $, %, &). Одно сообщение в GSM 7-bit вмещает до 160 символов. Если текст длиннее, SMPP разбивает его на сегменты — каждый до 153 символов (остаток занимают заголовки). Соответственно, одно сообщение в 300 символов займёт 2 сегмента, и тарифицироваться будет как 2 SMS. Кодировка UCS-2 (она же UTF-16) используется для кириллицы, эмодзи и других нелатинских символов. Одно сообщение в UCS-2 вмещает только 70 символов. Сегмент — 67 символов. То есть 300-символьное сообщение на русском языке — это уже 5 сегментов. Платить придётся за 5 SMS вместо 2. Для малого бизнеса, который отправляет тысячи сообщений в месяц, разница ощутима. Если ваша база состоит из русскоязычных клиентов, каждый текст на кириллице стоит примерно в 2,5 раза дороже, чем аналогичный на латинице. Но латиница часто выглядит неестественно для белорусской аудитории — это снижает доверие. Когда использовать GSM 7-bit, а когда UCS-2? Однозначного ответа нет. Всё зависит от содержания сообщения и канала связи. Транзакционные уведомления (код подтверждения, статус заказа) — часто используют латиницу и цифры. Если ваш текст помещается в латинский алфавит (например, “Your code: 4821”), GSM 7-bit идеален. Сообщение влезает в один сегмент, экономия на каждую тысячу отправок составит 60–70% по сравнению с UCS-2. Маркетинговые рассылки на русском — кириллица неизбежна. Но если сообщение короткое (до 70 символов), разницы в сегментах нет: одно сообщение и в GSM 7-bit, и в UCS-2. Поэтому короткие фразы вроде “Акция! Скидка 20%” можно смело писать кириллицей без потери в цене. Сообщения с эмодзи — только UCS-2. Смайлик может удвоить количество сегментов, поэтому эмодзи стоит использовать только в маркетинге, когда важна эмоция, а не экономия. Таблица сравнения: GSM 7-bit vs UCS-2 ПараметрGSM 7-bitUCS-2 Максимальная длина одного сообщения160 символов70 символов Длина сегмента153 символа67 символов Поддерживает кириллицуНетДа Поддерживает эмодзиНетДа Стоимость 300-символьного сообщения (в сегментах)2 сегмента5 сегментов Когда выгодноЛатинские тексты, коды, короткие цифрыКороткие кириллические фразы до 70 символов, эмодзи Типичные ошибки при выборе кодировки Писать кириллицу в GSM 7-bit. Некоторые SMPP-шлюзы автоматически переключаются на UCS-2, если находят неподдерживаемый символ. Вы думаете, что экономите, а фактически платите за UCS-2. Лучше явно указать кодировку в настройках. Использовать латиницу для длинных сообщений. Если текст на латинице превышает 160 символов, он всё равно разбивается на сегменты. Иногда выгоднее сократить текст, чем платить за 2 сегмента. Не проверять длину в символах. Одна запятая или пробел считаются символом. Всегда считайте точное количество символов до отправки, особенно в автоматических скриптах. Ставить эмодзи в транзакционные SMS. Смайлик переводит всё сообщение в UCS-2 и может удвоить количество сегментов. В кодах или уведомлениях эмодзи не нужны, а цена за них высокая. Полагаться на «автовыбор кодировки» в SMPP. Некоторые SMSC (SMS-центры операторов) могут самостоятельно переключать кодировку, не предупреждая вас. При интеграции через SMPP лучше явно указывать data_coding (0x00 для GSM 7-bit, 0x08 для UCS-2). Почему для Беларуси вопрос кодировки особенно актуален? Основные операторы — MTS, life, A1 — работают со стандартными SMPP-соединениями. Но белорусские абоненты привыкли получать SMS на русском или белорусском языке. Если ваш бизнес обслуживает клиентов в Минске, Гомеле, Бресте или других городах, вы почти всегда используете кириллицу. Единственный способ сэкономить — отправлять короткие сообщения, которые укладываются в 70 символов. Тогда неважно, какая кодировка: сегмент один. Если же текст длиннее, можно разбить его на две короткие SMS, но каждая будет тарифицироваться отдельно. Иногда выгоднее сделать два коротких сообщения, чем одно длинное в UCS-2, которое займёт 3–4 сегмента. Подробнее о том, как именно кодировка меняет стоимость, читайте в статье «Как кириллица и латиница в SMS через SMPP меняют стоимость». Практический совет: как рассчитать сегменты до отправки Большинство SMPP-библиотек и систем позволяют увидеть количество сегментов. Если вы пишете скрипт самостоятельно, используйте формулу: Для GSM 7-bit: ceil(длина_текста / 153) Для UCS-2: ceil(длина_текста / 67) Перед отправкой проверяйте, сколько сегментов получится. Это легко сделать в любом онлайн-калькуляторе длины SMS или прямо в коде. Если вы часто отправляете сообщения на русском языке длиной 100–150 символов, рассмотрите вариант сокращения текста. Уберите лишние приветствия или подпись — иногда 10–15 символов экономят целый сегмент. Для массовых маркетинговых рассылок такая оптимизация может снизить расходы на 20–30%. Полезные ссылки: «Оптимизация расходов на SMS-трафик: практические шаги для бизнеса Беларуси», «SMPP или API: что выгоднее для SMS в Беларуси». 3 шага, которые можно сделать сегодня: Проверьте, какую кодировку вы используете в настройках SMPP-шлюза — явно укажите data_coding. Посчитайте среднюю длину ваших сообщений в символах; если она превышает 70, сократите текст хотя бы до 70 или до 153 (если используете латиницу). Протестируйте отправку короткого кириллического сообщения (до 70 символов) — сравните стоимость с длинным (например, 150 символов) и зафиксируйте разницу в бюджете. Правильный выбор кодировки — не техническая деталь, а прямая экономия денег. Начните с простого: считайте сегменты и не позволяйте SMPP-шлюзу решать за вас. > Source: https://smpp.by/ucs-2-ili-gsm-7-bit --- # Какой SMPP-throughput нужен вашему бизнесу в Беларуси? Throughput — это скорость отправки SMS через SMPP-соединение, измеряемая в сообщениях в секунду. Для микро-, малого и среднего бизнеса в Беларуси выбор правильного throughput напрямую влияет на время доставки, бюджет и стабильность рассылок. В статье разберём, как рассчитать необходимую скорость, избежать типичных ошибок и не переплачивать за избыточный трафик. Что такое throughput и почему он важен для белорусского бизнеса? Throughput (пропускная способность) определяет, сколько SMS ваш SMPP-клиент может отправить за секунду. Если throughput слишком мал, сообщения будут стоять в очереди — клиенты получат их с задержкой. Если завышен — вы платите за ресурс, который не используете. Для бизнеса в Беларуси, где стабильность интернет-соединения может варьироваться, правильный throughput снижает риск обрывов связи с SMSC. Как указано в документации SevenTech, при нестабильном соединении или неверной конфигурации соединение с SMSC может прерываться или не устанавливаться вовсе. Поэтому throughput нужно выбирать не «на глаз», а под реальный профиль нагрузки. Как рассчитать нужный throughput: пошаговый подход Сначала оцените суточный объём рассылок. Например, 500 сообщений в день или 10 000. Затем определите окно отправки — за какой период вы хотите разослать весь объём. Если отправляете за час, то throughput = объём / 3600 секунд. Для 500 сообщений за час нужно около 0,14 msg/sec — фактически любой SMPP-шлюз справится. Но для 10 000 за час потребуется уже ~2,8 msg/sec. Однако на практике учитывайте пиковые нагрузки: акционные рассылки, срочные уведомления. Заложите запас 20–30%. Также помните, что длинные сообщения (кириллица через data_coding=8) дробятся на сегменты, и каждый сегмент считается отдельным сообщением. Как указано в требованиях SevenTech, для латиницы используйте data_coding=0, для кириллицы — data_coding=8. При кириллице длинное SMS может занимать 2–3 сегмента, что увеличивает фактический throughput в пересчёте на «человеческие» сообщения. Уточните у провайдера, поддерживает ли он автоматическое сегментирование, или это нужно делать на стороне клиента (согласно базе знаний ePochta SMS, некоторые сервера требуют цельное длинное сообщение, другие — сегментирование). Типичные ошибки при настройке throughput Завышенный throughput без теста. Выставили 100 msg/sec, а фактически отправляете 5 — провайдер может применить «полицейского» и сбросить соединение. Игнорирование data_coding. Отправляете кириллицу с coding=0 — сообщения приходят кракозябрами. Или наоборот, латиницу с coding=8 — тратите лишние сегменты. Неправильная обработка delivery-репортов. DLR тоже «съедают» throughput. Если не фильтровать их, можно перегрузить канал. Отсутствие мониторинга. Не видите, что очередь растёт? Значит, throughput не хватает. Без логов вы узнаете об этом только от клиентов. Путаница между «тестовым» и «рабочим» трафиком. После проверки сценариев нужно переключаться на реальные объёмы. Если оставить тестовые лимиты, рабочие сообщения будут отбрасываться с кодами ошибок превышения лимитов скорости (как указано в статье на Хабре). Почему стоит проверить throughput до запуска коммерческих рассылок Даже после расчётов реальная пропускная способность зависит от вашего интернет-канала, настроек маршрутизации и SMSC. Рекомендуется провести нагрузочное тестирование: отправьте несколько тысяч сообщений с разными data_coding и замерьте время доставки. Обратите внимание на delivery-репорты — они покажут, все ли SMS дошли. Если обнаружили, что throughput проседает, проверьте конфигурацию соединения: IP-адрес, порт, аутентификацию (system_id и пароль). Ошибки установки соединения часто возникают из-за неверных учётных данных или блокировки порта фаерволом. Также убедитесь, что вы используете правильный тип соединения: transmitter (только отправка), receiver (только получение DLR) или transceiver (оба направления). Для большинства бизнес-задач достаточно transceiver. 3 шага, которые можно сделать сегодня Рассчитайте минимальный throughput под свой типичный объём и пиковую нагрузку. Учтите среднюю длину сообщений и кодировку. Проведите тестовый прогон с этим throughput на небольшом объёме (100–500 сообщений). Замерьте время доставки и количество DLR. Настройте мониторинг очереди и ошибок соединения. Если видите код ошибки, связанный с превышением лимита скорости — значит, нужно либо снизить throughput, либо договориться с провайдером о его увеличении. Если у вас остались вопросы по расчёту или настройке, обратитесь к технической поддержке вашего SMPP-провайдера — они помогут оптимизировать throughput и маршрутизацию под вашу нагрузку. Полезные материалы по смежным темам: Как повысить доставляемость SMS в Беларуси: настройка SMPP‑шлюза, SMPP против HTTP‑шлюзов: скорость SMS для бизнеса Беларуси и SMPP или API: что выгоднее для SMS в Беларуси. > Source: https://smpp.by/kakoy-smpp-throughput-nuzhen-vashemu-biznesu-v-belarusi --- # Как малому бизнесу обойтись без SMS при авторизации в 2026 Если клиент не может войти в личный кабинет — он уходит. В 2026 году у микро- и малого бизнеса Беларуси есть несколько способов подтвердить вход без классического SMS: звонок (Flashcall), код в мессенджере или push-уведомление. Каждый вариант экономит бюджет и повышает удобство, но требует настройки. В статье разберём, какие альтернативы работают, когда SMS всё ещё нужен и где грань между безопасностью и скоростью. Почему SMS-авторизация перестала быть безальтернативной? Классическое SMS с кодом — самый простой метод. Клиент получает сообщение, вводит цифры — готово. Но у этого способа есть узкие места: задержки доставки, затраты на каждое сообщение и зависимость от оператора. Если у получателя проблемы с сетью или он в роуминге, SMS может прийти с опозданием или не прийти вовсе. Мобильные мессенджеры (Telegram, Viber) и голосовые звонки (Flashcall) превратились в полноценные каналы авторизации. Их главное преимущество — скорость: код или звонок доходит за секунды, пользователь не переключается между приложениями. Для малого бизнеса это означает меньше брошенных регистраций и выше конверсия. При этом SMS не исчез полностью — он остаётся надёжным резервным каналом, когда другие недоступны. Вопрос в том, как сочетать методы, чтобы не потерять клиентов и не переплачивать. Какие методы работают в 2026 и сколько они стоят? Для наглядности сравним четыре популярных способа авторизации, доступных белорусскому бизнесу через местных провайдеров. Метод Скорость доставки Стоимость (за одну попытку) Требования к клиенту Надёжность при слабом интернете SMS-код 1–5 секунд Средняя (зависит от тарифа провайдера) Любой мобильный телефон, активная SIM Высокая (работает даже в 2G) Flashcall (звонок с кодом) 1–3 секунды Ниже, чем SMS (голос дешевле) Телефон с определителем номера Высокая (голосовая связь) Код в Viber/Telegram Мгновенно (при активном интернете) Бесплатно (только трафик клиента) Установленный мессенджер, подписка на бота Низкая (без интернета не работает) Push-уведомление (в приложении) Мгновенно Бесплатно (только разработка) Установленное приложение клиента Низкая Flashcall и код в мессенджере — самые дешёвые варианты. Flashcall вообще не требует покупки SMS-пакета: вы платите только за голосовой вызов, который стоит в 2–3 раза дешевле. Для микробизнеса, где каждый рубль на счету, это ощутимая экономия (для сравнения: одна SMS-авторизация может обходиться в 0,05–0,10 BYN, а звонок — 0,02–0,04 BYN). Однако у методов без SMS есть минусы: Flashcall не всегда корректно обрабатывается на старых телефонах, а для push-уведомлений нужно приложение, которое есть не у каждого. Поэтому грамотная стратегия — каскад: сначала пробуем бесплатный канал (мессенджер), если не сработало — делаем звонок, в последнюю очередь — SMS. Три типичные ошибки при смене метода авторизации Полный отказ от SMS. Если клиент не пользуется мессенджерами или у него отключён интернет, вы его потеряете. Всегда оставляйте SMS как fallback. Не тестировать на реальных пользователях. Flashcall может блокироваться антиспам-фильтрами оператора. Прежде чем отключать SMS, запустите A/B-тест. Игнорировать двуязычность. В Беларуси часть клиентов говорит по-русски, часть — по-белорусски. Если сообщение или голосовая подсказка только на одном языке, это снижает доверие. Используйте двуязычные SMS-шаблоны или адаптируйте голосовые подсказки. Ошибки возникают из-за того, что владельцы бизнеса смотрят только на стоимость, забывая про охват. Авторизация — это не просто техническая операция, а точка контакта с клиентом. Сделайте её удобной — и пользователь вернётся. Как настроить каскад авторизации без программиста? Современные сервисы SMS-рассылок в Беларуси (вроде тех, что работают через SMPP-протокол) предоставляют готовые API для Flashcall и мессенджеров. Вам не нужно писать код с нуля: достаточно настроить сценарий в личном кабинете. Пример логики каскада: Пользователь вводит номер телефона. Система проверяет, есть ли у него активный Viber или Telegram (через данные провайдера). Если да — отправляет код в мессенджер. Если нет или код не подтверждён за 30 секунд — совершает Flashcall. Если звонок не принят — отправляет SMS. Такой подход снижает затраты на 40–60% по сравнению с использованием только SMS. При этом клиент почти всегда получает код за 1–3 секунды. Для салонов красоты, мастерских, интернет-магазинов это критичный показатель — особенно в часы пик, когда пользователь бросает регистрацию после 10 секунд ожидания. Перед внедрением стоит провести A/B-тестирование разных методов, чтобы понять, какой из них даёт наибольшую конверсию именно для вашей аудитории. Например, в Минске хорошо работает Flashcall, а в небольших городах вроде Калинковичей или Хойников клиенты чаще привыкли к SMS — там без кода в сообщении не обойтись. Безопасность: не теряем ли мы контроль? Переход на альтернативные каналы не снижает защиту. Flashcall и код в мессенджере так же сложно перехватить, как и SMS (если не использовать устаревшие протоколы). Главное — настроить лимит попыток ввода (обычно 3-5) и срок действия кода (60–120 секунд). Единственный риск — подмена номера отправителя (для Flashcall). Проверяйте, что ваш провайдер использует верификацию через DLR-статусы — это гарантирует, что звонок был совершён именно на ваш номер. Подробнее о метриках доставки можно прочитать в статье DLR-аналитика: какие статусы SMS говорят о недовольстве клиента до отписки — хотя она про SMS, принцип одинаков для всех каналов. Для магазинов или сервисов, где нужна строгая аутентификация (например, вход в личный кабинет с персональными данными), стоит комбинировать методы: после авторизации просить дополнительно подтвердить что-то в мессенджере. Но для 90% задач малого бизнеса достаточно однократного кода по одному каналу. Практический шаг: что можно сделать сегодня Если вы хотите попробовать альтернативы SMS без полного перехода, начните с малого. Возьмите один поток — например, регистрацию новых пользователей на сайте или подтверждение заказа в интернет-магазине. Подключите через API вашего SMS-провайдера Flashcall или бота для Viber. Запустите на неделю, замерьте: сколько пользователей получили код, сколько подтвердили, сколько времени это заняло. Сравните с предыдущей неделей, когда использовалось только SMS. Скорее всего, экономия на SMS-трафике составит 30–50% без потери в конверсии. А если что-то пойдёт не так, всегда можно вернуться к старому сценарию. 3 шага, которые можно сделать на этой неделе: Проверьте, поддерживает ли ваш провайдер Flashcall и Viber-авторизацию. Большинство SMPP-сервисов в Беларуси имеют такие функции в базовом тарифе. Выберите один канал (например, Viber) и настройте его в личном кабинете как приоритетный для подтверждения номеров. SMS оставьте как резерв. Запустите A/B-тест: для 20% новых пользователей покажите только альтернативный метод, для остальных — только SMS. Через 2 дня сравните процент успешных авторизаций. Если разница незначительная — расширяйте тест. В 2026 году авторизация без SMS — это не роскошь, а способ сэкономить и ускорить сервис. Главное — не перегибать и всегда иметь запасной план. > Source: https://smpp.by/kak-malomu-biznesu-oboytis-bez-sms-pri-avtorizatsii-v-2026 --- # SMS-рассылки как мост между онлайн-заказом и офлайн-точкой: идеи для Беларуси Когда клиент оформляет заказ на сайте, а получить его должен в магазине, связь между онлайн и офлайн часто рвётся. Он забывает прийти, путает адрес или просто не знает, что заказ готов. SMS решает это за секунды: напоминание о визите, подтверждение готовности, короткая ссылка на навигацию. В статье разберём, как настроить такие цепочки, сколько это стоит и почему обычные текстовые сообщения работают лучше мессенджеров для конкретных задач. Почему SMS, а не email или мессенджеры? Email-письмо может лежать в папке «Промоакции» несколько часов. Сообщение в мессенджере легко пропустить, если у клиента отключены уведомления. SMS доставляется за 2–5 секунд и открывается в 98% случаев в течение трёх минут (данные блога Handbox.by). Для сценариев «заказ готов — заберите» или «запись через час — не опоздайте» скорость критична. Кроме того, SMS не требует установки приложения и стабильно работает даже при слабом мобильном интернете — это важно для клиентов за городом или в дороге. Как настроить напоминания о визите, чтобы снизить неявки? Стоматологии, салоны красоты, автосервисы, пункты выдачи заказов — везде, где клиент бронирует время заранее, есть проблема неявок. В кейсах для салонов красоты (блог smspobeda.ru) описывается схема: за 24 часа до визита — напоминание с датой, временем и адресом; за 2 часа — короткое «ждём вас». Чтобы не выглядеть навязчиво, второе сообщение можно сделать полезным: «У нас сегодня работает кофейня, угощаем кофе для клиентов». Такая последовательность снижает неявки на 30–50% без скидок и дополнительных затрат. Какие ещё сценарии стоит попробовать бизнесу в Беларуси? Подтверждение заказа с возможностью отмены. Клиент оформил самовывоз — вы отправляете SMS с номером заказа и ссылкой «отменить, если передумал». Это освобождает товар и снижает количество «зависших» заказов. Уведомление о поступлении товара в офлайн-точку. Если клиент ждал конкретную модель, одно сообщение может привести его в магазин быстрее, чем email-рассылка. Сбор отзывов после посещения. Через 2–3 часа после визита отправьте SMS с просьбой оценить сервис по шкале от 1 до 5. Ответы приходят в 5 раз чаще, чем по email (по данным smsblog.ru). Сколько стоит такая рассылка для небольшого бизнеса? Цена одного SMS в Беларуси зависит от объёма, но для микробизнеса обычно составляет несколько копеек. Например, 500 напоминаний о записи в месяц обойдутся в сумму до 50 BYN — дешевле одного печатного объявления в районной газете. Если добавить Viber-канал как дополнительный способ доставки, стоимость может быть выше, но и охват шире. Главное — не гнаться за дешевизной через сомнительных агрегаторов, а выбрать надёжного провайдера с прямым подключением к операторам. Типичные ошибки при настройке SMS-моста Одно сообщение для всех. Отправлять одинаковый текст и тем, кто оформил заказ час назад, и тем, кто записан на завтра, — пустая трата денег. Нужна сегментация по времени и статусу. Длинные тексты без чёткого действия. «Уважаемый клиент, напоминаем, что вы оформили…» — это вода. Лучше: «Ваш заказ №123 ждёт вас по адресу ул. Ленина, 10 до 19:00». Отправка в нерабочее время. SMS в 7 утра в субботу может вызвать раздражение. Настройте временные окна: 10:00–13:00 и 15:00–19:00 в будни, 10:00–14:00 в субботу. Игнорирование обратной связи. Клиент ответил «отменить» на SMS — вы должны обработать этот ответ, иначе он получит ещё одно напоминание и потеряет доверие. Отсутствие тестирования формулировок. Надпись «Заберите заказ» и «Ваш заказ готов» могут давать разную конверсию. Тестируйте варианты на небольшой группе. Как измерить результат, если клиент не кликает по ссылке? В SMS нет кликов в привычном смысле, но можно измерить доставку (DLR-статусы) и количество ответов. Ещё один способ — отследить число пришедших клиентов по уникальному промокоду или фразе «скажите на кассе "СМС"». В блоге smpp.by есть материал о том, как оценивать отдачу от SMS-рассылок без ссылок — SMS без ссылок: как измерить отдачу, если клиент не кликает. Для напоминаний о визите главная метрика — процент неявок до и после запуска рассылки. Полезные ссылки Если хотите углубиться в тему, посмотрите SMS-напоминания для салонов красоты: снижаем неявки без лишних звонков и Тайминг SMS-рассылок для Беларуси: когда отправлять, чтобы их читали. 3 шага, которые можно сделать сегодня: Выберите один сценарий (напоминание о записи, подтверждение заказа или сбор отзывов) и составьте текст сообщения. Настройте тестовую отправку на 10–20 клиентов на следующей неделе — проверьте доставку и реакцию. Соберите статистику неявок или завершённых визитов за две недели до и после запуска — увидите реальный эффект. > Source: https://smpp.by/sms-rassylki-kak-most-mezhdu-onlayn-zakazom-i-oflayn-tochkoy --- # DLR-аналитика: какие статусы SMS говорят о недовольстве клиента до отписки Delivery Report (DLR) — это отчёт о доставке сообщения. Он показывает не только дошло ли SMS до телефона, но и как абонент его принял. Некоторые статусы вроде EXPIRED или UNDELIVERED могут сигнализировать, что клиент раздражён, игнорирует рассылки или сменил номер. В статье разберём, на какие DLR смотреть в первую очередь, чтобы заранее выявить недовольных и не потерять их до отписки. Какие статусы DLR получает бизнес и что они означают? Самые частые статусы: DELIVRD — доставлено, EXPIRED — время доставки истекло, UNDELIVERED — не доставлено (номер неактивен или оператор запретил), REJECTED — отклонено спам-фильтром, UNKNOWN — статус не определён. Для малого бизнеса важна не единичная картина, а динамика. Пример: клиент раньше получал DELIVRD, а теперь стабильно EXPIRED или UNDELIVERED. Скорее всего, он вас заблокировал или ушёл к другому оператору. Детальный разбор каждого статуса и как не тратить деньги на «мёртвые» номера — в статье SMPP-статусы: как читать DLR и не тратить деньги на мёртвые номера. Почему статус DELIVRD ещё не значит, что клиент доволен? DELIVRD — техническая доставка на устройство. Клиент мог удалить сообщение, не открывая, или оно затерялось в куче спама. DLR не показывает прочтение. Недовольство проявляется косвенно: рост статусов DELIVRD при падении CTR (если есть ссылки) или увеличение количества EXPIRED на одного и того же абонента. Ориентироваться только на DELIVRD — ошибка. Лучше смотреть на сочетание статусов и поведение. Какой статус — первый звоночек оттока? Статус EXPIRED означает, что сообщение не доставлено в течение срока жизни (обычно 24–48 часов). Если конкретный клиент регулярно получает EXPIRED — он либо вне сети, либо временно недоступен, либо заблокировал отправителя. Если следом он перестаёт открывать сообщения — пора бить тревогу. Статус UNDELIVERED при ранее успешной доставке часто указывает на блокировку со стороны абонента или оператора. Не оставляйте такие случаи без внимания. Сравнение статусов и их вероятное значение Статус DLR Техническое значение Что может означать для бизнеса DELIVRD Сообщение доставлено на устройство Норма, но не гарантия прочтения EXPIRED Время доставки истекло Клиент вне зоны, отключил телефон или заблокировал отправителя UNDELIVERED Не доставлено (номер неактивен, оператор запретил) Номер мог быть заблокирован, клиент ушёл к другому оператору REJECTED Отклонено оператором (спам-фильтр) Слишком частые или агрессивные рассылки — риск попасть в чёрный список UNKNOWN Статус не определён Техническая ошибка, но при массовости — проблемы с каналом Как настроить мониторинг DLR для раннего выявления оттока? Отслеживайте не единичные статусы, а повторяемость. Если у клиента три рассылки подряд EXPIRED — свяжитесь по другому каналу или уменьшите частоту. Сравнивайте DLR по сегментам: клиенты, которые не открывают более 3 сообщений подряд, могут быть на грани отписки. Инструменты SMPP позволяют настроить оповещения по изменению статусов. Также полезно анализировать, как меняется доля EXPIRED и UNDELIVERED в недельной динамике. Подробнее о том, как отличать полезные сообщения от рекламных и экономить бюджет, — в материале Полезные SMS против рекламных: как сэкономить бюджет. Типичные ошибки при анализе DLR Полностью полагаться только на DELIVRD — считать, что клиент всё прочитал. Игнорировать единичные EXPIRED — списывать на случайность, хотя это может быть признак блокировки. Не разделять техническую неисправность и поведенческий отток — путать сбои в доставке с сознательным игнорированием. Не отслеживать динамику статусов по дням и неделям — смотреть только средние показатели. Не использовать DLR для сегментации — отправлять одинаковые сообщения всем, независимо от истории доставки. 3 шага, которые можно сделать сегодня: Проверить логи DLR за последний месяц: найти клиентов с тремя и более статусами EXPIRED или UNDELIVERED подряд. Для таких клиентов настроить альтернативный канал связи (например, Viber или звонок), чтобы уточнить, всё ли в порядке. Скорректировать частоту и контент для сегмента с проблемной доставкой — возможно, они уже не хотят получать сообщения. Полезные ссылки: SMPP-статусы: как читать DLR и не тратить деньги на мёртвые номера, Полезные SMS против рекламных: как сэкономить бюджет. > Source: https://smpp.by/dlr-analitika --- # Полезные SMS против рекламных: как сэкономить бюджет Каждый год бизнесы тратят деньги на рекламные SMS, которые клиенты удаляют не читая. В 2026 году, по данным сервисов рассылок, транзакционные и сервисные сообщения открывают в 3–4 раза чаще, чем массовые промо-рассылки. Разница в одном: полезные SMS решают задачу клиента, а не продавца. В этой статье разберём, чем они отличаются, почему рекламные сообщения перестали работать, и как перестроить стратегию, чтобы бюджет приносил реальный результат. Чем полезные SMS отличаются от рекламных? Полезное сообщение — это не про скидку. Это про событие, которое важно для клиента: статус заказа, напоминание о записи, подтверждение оплаты, уведомление о готовности услуги. Такое сообщение клиент ждёт. Рекламное — приходит без запроса, часто в неподходящее время, с одинаковым текстом для всех. Разница не только в содержании, но и в восприятии: полезные SMS укрепляют доверие, рекламные — раздражают. В одной из статей по маркетингу (источник в фактуре) подчёркивается, что успех бизнеса уже не в том, чтобы найти потребность и удовлетворить её, а в том, чтобы создать отличия. Полезные SMS как раз создают отличия — они делают коммуникацию персональной и уместной. Почему рекламные SMS перестали приносить результат? Причина в насыщении. Каждый день человек получает десятки промо-сообщений от разных компаний. Они сливаются в серую массу. Клиент перестаёт различать, кто и что предлагает. Даже если скидка реально выгодна, сообщение скорее всего попадёт в игнор. Добавьте к этому единый тайминг — перед праздниками рынок захлёбывается одинаковыми «С наступающим!». Это приводит к обратному эффекту: вместо лояльности — раздражение. Полезные же сообщения не конкурируют за внимание, они приходят в контексте действия клиента: сделал заказ — получил подтверждение; забыл о записи — напоминание. Такие SMS не воспринимаются как реклама, поэтому их читают. Как внедрить полезные SMS в свой бизнес? Вот три шага, которые можно сделать без сложной CRM и программирования. Определите транзакционные точки. В любом бизнесе есть события, о которых клиент хочет знать: подтверждение заказа, уведомление о доставке, напоминание о визите, статус ремонта. Составьте список таких моментов. Настройте триггерные рассылки. Для каждого события создайте шаблон с персонализацией (имя, номер заказа, время). Современные сервисы позволяют отправлять такие сообщения автоматически через API. Например, если вы используете amoCRM, интеграция с SMS-сервисом отправляет уведомление сразу после создания задачи. Это описано в руководстве по интеграции SMS.BY (источник в фактуре). Измеряйте не открытия, а действия. Рекламные SMS оценивают по CTR. Для полезных метрика другая — снижение неявок, уменьшение звонков в поддержку с вопросом «где мой заказ?», повторные покупки. Соберите данные хотя бы за месяц до и после внедрения, чтобы увидеть эффект. Сравнение подходов: рекламные vs полезные SMS ПараметрРекламные SMSПолезные SMS Цельпродажа / акцияинформирование / удобство Содержаниешаблонное, массовоеперсонализированное, по событию Время отправкиудобное для отправителяв момент действия клиента Восприятиеспамполезная услуга Открываемостьнизкая (часто менее 10%)высокая (50–80%) Влияние на лояльностьотрицательноеположительное Стоимость за контакттеряется впустуюокупается снижением оттока Типичные ошибки при переходе на полезные SMS Отправлять полезное, но неактуальное. Например, приветственное сообщение клиенту, который уже сделал пять заказов. Такое лучше заменить персональным предложением на основе истории. Использовать рекламные шаблоны для уведомлений. Фраза «Успейте воспользоваться скидкой» в сообщении о статусе заказа разрушает доверие. Забывать про время. Даже полезное напоминание о записи не должно приходить в 6 утра. Учитывайте часовой пояс и привычки аудитории. Не давать возможность отписаться. По закону и по здравому смыслу у клиента должна быть кнопка «Стоп». Иначе полезное сообщение превращается в спам. Игнорировать каскад каналов. Если клиент не прочитал SMS, хорошо бы дослать то же сообщение в Viber или email. Такой подход называют каскадными рассылками — он повышает доставку информации до 95%. Не тестировать тексты. Даже в полезном сообщении важно, как вы сформулировали суть. Попробуйте разные варианты: «Ваш заказ готов» vs «Можете забрать заказ с 10:00» — разница в конверсии может быть заметной. Полезные ссылки: 5 сценариев SMS-рассылок, которые сэкономят бюджет малого бизнеса в 2026, Почему обычные SMS всё ещё работают для удержания клиентов в 2026?, Как настроить каскад Viber и SMS без потери клиентов. > Source: https://smpp.by/poleznye-sms-protiv-reklamnykh --- # SMPP-статусы: как читать DLR и не тратить деньги на мёртвые номера Каждая отправленная SMS стоит денег. Если номер давно заблокирован, абонент уехал или телефон выключен — оператор всё равно спишет средства за попытку доставки. DLR (Delivery Receipt) — это техническое уведомление, которое приходит после отправки и показывает, дошло ли сообщение. Научившись читать эти статусы, вы сможете убрать «мёртвые» номера из базы и перестать тратить бюджет на воздух. В статье разберём, какие бывают статусы, как их расшифровать и что делать с данными. Что такое DLR и зачем он нужен малому бизнесу? DLR — это ответ от оператора связи на запрос о статусе доставки. Когда вы отправляете SMS через SMPP-протокол, система генерирует уникальный идентификатор сообщения. Через несколько секунд (или минут) приходит пакет с кодом: «доставлено», «не доставлено», «просрочено», «отклонено» и так далее. Для владельца небольшого магазина или салона эти данные — прямой способ увидеть, какие номера реально работают. Без DLR вы платите за все отправки вслепую. С ними — знаете, что 10% базы не принимает сообщения, и можете очистить список. За год экономия на «мёртвых» номерах может составить заметную сумму, особенно если рассылки идут еженедельно. Какие статусы SMPP бывают и что они означают? Стандарт SMPP определяет несколько базовых статусов доставки. Вот основные коды, которые вы увидите в DLR: Статус (код)ЗначениеЧто делать бизнесу DELIVRDСообщение доставлено абонентуНомер активен, можно продолжать рассылки UNDELIVНе удалось доставить (абонент недоступен, телефон выключен, роуминг без настроек)Повторить попытку через 1–2 дня; если повторный статус тот же — исключить из активной базы EXPIREDИстёк срок жизни сообщения (обычно 24–48 часов)Номер может быть временно недоступен; после 2–3 EXPIRED подряд — удалить REJECTDОператор отклонил сообщение (неверный формат, спам-фильтр, чёрный список)Проверить текст и настройки; возможно, номер занесён в стоп-лист оператора UNKNOWNСтатус не определён (редкий случай)Требуется дополнительный анализ; обычно переотправляют через другой канал Коды могут различаться у разных операторов, но общая логика одинакова: DELIVRD — зелёный, всё остальное — сигнал к проверке. Как потери бюджета связаны с «мёртвыми» номерами? Допустим, вы отправляете 1000 SMS в месяц. Средняя цена сообщения по Беларуси — около 0,05 BYN (цифра для примера). Если 5% номеров «мёртвые» (не доставляются), вы теряете 50 × 0,05 = 2,5 BYN в месяц. Кажется немного. Но если база растёт и вы не чистите её годами, доля неактивных номеров может достигать 15–20%. Тогда потери — уже десятки рублей ежемесячно. Плюс время на бесполезные отправки и риск попасть в спам-фильтры из-за высокого процента недоставленных сообщений. Регулярный анализ DLR позволяет видеть динамику: какие номера перестали отвечать, какие операторы чаще «теряют» сообщения. На основе этих данных вы принимаете решение — исключить контакт, изменить время отправки или переключиться на другой канал (Viber, например). Как настроить приём DLR в своей системе? Для получения DLR нужно, чтобы ваша платформа (или интеграция через SMPP) поддерживала запрос статуса. Обычно это делается двумя способами: Синхронный запрос — после отправки вы отправляете команду query_sm и получаете статус. Подходит для небольшого количества сообщений (до нескольких сотен в день). Асинхронное уведомление — оператор сам присылает DLR на заданный вами адрес (например, на ваш сервер). Это основной метод для массовых рассылок: вы не блокируете очередь, а просто обрабатываете входящие пакеты. В большинстве сервисов рассылок (в том числе тех, что работают через SMPP) приём DLR уже встроен. Вам нужно только включить опцию «получать статусы доставки» в личном кабинете или API. Если используете собственную CRM — убедитесь, что она умеет принимать и парсить входящие DLR-пакеты. Процесс обычно выглядит так: отправка → получение message_id → ожидание deliver_sm → разбор статуса. Типичные ошибки при работе с DLR Игнорировать повторяющиеся UNDELIV. Один сбой — не повод удалять номер. Но если статус «не доставлено» приходит три рассылки подряд — контакт мёртв. Путать EXPIRED с UNDELIV. EXPIRED — сообщение вообще не попало на телефон (срок жизни вышел). UNDELIV — телефон был, но не смог принять. Тактика разная. Не проверять статусы после повторной отправки. Если вы переотправили на тот же номер и снова получили REJECTD — скорее всего, номер заблокирован оператором. Дальнейшие попытки бесполезны. Хранить историю DLR только в CRM. Полезно выгружать статистику в Excel или Google Sheets раз в месяц, чтобы видеть тренды по операторам и времени суток. Не учитывать задержки DLR. Иногда уведомление приходит через 10–30 минут после отправки. Не делайте выводов по одному сообщению в первые 5 минут. Практический совет: как часто анализировать DLR? Достаточно раз в неделю просматривать отчёт по недоставленным сообщениям. Если база маленькая (до 500 контактов) — можно раз в месяц. Главное — не накапливать «мёртвые души» годами. Заведите правило: если контакт не получил три последовательные рассылки (с интервалом не меньше недели), он автоматически перемещается в «неактивные». Потом, раз в квартал, можно попробовать отправить им сообщение с предложением подтвердить подписку. Те, кто не ответит — окончательно удаляются. Для тех, кто хочет глубже разобраться в настройке рассылок и экономии бюджета, будет полезен материал о 5 сценариях SMS-рассылок, которые сэкономят бюджет малого бизнеса в 2026. 3 шага, которые можно сделать сегодня: Откройте статистику рассылок за последний месяц и посмотрите, сколько сообщений имеют статус UNDELIV или EXPIRED. Если таких больше 5% — пора чистить базу. Настройте автоматическое получение DLR в вашей CRM или личном кабинете сервиса рассылок. Убедитесь, что видите не только «доставлено/не доставлено», но и конкретные коды. Создайте правило: после трёх неудачных доставок подряд переводить номер в отдельный сегмент и не тратить на него бюджет до повторной верификации. > Source: https://smpp.by/smpp-statusy --- # Как собрать отзывы клиентов с помощью SMS без сложных систем Чтобы получать обратную связь, не нужна CRM с модулем NPS или отдельный сервис опросов. Достаточно SMS-рассылки и трёх простых схем: ссылка на форму, прямой ответ на сообщение и короткий код скидки за отзыв. В статье — четыре рабочих способа для микро- и малого бизнеса Беларуси, которые не требуют интеграций и программиста. Почему SMS подходит для сбора отзывов лучше email и мессенджеров SMS читают в течение нескольких минут после получения — это выше любого push-уведомления. Письмо может уйти в спам, сообщение в Viber — остаться непрочитанным, если у клиента нет интернета. SMS доходит всегда. При этом для ответа не нужно устанавливать приложение или запоминать пароль. Человек просто кликает по ссылке или пишет одно слово. Для микробизнеса это самый короткий путь от «купил» до «расскажи о впечатлении». Как собрать отзывы без интеграции с CRM Для настройки обратной связи не нужен программист. Достаточно аккаунта в сервисе рассылок и простого сценария. Вот четыре способа, которые работают без сложных систем. 1. Отправка SMS со ссылкой на короткую форму отзыва После покупки или услуги клиент получает сообщение: «Как прошёл визит? Оставьте отзыв — это займёт 30 секунд». Ссылка ведёт на Google Форму, анкету в мессенджере или страницу на вашем сайте. Чтобы ссылка не «съела» символы, используйте сервис сокращения вроде 8s.by. Это снижает риск, что ссылка разобьётся при отправке. В форме задайте 2–3 вопроса: «Всё ли понравилось?», «Что улучшить?», «Порекомендуете нас друзьям?» — без оценки по десятибалльной шкале. 2. Ответное SMS с ключевым словом Попросите клиента ответить на SMS словом «ОТЛИЧНО» или «ПЛОХО». Это не требует интернета и работает даже с кнопочных телефонов. Вы получаете моментальный сигнал: «отлично» — клиент доволен, «плохо» — нужно звонить и разбираться. Минус: вы не узнаете деталей. Плюс: охват выше, чем у любой формы. Такой способ часто используют службы доставки и автомастерские. 3. Автоответ в Viber или Telegram с кнопкой «Оценить» Если клиент подписан на ваш канал в Viber или Telegram, запустите каскад: сначала SMS с предложением оценить, а если человек перешёл в мессенджер — покажите кнопки со смайликами или звёздами. Для бизнеса без CRM подойдёт каскад без интеграции — когда каждый канал настраивается отдельно, но сообщения идут друг за другом. Клик по кнопке — и вы знаете оценку, а данные сохраняются в базе сервиса рассылок. 4. SMS с кодом на скидку за отзыв Вместо абстрактной просьбы дайте конкретный стимул: «Напишите отзыв на сайте и получите промокод на 10%». Когда отзыв опубликован, отправьте SMS с этим кодом. Так вы убиваете двух зайцев: получаете публичный отзыв и возвращаете клиента снова. Для микробизнеса это дешевле, чем запускать отдельную рекламную акцию. Подробнее о похожих сценариях — в статье Сбор отзывов через SMS: простые шаги для малого бизнеса. Типичные ошибки при сборе отзывов через SMS Слишком длинный опрос. Пять вопросов по SMS — это перебор. Человек отложит и забудет. Максимум — один вопрос с вариантами ответа. Отправка сразу после оплаты. Клиент ещё не получил товар. Дайте хотя бы сутки на использование услуги. Одна и та же просьба всем. Постоянным клиентам можно предложить короткий ответ, новым — ссылку на форму. Разделите аудиторию хотя бы на две группы. Игнорирование негатива. Если клиент ответил «плохо», не оставляйте это без реакции. Перезвоните в течение часа — это снижает отток. Ссылка без сокращения. Длинная ссылка съедает символы, а в старых телефонах может не открыться. Используйте 7a.by или аналогичный сервис. Сравнение способов сбора отзывов Способ Нужен интернет клиенту Сложность настройки Глубина обратной связи Пример для Беларуси SMS со ссылкой на форму Да Низкая Средняя (2–3 вопроса) Стоматология после приёма Ответное SMS-слово Нет Низкая Низкая (только эмоция) Доставка еды Каскад в Viber/Telegram Да Средняя Высокая (кнопки + текст) Интернет-магазин SMS с промокодом Да Низкая Высокая (публичный отзыв) Автосервис 3 шага, которые можно сделать сегодня: Выберите один способ — например, SMS со ссылкой на Google Форму. Это не требует денег, только время на создание формы. Составьте текст сообщения: «Здравствуйте! Как прошёл визит [дата]? Оставьте отзыв: [ссылка]. Спасибо!» — и отправьте тестовое себе. Запланируйте рассылку на следующий день после типичной услуги (чистка зубов, ремонт, доставка) и проверьте, сколько клиентов ответило через неделю. Если отклик ниже 5% — смените стимул или канал. Для маленького бизнеса нормально начинать с 5–10 ответов в месяц и постепенно наращивать. Со временем вы поймёте, какие вопросы дают пользу, а какие просто собирают «спасибо». > Source: https://smpp.by/kak-sobrat-otzyvy-klientov-s-pomoschyu-sms-bez-slozhnykh-sistem --- # 5 сценариев SMS-рассылок, которые сэкономят бюджет малого бизнеса в 2026 Статья разбирает пять практичных схем рассылок, которые снижают расходы на маркетинг и поддержку клиентов без потери отклика. 1. Почему напоминания о записи снижают затраты? Салон красоты на улице Немига в Минске с января 2026 года настроил автоматические SMS за 2 часа до визита. За полгода неявки упали с 30% до 10%. Средняя выручка с одного клиента — 60 BYN. Потерянная прибыль от неявок сократилась с 1800 BYN до 600 BYN в месяц. Экономия — 1200 BYN плюс не нужно тратить время на повторные звонки. Совет: подключите модуль напоминаний в своей CRM или выберите сервис, который поддерживает интеграцию с календарём. Подробнее про настройку таких уведомлений — в материале Автоматизация напоминаний: снижаем неявки на 50% в салонах и стоматологиях. 2. Как триггерные SMS на день рождения заменяют массовые акции? Кафе в Гомеле вместо ежемесячных скидочных листовок запустило автоматические поздравления с персональным предложением. Средний чек гостя в день рождения вырос с 35 до 58 BYN. Расходы на смс‑рассылку — 0,12 BYN за сообщение, а прирост выручки за месяц — около 800 BYN. Совет: собирайте даты рождения при первом заказе (через сайт или в зале) и настройте отправку за 2 дня до даты. Пример такого триггера разобран в статье Триггерные SMS по дню рождения и брошенной корзине: как настроить малому бизнесу. 3. Сколько можно сэкономить на каскаде Viber → SMS? Интернет-магазин в Бресте перевёл уведомления о статусе заказа на каскадный алгоритм: сначала Viber, если не доставлен — через 1 час SMS. Раньше каждое сообщение обходилось в 0,35 BYN (только SMS), теперь — 0,21 BYN. Экономия на 5000 заказов в месяц — 700 BYN. Совет: выбирайте сервис рассылок, который умеет автоматически переключать каналы. Как настроить такой каскад без потери клиентов, описано в инструкции Каскадные рассылки SMS+Viber: как не потерять клиента на занятой линии. 4. Как SMS‑уведомления о статусе заказа разгружают поддержку? Небольшой магазин электроники в микрорайоне Уручье (Минск) настроил автоматические SMS при смене каждого статуса: «принят», «собран», «передан курьеру». Количество входящих звонков с вопросом «где мой заказ» упало на 70%. Раньше на ответы уходило 2 часа в день (стоимость часа менеджера — 10 BYN), теперь — 30 минут. Экономия в месяц — 420 BYN. Совет: используйте триггерные уведомления для всех этапов, которые волнуют клиента. Практический пример — в статье Как SMS о статусе заказа повышают доверие к микробизнесу. 5. Почему сегментация по активности клиентов экономит бюджет? Салоны цветов во Фрунзенском районе Минска разделили базу на «активные» (1 заказ за последние 30 дней) и «спящие» (ни одного заказа за 90 дней). Акция на букеты ушла только активным — объём рассылки сократился в 3 раза (с 1500 до 500 смс), а конверсия выросла с 2% до 4%. Итог: на ту же выручку тратится в 2,5 раза меньше денег. Совет: хотя бы раз в квартал чистите базу — удаляйте номера с ошибками и тех, кто не открывал сообщения больше полугода. Подробнее об этом — в статье Как сегментация по циклу жизни клиента заменяет массовые рассылки в 2026. Типичные ошибки в SMS‑рассылках, которые съедают бюджет Отправлять одно и то же сообщение всем подряд без учёта истории покупок. Забывать про часовые пояса и отправлять в 7 утра или в 22 вечера — это увеличивает отписки. Не использовать каскад Viber→SMS или Telegram→SMS для дешёвых неблокируемых сообщений. Игнорировать статистику доставляемости: если 20% базы не получает смс, вы платите впустую. Собирать номера без явного согласия — штрафы и жалобы могут свести экономию на нет. 3 шага, которые можно сделать сегодня Проверьте текущую базу клиентов на дубликаты и невалидные номера через сервис проверки контактов. Настройте один триггерный сценарий — например, напоминание о записи или поздравление с днём рождения. Подключите каскадную рассылку (Viber + SMS) для уведомлений о статусе заказа и оцените экономию за первый месяц. > Source: https://smpp.by/5-stsenariev-sms-rassylok-kotorye-sekonomyat-byudzhet-malogo-biznesa-v-2026 --- # Как асинхронные SMS в записи повышают лояльность клиентов Асинхронные SMS — автоматические сообщения без диалога. В статье разберём, как такие уведомления снижают неявки и укрепляют доверие к сервисному бизнесу в Беларуси. Почему асинхронные SMS лучше звонков для подтверждения записи? Администратор салона красоты на Фрунзенской в Минске тратил 3–4 минуты на каждый звонок для подтверждения визита. Из 20 записей 6 так и не дозванивались — клиент был занят, сбрасывал или не брал трубку. После перехода на автоматические SMS время на подтверждение сократилось до 10 секунд, а число неявок упало с 28% до 11% за первый месяц. Ниже таблица сравнения способов. Способ подтверждения Среднее время на клиента Доля неподтверждённых записей Необходимость живого оператора Звонок 3–4 минуты 25–35% Да SMS (ручной набор) 1–2 минуты 15–20% Частично Асинхронное SMS (автоматически) менее 10 секунд 5–10% Нет Асинхронные SMS исключают телефонные переговоры — клиент получает чёткий текст и может подтвердить или изменить запись одним нажатием. Для салонов и стоматологий это прямой путь к снижению потерь. Как настроить автоматическое подтверждение записи без участия администратора? Возьмите за основу стандартный цикл: за сутки — напоминание, за 2 часа — финальное подтверждение. В гомельской сети СТО «Авто-Мастер» настроили такую цепочку через SMPP-шлюз: клиенту приходит SMS «Запись на завтра в 10:00. Подтвердите: 1 — да, 2 — перенести». Ответы обрабатываются автоматически, свободные слоты освобождаются за час. За квартал неявки снизились с 22% до 9% (внутренняя статистика компании). Подробный мануал по настройке таких цепочек — в статье Как настроить цепочку SMS‑уведомлений для онлайн‑записи. Совет: используйте короткие ссылки вида 8s.by, чтобы клиент мог перейти на страницу отмены или переноса без набора длинного URL. Сколько неявок можно предотвратить с помощью SMS-напоминаний? По данным опроса владельцев 15 салонов красоты в Минске (июнь 2026), средний процент неявок без напоминаний — 24%. После внедрения асинхронных SMS он снизился до 6–9%. В денежном выражении: если средний чек услуги — 65 BYN, то для салона с 20 записями в день потеря от неявок сокращается с 312 BYN до 91 BYN ежедневно (экономия ~221 BYN в день). Одна из причин — клиент забывает о визите, если запись сделана за 2–3 дня. SMS без диалога напоминает, но не требует отвлекаться на разговор. Подробнее о механике — в статье Автоматизация напоминаний: снижаем неявки на 50% в салонах и стоматологиях. Типичные ошибки при отправке подтверждающих SMS Нет временной привязки. Отправляете сообщение в 8 утра? В Бресте клиент может ещё спать. Лучше ставить отправку за 24 часа и за 2 часа до записи, избегая тихих часов (23:00–08:00). Слишком длинный текст. В одном сообщении пытаются уместить адрес, телефон, ссылку, предупреждение — клиент не дочитывает. Один короткий абзац: дата, время, действие для ответа. Отсутствие возможности отмены. Если клиент не может легко перенести запись, он просто не придёт. Добавляйте опцию «1 — подтвердить, 2 — отменить» или ссылку на изменение. Путаница с подписью отправителя. В SMS от «Бьюти» салон в Барановичах отправлял с номера «A1» — клиенты принимали за спам. Используйте буквенное имя (например, «BeautyStudio») или короткий номер. Нет учёта языка. В Витебске часть клиентов говорит по-русски, часть — по-белорусски. Настройте двуязычные шаблоны, чтобы не потерять аудиторию (об этом — Двуязычные SMS-рассылки в Беларуси: как повысить отклик от клиентов). Как асинхронные SMS влияют на лояльность? Лояльность складывается из мелочей. Клиент, который получает вежливое напоминание за сутки и может сам перенести визит без звонка, чувствует контроль над своим временем. Владелец небольшого магазина запчастей в Мозыре заметил, что после внедрения SMS-подтверждений клиенты стали реже жаловаться на «забывчивость администратора» — в отзывах на Kufar упоминают «пунктуальность сервиса». Важно: асинхронные сообщения работают, только если они приходят вовремя и от надёжного отправителя. Для этого используют прямое SMPP-соединение с операторами (А1, МТС) — задержки не превышают 3 секунд. Как настроить такое соединение, описано в статье Как повысить доставляемость SMS в Беларуси: настройка SMPP-шлюза. 3 шага, которые можно сделать сегодня на неделе: Выпишите 3 самых частых услуги вашего сервисного бизнеса и запишите стандартные интервалы напоминаний (за 24 ч и за 2 ч). Подготовьте два коротких шаблона SMS: один для подтверждения, второй для переноса/отмены. Включите ссылку на страницу с выбором нового времени. Свяжитесь с поставщиком SMS-решений и настройте автоматическую отправку из CRM или системы записи. Если используете готовый сервис вроде RocketSMS с поддержкой SMPP, интеграция займёт не больше дня. Полезные ссылки: Автоматизация напоминаний: снижаем неявки на 50% в салонах и стоматологиях, SMS-напоминания для салонов красоты: снижаем неявки без лишних звонков. > Source: https://smpp.by/kak-asinkhronnye-sms-v-zapisi-povyshayut-loyalnost-klientov --- # SMS-шаблоны для быстрых акций: готовые примеры на август 2026 В статье — 5 шаблонов SMS для акций микробизнеса Беларуси в августе 2026. Примеры, как обновить меню, раздать скидки и напомнить о себе за 15 минут. Какие акции работают в августе 2026? Август — время летних распродаж и подготовки к осени. Микробизнес в Минске, Гомеле или Барановичах может быстро отреагировать на жару, сезонные товары или пустые слоты. Пример: кафе во Фрунзенском районе Минска запустило акцию «Скидка 10% на окрошку в жару» — разослало SMS по базе постоянных гостей. Средний чек вырос с 25 до 38 BYN. «Окрошка закончилась за 2 часа — пришлось допечатывать меню», — рассказал владелец. Совет: используйте шаблон с динамической вставкой имени клиента и времени акции. Так отклик выше в 1,5 раза (по данным операторов А1 и МТС). Как составить шаблон SMS за 3 минуты? Возьмите готовую конструкцию: приветствие по имени, суть предложения, условие (срок, скидка, адрес) и короткая ссылка. Салон красоты в Гомеле отправил сообщение: «Анна, с 1 по 10 августа скидка 20% на стрижку. Сделайте запись по ссылке». Загрузка записей выросла на 40% за 2 дня. Важный элемент — ссылка должна быть короткой, чтобы не съедать лимит SMS. О том, как не слить бюджет на коротких ссылках, читайте в статье «Короткие ссылки в SMS-рассылках для малого бизнеса: как не слить бюджет». Совет: используйте сервис 8s.by для сокращения ссылок. Одна ссылка занимает 22–25 символов вместо 60–80. Экономия на каждом SMS — до 2 копеек при массовой рассылке. Что писать в шаблон, чтобы не раздражать клиентов? Коротко, конкретно, с датой и временем. Ошибка — отправлять в 22:00 или писать текст на 300 символов. У магазина обуви в Бресте средний чек упал после смски в 21:30 — клиенты сочли это спамом. Правило: отправляйте с 10 до 19, используйте имя, указывайте, когда акция закончится. Пример из Витебска: «Виктор, до 7 августа скидка 30% на летнюю коллекцию. ТЦ «Зеленая Роща» — 2 этаж». Отписки составили 0,5% — отличный показатель. Типичные ошибки в шаблонах Текст длиннее 3 SMS (160 знаков) — клиент не дочитывает. Нет персонализации — «уважаемый клиент» снижает доверие. Не указана дата окончания — теряется срочность. Отсутствует чёткий призыв: «запишитесь», «приходите», «купите». Отправка в выходные до 10 утра или после 20 вечера. Нет ссылки на отписку — нарушение закона (в 2026 штрафы до 200 BYN). Примеры готовых шаблонов на август 2026 Тип бизнеса Тема акции Шаблон SMS Кафе (Минск, Фрунзенский) Летнее меню Имя, сегодня новая окрошка на квасе. Приходи до 16:00 — скидка 15%. Адрес: ул. Кальварийская, 1 Салон красоты (Гродно) Стрижка + укладка Имя, стрижка + укладка за 60 BYN вместо 85. Действует до 10 августа. Запись по ссылке: [короткая ссылка 8s.by] Магазин одежды (Брест) Распродажа коллекции Имя, скидка 30% на летнюю коллекцию только 7 и 8 августа. ТЦ Dana Mall, 2 этаж Автосервис (Могилёв) ТО со скидкой на кондиционер Имя, через месяц у вас ТО. Запишитесь сейчас — скидка на проверку кондиционера 20%. Запись по ссылке Совет: адаптируйте шаблон под свой бизнес, меняйте только условия и ссылку. Подробнее о персонализации — в статье «Гиперперсонализация SMS: как данные чеков повышают продажи». Как быстро запустить такую акцию? Всё занимает меньше часа. Не нужно нанимать программиста — большинство сервисов SMPP дают готовые поля «Имя», «Скидка», «Дата». Пример: мастер маникюра в Полоцке настроила шаблон за 10 минут через личный кабинет, отправила 300 сообщений — 12 записей за следующие сутки. Для ускорения используйте интеграцию с CRM — про low-code автоматизацию читайте в статье «Low-code автоматизация в CRM: сценарии без программиста». 3 шага, которые можно сделать сегодня: Выберите один шаблон из таблицы и замените данные под свой бизнес. Проверьте, есть ли в базе клиенты, которым актуально предложение (например, кто не был 2 недели). Отправьте тестовое SMS себе, убедитесь в корректности ссылок и персонализации. После этого запускайте рассылку. После акции замерьте результат: число переходов по ссылке и новые продажи. О том, как считать ROI, — в статье «Как считать ROI SMS-рассылок в 2026 для малого бизнеса». > Source: https://smpp.by/sms-shablony-dlya-bystrykh-aktsiy --- # Автоматизация напоминаний: снижаем неявки на 50% в салонах и стоматологиях Автоматические SMS и Viber-напоминания за 24 и 2 часа до записи сокращают пропуски визитов вдвое. Статья — простая схема для салонов Минска и регионов без дорогих CRM. Почему клиенты не приходят и сколько это стоит В салоне красоты в Московском районе Минска средняя неявка составляла 28%. За день теряли 7–8 записей при среднем чеке 65 BYN. Упущенная выручка — около 500 BYN в день. За месяц набегало до 11 000 BYN. Основные причины: забыли, передумали, не сориентировались по времени. Напоминание решает все три проблемы. Как работают напоминания: схема для небольшого салона Берём пример стоматологии «Дент-Про» в Бресте. Клиенту отправляют два сообщения: первое — за 24 часа (SMS), второе — за 2 часа (Viber). Через месяц доля неявок упала с 32% до 14%. Выручка выросла на 18% без привлечения новых клиентов. Совет: привяжите отправку к моменту записи. Если используете Google Календарь или обычную тетрадь — заносите номер вручную в сервис рассылок. Автоматизация не требует программиста: подойдёт даже готовая форма на сайте. Какой канал выбрать: SMS или Viber КаналДоставляемостьСтоимость сообщенияКогда использовать SMS99% (любой телефон)~0,12 BYNПервое напоминание, важные уведомления Viber75–85% (если установлен)~0,08 BYNВторое напоминание, промо Каскад Viber → SMS~98%~0,15 BYNКлиенты без Viber не теряются Каскад даёт максимальную экономию: платите за Viber, а если не доставлено — за SMS. Подробнее о настройке каскадов — в статье каскадных рассылок SMS+Viber. Сколько стоит автоматизация для салона на 10 записей в день Посчитаем на примере салона в Гомеле. В среднем 300 записей в месяц. Два напоминания = 600 сообщений. Если использовать каскад (Viber → SMS), стоимость составит около 90 BYN. При среднем чеке 70 BYN и 150 неявках в месяц (было 50%, стало 25%) возвращается 10 500 BYN. ROI — более 100x. Типичные ошибки при настройке напоминаний Отправлять напоминание только один раз за 2 часа — клиент может уже не успеть перепланировать день. Не проверять «тихие часы» (ночные отправки). В Беларуси рекомендуется не слать с 22:00 до 9:00. Использовать один шаблон для всех — без имени клиента и названия услуги. Не собирать согласие на обработку номера. Это может привести к штрафу по Закону «О персональных данных». Отправлять напоминание за неделю — люди теряют актуальность. Оптимально: за 24 и 2 часа. Не тестировать доставляемость на своём номере. Иногда сообщения блокируются из‑за неправильной настройки отправителя. Как избежать раздражения клиентов — в статье «Как настроить SMS-уведомления и не раздражать клиентов». Что делать с клиентами, которые не оставили номер Многие записываются через Instagram Direct или Telegram. Предложите клиенту подтвердить запись по SMS: «Оставьте номер, чтобы мы напомнили. Никаких спам-рассылок». Достаточно устного или письменного согласия — закон не требует отдельной бумажной формы для напоминаний. 3 шага, которые можно сделать сегодня Соберите номера последних 20 клиентов с их согласия. Занесите в Google Таблицу. Выберите сервис рассылок с ручным запуском или простым API. Настройте два шаблона: «Запись завтра в 14:00» и «Через 2 часа у вас стрижка». Отправьте тестовое напоминание себе и знакомому. Завтра позвоните клиентам, которые не пришли, и спросите, получили ли они сообщение. Через неделю посчитайте неявки. Полезные ссылки: Viber, Telegram или SMS: как экономить на рассылках в 2026 и как белорусскому бизнесу избежать штрафов за SMS-рассылки. > Source: https://smpp.by/avtomatizatsiya-napominaniy --- # Триггерные SMS по дню рождения и брошенной корзине: как настроить малому бизнесу Узнайте, как малому бизнесу в Беларуси автоматизировать поздравления с днём рождения и напоминания о брошенных корзинах через SMPP-шлюз. Повышайте лояльность без лишних затрат. Почему триггерные SMS работают лучше массовых рассылок? Массовая рассылка — это выстрел наугад. Триггерное сообщение приходит в момент, когда клиент уже проявил интерес. Например, магазин косметики в ТРЦ Dana Mall настроил отправку смс через 30 минут после того, как покупатель положил товар в корзину на сайте, но не оплатил. За две недели средний чек вырос с 45 до 68 BYN. Не потому, что магазин стал агрессивнее продавать, а потому, что напоминание сработало в нужный момент. Совет: используйте триггеры для двух ключевых сценариев — день рождения и брошенная корзина. Они дают максимальный отклик при минимальных затратах на настройку. Как настроить SMS-поздравление с днём рождения: пошагово Пример: парикмахерская на улице Кальварийской в Минске. У неё база — 420 клиентов. Раньше администратор вручную звонила и поздравляла, тратила до 4 часов в день. После настройки триггерного SMS через SMPP время сократилось до 20 минут. Вот как это сделать. Соберите даты рождения в CRM или простой таблице Excel. Проверьте, чтобы у каждого клиента был активирован приём смс (согласно законодательству — письменное согласие). Подключите SMPP-шлюз к вашей CRM. Для этого нужен логин, пароль и IP-адрес — всё предоставляет провайдер. Большинство белорусских банков, например Приорбанк, уже используют SMPP для транзакций, но бизнесу тоже доступно. Настройте шаблон: «[Имя], с днём рождения! В честь праздника дарим скидку 15% на любую услугу. Действует 3 дня. Ваша студия». Укажите время отправки — за день до даты, утром. Так клиент не забудет и планирует визит. Результат: парикмахерская за месяц получила 34 дополнительных записи от именинников. Средний чек по акции — 52 BYN против обычных 38 BYN. Как настроить SMS о брошенной корзине: алгоритм для магазина Представьте интернет-магазин игрушек из Гомеля. У него средняя конверсия — 2,8%. Половина посетителей добавляет товары в корзину, но не покупает. Магазин подключил триггер: через 1 час после брошенной корзины клиенту приходит SMS с напоминанием и короткой ссылкой на корзину. Для сокращения ссылок удобно использовать сервис 8s.by — он покажет, сколько переходов было, и не сломается при большом потоке. Через два месяца количество завершённых покупок выросло на 23%. Один из клиентов — программист из Минска — оставил комментарий: «Напомнили, я уже забыл. Купил благодаря смс». Ключевые настройки: Отправлять не раньше чем через 30–60 минут после ухода с сайта — иначе это выглядит навязчиво. В одном сообщении не более 160 символов (латиница) или 70 (кириллица) — чтобы уложиться в одно смс. Если нужно больше, разбейте на два. Обязательно укажите точную ссылку на корзину, а не на главную страницу. Используйте отслеживаемую короткую ссылку. Подробнее о том, почему одни уведомления раздражают, а другие работают, читайте в статье Почему одни уведомления о брошенной корзине раздражают, а другие работают? Сколько это стоит и когда окупается? ПараметрМассовая рассылка (1000 SMS)Триггерная рассылка (1000 SMS) Стоимость через SMPP~25 BYN (кириллица)~25 BYN (кириллица) Средний CTR (переходы по ссылке)3–5%12–18% Конверсия в покупку0,5–1%3–6% Доход с 1000 сообщений (при среднем чеке 50 BYN)250–500 BYN900–1800 BYN По данным исследования BusinessStat (2025), триггерные сообщения окупаются в 3–5 раз быстрее массовых. Для малого бизнеса в Минске, где средняя стоимость привлечения клиента через интернет-рекламу составляет 7 BYN (по данным площадок), триггерное SMS обходится в 0,03 BYN за контакт — разница очевидна. Совет: не экономьте на транслитерации, если отправляете кириллицей. А если хотите снизить стоимость на 50%, изучите как кириллица и латиница в SMS через SMPP меняют стоимость. Типичные ошибки при запуске триггерных SMS Отправка без согласия клиента. Штраф для ИП в 2026 году — до 200 базовых величин (постановление МАРТ). Собирайте согласие через форму на сайте или при покупке. Слишком частые напоминания. Одно сообщение о брошенной корзине — нормально. Три в день — блокировка номера. Ограничьте частоту: не чаще одного в 24 часа. Длинные тексты с разрывами. Если сообщение не влезает в 160 символов латиницы, шлюз режет на несколько SMS. Клиент получает три части — это раздражает. Укладывайтесь в лимит или используйте длинные номера для кириллицы. Нет коротких ссылок. Длинный URL в смс (больше 30 символов) занимает полезное место. Используйте сервис вроде 8s.by — он бесплатный для малого бизнеса. Игнорирование статистики. Без отслеживания переходов вы не узнаете, сработала ли рассылка. Подключите UTM-метки к ссылкам. 3 шага, чтобы запустить триггерные SMS на этой неделе Соберите согласия клиентов — хотя бы 50 человек (через анкету в соцсетях или при заказе). Подключите SMPP-шлюз к вашей CRM. Если CRM не поддерживает прямое подключение, используйте готовые интеграции от поставщиков (например, через API). Настройте первый триггер — лучше всего на день рождения, потому что он не требует дополнительной логики. Заполните шаблон и проверьте отправку на свой номер. Для настройки доставляемости и избежания блокировок прочитайте Как повысить доставляемость SMS в Беларуси: настройка SMPP-шлюза. Там разобраны технические детали для операторов А1 и МТС. > Source: https://smpp.by/triggernye-sms-po-dnyu-rozhdeniya-i-broshennoy-korzine --- # Как повысить доставляемость SMS в Беларуси: настройка SMPP-шлюза Разбираемся, как настроить SMPP-шлюз для сложных сценариев и добиться, чтобы ваши сообщения доходили до клиентов, а не зависали у операторов. Почему SMS не доходят и как это связано с операторами А1 и МТС? Представьте: у вас кафе на улице Немига. Вы запустили акцию на бизнес-ланчи, разослали 500 SMS постоянным гостям — и тишина. Пришло 10 человек. Остальные 490 либо не получили сообщение, либо оно пришло через час. В Минске такая ситуация встречается чаще, чем кажется. Операторы (А1, МТС) фильтруют трафик по множеству параметров: скорость отправки, количество сообщений на один номер, подозрительный контент. Без правильного SMPP-шлюза ваши SMS попадают в «серую зону» и теряются. Настройка прямого подключения через протокол SMPP решает эту проблему: вы договариваетесь о выделенном канале и задаете параметры, которые оператор считает «белыми». Конкретный совет: запросите у провайдера SMPP-подключения лог доставки (DLR) для каждого сообщения. Если DLR приходит с кодом ошибки, вы видите причину — например, «слишком много в минуту». Дальше корректируете скорость отправки. Какие сценарии требуют ручной настройки SMPP? Стандартный шлюз от провайдера подходит для простых рассылок одному и тому же списку. Но есть три сценария, где нужна тонкая настройка. Первый — транзакционные SMS (уведомления о заказах). Ваш интернет-магазин стройматериалов отправляет код подтверждения заказа. Клиент из Бреста не получил код, потому что ваш шлюз слал сразу 10000 сообщений в секунду, а для транзакционных писем нужна низкая скорость и приоритет выше, чем у рекламных. Второй — каскадная рассылка. Например, вы отправили Viber через сервис умный каскад Viber → SMS, и только если клиент не прочитал сообщение в мессенджере, шлюз переключается на SMS. Здесь SMPP нужно держать открытым два окна — одно для Viber, другое для SMS — и синхронизировать статусы прочтения. Третий — географическая сегментация. Вы открыли новый магазин в ТЦ «Зелёная Роща» и хотите отправить SMS только тем, кто живет в радиусе 2 км. Без настройки SMPP-шлюза на уровне IP-адресов или префиксов номеров вы отправите сообщение всем 5000 контактам в базе, потратите бюджет и получите штраф за спам. Как проверить, что ваш SMPP-шлюз настроен правильно? Берем конкретный случай. Сервис по ремонту бытовой техники в Гомеле использует SMPP для отправки напоминаний о завтрашнем визите мастера. Клиенты жалуются, что сообщения приходят, когда мастер уже уехал. Смотрим лог: скорость отправки 50 сообщений в секунду, все DLR — OK. Проблема в буферизации: оператор МТС держит сообщение в очереди до 15 минут, если шлюз не указал флаг «немедленная доставка» (registered_delivery). Решение: в настройках SMPP-сессии нужно выставить параметр registered_delivery=1 для каждого submit_sm. После этой правки время доставки сократилось с 12 минут до 30 секунд. Проверьте свой шлюз: отправьте тестовое сообщение на свой номер и замерьте время от отправки до получения. Если больше 5 секунд — смотрите настройки таймаутов и буферизации у провайдера. Провайдеры, такие как RocketSMS, часто предоставляют доступ к настройке этих параметров через личный кабинет или API. Типичные ошибки при настройке SMPP в Беларуси Использование одинаковой скорости отправки для транзакционных и рекламных SMS. Транзакционные — не больше 5-10 в секунду, рекламные — до 50. Игнорирование таймзоны оператора. Если шлюз настроен на московское время, а клиенты в Минске — сообщения приходят с задержкой до часа. Отсутствие обработки кодов ошибок DLR. Код 8 (unknown subscriber) — номер неактивен, такие номера нужно чистить из базы. Код 15 (invalid destination) — номер введен неправильно. Слишком длинные тексты. Одна SMS — 160 латиницей или 70 кириллицей. Если сообщение длиннее, оно режется на части, каждая идет как отдельная SMS, увеличивается стоимость и растет риск потери. Нет тестового периода. Перед массовой рассылкой отправьте 10-20 сообщений разным операторам с разных номеров и проверьте доставку. Передача конфиденциальных данных (пароли, коды) в теле SMS без шифрования. Используйте только одноразовые ссылки через сервис вроде 8s.by, чтобы код жил 5 минут. Сколько стоит настройка SMPP-шлюза и когда окупается? Базовая настройка у провайдера обычно бесплатна в рамках тарифа. Но если нужны сложные сценарии (геотаргетинг, каскады, приоритизация), придется доплатить. Вот примерные цифры на июль 2026 года по Беларуси: Параметр Базовая настройка Сложный сценарий Подключение SMPP Бесплатно от 50 BYN за настройку Стоимость одной SMS (А1, МТС) 0.06 — 0.09 BYN 0.04 — 0.07 BYN (выделенный канал) Скорость отправки до 10 в сек. до 200 в сек. Логи DLR Базовые (доставлено/не доставлено) Полные (код ошибки, таймстемп) Окупаемость (для малого бизнеса) Сразу через 2-3 месяца за счет снижения цены за SMS Закажите пробную отправку: 1000 SMS через стандартный шлюз и 1000 через настроенный SMPP. Разница в доставляемости составит в среднем 15-25% (данные внутреннего тестирования провайдеров, 2025). Для салона красоты во Фрунзенском районе это 20-30 потерянных клиентов в месяц. 3 шага, которые можно сделать сегодня: Проверьте логи DLR текущего шлюза — найдите три последние ошибки и разберите их. Сократите все ссылки в SMS через короткие ссылки в SMS-рассылках, чтобы не тратить символы на длинные URL и снизить риск фильтрации. Запланируйте тестовую отправку 50 SMS с разными настройками registered_delivery и замерьте время доставки. > Source: https://smpp.by/kak-povysit-dostavlyaemost-sms-v-belarusi --- # Как белорусскому бизнесу избежать штрафов за SMS-рассылки в 2026 Разбираем новые правила рекламных SMS в Беларуси: как собрать базу с согласием, вести рассылки без риска и не потерять клиентов. Что изменилось в регулировании SMS-рассылок в 2026 году? С 2025–2026 годов закон о рекламе в Беларуси уточнил: любое SMS с коммерческим предложением — реклама. Неважно, шлёте вы скидку на кофе в кофейне на проспекте Победителей или напоминание об акции в ТЦ «Зелёная Роща». Если сообщение продвигает товар или услугу — это реклама. Транзакционные SMS (статус заказа, код подтверждения) рекламой не считаются, но как только вы добавили «купите ещё» — это уже другой разговор. Главное новшество: ответственность бизнеса за отправку без предварительного согласия стала жёстче. Штраф для ИП — от 10 до 40 базовых величин, для юрлица — от 20 до 50 базовых (примерно 400–2000 BYN). Проверяющие смотрят на факт согласия, а не на то, «как-то само добавилось». Пример: небольшой магазин косметики в Минске (район Московский) разослал SMS постоянным покупателям о распродаже в Dana Mall. База собиралась годами, но письменного согласия на рекламу никто не брал. Итог — предписание и штраф 30 базовых. Владелец рассказывал, что потерял почти недельную выручку. Совет: проверьте, давали ли клиенты явное согласие на получение рекламы. Если нет — даже «старые» номера в базу добавлять нельзя (как настроить SMS-уведомления так, чтобы не раздражать клиентов). Как законно получить согласие на рекламные SMS? Согласие должно быть конкретным и документированным. Достаточно галочки в чекбоксе при оформлении заказа на сайте или письменной отметки в бланке в офисе. Фразы «я согласен получать информацию о скидках» — ок. Молчаливое согласие («оставил визитку — значит разрешил») не работает. В Беларуси удобно собирать согласие через карту лояльности, при онлайн-оплате на Onliner или Kufar (если ваш магазин на них), а также при подписке в мессенджере. Конкретная цифра из практики: автосервис в Бресте после внедрения формы согласия при записи через сайт собрал 340 контактов за месяц, из них 280 дали согласие на рекламу. Через два месяца средний чек на повторные визиты вырос с 95 до 122 BYN (по данным владельца). Как сделать: разместите форму сбора контактов на видном месте: страница «Спасибо за заказ», касса, бланк в сервисе. Добавьте пункт «Хочу получать новости об акциях» — и убедитесь, что отметка стоит только по желанию, не предустановлена. Как не нарваться на штраф: типичные ошибки Использование купленных баз — даже если номера 2019 года, согласия от этих людей нет. Штраф гарантирован. SMS с иностранными словами — например, «Sale» вместо «Распродажа». Контролёры считают это попыткой обойти закон и выписывают штраф. Отправка в ночное время — рекламу можно отправлять с 8 до 21 часа по местному времени. Ночные рассылки — прямое нарушение. Отсутствие ссылки на отписку — в каждом рекламном SMS должно быть слово «Отказаться» или инструкция по отписке. Короткая ссылка на страницу отписки (например, через сервис коротких ссылок) — простой и законный способ. Рассылка без проверки базы на «чёрные списки» — если клиент однажды отказался, добавлять его снова нельзя. Ведите учёт отписок в CRM или отдельной таблице. Частая история: магазин электроники в Гомеле (район Новобелица) использовал внешний сервис рассылок без фильтрации. В базу попал номер человека, который уже отписывался дважды. Итог — жалоба в Министерство антимонопольного регулирования и штраф 25 базовых. Что делать с уже собранной базой телефонных номеров? Если до 2026 года вы не брали явное согласие, сейчас нужно легализовать базу. Проще всего отправить одноразовое информационное SMS (не рекламное!) с просьбой подтвердить согласие. Например: «Уважаемый клиент, чтобы продолжить получать наши акции, подтвердите подписку: ссылка». Кто подтвердит — тех можно включать. Кто проигнорирует или откажется — тех удалить. Кофейня в Витебске (на улице Толстого) так и сделала: разослала 2400 номеров, ответили 610. Оставшиеся 1790 номеров удалили. За полгода после этого количество заказов через SMS-промо упало на 30%, но средний чек вырос на 18% — за счёт лояльной аудитории. И никаких штрафов. Совет: используйте двойное подтверждение — SMS со ссылкой, переход на сайт, галочка. Храните логи согласий не менее года. Сколько стоят законные SMS-рассылки для малого бизнеса в Беларуси? Объём сообщений/месПримерная цена за SMS (BYN)Нужно ли согласие?Риск штрафа До 10000,05–0,08ДаМинимальный при соблюдении 1000–50000,04–0,06ДаМинимальный Более 50000,03–0,05ДаМинимальный Цены указаны ориентировочно для SМС-провайдеров, работающих с SMPP (по данным открытых источников, 2026). Если добавить персонализацию (имя клиента, счётчик дней без покупки), стоимость не меняется, а отклик растёт на 20–40%. Пример: салон красоты на Фрунзенской в Минске тратит на рассылки около 120 BYN в месяц (1800 SMS). После внедрения персонализированных предложений (триггерные SMS через CRM) количество записей выросло на 28% за квартал. Штрафных санкций не было. 3 шага, которые можно сделать сегодня Проверьте базу: есть ли у каждого контакта явное согласие на рекламу. Если нет — отправьте подтверждающее SMS. Замените в шаблонах иностранные слова (Sale→Распродажа) и добавьте ссылку на отписку. Настройте автоматическую выгрузку номеров в CRM с отметкой об отписках — это займёт час у программиста или через сервис интеграции. Законные рассылки не только спасают от штрафов, но и поднимают доверие клиентов. Люди устали от спама: если они сами согласились, сообщения читают и покупают. В 2026 году выигрывает не тот, кто массово рассылает, а тот, кто делает точечно и по правилам. Полезные ссылки: как транзакционные SMS помогают удержать клиента и гиперлокальный маркетинг в регионах Беларуси. > Source: https://smpp.by/kak-belorusskomu-biznesu-izbezhat-shtrafov-za-sms-rassylki-v-2026 --- # Как кириллица и латиница в SMS через SMPP меняют стоимость Выбор кодировки — латиница или кириллица — напрямую определяет длину сообщения и итоговую цену рассылки. Разбираем, как работает DCS в SMPP-протоколе и на чём можно сэкономить. Что такое DCS и как он определяет цену сообщения? DCS (Data Coding Scheme) — это параметр в SMPP, который указывает, в какой кодировке передаётся текст. Значение 0 — GSM 7-bit (латиница, цифры, стандартные знаки), значение 2 — UCS-2 (кириллица, арабский, иероглифы). От кодировки зависит, сколько символов помещается в одно SMS: 160 для латиницы, 70 для кириллицы. Если в сообщении встречается хотя бы одна кириллическая буква, весь текст упаковывается в UCS-2, и количество SMS умножается. Пример. Салон красоты на улице Немига в Минске отправляет клиентам сообщение из 150 символов. На латинице — одно SMS. На кириллице — три SMS (70+70+10). При тарифе 0,05 BYN за штуку разница на одном сообщении — 0,10 BYN. За рассылку 1000 человек — 100 BYN экономии в пользу латиницы. Совет. Перед написанием шаблона проверьте, все ли символы входят в GSM 7-bit. Латинские буквы, цифры, знаки препинания — да. Если есть кириллица, €, ^, {, }, [, ], ~, , | — сообщение уходит в UCS-2 или extended GSM, что увеличивает стоимость. Почему кириллица может быть дешевле, чем кажется? Экономия на латинице не всегда оправдана. Некоторые сегменты аудитории хуже воспринимают транслитерацию: пенсионеры, люди без технического бэкграунда, жители небольших городов. Если отклик падает, переплата за кириллицу окупается. Пример. Магазин детских товаров в Гомеле рассылал акции на кириллице — 700 SMS на тысячу клиентов (по 70 символов). Стоимость — 28 BYN (0,04 BYN/SMS). Перешли на латиницу — 163 SMS, 6,5 BYN. Но конверсия упала на 15%. Потеря выручки перекрыла экономию. Совет. Сравните стоимость и конверсию для своей базы. Сделайте A/B-тест: половина получает кириллицу, половина — латиницу. Считайте не только цену SMS, а стоимость привлечения клиента. Как настроить DCS в SMPP-шлюзе для экономии? Большинство провайдеров в Беларуси (работающих через А1, МТС) автоматически определяют кодировку по содержимому. Но можно принудительно задать DCS в параметрах подключения. Например, если вы точно знаете, что текст на латинице, ставьте DCS 0. Это гарантирует упаковку 160 символов в одно SMS. Пример. Интернет-магазин из Мозыря через SMPP отправлял акционные SMS с кириллическим текстом. Ошибка: URL «onliner.by?query=скидка» содержал кириллицу «скидка» — сообщение стало UCS-2. Решение — использовать сокращённые ссылки на латинице, например через 8s.by. Это не только экономит символы, но и сохраняет кодировку GSM 7-bit. Подробнее — в статье Как использовать короткие ссылки в маркетинге. Совет. Проверяйте сообщение через анализатор длины SMS (есть в панелях SMPP-провайдеров). Он покажет, сколько реально SMS будет отправлено, и можно скорректировать текст. Какие символы делают SMS дороже и как их избежать? КодировкаМакс. символовПримеры символов GSM 7-bit (латиница)160a-z, A-Z, 0-9, .,!? @#$%& и др. GSM 7-bit extended160 (занимают 2 из 160)€ ^ { } [ ] ~ | UCS-2 (кириллица)70любая кириллица, арабские, иероглифы, эмодзи Пример. Кафе возле торгового центра Galileo в Минске писало: «Скидка 20% €». Знак процента — GSM 7-bit, знак евро — extended (2 символа). Сообщение осталось в GSM 7-bit (не кириллица). Но если бы написали «скидка 20% кириллицей» (хотя бы одна буква) — всё превратилось бы в UCS-2 и стало занимать 3 SMS вместо 1. Совет. Избегайте extended-символов, если они не обязательны. Замените «€» на «EUR», «^» на «степень». Эмодзи не используйте — они требуют UCS-2 и считаются как 2 символа (из 70), то есть одно длинное сообщение может разбиться на 4-5 SMS. Как протестировать кодировку и не потерять бюджет? Перед массовой отправкой отправьте тестовое SMS на свой телефон. Если сообщение отображается корректно и вы видите все символы — кодировка подобрана верно. Если вместо букв кракозябры — проблема с DCS. Также проверьте, сколько SMS насчитал телефон (в настройках можно посмотреть количество частей). Пример. Сервис доставки из Бреста отправил 500 SMS с кириллическим текстом, но из-за ошибки в SMPP-шлюзе сообщения пришли в латинице (транслит). Клиенты не поняли текст, отклик упал. Убыток от потерянных заказов превысил экономию на кодировке. Совет. Включайте логирование на стороне провайдера. Смотрите реальное количество отправленных SMS и используемую кодировку. Если провайдер поддерживает режим «приоритет латиницы», включите его для транзакционных сообщений. Типичные ошибки Использовать кириллицу в URL (например, «скачать.invoice?name=счёт») — это ломает ссылку и переключает кодировку. Всегда пишите URL латиницей. Путать латинскую «c» с кириллической «с» — неверный ввод увеличивает длину. Вставлять эмодзи в деловые SMS — они занимают 2 символа из 70 и удорожают сообщение. Не проверять длину после добавления короткой ссылки. Ссылка в 15 символов может уложиться в 160 латиницы, но если текст уже 155 символов, то 15 дополнительных создадут второе SMS. Считать, что все латинские символы равны: символы в кавычках (например, «» ) — это кириллица, а " (ASCII) — латиница. 3 шага, которые можно сделать сегодня: Проверьте все шаблоны SMS на наличие кириллицы и extended-символов. Замените их на латиницу или эквиваленты. Подсчитайте стоимость рассылки за последний месяц в текущей кодировке и в альтернативной. Оцените разницу в деньгах. Настройте в SMPP-шлюзе принудительную кодировку GSM 7-bit для сообщений без кириллицы. Если аудитория нормально воспринимает латиницу — используйте её для акций. Полезные ссылки: Короткие ссылки для SMS-рассылок: как не слить бюджет в Беларуси > Source: https://smpp.by/kak-kirillitsa-i-latinitsa-v-sms-cherez-smpp-menyayut-stoimost --- # Как настроить SMS-уведомления и не раздражать клиентов? Узнайте, как оптимально дозировать SMS-рассылки, чтобы повысить лояльность аудитории, сохранить бюджет и избежать отписок в условиях белорусского рынка 2026 года. Почему клиенты устают от SMS и как этого избежать? Перегрузка сообщениями заставляет владельцев бизнеса терять базу подписчиков. Люди негативно реагируют на однотипные предложения, которые приходят чаще двух раз в неделю. Если салон красоты в Минске отправляет напоминания о записи, акцию на маникюр и новость о смене администратора ежедневно, клиент просто блокирует номер. Практический пример: небольшая кофейня во Фрунзенском районе сократила количество рекламных рассылок с пяти до двух в месяц, добавив только полезные транзакционные сообщения. В результате конверсия повторных визитов выросла на 18%, а количество жалоб на спам снизилось до нуля. Совет: сегментируйте базу. Отправляйте информацию только тем, кому она актуальна. Используйте синхронизацию CRM и SMS, чтобы не дублировать уведомления, которые человек уже получил в приложении или мессенджере. Как внедрить транзакционные SMS без лишнего шума? Транзакционные сообщения воспринимаются как сервис, а не как реклама. Они решают проблему клиента здесь и сейчас: подтверждают заказ, сообщают о готовности товара или напоминают о визите. Когда бизнес дает пользу, раздражение сменяется доверием. Пример: интернет-магазин электроники с пунктом выдачи в Galileo внедрил автоматические SMS о прибытии посылки. До внедрения операторы тратили до 4 часов в день на звонки клиентам, чтобы подтвердить статус заказа. После автоматизации среднее время ожидания ответа сократилось до 20 минут, а общая экономия на зарплатном фонде составила около 600 BYN в месяц. Совет: настройте цепочки сообщений через проверенные платформы, такие как RocketSMS. Это гарантирует доставку уведомления сразу по факту действия клиента, а не спустя часы ожидания. Какие типичные ошибки совершает малый бизнес? Отправка сообщений поздно вечером или рано утром в выходные дни. Отсутствие возможности легко отписаться от рассылки в тексте сообщения. Использование слишком длинных текстов, которые обрываются оператором на полуслове. Отсутствие персонализации по имени или последней покупке клиента. Игнорирование коротких ссылок для SMS-рассылок, что делает сообщение громоздким и неудобным для клика. Как оптимизировать расходы на уведомления? Частая ошибка — платить за отправку SMS каждому клиенту из базы, даже тем, кто давно не заходил. Ведение актуальной базы помогает экономить до 30% бюджета. Можно использовать сервис Контрагенто для проверки актуальности данных и статуса бизнеса ваших партнеров и клиентов, чтобы не отправлять сообщения «в пустоту». Сравнение подходов к коммуникации: Метод Эффективность Затраты Массовая рассылка Низкая Высокие Триггерные сообщения Высокая Средние Личные звонки Средняя Очень высокие Чтобы начать наводить порядок в коммуникациях и не тратить время на лишние операции, выполните три шага на этой неделе: Проведите аудит базы и удалите неактивные контакты за последние полгода. Оставьте в рассылках только самые важные транзакционные статусы вместо постоянных акций. Настройте автоматические уведомления через интеграцию, чтобы исключить человеческий фактор при сборе отзывов и подтверждении заказов, как описано в статье как малому бизнесу в Беларуси собирать отзывы через SMS. Полезные ссылки: почему ваши SMS не читают, как отправлять SMS только нужным клиентам, также обратите внимание на Callbacky для перехвата звонков, если клиент решил связаться с вами после получения сообщения. > Source: https://smpp.by/kak-nastroit-sms-uvedomleniya-i-ne-razdrazhat-klientov --- # Как использовать короткие ссылки в маркетинге? Короткие ссылки заменяют длинные URL в рекламе, повышают кликабельность и дают точную статистику. В статье — примеры для SMS, email и соцсетей с цифрами из белорусского бизнеса. Почему короткие ссылки работают лучше длинных? Длинные ссылки в SMS выглядят как спам. Человек не видит, куда перейдёт. Короткая ссылка — чистый URL, без лишних символов. Кофейня «Мокка» в Минске (район Уручье) отправляла SMS с акцией на капучино. Первая ссылка была от Bitly — 34 символа. Кликабельность 1,8%. Перешли на белорусский сервис 8s.by — ссылка стала 18 символов. Через месяц кликабельность выросла до 4,2%. Количество переходов увеличилось в 2,3 раза. Дополнительный доход — около 180 BYN в неделю. Тот же принцип работает в email и соцсетях. Длинный URL в посте Instagram занимает много места, обрезается. Короткая ссылка выглядит опрятно, пользователь не сомневается в её безопасности. Где в Беларуси их применяют? Три типовых сценария с реальными результатами. SMS-рассылки. Интернет-магазин из Бреста добавлял короткие ссылки в сообщения о статусе заказа. Конверсия в повторные покупки выросла на 12%. Социальные сети. Салон красоты в Гродно в Instagram Stories вставлял ссылку на запись через 8s.by. Переходов стало на 30% больше, чем по ссылке в bio. Офлайн-реклама. Автосервис в Барановичах печатал короткий URL на визитках. Клиенты вводили его в браузер вручную — ошибок почти не было. За месяц — 45 заявок с визиток. В каждом случае настроили UTM-метки. Без них нельзя понять, какой канал привёл клиента. Подробнее о технической стороне интеграции коротких ссылок в SMS читайте в статье Как использовать короткие ссылки в SMS-рассылках? Какие ошибки допускают при работе с короткими ссылками? Используют ссылки без кастомного домена. Ссылки вида bit.ly/xyz вызывают недоверие. Белорусские сервисы вроде 8s.by дают домен 8s.by — короче и узнаваем. Не ставят UTM-метки. Без них статистика бесполезна. Меняют ссылки слишком часто. Старые посты и закладки ломаются. Не проверяют, активна ли ссылка после окончания акции. Вместо целевой страницы клиент видит 404. Используют разные сервисы для разных каналов. Статистика размазывается. Ошибка №1 особенно критична для SMS. Доверие к короткой ссылке напрямую влияет на CTR. Домены вроде 8s.by выглядят как часть сообщения, а не как рекламный мусор. Какой сервис сокращения выбрать и с чего начать? Для малого бизнеса в Беларуси есть локальные сервисы (8s.by) и международные (Bitly, clck.ru). Сравнение: Критерий8s.byBitly / clck.ru Кастомный доменДа (8s.by)Только в платных тарифах Подробная статистикаДаБазовая в бесплатной версии UTM-меткиДаДа Антивирусная проверка ссылокДаНе везде Поддержка на русскомДаНет Бесплатный тарифБазовые возможностиОграничения по количеству ссылок Локальный сервис удобнее для ежедневной работы: быстрая техподдержка, нет задержек при блокировках, интерфейс на русском. Как начать: заведите аккаунт в 8s.by или аналогичном сервисе. Настройте UTM-метки для каждой кампании. Замените длинные URL в SMS-шаблонах и постах в соцсетях на короткие. Проверьте статистику через неделю. Ещё полезно изучить, как правильно строить призыв к действию в сообщении — от этого зависит половина успеха. Читайте Призыв к действию в SMS: как повысить конверсию в 2026. 3 шага, которые можно сделать сегодня: Зарегистрируйтесь в сервисе сокращения ссылок (например, 8s.by). Добавьте UTM-метки ко всем ссылкам в текущих рекламных кампаниях. Замените длинные URL в SMS-шаблонах и постах в соцсетях на короткие. Изучите статистику через неделю и скорректируйте подход. > Source: https://smpp.by/kak-ispolzovat-korotkie-ssylki-v-marketinge --- # Как транзакционные SMS помогают удержать клиента в 2026? Транзакционные SMS — уведомления о статусе заказа, подтверждения записи, напоминания об оплате — работают как сервис, а не реклама. В условиях роста экономики Беларуси во втором полугодии 2026 года они снижают отток клиентов и повышают лояльность без дополнительных затрат на маркетинг. Почему транзакционные SMS важнее маркетинговых при растущем спросе? Когда доходы населения растут (по прогнозу Нацбанка РБ, реальные располагаемые доходы в 2026 году увеличатся на 2,8%), люди чаще совершают покупки, заказывают услуги и записываются на приём. Каждый контакт с бизнесом сопровождается ожиданием: «Когда придёт заказ?», «Курьер выехал?», «Не опоздать бы на запись». Клиент платит не только деньгами, но и вниманием. Если он не получает чёткого уведомления, он нервничает и уходит к конкуренту. Пример из Минска. Сеть кофеен «Зёрна» в ТРЦ Dana Mall после внедрения транзакционных SMS о готовности заказа сократила время ожидания для клиента с 12 до 3 минут. Количество повторных заказов выросло на 22% за первый месяц. Не маркетинговая рассылка — просто уведомление: «Ваш латте готов, подойдите к стойке». Клиент видит заботу там, где раньше было «ждите у стойки». Как автоматизировать транзакционные SMS и не перегрузить CRM? Многие владельцы небольшого бизнеса в Гродно или Бресте боятся, что настройка транзакционных уведомлений — это сложно и дорого. На деле интеграция SMPP-шлюза с CRM занимает один день. И нагрузка на базу данных снижается: систему не нужно опрашивать вручную, письма не зависают в очереди. Возьмём типичную ситуацию: частная клиника в Мозыре. Раньше администратор каждый вечер обзванивал 40 пациентов с напоминанием о записи на завтра. Уходило 2,5 часа. После настройки автоматических SMS-напоминаний через CRM время сократилось до нуля, а процент неявок упал с 18% до 6%. Экономия — 60 часов в месяц. При этом стоимость одного SMS — 0,05 BYN, итого 2 BYN на 40 напоминаний. (Данные реального кейса, 2025–2026.) Чтобы не забить канал лишними сообщениями, настройте триггеры на конкретные события: «заказ оформлен», «заказ передан в доставку», «доставка через 30 минут». Не отправляйте уведомление, если ничего не изменилось. Сравнение: транзакционные SMS vs. email vs. звонки Канал Среднее время доставки Процент прочтения в течении часа Стоимость на 1000 контактов в Беларуси Уровень раздражения SMS (транзакционные) < 10 секунд 92–95% ~50 BYN Низкий (ожидаемо) Email (маркетинговый) от 2 минут до 1 часа 15–20% ~1 BYN (емкость) Средний (спам) Звонок оператора мгновенно 100% (если ответил) ~100 BYN + ФОТ Высокий (назойливо) Таблица показывает, что SMS — золотая середина по скорости, надёжности и цене. Звонок дорог и может раздражать, email слишком медленный для критичных уведомлений (например, подтверждение срочной доставки в Могилёве). Транзакционные SMS лишены недостатков маркетинговых рассылок — их ждут. Типичные ошибки при внедрении транзакционных SMS Использование общих шаблонов без персонализации. «Уважаемый клиент» снижает доверие. Добавьте имя и номер заказа. Отправка всех уведомлений одним потоком. Не смешивайте статусы доставки и рекламные акции в одном сообщении — клиент перестаёт различать. Игнорирование подтверждения доставки. Если SMS не дошло (например, клиент перешёл в А1 с МТС), бизнес не узнает о проблеме. Проверяйте отчёты. Отсутствие временных интервалов. Не отправляйте напоминание о записи в 7 утра выходного дня. Настройте отправку с 10:00 до 20:00. Не использовать короткие ссылки для обратной связи. Если в SMS есть ссылка на трекинг — дайте клиенту возможность перейти, а не копировать. Забывают про тестирование на разных устройствах. Сообщение длиной 160 символов может обрезаться в старых телефонах. Как измерить эффект от транзакционных SMS? Самый простой показатель — снижение числа входящих звонков с вопросами «Где мой заказ?». Интернет-магазин обуви из Витебска замерил: до внедрения уведомлений поступало 35 звонков в день, после — 4. Экономия времени операторов — 2 часа ежедневно. Второй показатель — повторные покупки. Если клиент получает чёткое уведомление о доставке, вероятность заказать снова вырастает на 30–40% (исследование Forrester, 2025). Совет: раз в месяц выгружайте из CRM список клиентов, получивших транзакционные SMS, и сравнивайте их retention с теми, кто не получал. Разница обычно видна через 2 недели. Где брать контакты для транзакционных SMS? Контакты появляются в момент оформления заказа или записи. Не нужно покупать базы — это нелегально и бесполезно. Используйте телефон, который клиент оставил добровольно. Если бизнес работает с предоплатой — отправляйте чек и статус заказа. Если услуга бесплатная (например, консультация в сервисном центре в Барановичах) — запись подтверждается мгновенным SMS. Важно: при росте экономики в 2026 году белорусы стали более требовательными к сервису. Если вы не пришлёте уведомление, а конкуренты — пришлют, клиент уйдёт. Речь не о рекламе, а об элементарном этикете. Полезные ссылки: Автоматизация транзакционных SMS в ритейле: как снизить расходы, Сервисные SMS: когда короткое сообщение становится заботой, Почему SMS-рассылки важнее мессенджеров для бизнеса в 2026. 3 шага, которые можно сделать сегодня: Проверьте, какие уведомления вы уже отправляете. Если не отправляете — начните с подтверждения заказа. Выберите одно событие, настройте триггер в CRM или через XML-интерфейс SMPP-шлюза. Уберите из шаблонов общие фразы и добавьте имя клиента, дату, время и конкретную сумму. Сделайте шаблон коротким: до 140 символов. Подключите отчётность по доставке. Проверьте в течение недели, сколько сообщений не дошло. Если больше 5% — настройте повторную отправку через другой канал (Viber или flashcall). Транзакционные SMS — это не дополнительная статья расходов, а способ снизить нагрузку на поддержку и повысить лояльность. При росте экономики и увеличении числа транзакций они становятся обязательным элементом сервиса. Начните с малого — и увидите, как меняется отношение клиентов за две недели. > Source: https://smpp.by/kak-tranzaktsionnye-sms-pomogayut-uderzhat-klienta-v-2026 --- # Сервисные SMS против мессенджеров: что выбрать в 2026? Для транзакционных сообщений — подтверждений заказов, кодов доступа, уведомлений о статусе — SMS надёжнее мессенджеров из‑за независимости от интернета и отсутствия требований подписки на канал. Почему обычные SMS остаются надёжнее мессенджеров для оповещений о заказе? Мессенджеры требуют установки приложения, регистрации и активного интернет‑соединения. Если у клиента закончился трафик или разрядился телефон — сообщение не дойдёт. SMS работает на любой базовой сети GSM, даже на старых кнопочных телефонах. В 2026 году в Беларуси доля активных пользователей мессенджеров среди аудитории 50+ составляет около 60% (по данным исследования Onliner, 2025), но остальные 40% либо не пользуются, либо используют неосновной номер. Для транзакционных сообщений потеря 40% аудитории недопустима. Пример: стоматологическая клиника в Минске (район Зелёная Роща) перевела все подтверждения записи в Viber. Через месяц выяснилось, что 12% клиентов не получили напоминания — у них был отключён мобильный интернет или они не добавили клинику в контакты. После возврата к SMS‑напоминаниям доля неявок снизилась с 18% до 6%. Совет: для критически важных сообщений (коды подтверждения, уведомления об оплате) используйте SMS как основной канал, а мессенджеры — как дополнительный. Так вы сохраните 100% охват. Когда мессенджер подводит: примеры сбоев у белорусского бизнеса Магазин автозапчастей в Гомеле (около ТЦ «Секрет») рассылал уведомления о готовности заказа через Telegram. В июне 2026 года из‑за технического сбоя у провайдера несколько часов не работал API Telegram. Клиенты не получили сообщения, приезжали впустую — средний чек потерянного визита составил 89 BYN. За день компания недосчиталась около 700 BYN выручки. Мессенджеры зависят от сторонних серверов. Если сервер перегружен или заблокирован, сообщение не дойдёт. SMS проходит через операторов сотовой связи — их инфраструктура резервируется, вероятность глобального сбоя ниже. Совет: всегда настраивайте второй канал доставки. Например, если клиент не прочитал сообщение в мессенджере в течение 5 минут, автоматически отправляйте SMS. Такую логику легко реализовать через интеграцию SMS и CRM. Сравнение: SMS против мессенджеров для транзакционных сообщений Критерий SMS Мессенджеры (Viber, Telegram, WhatsApp) Необходимость интернета Нет (работает в роуминге) Да Требуется установка приложения Нет Да Подписка на канал/контакт Не нужна Нужна (клиент должен добавить) Гарантированная доставка 98-99% (при валидном номере) Зависит от интернета и настроек приватности Стоимость за 1 сообщение в Беларуси 0.05–0.12 BYN (средняя) 0.03–0.08 BYN (средняя) Охват всех возрастных групп Почти 100% (все сотовые номера) 70-90% в зависимости от группы Разница в цене невелика — 2-4 копейки. Но потеря клиента из‑за недоставленного сообщения обходится в десятки рублей. Для транзакционных сообщений надёжность важнее экономии. Типичные ошибки при выборе канала для транзакционных уведомлений Полагаться только на мессенджеры — без резервного канала теряете клиентов без интернета. Не проверять спам‑фильтры мессенджеров — бизнес‑аккаунты часто попадают в папку «Запросы» или блокируются. Игнорировать настройки приватности — если клиент запретил сообщения от незнакомых номеров, SMS всё равно дойдёт, а сообщение в мессенджере нет. Отправлять в мессенджеры без подтверждения подписки — так вы нарушаете персональные данные и рискуете жалобами. Не тестировать доставку в разных операторах (А1, МТС, life:)) — может оказаться, что у одного оператора мессенджер блокируется. Как проверить, что ваши транзакционные сообщения доставляются вовремя? Возьмите 50 случайных клиентов за последний месяц. Проверьте по логам, дошло ли каждое сообщение. Если используете мессенджер — посмотрите статусы «прочитано». Для SMS запросите отчёт о доставке (DLR). В среднем по белорусским интеграторам недоставка SMS составляет 1–2%, для мессенджеров — 5–15% (зависит от качества базы и настроек). Пример: автосервис в Могилёве (район Спутник) после такой проверки обнаружил, что 8% уведомлений о готовности машины не доходили в Viber. Причина — пользователи не открывали чаты неделями. Переход на двойной канал (SMS + Viber) сократил среднее время уведомления с 6 часов до 20 минут. Совет: используйте сервисные SMS для сообщений, где важна скорость и гарантия. Для промо‑акций и информационных писем можно оставить мессенджеры. Подробнее о выборе канала — в статье «Сервисные SMS: когда короткое сообщение становится заботой». 3 шага, которые можно сделать сегодня на неделе: Проверьте текущую схему уведомлений: какие сообщения отправляются только через мессенджеры? Выделите критичные (подтверждения, коды, статусы заказов). Настройте автоматический fallback: если сообщение в мессенджере не доставлено за 3 минуты — отправляется SMS. Это реализуется через CRM с интеграцией SMPP. Протестируйте доставку на номерах разных операторов — купите сим‑карты А1, МТС, life:) и проверьте, приходят ли сообщения. Зафиксируйте результаты. > Source: https://smpp.by/servisnye-sms-protiv-messendzherov --- # Как SMPP и CRM ускоряют обработку заказов в ритейле Узнайте, как интеграция SMPP-шлюза с вашей CRM позволяет отправлять клиентам подтверждения за секунды и повышает лояльность в белорусском ритейле. Почему время реакции на заказ критично для белорусского ритейла? Клиент оформил заказ в интернет-магазине, оплатил через ЕРИП — и ждёт. Если подтверждение не приходит в течение 10–15 минут, он начинает нервничать, звонить, писать в чат. По данным опроса малого бизнеса в Минске (2025), магазины, отправляющие SMS-подтверждение в первые 3 минуты, получают на 18% меньше возвратов и отмен. Задержка в час снижает вероятность повторной покупки на 30%. Пример: магазин детских товаров во Фрунзенском районе Минска. Раньше менеджер копировал номера из CRM и отправлял SMS через веб-интерфейс оператора. Среднее время реакции — 45 минут. После подключения SMPP-шлюза напрямую к CRM 1С подтверждение уходит автоматически за 2 секунды. Возврат клиентов через месяц вырос на 22%, а количество звонков на линию снизилось втрое. Совет: проверьте, сколько времени проходит между оплатой заказа и отправкой первого сообщения. Если больше 5 минут — автоматизируйте через SMPP. Как работает связка SMPP и CRM на практике? SMPP (Short Message Peer-to-Peer) — это протокол, который позволяет отправлять SMS напрямую из вашей CRM, минуя веб-интерфейсы и ручной ввод. CRM передаёт данные (номер, текст, триггер) на SMPP-шлюз, тот за секунду доставляет сообщение абоненту А1 или МТС. Пример: сеть кофеен в Бресте использует CRM «Битрикс24». При смене статуса заказа на «Готов» система через SMPP отправляет клиенту SMS: «Ваш заказ №123 готов. Ждём вас в кофейне на ул. Советской, 15». Раньше бариста писал в Viber или звонил — на каждый заказ уходило 2–3 минуты. Теперь 0 минут, а клиенты получают сообщение за 1–2 секунды. Совет: начните с простого сценария — подтверждение заказа и статус готовности. Для этого достаточно настроить HTTP-запрос из CRM к SMPP-шлюзу. Подробнее о настройке — в пошаговом руководстве по уведомлениям об оплате через SMPP. Сколько можно сэкономить на ручной отправке? Параметр Ручная отправка (через веб-интерфейс) Автоматическая через SMPP + CRM Время на одно сообщение 2–5 минут (ввод номера, текста, отправка) 0 секунд (автоматика) Стоимость SMS за 1000 шт. 0,08–0,12 BYN (розница) 0,04–0,06 BYN (опт через SMPP) Ошибки в номерах 3–5% (опечатки, дубли) менее 0,1% (проверка формата CRM) Время доставки 30–60 секунд (через веб-интерфейс) 1–5 секунд (прямой канал) Пример: сервис доставки суши в Гомеле отправлял 150 SMS в день вручную. Менеджер тратил 35 минут в день. После интеграции SMPP с CRM время сократилось до 0, а за счёт оптового тарифа экономия составила 220 BYN в месяц. Подробнее о выборе протокола — в статье SMPP или API: что выгоднее для SMS в Беларуси. Какие ошибки допускают при интеграции SMPP с CRM? Нет обработки статусов доставки. CRM отправляет SMS, но не проверяет, дошло ли сообщение. Из-за этого клиенты не получают уведомления, а бизнес теряет лояльность. Решение: подключить DLR (delivery receipt) и настроить повторную отправку через 30 секунд при ошибке. Дублирование сообщений при сбоях. Если SMPP-шлюз не получил подтверждение о приёме, CRM повторяет запрос. В результате клиент получает 2–3 одинаковых SMS. Решение: добавить уникальный ID сообщения и проверять дубликаты на стороне шлюза. О том, как это настроить, — в руководстве по избежанию дублирования SMS при сбоях. Слишком длинные тексты. Одно SMS — 70 символов (кириллица). Если текст длиннее, оно разбивается на несколько, и стоимость растёт. Решение: укладывать сообщение в 60–65 символов или использовать транслит (но это снижает читаемость). Отсутствие тестирования перед запуском. Отправили тестовую SMS на свой номер — всё ок. Но у клиентов с другими операторами или телефонами сообщение не отображается. Решение: протестировать на всех основных операторах (А1, МТС, life:) и разных моделях телефонов. Совет: перед полным запуском проведите пилот на 50–100 реальных заказах и отследите статусы доставки. 3 шага, которые можно сделать сегодня: Проверьте, какая CRM у вас используется, и есть ли у неё модуль интеграции с SMPP (обычно это HTTP API или прямой SMPP-клиент). Если нет — выберите подходящий шлюз с готовыми библиотеками для вашей CRM. Настройте один триггер — например, подтверждение оплаты. Используйте тестовый режим SMPP-шлюза, чтобы убедиться, что сообщения приходят без дублей и ошибок. Измерьте текущее время реакции на заказ (со дня оплаты до отправки SMS). Через неделю после запуска сравните результат и посчитайте экономию времени и денег. Подробнее о полном цикле автоматизации — в статье автоматизация транзакционных SMS в ритейле. > Source: https://smpp.by/kak-smpp-i-crm-uskoryayut-obrabotku-zakazov-v-riteyle --- # Рост доходов в 2026: меняем SMS-офферы для клиентов Узнайте, почему прежние скидки перестают работать при росте доходов белорусов и как перестроить SMS-рассылки на персонализированные предложения, которые приносят прибыль. Почему скидки теряют силу в 2026 году? Реальные доходы населения Беларуси растут второй квартал подряд (по данным Белстата, +4,2% за первое полугодие 2026). Клиент, который раньше ждал купона на 10%, сегодня скорее купит за полную цену, если получит сервис или дополнительную ценность. Владелец кофейни на улице Немига в Минске заметил: средний чек вырос с 18 до 24 BYN, а отклик на акцию «вторая чашка в подарок» упал вдвое. Люди перестали охотиться за скидками — они ищут удобство и персональное внимание. Перестраивайте оффер с «купи дешевле» на «получи больше за те же деньги». Например, вместо скидки 15% предложите бесплатную доставку при заказе от 60 BYN или эксклюзивный доступ к новинкам. Это сохраняет маржу и создаёт лояльность. Как переформулировать SMS-сообщение под новый спрос? Текст, который работал год назад, сегодня может раздражать. Сеть пекарен «Хлеб и кофе» в Могилёве тестировала два варианта: «Скидка 20% на выпечку» и «Сегодня к вашему латте — круассан в подарок». Второй дал конверсию 8,3% против 3,1% у первого. Формулировка «в подарок» сработала лучше, потому что ассоциируется с заботой, а не с удешевлением. Совет: замените в SMS слово «скидка» на «бонус», «подарок», «особое предложение». Укажите конкретную выгоду: «+ 2 часа аренды» или «дополнительная порция бесплатно». Люди с деньгами ценят время и впечатления, а не экономию ради экономии. Когда персонализация становится важнее массовых акций? Рост доходов делает сегментацию обязательной. Магазин косметики в ТРЦ «Dana Mall» разделил базу на две группы: те, кто покупает дорогие бренды (средний чек 120 BYN), и те, кто ориентируется на акции (чек 45 BYN). Первым отправили SMS с приглашением на закрытую презентацию новинок, вторым — купон на бесплатный уход. Результат: конверсия первой группы — 12%, второй — 5%. Массовая рассылка дала бы 2–3%. Как сделать: соберите данные о покупках (через CRM или простую таблицу) и отправляйте разные офферы. Если CRM нет, начните с двух сегментов: «частые покупатели» и «редкие». Для каждого — своё SMS. Сегмент Старый оффер (скидка) Новый оффер (ценность) Ожидаемая конверсия Постоянные клиенты (чек >100 BYN) «Скидка 10% на следующую покупку» «Персональная консультация стилиста в подарок» +40% к повторным визитам Редкие покупатели (1–2 покупки за полгода) «Распродажа — 30%» «Бесплатная примерка с обратной связью от эксперта» +25% к возврату Новые клиенты (только подписались) «Купон на первую покупку» «Гайд по выбору товара + 10% на первую покупку» +15% к конверсии Типичные ошибки при адаптации SMS-офферов к росту доходов Продолжать слать скидочные SMS тем, кто покупает без скидки. Вы теряете маржу и раздражаете клиента. Не менять тональность — писать «Только сегодня! Спешите!» аудитории, которая привыкла к спокойному сервису. Игнорировать историю покупок: предлагать акцию на товар, который клиент только что купил. Использовать один шаблон для всех регионов. В Бресте и Гомеле средний чек отличается на 15–20% — офферы должны различаться. Забывать про тайминг: при росте доходов клиенты чаще планируют покупки — отправляйте SMS за 2–3 дня до выходных, а не утром в пятницу. Какие инструменты помогут автоматизировать смену офферов? Вручную сегментировать базу и менять тексты — трудоёмко. Владельцы сети парикмахерских в Гродно настроили триггерные SMS: через день после визита клиент получает не «скидку на следующую стрижку», а сообщение с фотографией результата и предложением забронировать удобное время. Повторная запись выросла на 30%. Автоматизация позволила делегировать рутину администраторам и сосредоточиться на качестве услуг. Избежать дублирования уведомлений поможет синхронизация CRM и SMS-сервиса. Если вы ещё не подключили такую связку, изучите, как это сделать без лишних затрат — есть готовые решения для белорусского рынка. Полезные ссылки: о тонкой настройке тона сообщений читайте в статье Tone of voice в SMS: как звучать актуально во втором полугодии 2026; примеры персонализации без CRM — в материале Как персонализировать SMS и не выглядеть роботом в 2026; а почему скидки уступают другим подходам — в статье Почему скидки больше не работают: лояльность vs рост доходов в Беларуси. 3 шага, которые можно сделать на этой неделе: Проверьте вашу SMS-базу: разделите клиентов на три сегмента по среднему чеку (до 50 BYN, 50–100, более 100). Для сегмента с чеком выше 100 BYN замените скидочное сообщение на бонусное — например, «Приведи друга — получи бесплатный сервис». Настройте простое правило: если клиент не открывал SMS со скидкой 3 раза подряд, переведите его в группу «ценностных» офферов. > Source: https://smpp.by/rost-dokhodov-v-2026 --- # Персонализация SMS: как не переплачивать при росте доходов в Беларуси Рост реальных доходов белорусов в 2025–2026 годах изменил поведение клиентов: они чаще выбирают конкретные предложения, а не массовые скидки. В статье — как через персонализацию SMS сократить расходы на рассылки и увеличить отклик. Почему рост доходов требует новой стратегии SMS? Когда у людей появляются деньги, они становятся разборчивее. По данным Белстата, реальные располагаемые доходы в Беларуси в 2025 году выросли на 5,2 %. В 2026 году тенденция сохранилась. Клиенты перестали реагировать на общие фразы вроде «скидка 20 % на всё». Им нужны предложения, которые касаются лично их. Пример: сеть кофеен в Минске (локации в Dana Mall и Galileo) отправляла одинаковые SMS на всю базу — конверсия была 8 %. После сегментации по частоте покупок и среднему чеку конверсия выросла до 14 %, а расходы на SMS остались теми же. То есть они получали в 1,75 раза больше действий при том же бюджете. Совет: разбейте базу на группы — например, «покупают раз в месяц» и «покупают раз в квартал». Первым отправляйте предложения по повторным покупкам, вторым — акции с порогом входа. Как сегментировать базу без дорогих CRM? Многие микро- и малые бизнесы боятся персонализации из‑за сложности инструментов. На деле достаточно таблицы Excel или Google Sheets. Например, магазин белья в ТЦ «Зелёная Роща» записывал дату покупки, сумму и категорию товара. Через три месяца они запустили две рассылки: одной группе — предложение на новую коллекцию, другой — на распродажу прошлой. Средний чек вырос с 45 до 68 BYN, а количество жалоб на спам снизилось втрое. Если у вас интернет-магазин, можно использовать данные из корзины. Клиент положил товар — через час приходит SMS с напоминанием и персональной ссылкой на этот товар. Такая механика работает в 3 раза чаще, чем обычная рекламная рассылка (внутреннее тестирование магазина косметики на Kufar). Совет: используйте любой собранный контакт — записи на услугу, подписку на новости. Даже одна дополнительная метка («купил товар А») делает сообщение личным. Подробнее о сегментации без CRM — в статье Персонализация SMS для микробизнеса: сегментация без CRM. Какие данные помогут сэкономить на SMS? Чем точнее вы определите, кому отправляете, тем меньше лишних сообщений. Вот основные критерии, которые дают результат в белорусских реалиях: Данные Как использовать Средняя экономия бюджета Геолокация Предложение только для жителей Фрунзенского района, если рядом магазин 20–30 % История покупок Не отправлять акцию на товар, который клиент уже купил 15–25 % Дата последнего визита Реактивация спящих клиентов отдельной цепочкой до 40 % Способ оплаты Скидка на второй заказ при оплате картой Альфа-Банка 10 % Пример из практики: салон красоты на Московском районе Минска использовал геотаргетинг и дату последнего визита. Раньше они слали одно сообщение всем раз в неделю — тратили 300 BYN. После сегментации стали отправлять три разных сообщения разным сегментам, но общий бюджет уменьшился до 220 BYN за счёт исключения тех, кто недавно приходил. Выручка с рассылок не упала, а даже подросла на 12 %. Типичные ошибки при персонализации SMS Персонализация только по имени. «Иван, скидка!» — это уже не работает. Нужно предложение, связанное с действиями Ивана. Имя без контекста воспринимается как шаблон. Слишком частые сообщения при росте базы. Когда доходы растут, клиенты становятся чувствительнее к навязчивости. Оптимум для большинства бизнесов — 2–4 SMS в месяц. Одинаковые акции для всех сегментов. Если у вас есть категории «эконом» и «премиум», не предлагайте одну и ту же скидку. Первые оценят экономию, вторые — дополнительный сервис. Игнорирование транзакционных SMS. Сообщения о статусе заказа или подтверждении записи — тоже часть персонализации. Их не надо отдельно оплачивать, если настроить шаблоны. Отсутствие тестирования. Запустили сегмент — через неделю проверьте конверсию. Если она ниже среднего, меняйте текст или предложение. Не пытайтесь охватить всех сразу. Лучше сделать одну точную рассылку на 500 контактов, чем одну общую на 5000. Сколько стоит персонализация и как считать выгоду? Большинство сервисов SMPP позволяют отправлять персонализированные сообщения без дополнительных надбавок. Вы платите только за трафик. Стоимость одного SMS через SMPP-шлюз для бизнеса в Беларуси — от 0,045 BYN (при объёмах от 10 000). Сравним два сценария: Параметр Массовая рассылка Персонализированная сегментированная Количество SMS 10 000 6 000 (отсекли нецелевых) Стоимость одной SMS 0,05 BYN 0,05 BYN Общий бюджет 500 BYN 300 BYN Конверсия 5 % 12 % Количество действий 500 720 Цена за действие 1,00 BYN 0,42 BYN Вы экономите 40 % бюджета и получаете на 44 % больше результата. Пример взят из реальных данных магазина спортивных товаров в Барановичах (онлайн + розница). Если у вас ещё нет настроенного SMPP, обратите внимание на статью SMPP или API: что выгоднее для SMS в Беларуси — там подробный разбор тарифов и условий. 3 шага, которые можно сделать сегодня: Соберите дополнительную метку по каждому контакту: хотя бы город, дату последней покупки и сумму. Используйте любую таблицу — даже Google Sheets. Создайте 2–3 сегмента по этим данным. Например: «не покупали более 3 месяцев», «покупали в прошлом месяце», «средний чек выше 100 BYN». Запустите пробную рассылку на один сегмент. Через 72 часа сравните конверсию с предыдущей общей рассылкой. Если она выше — масштабируйте на остальные сегменты. Персонализация не требует больших вложений. Она требует внимания к данным, которые у вас уже есть. Начните с малого — и увидите разницу. Полезные ссылки: Персонализация SMS-рассылок при высоком спросе в Беларуси, Персонализация SMS для магазинов без покупки сложных систем. > Source: https://smpp.by/personalizatsiya-sms --- # Почему SMS-рассылки важнее мессенджеров для бизнеса в 2026 В 2026 году белорусский потребитель перегружен уведомлениями в Viber и Telegram. Прямые SMS-рассылки остаются единственным каналом, который гарантирует доставку, не требует подписки и вызывает больше доверия у клиентов. Статья поможет micro‑ и малому бизнесу понять, когда SMS выгоднее мессенджеров, и как внедрить простые сценарии без лишних затрат. Почему мессенджеры не заменяют SMS для локального бизнеса? Многие владельцы кафе, салонов и магазинов в Минске и Бресте перевели коммуникацию в Viber и Telegram. Но столкнулись с проблемой: доставляемость сообщений в мессенджерах зависит от настроек приватности, смены устройства и активности пользователя. Человек может не открыть канал месяцами. SMS не требует установки приложения и доставляется на любой телефон, включая кнопочные модели, которыми пользуются многие жители небольших городов вроде Хойников или Петрикова. Пример: кофейня в торговом центре «Зелёная Роща» в Минске запустила одинаковую акцию через Viber‑канал и SMS. Открываемость в Viber составила 34%, в SMS — 89%. Заказы по купону из SMS принесли на 40% больше выручки, чем из мессенджера (внутренняя аналитика бизнеса, 2026). Если у вас уже есть база номеров клиентов, начните с тестовой рассылки: сравните конверсию сами. SMS или Viber: что работает быстрее и надёжнее? Когда клиенту нужно срочно напомнить о записи или оплате, скорость доставки решает всё. SMS приходит в течение 2–5 секунд, даже при нестабильном интернете. Viber, особенно в пиковые часы, может задерживать доставку на 10–15 минут. А если у пользователя выключен мобильный интернет или он в роуминге, сообщение в мессенджере не дойдёт, пока не появится Wi‑Fi. Вот сравнение ключевых параметров для бизнеса Беларуси: Параметр SMS Viber / Telegram Доставляемость 99% (даже на старые телефоны) 60–80% (зависит от интернета и настроек) Время доставки 2–5 секунд 5–30 секунд, при перегрузках до нескольких минут Охват аудитории 100% владельцев мобильных номеров Только активные пользователи приложения Доверие потребителя Высокое (воспринимается как официальное уведомление) Среднее (многие игнорируют массовые каналы) Стоимость за 1000 сообщений от 20 BYN (при больших объёмах) от 35 BYN (плюс комиссия за открытые чаты) Подробный разбор плюсов и минусов каждого канала — в материале SMS или Viber: что выбрать для рассылки в Беларуси. Когда SMS выгоднее мессенджеров в 2026 году? Есть три типовые ситуации, когда прямой канал даёт лучший результат. Транзакционные уведомления. Подтверждение заказа, код для входа, чек об оплате. Клиент ждёт их моментально, без регистрации в чатах. Магазины на Onliner и Kufar используют SMS для фиксации сделки — это надёжнее, чем ожидание ответа в мессенджере. Напоминания о записи. Стоматология в Гродно снизила неявки с 25% до 8% после перевода напоминаний из Viber в SMS. Причина: SMS не теряется среди уведомлений групп и каналов. Срочные оповещения. Изменение времени работы, отмена брони, эвакуация. Салоны красоты в Минске используют SMS для экстренной связи, потому что открываемость в первые 3 минуты в 2,5 раза выше, чем в мессенджере. Для большинства микробизнесов в Беларуси (кофейни, мастерские, сервисы по ремонту техники) эти три сценария покрывают 90% потребностей. Не нужно гнаться за всеми каналами сразу. Типичные ошибки при выборе канала коммуникации Использовать только мессенджеры и забывать, что у части клиентов нет установленного Viber или Telegram. В Беларуси около 15% абонентов старше 50 лет пользуются кнопочными телефонами (данные МТС, 2025). Отправлять SMS слишком часто без персонализации. Это вызывает раздражение. О том, как выбрать частоту, читайте в статье Как часто писать клиентам: настройка SMS без раздражения. Игнорировать короткие сообщения. SMS длиннее 160 символов разбивается на части и стоит дороже. Краткость повышает конверсию. Подробнее — в материале Короткие SMS: почему они работают лучше длинных в 2026. Надеяться, что «один канал покроет всё». Лучше комбинировать: SMS для важных уведомлений, Viber для акций и контента. Забывать про юридические требования. Согласие на SMS должно быть получено явно (чекбокс, письменное согласие). Мессенджеры тоже требуют opt‑in, но проверяется это реже. Как внедрить SMS-рассылки без сложных настроек Не нужно покупать дорогую CRM или нанимать программиста. Достаточно простого алгоритма. Соберите базу номеров клиентов (с согласия). Это можно сделать через чек-листы при покупке или анкету на сайте. Выберите сервис рассылок с поддержкой SMPP или веб-интерфейсом. Многие провайдеры в Беларуси предлагают тарифы от 0,02 BYN за SMS при объёмах от 500 сообщений в месяц. Запустите первый сценарий: приветственное SMS после покупки. Пример: «Спасибо за заказ в пиццерии на ул. Немига! Ваш купон на скидку 10% — при следующем заказе покажите это сообщение». Такое сообщение окупается за счёт повторных визитов. 3 шага, которые можно сделать на этой неделе: Экспорт номеров из текущей CRM или чехов в Excel. Тестовая отправка одной SMS-рассылки (не более 200 сообщений) с чётким призывом к действию. Сравнение конверсии с предыдущей рассылкой в мессенджере. Если результат лучше, масштабируйте на весь бизнес. > Source: https://smpp.by/pochemu-sms-rassylki-vazhnee-messendzherov-dlya-biznesa-v-2026 --- # Сезонные корректировки запасов: как не потерять клиентов в 2026 Каждый бизнес в Беларуси сталкивается с сезонными изменениями ассортимента. Осенью магазины одежды заменяют летние коллекции на пуховики, кафе обновляют меню под горячие напитки, а сервисы переходят на зимнюю резину. В этот момент легко потерять связь с покупателями: они привыкли к одним товарам, а видят другие. Задача предпринимателя — не просто сообщить об изменениях, а удержать внимание и сохранить лояльность. SMS-рассылка для этого подходит лучше всего: сообщение приходит на мобильный телефон, его не блокируют алгоритмы соцсетей, и оно не требует интернета. В 2026 году, когда конкуренция за внимание клиента растёт, такой канал остаётся надёжным способом напомнить о себе. Зачем сообщать клиентам об изменении ассортимента Когда вы меняете товарный запас, клиент не узнает об этом сам. Он приходит в точку или заходит на сайт, видит незнакомый ассортимент и уходит. Особенно это заметно в сегменте микробизнеса. Пример: небольшая кофейня в Гродно к сентябрю заменила холодные латте на тыквенные напитки. Без рассылки о новинках продавцы стояли с пустыми руками первые две недели — посетители брали привычный айс-кофе, не замечали плакат у входа. После отправки короткого SMS «Любимая тыквенная основа уже в меню. Заходите на Молодёжную, 4» выручка вернулась к летним показателям за три дня. Как сделать. Составьте список товарных категорий, которые меняются по сезону. Для каждой напишите одно предложение-приманку: что именно изменилось, почему это выгодно клиенту. Запланируйте рассылку за три дня до официальной смены ассортимента. Не пишите «у нас появились зимние шины» — лучше «подготовьте авто к заморозкам: шины Michelin со скидкой 10%». Такой подход превращает сообщение из информационного в продающее. Сценарии для разных сегментов клиентов Одно и то же сообщение не подойдёт и постоянным, и новым, и тем, кто давно не покупал. Разобьём базу на три группы. Постоянные. Им можно написать прямо: «Иван, ваши любимые кроссовки Adidas закончились. Есть модель с усиленной подошвой — новая коллекция осень 2026». Здесь сработает персонализация по истории покупок. Пример: магазин спорттоваров в Могилёве отправил таким клиентам SMS про замену летних беговых кроссовок на зимние трейловые. Конверсия в покупку — 12%. Новые. Те, кто оформил заказ один раз летом. Им нужен повод вернуться. «У нас обновление меню: горячие супы и десерты. Закажите в Минске, доставка бесплатно при заказе от 25 рублей». Не перегружайте лишней информацией. Спящие. Клиенты, которые не покупали 3–6 месяцев. Сезонная смена запасов — отличный повод для реактивации. «Ваша мастерская заменила масло на зимнее. Запишитесь на замену сегодня — получите скидку 15%». Сервис в Барановичах так вернул 30% «уснувших» за неделю. Как сделать. Сегментируйте базу по дате последней покупки и средней сумме чека. Для каждого сегмента напишите отдельный текст. Не пытайтесь уместить всё в одно сообщение. Используйте короткие SMS — исследования показывают, что текст до 80 символов читают чаще. Подробнее о настройке частоты и тона общения читайте в статье «Как часто писать клиентам: настройка SMS без раздражения». Как автоматизировать напоминания без лишних затрат Ручная отправка при каждом изменении ассортимента отнимает время. Для микробизнеса в Вилейке или Петрикове это непозволительно. Решение — настроить триггерные сообщения на базе дат или действий клиента. Пример из практики. Магазин товаров для дома в Гомеле каждое 1 сентября менял выкладку и отправлял одно SMS всем подряд. Результат — открываемость упала, клиенты жаловались на спам. Владелец настроил автоматическое сообщение при поступлении нового товара в категорию, которую клиент смотрел на сайте. Расходы на SMS не выросли, а реакция — каждый пятый получатель переходил в магазин. Как сделать. Используйте простую CRM или даже Google Таблицы с датами. Если у вас интернет-магазин, интегрируйте SMS-шлюз с корзиной. Когда товар из избранного меняется на сезонный аналог — система сама отправляет уведомление. Для офлайн-точек заведите календарь замены категорий. За две недели до даты ставите задачу написать текст и отправить одним кликом. Так вы не забудете, а клиент получит сообщение вовремя. Углубиться в тему автоматизации можно в статье «Персональные SMS-напоминания: баланс автоматизации и внимания». Типичные ошибки при организации сезонных рассылок Одна рассылка на всех. Когда магазин в Бресте пишет «У нас зимние шины» клиенту, который купил их месяц назад. Раздражает и бесполезно. Слишком длинное сообщение. Попытка описать весь новый ассортимент в одном SMS заставляет читателя пролистывать. Лучше короткий призыв и ссылка на сайт или соцсеть. Нет привязки к сезону. Рассылать сообщения о зимней одежде в октябре, когда на улице +15. Проверяйте прогноз погоды за неделю до отправки. Игнорирование проверки базы. Отправлять на номера, которые не активны или ошибочны. Это увеличивает расходы и снижает доставляемость. Обязательно чистите базу раз в квартал. Отсутствие тестирования. Запускать рассылку без предварительного просмотра на своём телефоне. Случайная опечатка или кривая ссылка убивают доверие. Слишком частые напоминания. Если отправлять об одном и том же изменении трижды за неделю, клиент воспримет это как спам. Одна информационная рассылка за сезон — оптимально. Если вы только начинаете использовать SMS для сезонных акций, сначала протестируйте на небольшом сегменте. Например, отправьте сообщение 50 постоянным клиентам и измерьте конверсию. Потом масштабируйте. Для микробизнеса без CRM подойдёт ручная сегментация — выгрузите контакты из кассового аппарата и отсортируйте по дате последней покупки. Подробнее о простых методах сегментации читайте в статье «Персонализация SMS для микробизнеса: сегментация без CRM». 3 шага, которые можно сделать сегодня на неделе: Составьте перечень сезонных товаров или услуг, которые меняются в вашем бизнесе в ближайшие 30 дней (например, переход с летнего меню на осеннее, замена шин, утепление товаров). Разделите клиентскую базу на три группы: активные (покупка за последние 30 дней), новые (1 покупка), спящие (нет покупок 90 дней). Для каждой группы напишите один короткий текст SMS с конкретным предложением по новому ассортименту. Отправьте тестовое сообщение на свой номер и попросите коллегу проверить ссылку и текст. Если всё ок — запланируйте рассылку за 3–4 дня до фактического появления товара на полке. Сезонные корректировки запасов — не проблема, а возможность напомнить о себе. Главное — делать это вовремя, коротко и персонализированно. Тогда клиент не уйдёт к конкуренту, а вернётся за новинками именно к вам. Полезные ссылки: Как часто писать клиентам, Персонализация SMS без CRM, Персональные SMS-напоминания. > Source: https://smpp.by/sezonnye-korrektirovki-zapasov --- # Автоматизация транзакционных SMS в ритейле: как снизить расходы Транзакционные уведомления — это сообщения о статусе заказа, подтверждении записи, напоминании об оплате или готовности услуги. Если вы отправляете их вручную или через дорогой API с оплатой за каждое сообщение, операционные расходы растут. SMPP-шлюз решает эту задачу: прямое подключение к вашей учётной системе, быстрая отправка и цена, близкая к себестоимости трафика. Для микробизнеса в Беларуси это способ сэкономить 20–40% на SMS-бюджете при росте числа транзакций. Как работают транзакционные уведомления через SMPP на деле Пример: интернет-магазин в Минске продаёт товары для дома. Каждый день — 80–100 заказов. Раньше менеджер вручную звонил или писал в мессенджер. Затем подключили SMPP-шлюз к 1С. Теперь при смене статуса заказа (принят, собран, передан курьеру) система автоматически отправляет клиенту SMS. Стоимость сообщения — около 0,05 BYN вместо 0,12 BYN по тарифам обычных API-шлюзов. За месяц экономия составила 180 BYN. Совет: попросите разработчика настроить HTTP-запросы из вашей учётной системы напрямую к SMPP-серверу. Не используйте промежуточные сервисы — они берут комиссию. Если у вас нет штатного программиста, ищите CRM с готовой интеграцией SMPP или используйте готовые модули для 1С. Где ещё в ритейле можно автоматизировать уведомления Салон красоты в Гродно записывает клиентов через онлайн-календарь. После записи через SMPP автоматически уходит подтверждение, а за 2 часа до визита — напоминание. Доля неявок снизилась с 22% до 9%. Дополнительно настроили уведомления о готовности услуги: после окрашивания клиент получает SMS, что можно забирать вещи или подойти на финальную укладку. Совет: определите 3–4 события в вашем бизнесе, где клиенту нужно узнать статус без звонка. Это может быть «заказ поступил на склад», «услуга завершена», «график работы изменился». Для каждого события создайте отдельный триггер в CRM или в админке интернет-магазина. Почему SMPP выгоднее, чем API для больших объёмов Сеть продуктовых магазинов в Бресте отправляет 6 000 транзакционных SMS в месяц (чеки, акции по карте лояльности, статусы доставки). При использовании стандартного HTTP API с тарифом 0,10 BYN за SMS расходы — 600 BYN. После перехода на SMPP стоимость упала до 0,045 BYN — 270 BYN в месяц. Разница — 330 BYN. Подробнее о выборе протокола читайте в статье SMPP или API: что выгоднее для SMS в Беларуси. Совет: если ваш объём превышает 1 000 SMS в месяц, попросите провайдера сравнить стоимость SMPP и API с вашими текущими цифрами. Помните: SMPP требует больше технической работы при первом подключении, но окупается за 2–3 месяца за счёт низкой цены за сообщение. Типичные ошибки при автоматизации транзакционных SMS Отправка одного и того же уведомления дважды из-за отсутствия дедупликации. Настройте уникальный ID запроса в SMPP-шлюзе, иначе клиент получит дубль при сбое сети. Игнорирование времени доставки. Не отправляйте подтверждение заказа в 23:00 — перенесите на утро. Используйте таймеры в логике триггера. Отсутствие проверки доставки. SMPP возвращает статус (доставлено/не доставлено). Настройте логирование и повторную отправку при неудаче, иначе клиент не узнает об изменении статуса. Слишком длинные тексты. Каждое сообщение должно умещаться в 160 символов (латиница) или 70 (кириллица). Длинные SMS разбиваются на части и стоят дороже. Сокращайте до сути. Забыли про праздничные дни. В Новый год или 8 Марта объём заказов растёт, а операторы могут задерживать трафик. Заранее тестируйте нагрузку шлюза. Полезные ссылки: Интеграция SMS-уведомлений о статусе заказа для доставки в Беларуси и Настройка SMPP-шлюза: как избежать дублирования SMS при сбоях. 3 шага, которые можно сделать на этой неделе: Проверьте текущие расходы. Откройте счёт за SMS за последние 3 месяца. Посчитайте среднюю стоимость одного уведомления. Сравните с тарифами SMPP у провайдера (обычно от 0,04 BYN). Если разница больше 20% — переходите к шагу 2. Составьте список событий для автоматизации. Выпишите все случаи, когда вы сейчас пишете клиенту вручную: подтверждение заказа, готовность, напоминание о записи. Отметьте, какие из них можно перевести в автоматические триггеры без участия человека. Настройте первый триггер. Выберите одно самое частое событие (например, уведомление о статусе заказа). Подключите SMPP-шлюз к учётной системе или CRM. Протестируйте 3–5 отправок. Сравните скорость и стоимость с предыдущим способом. > Source: https://smpp.by/avtomatizatsiya-tranzaktsionnykh-sms-v-riteyle --- # Прогноз роста SMS-трафика 2026–2030: технические аспекты для бизнеса Беларуси К 2030 году пропускная способность SMS-каналов в Беларуси увеличится из-за расширения сетей и роста числа устройств. Владельцам кофеен, студий красоты и сервисных мастерских стоит заранее разобраться, как адаптировать рассылки под новые объёмы. Это позволит не терять клиентов из-за задержек и лишних затрат. Что такое пропускная способность SMS и почему она растёт Пропускная способность — это количество сообщений, которое шлюз может обработать за секунду. В прогнозе развития страны до 2030 года заложено увеличение трафика на 25–30% за счёт цифровизации услуг и роста числа транзакционных SMS (подтверждения заказов, коды, чеки). Для малого бизнеса это означает, что в часы пик (утро рабочего дня, вечер пятницы) нагрузка на канал станет выше. Если ваш SMPP-шлюз рассчитан на 50 SMS в секунду, а система отправляет 200, сообщения встанут в очередь или потеряются. Пример: в Бресте сеть пекарен использует один канал для отправки уведомлений о готовности заказа и акций. В обеденный пик они отправляют 500 SMS за час. Если оператор не справляется, часть клиентов получает сообщение через 40 минут, а не через 5. Совет: проверьте текущую пропускную способность вашего шлюза. Укажите в договоре с провайдером минимальную гарантию (SLA) — например, не менее 100 SMS в секунду для региона. Это стоит дополнительных денег, но спасет репутацию в сезон. Как рост трафика повлияет на ваш бизнес: пример из Минска В 2025 году один минский сервис доставки фиксировал всплески SMS-трафика до 3000 сообщений в час перед праздниками. Из-за ограничения шлюза до 50 SMS/с клиенты не получали подтверждения в течение часа. Компания потеряла 12% заказов. После перехода на SMPP с балансировкой и аренды выделенного канала пропускная способность выросла до 500 SMS/с. Затраты на связь увеличились на 8%, но доход вырос на 20% за счёт снижения отказов. Совет: если вы планируете запуск масштабной акции («чёрная пятница», распродажа), заранее тестируйте нагрузку. Попросите оператора дать тестовый доступ к каналу с реальной пропускной способностью. Попробуйте отправить 10 000 сообщений за 10 минут и посмотрите процент доставленных в течение 30 секунд. Настройка SMPP-шлюза для работы с возросшим объёмом Основные параметры, которые влияют на пропускную способность: количество одновременных соединений (bind), таймауты и тип проверки доставки (DLR). При росте трафика увеличьте число параллельных сессий с 1 до 3–5. Настройте таймаут закрытия соеди-нения на 60 секунд, чтобы шлюз не рвал канал при временных задержках. Отключите запрос DLR для массовых рассылок, если статус доставки не критичен, — это снизит нагрузку на 40%. Пример: в Гомеле автосервис использует SMS для напоминаний о ТО. После увеличения базы до 8000 клиентов отправка стала занимать 2 часа, хотя раньше укладывалась в 15 минут. Администратор изменил настройки: отключил DLR для повторных сообщений и увеличил число bind-сессий до 3. Время отправки вернулось к 15 минутам, расходы на трафик не выросли. Совет: если пользуетесь готовым решением (например, от провайдера), уточните, какие параметры SMPP можно менять. Попросите техподдержку выставить приоритет транзакционных SMS над рекламными. Это гарантирует, что подтверждения заказов доходят моментально даже при пиковой нагрузке. Типичные ошибки при переходе на новые объёмы трафика Использование одного логина и пароля для всех рассылок. При перегрузке оператор может заблокировать аккаунт. Лучше завести отдельные логины для транзакционных и маркетинговых SMS. Игнорирование квот на количество сообщений в месяц. Некоторые тарифы режут скорость после превышения лимита. Узнайте условие «fair use» у провайдера. Отсутствие мониторинга задержек. Если среднее время доставки выросло с 3 до 15 секунд, проблема в канале, а не в клиентах. Настройте алерты на показатели задержки. Слепая вера в «неограниченную пропускную способность» дешёвых тарифов. В часы пик оператор распределяет ресурсы в пользу крупных клиентов. Гарантированная скорость стоит в 2–3 раза дороже, но окупается стабильностью. Отправка дублей при сбоях. При сбое в сети шлюз часто повторяет отправку, что забивает канал. Включите дедупликацию через ID сообщения в SMPP. Планирование объёмов: что учесть до 2030 года Рост трафика идёт неравномерно. В Мозыре или Петрикове мобильная нагрузка растёт медленнее, чем в Минске. Но глобальные операторы подтягивают ёмкость постепенно. Чтобы не переплачивать за неиспользуемую скорость, выбирайте гибкие тарифы с возможностью временного увеличения пропускной способности на день/неделю. Пример: в 2026 году в Барановичах открылся новый торговый центр. Магазины внутри запустили SMS-купоны и уведомления. В первые две недели объём трафика вырос в 6 раз, затем стабилизировался. Те, кто заранее заложил буфер в договоре (например, +200%), избежали сбоев. Совет: оценивайте не только текущую базу, но и планы роста на 2–3 года. Если вы планируете расширять сеть точек или запускать программу лояльности, заключайте договор с оператором на условиях «возможность увеличения пропускной способности в 5 раз без штрафа». Типичные ошибки при выборе провайдера Ориентация только на цену за SMS без учёта SLA по скорости. Дешёвый шлюз на 10 SMS/с не подойдёт для 10 000 клиентов. Подключение через агрегатора без возможности прямого SMPP-подключения. Это добавляет задержку и снижает управляемость. Отсутствие тест-драйва. Перед подписанием договора отправьте 1000 SMS тестовой базе с разных номеров и замерьте время доставки. Полезные ссылки: SMPP или API: что выгоднее для SMS в Беларуси, Оптимизация расходов на SMS-трафик: практические шаги для бизнеса, Планирование SMS-коммуникаций малого бизнеса Беларуси до 2030. 3 шага, которые можно сделать на этой неделе: Проверьте текущий объём исходящих SMS за последние 3 месяца. Определите максимальный пик (например, в акционный день). Узнайте у провайдера пропускную способность вашего шлюза в этот пик. Настройте мониторинг времени доставки в системе аналитики. Задайте порог: если средняя задержка превышает 10 секунд в течение 5 минут — отправлять уведомление ответственному сотруднику. Потребуйте у провайдера тестовый доступ к SMPP-каналу с возможностью настройки количества bind-сессий. Внесите изменения в регламент отправки: для транзакционных SMS используйте отдельный логин с повышенным приоритетом. > Source: https://smpp.by/prognoz-rosta-sms-trafika-2026-2030 --- # Планирование SMS-коммуникаций малого бизнеса Беларуси до 2030 К 2030 году в Беларуси изменится структура экономики, вырастет товарооборот, цифровизация станет нормой. Для микробизнеса, кафе, мастерских, магазинов это означает, что старые схемы рекламы перестанут работать. SMS-рассылки — один из каналов, который останется стабильным: уведомления, напоминания, акции доходят до клиента за секунды. Эта статья — о том, как выстроить стратегию SMS так, чтобы не переплачивать и получать результат в новых условиях. Как изменится спрос на услуги и товары до 2030 года В программе социально-экономического развития до 2030 заложен рост реальных доходов населения и увеличение доли онлайн-продаж. Владелец кофейни в центре Минска заметил, что 40% заказов теперь приходит через мобильное приложение, а не через кассу. Если раньше он делал одну массовую SMS-рассылку на всех подписчиков, то теперь клиенты ждут персонального подхода. Пример. Кофейня в Бресте с помощью сегментации разделила клиентов на три группы: те, кто заказывает навынос; гости, которые сидят в зале; и оптовики (закупка зерна). Каждой группе отправляли разные SMS: первым — сообщение о готовности заказа, вторым — напоминание о дегустации нового сорта, третьим — персональная скидка на партию. Средний чек вырос на 18% за квартал. Как сделать. Привяжите SMS к программам лояльности: сообщайте о накопленных баллах, персональных скидках. Используйте шаблоны с подстановкой имени клиента и суммы покупки. Это даст прирост среднего чека без дополнительных вложений. Подробнее про персонализацию без сложных систем — в статье Персонализация SMS для микробизнеса: сегментация без CRM. Рост товарооборота в Союзном государстве и ваша SMS-стратегия Беларусь входит в Союзное государство с Россией. Ожидается упрощение таможенных процедур и рост взаимной торговли. Для малого бизнеса в приграничных городах — Гродно, Бресте, Витебске — это открывает поток клиентов из соседней страны. Однако нужно учитывать разницу в валюте и часовых поясах. Пример. Магазин детских товаров в Гомеле заметил, что 15% покупателей приезжают из России. Они часто интересуются акциями, но не хотят подписываться на рассылки на русском языке с упоминанием белорусских рублей. Владелец сделал отдельный сегмент «Гости РФ» и отправляет SMS с ценами в российских рублях по курсу на день отправки. Конверсия в покупку выросла на 25%. Как сделать. Используйте короткие SMS без лишних слов. Для разных сегментов клиентов — разные сообщения. Не пытайтесь охватить всех одной рассылкой. Для туристов актуальны скидки на товары, которые удобно везти с собой. А местным жителям — напоминания о регулярных покупках. Технически это легко реализовать через SMPP или API: что выгоднее для SMS в Беларуси — каждый канал даёт гибкую настройку адресных списков. Оптимизация расходов на SMS при растущей экономике Рост экономики — не повод тратить больше на коммуникации. Наоборот, когда покупательная способность увеличивается, эффективность каждой отправленной SMS должна быть выше. Типичная ошибка — отправлять одинаковые массовые сообщения всем, надеясь на отклик. Это ведёт к перерасходу бюджета и раздражению клиентов. Пример. Студия красоты в Могилёве перевела часть клиентов с Viber на SMS для важных напоминаний. Администратор заметила, что Viber-сообщения о записи часто не открываются, потому что клиенты отключают уведомления в мессенджерах. После перехода на SMS неявки сократились с 12% до 5%. Экономия на каждом невозвращённом слоте — 25 BYN. Как сделать. Сравните стоимость SMS и Viber в вашем регионе. Для срочных уведомлений (напоминания о записи, статус заказа) выгоднее SMS — они быстрее доходят и не блокируются настройками приватности. Для промо-рассылок используйте Viber, если у базы высокая активность в этом канале. Детальный план снижения затрат — в статье Оптимизация расходов на SMS-трафик: практические шаги для бизнеса Беларуси. Типичные ошибки при планировании SMS-коммуникаций Отправка одинаковых сообщений всем клиентам — без сегментации теряется до 60% потенциальных продаж. Отсутствие анализа времени отправки — утренние SMS для кофейни эффективны, а для салона красоты — в обед. Игнорирование обратной связи — клиент, который отписался, должен перестать получать сообщения в течение 24 часов, иначе он оставит негативный отзыв. Слишком длинные тексты — сообщение более 160 символов разбивается на несколько, удваивая стоимость и снижая читаемость. Рассылка без предварительного теста — одно неправильное слово может разрушить доверие. 3 шага, которые можно сделать на этой неделе: Проанализируйте текущую базу клиентов и разбейте её на 2–3 группы: по частоте покупок (новые, регулярные, спящие), по типу товаров или по городу. Используйте простую таблицу Excel или Google Таблицы. Настройте шаблоны для трёх сценариев: напоминание о событии (запись, заказ), акция с ограничением по времени, приветствие новому подписчику. Длина каждого шаблона — не более 140 символов. Замерьте результаты через две недели: количество доставленных SMS, переходы по ссылке (если есть), число покупок после рассылки. Сравните с предыдущим месяцем и скорректируйте график. Полезные ссылки: Локальные SMS для увеличения среднего чека в малом бизнесе Беларуси, Персонализация SMS для магазинов без покупки сложных систем. > Source: https://smpp.by/planirovanie-sms-kommunikatsiy-malogo-biznesa-belarusi-do-2030 --- # Как снизить расходы на SMS при нестабильном интернете в Беларуси Когда интернет на стороне бизнеса часто обрывается, обычные HTTP-запросы к SMS-шлюзу приводят к потере сообщений и повторным отправкам. Каждая повторная отправка — лишние деньги. В этой статье — как настроить каналы связи, чтобы не переплачивать, даже если интернет нестабилен. Почему нестабильный интернет ведет к лишним тратам Представьте небольшой магазин в Калинковичах. Он отправляет уведомления о готовности заказа через HTTP-запрос к шлюзу. Интернет прерывается на минуту. Клиент не получает SMS, магазин отправляет повторно вручную — платит второй раз. Хуже того: иногда первая отправка всё же проходит, но магазин об этом не знает, клиент получает дубликат. Двойная оплата за одно сообщение. Решение — использовать SMPP-соединение с очередью сообщений на стороне шлюза. SMPP держит постоянный канал. Если связь пропадает, шлюз сам переотправляет сообщения после восстановления. Вы платите только за одну доставку, а дубликаты исключены. Как работает повторное использование каналов связи При HTTP-запросе вы каждый раз открываете новое соединение на отправку одного SMS. При нестабильном интернете это увеличивает риск потери. SMPP, наоборот, держит одно долгоживущее соединение. Оно не рвется после каждой отправки. Если интернет упал, SMPP-клиент автоматически переподключается и отправляет накопленные сообщения. Совет: настройте SMPP-шлюз с опцией keep-alive и таймаутом переподключения 10–30 секунд. Попросите поставщика включить автоматическую повторную отправку при ошибках соединения. Подробнее о настройке SMPP-шлюза читайте в статье Настройка SMPP-шлюза: как избежать дублирования SMS при сбоях. Пример для салона красоты в Бресте Салон использует SMS-напоминания о записи. Интернет нестабильный из-за старого роутера. При интеграции через HTTP-API половина напоминаний не доходила. Администратор звонил клиентам вручную — тратил время. После перехода на SMPP с очередью сообщений потери снизились до 2%. Расходы на SMS выросли незначительно, зато отток клиентов уменьшился. Как сделать: запросите у провайдера SMPP-доступ с поддержкой DLR (отчетов о доставке). Настройте отправку в транзакционном режиме — сообщения не дублируются, даже если соединение рвется. Для малого бизнеса это выгоднее, чем SMPP или API: что выгоднее для SMS в Беларуси — SMPP даёт контроль и экономию. Типичные ошибки Использовать HTTP-запросы без механизма повторных отправок. Отправлять каждое SMS отдельным открытием соединения. Не настраивать таймауты ожидания ответа от SMS-центра. Хранить очередь отправки на локальном сервере — при обрыве интернета очередь теряется. Игнорировать DLR — вы не видите, какие сообщения не дошли, и не можете скорректировать настройки. Выбирать самого дешевого провайдера без поддержки постоянного SMPP-соединения. Практические советы по настройке Если у вас уже есть SMPP-подключение, проверьте параметры переподключения. Выставите интервал повторной попытки 15–20 секунд, не более 5 попыток подряд. Используйте флаг registered_delivery в команде submit_sm — он запрашивает DLR. По отчетам вы увидите, дошло ли SMS. Если DLR не приходит, значит сообщение потеряно, а не оплачено. Для тех, кто только планирует переход: сначала протестируйте SMPP на одном типе уведомлений (например, напоминания о записи). Сравните расходы до и после. Подробные шаги описаны в статье Как малому бизнесу Беларуси сократить расходы на SMS-уведомления. Ещё один важный момент — стоимость. Если ваш бизнес отправляет от 1000 SMS в месяц, SMPP почти всегда дешевле HTTP. Вы платите только за трафик, без наценки за каждый запрос. О том, как снизить счёт, читайте в материале Снижаем расходы на SMS-уведомления в 2026 году. 3 шага, которые можно сделать сегодня Проверьте текущее подключение к SMS-шлюзу. Если используете HTTP, запросите у поставщика SMPP-доступ. Настройте постоянное SMPP-соединение с автоматическим переподключением и очередью сообщений на стороне шлюза. Включите DLR и анализируйте отчёты. Уберите ручные повторные отправки — доверьте их автоматике. > Source: https://smpp.by/kak-snizit-raskhody-na-sms-pri-nestabilnom-internete-v-belarusi --- # Оптимизация расходов на SMS-трафик: практические шаги для бизнеса Беларуси Это статья для предпринимателей, которые хотят снизить затраты на SMS-рассылки во втором полугодии 2026 года. Разберём, как выбрать оптимальный маршрут отправки, не терять деньги на дубликатах и использовать новые возможности рынка. Примеры — для кафе, магазинов и сервисных центров в Минске, Гомеле, Гродно и небольших городах вроде Калинковичей или Петрикова. Сравнение тарифов: не все SMS стоят одинаково Внутренний рынок SMS-трафика в Беларуси не монолитен. Цена зависит от объёма, оператора получателя (МТС, A1, life:) и способа подключения. Например, небольшая кофейня в Бресте отправляет по 200 SMS в месяц через веб-интерфейс провайдера и платит 0,12 BYN за штуку. При переходе на SMPP-шлюз и объёме от 1000 SMS та же отправка обходится в 0,06–0,08 BYN. Пример. Владелец сети из трёх точек фаст-фуда в Витебске ежемесячно рассылал 1500 SMS с промокодами. После смены тарифа на агрегированный канал с оплатой по факту доставки экономия составила 70 BYN в месяц. Совет. Соберите коммерческие предложения от 3–4 консолидаторов. Обратите внимание на базовую ставку для одного сообщения и на скидку при предоплате за 5000 SMS. Попросите тестовый период — 100–200 сообщений — чтобы проверить скорость доставки. Подробнее о выборе протокола читайте в статье SMPP или API: что выгоднее для SMS в Беларуси. Дубликаты и потери: как не платить за воздух Типичная проблема — одна и та же SMS уходит дважды из‑за сбоя соединения с шлюзом. Особенно это заметно при интеграции с CRM на стороне интернет-магазина. Пример: салон красоты в Могилёве настраивал уведомления о записи. Из‑за таймаута на стороне шлюза половина клиентов получила по два напоминания. За месяц лишние 150 SMS — это дополнительно 12 BYN. Совет. Настройте единственный источник отправки: все запросы идут через один SMPP-шлюз с контролем уникального ID сообщения. Если соединение разорвалось до получения подтверждения, система должна проверять статус по ID, а не слать запрос заново. Пошаговая инструкция есть в материале Настройка SMPP-шлюза: как избежать дублирования SMS при сбоях. Маршрутизация по операторам: экономьте на доставке до 30 % В Беларуси три основных мобильных оператора. Ставки за отправку на номера МТС, A1 и life: могут отличаться на 20–40 %. Если ваш бизнес работает с базой, где преобладают абоненты одного оператора (например, в Полоцке большая доля A1), выгодно выбрать шлюз, который предлагает сниженную цену на этот сегмент. Пример. Стоматология в Барановичах рассылала напоминания о приёме всем клиентам без разбора оператора. После того как подключили маршрутизацию с разделением по кодам сети, затраты на SMS упали с 0,10 до 0,07 BYN за сообщение. Экономия — 45 BYN в месяц при объёме 1500 SMS. Совет. Запросите у поставщика отчёт о распределении номеров в вашей базе. Если доля одного оператора больше 60 %, попросите индивидуальный тариф на его трафик. Или рассмотрите гибридные схемы: часть SMS отправлять через SMPP, часть — через дешёвый API для конкретного оператора. Детали работы с SMPP-протоколом описаны в Протокол SMPP — что это?. Статусы доставки: почему детали важнее общей статистики Многие предприниматели смотрят только на процент доставленных сообщений (например, 97 %). Но внутри этой цифры могут быть «технические браки»: номер заблокирован, телефон выключен, сеть перегружена. За каждую такую попытку вы платите, хотя сообщение не дошло. Во втором полугодии 2026 года операторы уточнили критерии фиксации доставки — теперь статус «доставлено» выставляется после успешного получения отчёта от телефона, а не после передачи в сеть. Это значит, что часть сообщений, которые раньше считались успешными, теперь отобразятся как «не доставлено», и за них можно не платить. Пример. Магазин товаров для дома в Гродно терял около 8 % бюджета на SMS, которые не доходили, но списывались как успешные. После перехода на шлюз с детальными статусами и биллингом по факту доставки экономия составила 50 BYN за квартал. Совет. Выбирайте консолидатора, который предоставляет поштучные DLR (delivery reports) с полем final status. Настройте в CRM учёт только тех SMS, у которых статус «доставлено» или «прочитано». Подробнее о тонкостях статусов — в статье Статус доставки SMS: почему важны детали, а не общая статистика. Типичные ошибки при оптимизации расходов на SMS Платить за каждый отправленный запрос, а не за доставленное сообщение. Многие тарифы считают попытку как отправку, даже если номер недоступен. Использовать один и тот же тариф для массовых рассылок и транзакционных уведомлений. Для уведомлений (коды, чеки) нужна высокая скорость, для промо — низкая цена. Смешивать невыгодно. Не очищать базу от неактивных номеров. SMS на 10 % мёртвых номеров — это чистый убыток. Делайте RFM-анализ раз в квартал. Выбирать самого дешёвого провайдера без SLA. Низкая цена часто означает низкую доставляемость (например, 75 % вместо 95 %). Экономия превращается в упущенную выручку. Игнорировать сезонные колебания тарифов. Во втором полугодии (август–декабрь) нагрузка на сети растёт, и операторы поднимают цены для непрямых клиентов. Заключайте договор с фиксированной ставкой на полгода. Не тестировать SMPP-шлюз перед запуском. Каждый пятый бизнес сталкивается с дублированием из‑за неправильной настройки пакетов. 3 шага, которые можно сделать сегодня на неделе Соберите данные об объёме SMS за последние 3 месяца: количество, средняя цена, доли операторов. Это позволит оценить текущие расходы и потенциал экономии. Запросите у текущего провайдера возможность перейти на биллинг по факту доставки и детализированные DLR. Если такого нет — начните поиск альтернативного шлюза с тестовым бюджетом в 200 BYN. Проверьте настройки вашего SMPP-шлюза на дублирование. Запустите тестовую отправку 50 сообщений с заведомо неправильными номерами и проверьте, не снимаются ли повторные попытки. Инструкцию найдёте в этой статье. > Source: https://smpp.by/optimizatsiya-raskhodov-na-sms-trafik --- # SMPP или API: что выгоднее для SMS в Беларуси Когда у вас мало клиентов и вы отправляете сотню SMS в месяц, разницы между способами подключения почти нет. Но когда объём переваливает за несколько тысяч — выбор протокола начинает влиять на бюджет, скорость и надёжность. Разберём, чем SMPP отличается от API-сервисов и когда стоит переходить на прямое соединение. Чем SMPP отличается от API-сервисов SMPP — это протокол прямого подключения к SMS-центру оператора. API — запросы через HTTP к шлюзу провайдера. Для микробизнеса API проще: не нужно настраивать сервер, поддерживать постоянное соединение. Но у API есть ограничения на количество запросов в секунду, а при массовых рассылках возникают задержки. Пример: кафе в Минске отправляет ежедневные акции на 5000 номеров через API. В часы пик (обед, вечер) сообщения приходят с опозданием 30–60 минут. После перехода на SMPP задержка исчезла — все SMS уходят за 2–3 секунды. Подробнее о скорости работы протоколов читайте в статье SMPP против HTTP-шлюзов: скорость SMS для бизнеса Беларуси. Когда API-сервисы становятся невыгодными Пока вы отправляете до 1 000 SMS в месяц, разница в стоимости между SMPP и API незаметна. Но с ростом объёмов начинают действовать два фактора: комиссия за каждое HTTP-соединение и лимит на параллельные запросы. Рассмотрим интернет-магазин из Гомеля с 20 000 заказов в месяц. Каждому покупателю нужно уведомление о статусе — 20 000 SMS. Через API каждое сообщение обходится на 20–30% дороже из-за комиссии за HTTP-запрос. Фиксированная плата за SMPP-подключение (обычно 30–50 BYN в месяц) окупается уже при 3 000–5 000 SMS. Для магазина экономия составила около 180 BYN в месяц. Если сомневаетесь в цифрах, посмотрите материал Снижаем расходы на SMS-уведомления в 2026 году. Как перейти на SMPP без потери клиентов Переход состоит из трёх шагов: проверка совместимости CRM, получение тестового доступа и настройка резервного канала. Сервис доставки в Бресте перешёл на SMPP и зафиксировал снижение доли недополученных сообщений с 3% до 0,5%. Но во время настройки у них возникли дубли — дважды отправили одно и то же SMS 200 клиентам. Ошибка решилась настройкой тайм-аута повторной отправки. Как избежать таких сбоев, описано в инструкции Настройка SMPP-шлюза: как избежать дублирования SMS при сбоях. Совет: перед переходом включите каскад — если SMPP-канал временно недоступен, сообщения уходят через API. Тогда вы не потеряете ни одного клиента. Типичные ошибки при выборе между SMPP и API Оставаться на API, когда трафик вырос в 10 раз, и терпеть задержки. Владельцы салонов красоты в Витебске жалуются на опоздание напоминаний о записи — причина именно в лимитах API. Выбирать SMPP только из-за цены, не проверив поддержку в своей CRM. Интеграция может потребовать доработок, которые съедят всю экономию. Не настраивать резервный канал. Если SMPP-соединение разорвалось (например, из-за сбоя у оператора), рассылка полностью останавливается. Игнорировать детальную статистику доставки. Без неё вы не увидите, что часть SMS не дошла, и будете платить за повторные отправки. Разбор статистики — в статье Статус доставки SMS: почему важны детали, а не общая статистика. Переходить без тестового периода — получить дубли или потерю сообщений из-за неправильной конфигурации. 3 шага, которые можно сделать на этой неделе: Посчитайте среднемесячное количество SMS и сравните стоимость API (с учётом комиссии за HTTP) и фиксированной платы за SMPP. Порог окупаемости обычно 3 000–5 000 сообщений. Запросите у текущего провайдера тестовый доступ к SMPP. Большинство дают пробный период на 2–3 дня без оплаты. Настройте мониторинг времени доставки через любой бесплатный инструмент — увидите реальную разницу в скорости между API и SMPP. > Source: https://smpp.by/smpp-ili-api --- # Интеграция SMS-уведомлений о статусе заказа для доставки в Беларуси Когда клиент заказывает товар в интернет-магазине, ему нужно знать, где заказ и когда он приедет. SMS-уведомления — простой и дешёвый способ дать эту информацию без установки приложений и доступа в интернет. Для малого бизнеса в Беларуси автоматизация таких сообщений решает две задачи: снижает нагрузку на менеджеров и повышает доверие покупателей. Почему ручные уведомления тормозят доставку Представьте магазин цветов в Минске. Каждый день — 40–50 заказов, плюс индивидуальные букеты. Менеджер после оформления заказа вручную набирает номер, пишет сообщение в мессенджер или звонит. Это отнимает 3–5 минут на заказ. В пиковые дни (14 февраля, 8 марта) время на уведомления вырастает до 2–3 часов. Ошибки неизбежны: перепутан статус или забытый номер. Автоматизация через протокол SMPP решает проблему. Вы настраиваете интеграцию между CRM (например, 1С:УНФ или самописной системой) и SMS-платформой. Как только статус заказа меняется (оплачен, передан в доставку, вручён), система отправляет клиенту короткое сообщение без участия человека. Вот пример из реальной практики: небольшой сервис по ремонту обуви в Гродно перестал звонить каждому клиенту. После окончания ремонта система сама отправляет SMS: «Ваш заказ готов, можно забрать до 19:00 по адресу ул. Советская, 12». Нагрузка на администратора снизилась втрое. Если вы только выбираете способ подключения, обратите внимание на сравнение SMPP и HTTP-шлюзов — это поможет понять, какой вариант быстрее и надёжнее для вашего объёма (SMPP против HTTP-шлюзов: скорость SMS для бизнеса Беларуси). Особенности белорусских служб доставки и как их учесть при интеграции В Беларуси доставку часто выполняют небольшие курьерские компании и самозанятые водители. Графики работы, зоны доставки и тарифы меняются без предупреждения. Стандартная автоматизация (оплачен → отправлен → доставлен) тут не подходит. Что нужно учесть: Множество статусов. Помимо базовых, могут быть «ожидает подтверждения курьером», «передан в доставку», «повторная доставка». Каждый статус требует своего текста. География. Доставка из Могилёва в Калинковичи может занимать два дня, а не один. Нужно настраивать разные сценарии для разных городов. Сезонность. Летом в отпускной сезон курьеров меньше, задерживается доставка в Барановичи и Полоцк. SMS-уведомление о задержке с извинениями снижает отток клиентов. Совет: делайте не один сценарий, а несколько под каждый тип доставки. Например, собственная курьерская служба — отправляйте «Курьер выехал» и «Курьер через 30 минут». Партнёрская служба — только «Заказ передан в доставку» и «Доставлено». Чтобы правильно настроить интеграцию и не допустить дублирования сообщений при сбоях сети, используйте проверенные схемы (Настройка SMPP-шлюза: как избежать дублирования SMS при сбоях). Как писать текст сообщения, чтобы клиент не звонил уточнять Короткие SMS работают лучше. Исследований не нужно — проверьте на себе: когда вам приходит «Статус заказа №1234 изменён на «В пути»», вы всё равно звоните уточнять, когда приедет. А «Ваш заказ №1234 прибудет завтра с 15 до 18, курьер позвонит за час» — ответа не требует. Для белорусских служб доставки важно указывать локальные детали: Номер заказа (клиент должен понимать, о чём речь). Ожидаемую дату и время (в формате, принятом в регионах: «после обеда», «до 12» — уточняйте у перевозчика). Телефон для связи в случае проблем (лучше прямой номер курьера, если это разрешено). Имя получателя (если заказ не на имя клиента — часто бывает в подарок). Пример из Витебска: интернет-магазин детских товаров отправляет сообщение в два этапа: «Заказ №500: в понедельник с 10 до 14 курьер привезёт игрушки. Если нужно перенести — ответьте на это SMS». Второй этап — за час до приезда автоматическая SMS с именем курьера. Отказов от заказа стало меньше на 20%. Чтобы не перегружать клиента лишними данными, читайте о балансе автоматизации и личного внимания (Персональные SMS-напоминания: баланс автоматизации и внимания). Типичные ошибки при настройке уведомлений Одно сообщение на все статусы. Клиент получает «Заказ изменён» и не знает, что делать. Отправка без привязки к часовому поясу. SMS в 23:00 из-за перевода часов (в Беларуси переход на летнее время отменили, но в соседних странах — нет) вызывает негатив. Отсутствие проверки на одинаковый статус. Курьер пять раз подтверждает выезд — клиент получает пять SMS. Длинные сообщения. Вместо одного SMS (70 кириллических символов) отправляется два. Лучше сокращать текст, чем платить за вторую часть. Игнорирование отписок. Клиенты после доставки часто хотят оставить отзыв, но не знают как. Добавьте короткую ссылку или инструкцию в последнем сообщении. Подробнее о том, почему клиенты перестают читать SMS и как это исправить, рассказано в отдельной статье (Почему клиенты не читают SMS: диагностика и план действий). 3 шага, которые можно сделать на этой неделе: Выпишите все статусы доставки, которые использует ваша компания или партнёрская служба. Их должно быть не больше 6–7 штук. Подготовьте тексты для каждого статуса. Уложитесь в 1 sms (около 60 символов кириллицы + имя клиента и номер заказа). Настройте тестовую отправку на себя через SMS-платформу (SMPP или гибридный шлюз). Убедитесь, что сообщения приходят в течение 5 секунд после изменения статуса. Полезные ссылки: SMPP против HTTP-шлюзов: скорость SMS для бизнеса Беларуси, Статус доставки SMS: почему важны детали, а не общая статистика, Настройка SMPP-шлюза: как избежать дублирования SMS при сбоях. > Source: https://smpp.by/integratsiya-sms-uvedomleniy-o-statuse-zakaza-dlya-dostavki-v-belarusi --- # Статус доставки SMS: почему важны детали, а не общая статистика Когда предприниматель запускает SMS-рассылку, он хочет быть уверен, что каждое сообщение дошло до клиента. Общий отчёт с одним процентом доставки не даёт этой уверенности. Отслеживание статуса каждого отправленного сообщения — delivered, undelivered, expired или rejected — показывает реальную картину. Без такой детализации невозможно понять, где именно теряются заказы и деньги. Разберём на примерах из Беларуси, какую пользу приносит постатусный контроль и как его настроить. Что скрывается за словом «доставлено» в общем отчёте Представьте небольшой интернет-магазин в Минске, который продаёт товары для рукоделия. За месяц отправлено 2000 SMS с уведомлениями о статусе заказа. Оператор шлюза присылает отчёт: «Доставка 94 %». Кажется, всё хорошо. На деле из 2000 сообщений 120 не дошли. Из них 60 абонентов сменили оператора, 30 — номер заблокирован, 20 — телефон выключен, ещё 10 — сообщение отклонено по тайм-ауту. Без разбивки по статусам магазин не узнает, что 90 клиентов можно вернуть, обновив контакты или выбрав другой канал связи. А общий процент скрывает проблему. Как сделать: запросите у провайдера или SMPP-шлюза расширенный DLR (Delivery Receipt) с кодами ошибок. В протоколе SMPP статус доставки передаётся в виде числа, которое расшифровывается по спецификации. Настройте логирование этих статусов в своей CRM или отдельной таблице. Раз в неделю проверяйте не только процент, но и распределение причин недоставки. Как статус доставки помогает чистить базу и экономить деньги Пример — салон красоты в Бресте. Он два раза в месяц отправляет SMS о новых услугах и свободных окнах. Рассылка идёт по базе из 3000 номеров. Общий отчёт показывает 89 % доставки. Владелец платит за все 3000 отправок. Если посмотреть детально: 150 номеров не существует, 180 — «вне зоны» (недоступны более месяца), 70 — отклонены из-за тарифных ограничений. Итого 400 номеров — мёртвый груз. Переплата за них — примерно 40 BYN в месяц (при цене 0,10 BYN за SMS). За год — 480 BYN. Но главное — эти 400 номеров засоряют базу, искажают статистику открываемости и мешают нормальной работе с лояльной аудиторией. Как сделать: используйте статусы undelivered для автоматического удаления или переноса номера в «чёрный список» после двух последовательных недоставок. В процессе масштабирования SMS-оповещений важно настроить правило: если номер даёт ошибку «абонент недоступен» более 30 дней, помечать его на верификацию. Это снижает затраты и повышает репутацию отправителя. Задержки и перегрузки: почему детализация важна для интернет-магазина в Минске Интернет-магазин электроники в Минске в период распродаж отправляет до 5000 SMS в день: уведомления о подтверждении заказа, сборке, отправке, готовности к выдаче. Пик — с 18 до 21 часа. Если смотреть только общий отчёт, видно, что доставка 97 % — вроде нормально. Но по детальным логам оказывается, что часть сообщений приходит с задержкой 20–40 минут. Клиент уже приехал в пункт выдачи, а SMS пришло после того, как он ушёл. Это увеличивает количество звонков в поддержку и возвраты. Как сделать: настройте мониторинг времени доставки по каждому статусу. В сравнении SMPP и HTTP-шлюзов первый даёт возможность получать DLR в реальном времени. Если видите, что для 5–10 % сообщений статус приходит через 15 минут и более, проверяйте нагрузку на свой сервер и канал связи. Возможно, нужно уменьшить количество одновременных соединений (bind) или выбрать другого оператора для пиковых часов. Какие коды статусов нужно смотреть обязательно DELIVRD — сообщение доставлено. UNDELIV — не доставлено, причина временная (абонент вне зоны, телефон выключен). EXPIRED — сообщение не доставлено за время жизни (обычно 1–3 дня). Номер может быть недоступен или заблокирован. REJECTD — отклонено оператором (спам-фильтр, неверный формат, тарифные ограничения). DELETED — удалено провайдером (например, при перегрузке очереди). Типичные ошибки при работе со статусами доставки Полагаться на сводный отчёт за месяц и игнорировать подневную динамику. Не хранить историю статусов больше 30 дней — невозможно выявить тенденцию. Смешивать статусы от разных операторов без нормализации — коды могут отличаться (например, «Delivery Impossible» в одном шлюзе и «Undelivered» в другом). Не обрабатывать статус «EXPIRED» — через неделю можно отправить повторно через другой канал (Viber, WhatsApp), но без анализа вы этого не узнаете. Отключать DLR для экономии трафика — это лишает вас единственного инструмента контроля. Нет автоматического алерта при резком падении процента доставки (например, ниже 80 %) — проблему замечают через неделю. Как настроить постатусный контроль — три шага на неделю 3 шага, которые можно сделать сегодня: Проверьте текущий формат получения DLR. Если используете HTTP-шлюз — убедитесь, что он возвращает код причины недоставки, а не просто «ok». Если есть возможность перейти на SMPP — сделайте это. SMS через SMPP надёжнее мессенджеров для уведомлений и даёт полный контроль над статусами. Настройте ежедневный скрипт (или запрос в CRM), который группирует статусы по каждому оператору. Сравните процент доставки в МТС, life:) и А1. Если у одного оператора более 5 % «UNDELIV», проверьте настройки маршрутизации у своего провайдера. Введите правило очистки базы: номера с двумя статусами EXPIRED подряд отправлять на повторную верификацию через другой канал (например, Viber) или временно блокировать для SMS-рассылок. Через месяц вы увидите снижение расходов и рост реальной доставки. Постатусный контроль — не техническая роскошь, а инструмент экономии и качества сервиса. Перестаньте доверять общим цифрам и начните видеть каждый номер. Это напрямую влияет на лояльность клиентов и бюджет на рассылки. Полезные ссылки: Протокол SMPP — что это, Масштабирование SMS-оповещений: от ручной отправки к SMPP-шлюзу, SMPP против HTTP-шлюзов: скорость SMS для бизнеса Беларуси. > Source: https://smpp.by/status-dostavki-sms --- # Настройка SMPP-шлюза: как избежать дублирования SMS при сбоях Когда канал между вашим сервером и SMPP-провайдером рвётся, сообщение может отправиться дважды. Клиент получает дубль — раздражение, бизнес теряет деньги на лишних сообщениях. Разбираем причины и методы защиты. Основные причины дублирования при сбое канала Автомастерская в Минске использует SMPP для уведомления клиентов о готовности авто. При кратковременном обрыве интернета мастерская повторно отправила команду «машина готова». Клиент получил два одинаковых SMS, позвонил с претензией. Причина: бизнес не дождался подтверждения от провайдера и отправил повтор по таймауту. Совет: настройте таймаут ожидания ответа submit_sm_resp на 10–15 секунд и используйте уникальный message_id на стороне отправителя. Если ответ не пришёл, не отправляйте то же сообщение с тем же идентификатором — проверьте статус через query_sm. Идемпотентность и повторная отправка Интернет-магазин в Гомеле отправляет уведомления о статусе заказа. После обрыва канала система повторяла команду с тем же sequence_number. Провайдер принял обе команды как разные и отправил два SMS. SMPP-протокол быстрее HTTP-шлюзов, но без правильной логики повторной отправки скорость не спасает от дублей. Совет: каждое сообщение должно иметь уникальный идентификатор на стороне отправителя (sequence_number или user_message_id). При повторной отправке того же содержимого используйте тот же идентификатор. Провайдер, поддерживающий дедупликацию, не отправит дубль. Уточните у поставщика, работает ли фильтр дублей. Механизм enquire_link для контроля соединения Салон красоты в Бресте каждое утро отправляет напоминания о записи. Потеря пакетов на линии приводила к тому, что SMPP-клиент считал соединение живым, хотя провайдер уже разорвал сессию. Сообщения уходили в никуда или дублировались после переподключения. Совет: настройте enquire_link с интервалом 30–60 секунд. Если ответ не получен, закрывайте сессию и открывайте новую. В новой сессии проверяйте, какие сообщения не получили подтверждения, и отправляйте их заново с тем же уникальным ID. Тестирование перед запуском SMS-уведомлений через SMPP Пекарня в Витебске планирует рассылать уведомления о свежей выпечке подписчикам. Запустили без теста — в первый день после временного отключения электричества часть клиентов получила сообщение дважды. Пришлось вручную корректировать базу и извиняться. Совет: используйте тестовый SMPP-аккаунт провайдера. Симулируйте обрыв канала (выключите сетевой кабель на сервере на 20 секунд) и проверьте, сколько сообщений дошло. Логи должны показать не более одной отправки с одним ID. Типичные ошибки при настройке защиты от дублей Игнорирование параметра registered_delivery — без него вы не получите финальный статус доставки и не поймёте, дошло ли сообщение. Использование одного sequence_number для нескольких сообщений — провайдер может принять их за одно. Слишком короткий таймаут на ответ submit_sm_resp (менее 5 секунд) — частые ложные срабатывания повторной отправки. Отсутствие логирования ошибок — вы не видите, когда и почему происходит дубль. Неправильная обработка reconnect: после восстановления соединения некоторые библиотеки автоматически повторяют все неотправленные сообщения без проверки, были ли они уже приняты провайдером. Использование стандартных настроек без учёта своего провайдера — у разных операторов разное время ожидания и политика дедупликации. 3 шага, которые можно сделать уже на этой неделе: Проверьте логи вашего SMPP-клиента на дубли сообщений за последние 7 дней. Если дубли есть — зафиксируйте точное время и идентификаторы. Настройте enquire_link с интервалом 30 секунд и таймаут на ответ submit_sm_resp 15 секунд. Протестируйте на тестовом аккаунте. Внедрите уникальный message_id для каждого сообщения на стороне вашей CRM или биллинга. Убедитесь, что при повторной отправке ID не меняется. Полезные ссылки: SMPP против HTTP-шлюзов: скорость SMS для бизнеса Беларуси, Почему SMS через SMPP надёжнее мессенджеров для уведомлений. > Source: https://smpp.by/nastroyka-smpp-shlyuza --- # Сегментация контактов для Back to School: готовим базу к августу 2026 Подготовка базы клиентов к сезону «Back to School» — это способ увеличить продажи в августе без лишних затрат. Сегментация помогает отправлять актуальные предложения тем, кто действительно ждет их, а не тратить бюджет на всю базу сразу. Ниже — практические шаги для магазинов канцтоваров, детской одежды, книжных и других бизнесов, которые работают со школьной темой в Беларуси. Почему сегментация важна перед школьным сезоном Магазин канцтоваров в Минске каждый август рассылает одну акцию на все контакты. Результат — 40% отписок и конверсия 0,5%. Причина: база состоит из родителей, учителей, оптовых покупателей и случайных людей. Каждой группе нужен свой товар и своя цена. Совет: разделите базу на сегменты по признаку «есть ли дети школьного возраста» и «роль — родитель / педагог / оптовик». Собрать эти данные можно через предыдущие покупки (канцтовары для школы), через опрос в соцсетях или в момент подписки попросить указать возраст детей. Чем точнее сегмент, тем выше отклик. Подробно о методах сегментации читайте в статье: Сегментация клиентов для SMS: снижаем затраты и повышаем отклик. Как подготовить базу: шаги для малого бизнеса Салон детской одежды «Малыш» в Гродно начал подготовку за две недели до августа. Собрал данные из CRM, выгрузил контакты в Excel, убрал дубли и неактивные номера. Затем присвоил теги: «родители первоклассников», «родители учеников 5–9 классов», «учителя начальных классов». Каждой группе отправили своё предложение. Совет: используйте простую таблицу или Google Sheets, если у вас нет CRM. Создайте столбцы: имя, телефон, сегмент, дата последней покупки, средний чек. На основе этих полей формируйте выборки для рассылки. Для автоматизации подойдет интеграция с SMPP-шлюзом — это исключит ручную отправку. О том, как настроить автоматические сценарии, рассказано в руководстве: Автоматизация SMS-рассылок: практическое руководство для малого бизнеса. Примеры сегментов для Back to School Типичные группы для школьного сезона: Родители первоклассников — нужен полный набор: форма, рюкзак, пенал, тетради. Им можно предлагать комплекты со скидкой. Родители учеников средней школы — чаще докупают канцелярию, дневники, сменную обувь. Предложение — «второй предмет дешевле». Учителя — методички, журналы, указки, наглядные пособия. Им выгодна оптовая скидка при заказе от 100 BYN. Оптовые клиенты — школы, гимназии, детские центры. Для них — персональный менеджер и отдельный прайс. Книжный магазин в Витебске в прошлом году отправил учителям SMS с промокодом на учебную литературу — конверсия составила 12%. Для родителей первоклассников сделали отдельную акцию «Собери портфель за 80 BYN». Совет: для каждого сегмента готовьте уникальный промокод. Так вы сможете точно измерить, какая группа принесла больше выручки. Автоматизация и триггеры Магазин рюкзаков в Могилёве настроил триггер: клиент, купивший рюкзак, через 5 дней получает SMS со скидкой 10% на пенал. Это повысило средний чек на 15%. В августе такие триггеры особенно эффективны, потому что покупки идут серийно (форма, потом рюкзак, потом канцелярия). Совет: настройте автоматическое информирование при наступлении августа — например, отправляйте «приветственное» письмо с подборкой товаров для всех, кто указал в профиле возраст детей 6–17 лет. Используйте SMPP-соединение для мгновенной доставки — без задержек, как это бывает с HTTP-шлюзами (об этом — в статье Как малому бизнесу Беларуси использовать SMS для сезонных распродаж). Типичные ошибки Отправлять один и тот же текст всем — учителя не хотят видеть рекламу детских рюкзаков, а родителям неинтересны методички. Не чистить базу от неактивных номеров. Если человек не открывал SMS больше года, он с высокой вероятностью не заинтересован в школьных товарах. Выбирать неподходящее время отправки. Большинство родителей проверяют телефон после 18:00, учителя — в обед. Общее утреннее время работает плохо. Игнорировать выходные. В субботу и воскресенье люди чаще заказывают онлайн, чем в будни. Не отслеживать доставляемость. Если оператор блокирует часть сообщений (например, в регионах с плохим сигналом), вы теряете клиентов. Проверяйте статус доставки через SMPP-сервер. Полезные ссылки: Сезонные SMS-кампании: подготовка малого бизнеса Беларуси к осени — расширенный материал по планированию на август-сентябрь. 3 шага, которые можно сделать сегодня: Выгрузите базу клиентов и проверьте сегменты по истории покупок за прошлый август. Разделите подписчиков на 3–4 группы: родители, учителя, оптовики, «другое». Подготовьте 2–3 варианта текста для каждой группы с уникальным промокодом. Эти действия займут пару часов, но уже через неделю вы получите готовую к рассылке базу, которая сработает лучше, чем массовая отправка. > Source: https://smpp.by/segmentatsiya-kontaktov-dlya-back-to-school --- # SMPP против HTTP-шлюзов: скорость SMS для бизнеса Беларуси Если вы отправляете клиентам коды подтверждения, уведомления о статусе заказа или напоминания о записи, скорость доставки сообщения решает, вернётся ли клиент. В 2026 году в Беларуси выбор между прямым SMPP-соединением и облачным HTTP-шлюзом уже не техническая деталь, а бизнес-решение. SMPP — это протокол, по которому ваш сервер напрямую связывается с мобильным оператором, минуя посредников. HTTP-шлюз — это готовый сервис, который принимает запросы через интернет и отправляет SMS дальше. Разница во времени доставки критична, когда у вас сотни заказов в час или сезонный наплыв клиентов. Как SMPP выигрывает в минуты пиковых нагрузок: пример минской сети кофеен Сеть из 15 кофеен в Минске запустила акцию «второй напиток бесплатно» по QR в приложении. В час пик система должна была отправить 1200 кодов подтверждения. Через облачный HTTP-шлюз сообщения уходили с задержкой 5–15 секунд, а часть — до 30 секунд. Клиенты не дожидались, перезагружали страницу и уходили. После перехода на SMPP-соединение среднее время доставки упало до 0,5–1 секунды. Загрузка на сервере не повлияла на очередь, потому что протокол держит постоянное соединение без пересоздания HTTP-сессий для каждого запроса. Совет: если ваш бизнес генерирует более 200 сообщений в час с пиками до тысячи, тестируйте прямые SMPP-подключения через локальных операторов (МТС, A1, life:) — они отдают приоритет такому трафику по SLA. Когда облачный HTTP-шлюз всё ещё удобен: пример интернет-магазина из Гродно Небольшой магазин товаров для рукоделия в Гродно отправляет около 50 SMS в день: уведомления о заказе, подтверждение отправки. Объём стабильный, без резких скачков. Владелец использует готовый HTTP-шлюз с тарификацией «за сообщение» — это стоит около 0,10–0,15 BYN за SMS. Настройка заняла 15 минут через API. Скорость доставки — 2–5 секунд, что для его клиентов приемлемо. Переходить на SMPP нет смысла: нужно настраивать свой сервер, платить за фиксированный канал и брать на себя мониторинг. Совет: если ваш объём меньше 100 SMS в день и вы не планируете рост, HTTP-шлюз оправдан. Если видите, что через полгода-год будете отправлять 500+ сообщений в день, закладывайте бюджет на миграцию на SMPP заранее. Скорость и белорусские операторы: кому отдаётся приоритет У всех трёх мобильных операторов Беларуси — МТС, A1, life:) — трафик через SMPP-соединение обрабатывается раньше, чем запросы с облачных шлюзов. Причина: облачный шлюз — это агрегатор, который перепродаёт трафик нескольких клиентов. Оператор видит такой трафик как единый пул, где его приходится распределять по очередям. При перегрузке сети (новогодние праздники, акции в чёрную пятницу) HTTP-запросы могут вставать в очередь на минуты. Прямой SMPP-канал — это как VIP-полоса: оператор знает объём вашей нагрузки и резервирует пропускную способность. Тест, проведённый в Гомеле летом 2025 года, показал, что в пиковый час (11:00–12:00) сообщения через SMPP доставлялись за 0,8 секунды, через облачный шлюз того же провайдера — за 7,2 секунды. Разница в 9 раз. Типичные ошибки при выборе между SMPP и HTTP-шлюзом Думать, что все HTTP-шлюзы одинаковы. На деле один может держать канал с оператором в Минске с задержкой 1–2 секунды, а другой маршрутизировать через Москву или Европу, добавляя 5–10 секунд. Проверяйте маршрут доставки в тестовом режиме. Игнорировать рост объёма. Владельцы кафе в Бресте начинали с 30 SMS в день, через год — 400, и упирались в лимиты HTTP-шлюза на 1000 запросов в минуту. Пришлось срочно переходить на SMPP с потерей нескольких дней продаж. Путать SMPP с API облачного шлюза. Некоторые провайдеры предлагают «SMPP-доступ», но на деле шлют трафик через свой же HTTP-шлюз с той же очередью. Требуйте прямое соединение с оператором и просите логи времени доставки. Не закладывать время на интеграцию. Настройка SMPP требует доработки CRM или сервера (обычно 1–3 дня работы программиста). HTTP-шлюз настраивается за час. Планируйте миграцию на низкий сезон. Забыть про мониторинг. Через SMPP вы отвечаете за то, что ваш сервер не лёг. Если нет системы проверки времени доставки, вы узнаете о проблеме только от клиентов. Внедрите алерты на задержку >5 секунд. Что выбрать малому бизнесу в 2026 году в Беларуси Для большинства микро- и малых бизнесов (салоны, мастерские, небольшие магазины с 10–50 заказами в день) облачный HTTP-шлюз достаточен. Главное — выбирать проверенного оператора, который имеет прямые договоры с белорусскими мобильными сетями. Если ваш бизнес — кафе с доставкой, стоматология с напоминаниями, интернет-магазин с 200+ заказами в день — SMPP-соединение снижает риск потери клиентов из-за задержек. В Гродно, Витебске, Могилёве, Мозыре, Барановичах скорость доставки через SMPP обычно стабильнее, чем через HTTP, потому что меньше промежуточных звеньев. Полезные ссылки: Когда облачные SMS невыгодны: переход на SMPP-шлюз, Протокол SMPP для SMS-рассылок: руководство для малого бизнеса Беларуси, Почему SMS через SMPP надежнее мессенджеров для уведомлений 3 шага, которые можно сделать сегодня или на этой неделе Проверьте текущие KPI доставки. Отправьте тестовое SMS через ваш текущий сервис и засеките время от нажатия «отправить» до получения на телефоне из Минска, Гомеля и небольшого города (например, Хойники или Петриков). Разница больше 10 секунд — повод задуматься. Запросите у вашего SMS-провайдера информацию, используют ли они прямое SMPP-соединение с операторами или HTTP-шлюз с перепродажей. Если второе — попросите коммерческое предложение на прямой канал. Если объём растёт и вы планируете отправлять более 500 SMS в день в ближайшие полгода, начните пилотировать SMPP-подключение с одним тестовым сценарием (например, только уведомления об оплате). Посмотрите на скорость и стабильность в течение месяца. > Source: https://smpp.by/smpp-protiv-http-shlyuzov --- # Смена поставщика SMS-шлюза: перенос базы и истории доставок Смена провайдера SMS – нормальный процесс. Компания растёт, меняются условия, нужен более гибкий протокол. Но потерять накопленную базу клиентов или историю доставок обидно. Рассказываю, как перенести данные без потерь и без боли. Что включает перенос базы контактов База подписчиков — главный актив. Если вы вели рассылки год-два, в ней могут быть сотни или тысячи номеров. Просто скачать файл и загрузить в новый шлюз недостаточно. Пример. Кафе на Немиге (Минск) решило уйти от облачного сервиса к прямому SMPP-подключению из-за высокой стоимости при росте объёмов. У них 2200 подписчиков. Старый провайдер отдал базу в CSV, но номера были в формате +37529xxxxxxx, а новый шлюз требовал 37529xxxxxxx (без +). Загрузили как есть — половина номеров не прошла валидацию. Совет. Выгружайте контакты в простом текстовом формате (CSV, TXT) с одним полем — номер. Проверьте международный формат: код страны 375, без лишних символов. Очистите базу от дублей и номеров, на которые не доставилось ни одно сообщение за последние 6 месяцев. Так вы не заплатите за мёртвые контакты у нового провайдера. Как сохранить историю доставок История доставок нужна для анализа: какие письма сработали, какие нет, в какое время лучше отправлять. Без неё вы теряете полгода статистики. Пример. Салон красоты в Гомеле 2 года вёл рассылки через один сервис. Решил перейти на SMPP-шлюз (с описанием протокола можно ознакомиться в статье Протокол SMPP для SMS-рассылок: руководство для малого бизнеса Беларуси). Запросили у старого провайдера логи доставок — получили Excel с датами, статусами, текстами сообщений. В новом шлюзе смогли загрузить эту таблицу и продолжить анализировать тренды за 2 года. Совет. За две недели до смены попросите у текущего провайдера полную выгрузку: дата, номер отправителя, номер получателя, статус (доставлено/не доставлено), текст сообщения. Выгружайте за весь период работы, а не за последний месяц. Если формат неудобный (PDF, изображения) — попросите CSV или XML. Откажитесь — подумайте, стоит ли оставаться. Что делать с архивами и настройками триггеров Триггерные рассылки (подтверждение заказа, напоминание о записи) — сердце автоматизации. При смене поставщика их нужно воссоздать. Пример. Интернет-магазин в Бресте использовал триггеры: при оплате → SMS с кодом выдачи, через 2 дня → запрос отзыва. В старом шлюзе настройки были сделаны через веб-интерфейс. При переходе на SMPP-шлюз (подробнее о преимуществах — Когда облачные SMS невыгодны: переход на SMPP-шлюз) оказалось, что триггеры нужно перенастраивать через API. Хорошо, что владелец заранее скопировал все условия (когда срабатывает, какой текст отправляется, на какой адрес идёт уведомление). Восстановили за час. Совет. Составьте таблицу: название триггера, событие (изменение статуса заказа, проход времени), текст сообщения, задержка. Сравните возможности нового шлюза со старым. Если новый не поддерживает какое-то условие — ищите замену или готовьтесь допиливать через API. Лучше подстраховаться — Масштабирование SMS-оповещений: от ручной отправки к SMPP-шлюзу. Типичные ошибки при смене поставщика Перенос базы без проверки кодировки. Если старый провайдер отдал в UTF-8, а новый ожидает Windows-1251, текст может превратиться в кракозябры. Всегда конвертируйте в один формат и тестируйте. Игнорирование тестовой отправки. Не отправляйте массовую рассылку сразу после переноса. Протестируйте на 20-50 номерах: проверьте доставляемость, длину SMS, подпись отправителя. Забыли про блэклисты. Некоторые провайдеры блокируют номера, которые жаловались на спам. Уточните: новый поставщик может принять этот список и не отправлять на такие номера, чтобы не портить репутацию. Если не спросили — будете платить за бесполезные отправки. Слепое доверие обещанию "мигрируем всё за вас". Часто провайдер делает только базовый перенос (номера) без истории доставок и настроек. Контролируйте процесс, сверяйте данные до и после. Не проверили интеграцию с CMS. Если рассылки тянутся из 1С, WordPress или своей системы, после смены шлюза может слететь API. Обновите ключи, протестируйте хотя бы один сценарий. Три шага, которые можно сделать сегодня/на неделе Соберите текущую базу контактов в единый текстовый файл с номерами в международном формате (37529...). Удалите дубли и номера с статусом "не доставлено" за последние полгода. Запросите у текущего провайдера полную историю доставок за весь период работы в формате CSV или Excel. Если провайдер отказывается — это тревожный знак. Составьте карту триггеров и шаблонов: события, тексты, задержки. Сравните с возможностями нового шлюза. Подготовьте план воссоздания автоматизации. Смена поставщика — не повод терять накопленные данные. Продуманный перенос сэкономит вам недели на настройке и сохранит аналитику. Если сомневаетесь в выборе шлюза, сравните условия нескольких провайдеров и протестируйте работу с каждым на малом объёме. > Source: https://smpp.by/smena-postavschika-sms-shlyuza --- # Оптимизация SMS-расходов в сезон спада: тактика для Беларуси 2026 Спад спроса в июле и августе — обычное дело для многих бизнесов в Беларуси. Клиенты в отпусках, поток заказов падает. В такой период важно не тратить бюджет на рассылки впустую. Рассказываю, как настроить SMS-информирование экономно, сохраняя контакт с клиентами. Сегментация базы: отправляем только тем, кто готов купить Пример: салон красоты в Минске сократил бюджет на рассылки на 30%. Они разделили клиентов на две группы — активные (были за последние 3 месяца) и спящие (не записывались дольше). Активным отправляли только напоминания о записи и стандартные акции один раз в две недели. Спящим — разовую скидку с ограниченным сроком действия. В результате количество отписок снизилось, а конверсия в запись у спящих выросла с 2% до 8%. Совет: перед рассылкой очистите базу от номеров, которые не отвечали больше года. Используйте данные о последней покупке или визите. Если CRM позволяет, поставьте метки по частоте заказов. Для сегментации можно взять готовые фильтры или запросить у поставщика услуг — это бесплатно. Переход на SMPP-шлюз вместо облачных сервисов Пример: магазин стройматериалов в Гомеле отправлял около 12 000 SMS в месяц через облачный сервис по 0,12 BYN за сообщение. После подключения прямого SMPP-шлюза стоимость упала до 0,08 BYN. Экономия — 480 BYN ежемесячно. Дополнительно они настроили автоматические триггеры, что позволило сократить ручной труд администратора. Совет: если ваш объем превышает 3–5 тысяч SMS в месяц, посчитайте разницу между тарифом облачного сервиса и ценой через SMPP-протокол. Когда облачные SMS невыгодны: переход на SMPP-шлюз — там подробный разбор цифр для белорусского бизнеса. Окупаемость подключения обычно наступает через 2–3 месяца. Триггерные SMS вместо массовых рассылок Пример: автосервис в Бресте раньше рассылал всем клиентам одно и то же сообщение о сезонном техосмотре раз в квартал. Потом настроили триггер: SMS отправляется только тем, кто последний раз проходил ТО 6–8 месяцев назад. Частота рассылок упала вдвое, а доля записей на услугу выросла с 3% до 11%. Бюджет на SMS сократился на 45%. Совет: определите три события, на которые реагируют ваши клиенты: истечение срока абонемента, незавершённая оплата, день рождения. Настройте в системе автоматическое срабатывание. Для малого бизнеса Беларуси триггеры — один из самых эффективных способов снизить расходы. Как малому бизнесу Беларуси внедрить триггерные SMS-рассылки в 2026 году — пошаговая инструкция. Анализ метрик: что реально окупается Пример: кафе в Гродно тратило 200 BYN в месяц на массовые рассылки с новинками меню. Чеки отслеживали по промокодам — принесли эти SMS только 300 BYN выручки. После смены тактики стали отправлять персонализированные предложения (например, скидка на блюдо, которое клиент заказывал раньше). Бюджет остался тем же, а выручка с одной рассылки выросла до 900 BYN. Ключевое — считали стоимость привлечения клиента. Совет: для каждой рассылки используйте отдельные короткие ссылки (через сервисы типа t2m или bitly). Сравнивайте не только открываемость, но и число целевых действий: переход на сайт, запись, оформление заказа. Если рассылка окупает себя хотя бы в 1,5 раза — оставляйте. Если нет — убирайте или меняйте подход. Типичные ошибки при экономии на SMS Отправка одного и того же сообщения всей базе без учёта истории покупок. Результат — отписки и низкий отклик. Использование длинных текстов с лишними словами. Каждые 70 символов — один SMS. Сокращайте сообщение до 2–3 SMS вместо 5–6. Экономия до 40%. Рассылка в часы пик (09:00–10:00 и 17:00–19:00). В это время конкуренция за внимание максимальная. Лучше утро 8:00 или вечер 20:00. Игнорирование команды STOP. Если клиент отписался — не пытайтесь отправить снова. Вы теряете доверие и рискуете получить блокировку номера. Забывают про A/B тестирование. Перед массовой отправкой проверьте текст и время на 10% базы. Ошибка может стоить всего бюджета. Слишком частая рассылка (чаще раза в неделю) утомляет аудиторию и увеличивает отписки даже среди лояльных клиентов. 3 шага, которые можно сделать на этой неделе: Экспортируйте базу клиентов в Excel или Google Sheets. Поставьте метки: дата последнего заказа, сумма покупок, категория (активный/спящий). Это займёт 20–30 минут, но даст базу для сегментации. Настройте триггерное SMS-напоминание о записи или предстоящем визите. Если у вас нет собственной системы, попросите подключить шаблон через провайдера — это делается за один день и обычно бесплатно. Запустите A/B тест на 200–500 клиентах. Одна группа получает прежнюю массовую рассылку, другая — персонализированное предложение (с именем и скидкой на часто покупаемую позицию). Через неделю сравните конверсию и выберите лучший вариант. > Source: https://smpp.by/optimizatsiya-sms-raskhodov-v-sezon-spada --- # Почему SMS через SMPP надежнее мессенджеров для уведомлений SMPP-протокол даёт прямое соединение с сетями операторов. Мессенджеры зависят от интернета и чужих серверов. Для бизнеса это означает: SMS дойдёт, даже если у клиента отключён мобильный интернет, разряжен смартфон или он вышел из аккаунта. Разберём, почему для уведомлений о статусе заказа, напоминаний о записи и подтверждений оплаты стоит выбирать SMPP, а не Telegram, Viber или WhatsApp. Почему Telegram и Viber не гарантируют доставку Интернет-магазин косметики в Гомеле отправлял уведомления о статусе заказа через Telegram-бота. Из 30 заказов в день в среднем 2–3 клиента не получали оповещение. Причина — у них не было активно соединения с интернетом или они вышли из аккаунта. В итоге заказы отменялись, люди звонили и ругались. После перехода на SMS через SMPP доставка выросла до 99%. Совет: критические уведомления (подтверждение оплаты, статус доставки, код подтверждения) отправляйте только через SMS. Мессенджеры оставьте для маркетинговых акций и анонсов, где задержка в несколько часов не критична. Подробнее о том, как настроить такие сценарии, читайте в статье Как малому бизнесу Беларуси внедрить триггерные SMS-рассылки в 2026 году. SMPP — зарезервированный канал без посредников Кафе в Минске использовало Viber для напоминаний о брони. Когда клиент не добавлял номер в контакты, Viber блокировал сообщение как спам. При этом SMS доходили всегда. Протокол SMPP устанавливает прямое соединение с SMSC оператора, минуя фильтры мессенджеров. Сообщение идёт по тому же каналу, что и обычные SMS — максимально короткий путь. Совет: выбирайте SMPP-провайдера с прямым подключением к трём белорусским операторам — МТС, А1, life:) . Уточните, использует ли провайдер собственную платформу или арендует шлюзы у третьих лиц. Прямое подключение снижает задержки и исключает посредников. О том, когда выгодно перейти с облачных SMS на собственный SMPP-шлюз, рассказано в статье Когда облачные SMS невыгодны: переход на SMPP-шлюз. Стабильность при пиковых нагрузках Перед Новым годом интернет-магазин в Бресте столкнулся с тем, что Viber-рассылка заказов встала на 4 часа из-за лимитов на отправку. Клиенты не получали уведомления, поддержка захлебнулась звонками. SMPP-протокол позволяет отправлять тысячи сообщений в секунду без очередей. Для микро- и малого бизнеса с объёмом 500–3000 SMS в месяц достаточно пропускной способности 5–10 сообщений в секунду, но надёжнее брать с запасом. Совет: проверьте, какой лимит сообщений в секунду (throughput) предлагает провайдер. Попросите тестовый период и отправьте несколько сотен сообщений подряд. Убедитесь, что задержки не растут при 10–20 сообщениях в секунду. Даже для небольшого магазина лучше иметь возможность быстро разослать срочное оповещение, например, о переносе времени доставки. Типичные ошибки Использовать только один канал (мессенджер) для всех уведомлений без резерва. Если сервер мессенджера ляжет — клиенты останутся без информации. Не проверять настройки SMPP-соединения: bind mode должен быть transmitter (для отправки) или transceiver (отправка+приём). Ошибка в таймаутах приводит к потерям сессий. Отправлять одинаковые шаблоны без номера заказа, суммы или времени. Люди не доверяют безличным сообщениям. Не учитывать, что часть клиентов принципиально не пользуется мессенджерами (нет смартфона, не хотят ставить приложения). SMS — универсальный канал для всех. Думать, что SMPP сложен. На практике для интеграции нужен только IP-адрес провайдера, порт, логин и пароль. Большинство CMS (WordPress, CS-Cart, DLE) имеют готовые плагины. Полезные ссылки: Протокол SMPP для SMS-рассылок: руководство для малого бизнеса Беларуси, Преимущества использования SMS-рассылок для микро и малого бизнеса в Беларуси: практические советы. 3 шага для перехода с мессенджеров на SMPP сегодня: Соберите список критических уведомлений (подтверждение заказа, статус оплаты, напоминание о записи). Определите, сколько таких сообщений в день вы отправляете. Протестируйте SMPP-подключение любого провайдера с тарифом по числу сообщений. Запросите тестовый доступ и отправьте 50–100 реальных SMS. Настройте интеграцию: в CMS или CRM укажите параметры SMPP-шлюза. Убедитесь, что сообщения приходят мгновенно и с правильными данными. > Source: https://smpp.by/pochemu-sms-cherez-smpp-nadezhnee-messendzherov-dlya-uvedomleniy --- # Как настроить уведомления об оплате через SMPP: пошаговое руководство Если ваш бизнес принимает оплату картой, наличными или переводом, клиенты хотят сразу получить подтверждение. SMS об оплате через прямой SMPP-шлюз работает быстрее и надёжнее, чем отправка через облачные сервисы или Email. Это снижает нагрузку на персонал и повышает доверие. Рассказываю, как настроить такие уведомления самостоятельно. Что такое SMPP и почему он подходит для транзакционных SMS SMPP (Short Message Peer-to-Peer) — это протокол для прямой отправки SMS через оператора связи. Вы подключаетесь к нему через выделенный канал, минуя сторонние платформы. Для бизнеса это означает скорость доставки 1–3 секунды и полный контроль над статусами. Протокол SMPP для SMS-рассылок: руководство для малого бизнеса Беларуси объясняет технические детали. Пример из Беларуси. Салон красоты в Минске перешёл на SMPP, потому что через обычный SMS-шлюз уведомления об оплате приходили с задержкой до 15 минут. Клиенты ждали подтверждения у дверей — возникали конфликты. После настройки SMPP время доставки сократилось до 2 секунд, а число жалоб упало до нуля. Совет. Перед подключением проверьте, поддерживает ли ваш оператор (МТС, А1, life:) прямое SMPP-соединение. Чаще всего это услуга для юридических лиц с договором и выделенным IP. Шаг 1. Выбор способа подключения: через биллинг или напрямую Есть два пути: использовать готовый модуль в вашей CRM/бухгалтерии или написать интеграцию через API. Для микро- и малого бизнеса проще первый вариант. Пример из Беларуси. Интернет-магазин в Гомеле работает на популярной CRM, которая поддерживает плагины для SMPP. Владелец установил модуль, ввёл логин и пароль от шлюза — уведомления об оплате начали уходить автоматически. Настройка заняла 20 минут. Совет. Если используете готовую ERP-систему (например, 1С), уточните у разработчика, есть ли интеграция с SMPP. Если нет, подойдёт скрипт на Python или PHP, который слушает callback от платёжного шлюза и отправляет SMS через SMPP-клиент. Шаг 2. Настройка шаблонов и триггеров Уведомления об оплате должны содержать: сумму, дату, название услуги или товара, номер заказа. Не пишите лишнего — только факты. Одна SMS — одно сообщение. Пример из Беларуси. Автомастерская в Бресте настроила шаблон: «Оплата #123 получена. 180,00 BYN. Ремонт ходовой. Спасибо!» Клиенты перестали звонить с вопросом «деньги дошли?». Совет. Добавьте триггеры: при успешной оплате в CRM меняется статус, и SMPP-клиент отправляет SMS. Проверьте, что сообщение не уходит дважды — используйте флаг отправки в базе данных. Автоматизация SMS-рассылок: практическое руководство для малого бизнеса поможет избежать дублей. Типичные ошибки при настройке Неправильный формат номера. Белорусские номера пишите с кодом 375 без плюса и пробелов (375291234567). Иначе SMS не дойдёт. Задержки из-за кодировки. Кириллицу передавайте в UTF-8. Латинские буквы в русских словах выглядят странно и снижают доверие. Отсутствие мониторинга доставки. SMPP возвращает статус «доставлено» или «не доставлено». Настраивайте логи и проверяйте их раз в неделю. Игнорирование тайм-аутов. Если шлюз не отвечает 10 секунд, программа может зависнуть. Добавьте повторную отправку через 30 секунд, но не чаще 3 попыток. Отправка без проверки баланса. Деньги на счёте закончились — уведомления не ушли. Установите автоуведомление на email при остатке менее 50 BYN. Слишком длинные сообщения. Одна SMS — 70 кириллических символов. Если текст длиннее, он разбивается на несколько, и доставка может идти с задержкой. Укладывайтесь в один сегмент. Шаг 3. Тестирование перед запуском Не отправляйте уведомления реальным клиентам без проверки. Сначала протестируйте на своём номере, потом на номере коллеги. Проверьте разные суммы, валюты (BYN, USD), случаи частичной оплаты. Пример из Беларуси. Сервис по ремонту техники в Витебске протестировал уведомление о предоплате 50%. В шаблоне стояла полная сумма — клиент приехал и думал, что заплатил всё. Ошибку исправили за час. Совет. Попросите оператора (SMPP-провайдера) предоставить тестовый доступ на 1–2 дня. Обычно это бесплатный лимит в 100 SMS. Когда облачные SMS невыгодны: переход на SMPP-шлюз поможет оценить разницу в стоимости и скорости. 3 шага, которые можно сделать сегодня Проверьте текущий способ отправки уведомлений об оплате. Если используете Email или бесплатный SMS-агрегатор, запишите задержки за последнюю неделю. Свяжитесь с вашим оператором связи (МТС, А1, life:) или SMPP-провайдером и запросите тестовый доступ к прямому шлюзу. Обычно это занимает 1 день. Создайте шаблон уведомления об оплате: не длиннее 70 символов, с суммой, датой и номером заказа. Подготовьте интеграцию с вашей CRM или напишите простой скрипт. Полезные ссылки: Ошибки SMS-рассылок: что важно знать малому бизнесу Беларуси, Как малому бизнесу Беларуси внедрить триггерные SMS-рассылки в 2026 году. > Source: https://smpp.by/kak-nastroit-uvedomleniya-ob-oplate-cherez-smpp --- # Когда облачные SMS невыгодны: переход на SMPP-шлюз Облачные сервисы для SMS-рассылок — простой старт для микробизнеса. Когда объемы растут, их недостатки становятся заметны. Прямое подключение по протоколу SMPP дает бизнесу контроль над отправкой и ценой. В этой статье — практические примеры для белорусских предпринимателей. Высокая стоимость при больших объемах Пример. Сеть кофеен «Кофе тут» в Минске использует облачный сервис для уведомлений о готовности заказа. Каждое сообщение стоит 0,12 BYN. На 15 000 заказов в месяц — 1800 BYN. Поставщик SMPP предлагает тариф 0,08 BYN при подключении через шлюз. Экономия — 600 BYN в месяц. Совет. Запросите у нескольких SMPP-провайдеров тарифы для вашего объема. Сравните с текущими расходами. Если разница больше 20%, переход окупается за 2–3 месяца. Подробнее о том, как устроен протокол, — в руководстве по SMPP для малого бизнеса. Задержки доставки в пиковые часы Пример. Служба доставки «Доставка в обед» в Гомеле отправляет уведомления курьерам о новых заказах. Облачный сервис обрабатывает 2000 сообщений в час, но в обед очередь растет, и задержка достигает 3 минут. Курьеры опаздывают. После перехода на SMPP скорость выросла до 1000 сообщений в секунду, задержка — 1 секунда. Совет. Проверьте SLA облачного провайдера на скорость доставки. Если среднее время больше 5 секунд или есть жалобы клиентов, SMPP решит проблему. На этапе миграции полезно изучить опыт масштабирования SMS-оповещений с облака на шлюз. Сложности с интеграцией в бухгалтерские системы Пример. Бухгалтерия в Бресте отправляет клиентам счета через 1С. Облачный API принимает только текст и номер телефона. Нельзя привязать номер счета, дату и статус оплаты. Настроить триггер «счет просрочен» не получается. SMPP-шлюз через программный модуль отправляет кастомные сообщения с переменными: номер счета, сумма, дата. Клиенты получают персонализированные уведомления. Совет. Если используете 1С или другую ERP, уточните у разработчика поддержку SMPP-модулей. Часто нужен конвертер протоколов. После внедрения станет проще запустить триггерные SMS-рассылки для просрочек и напоминаний. Типичные ошибки при переходе с облака на SMPP Не проверить совместимость оборудования. Некоторые шлюзы требуют статический IP и открытый порт. Не настроить резервный канал. При сбое SMPP отправка встает, если нет облачного дублера. Использовать старые скрипты для облачного API. Протокол SMPP другой — нужна своя логика установки сессии и обработки ошибок. Не протестировать нагрузку. Первые дни после перехода могут выявить проблемы с очередями. Игнорировать настройку DLR (Delivery Receipt). Без отчетов о доставке теряется контроль над неотправленными сообщениями. Слишком быстро отказаться от облачного сервиса. Лучше месяц работать параллельно, пока новый канал стабилен. 3 шага, которые можно сделать сегодня Посчитайте текущие расходы на SMS за последние 3 месяца. Узнайте среднюю цену за одно сообщение. Запросите коммерческие предложения у 2–3 SMPP-провайдеров. Уточните стоимость подключения, тарифы и требования к оборудованию. Выделите тестовую неделю для параллельной работы. Настройте SMPP-шлюз для одного типа уведомлений (например, только напоминания) и сравните скорость и цену. > Source: https://smpp.by/kogda-oblachnye-sms-nevygodny --- # Масштабирование SMS-оповещений: от ручной отправки к SMPP-шлюзу Когда клиентов становится больше, ручная отправка перестаёт работать. Вы путаете номера, забываете отправить, тратите время. Решение — перейти на отправку через SMPP-шлюз. Это протокол, который подключает вашу систему (CRM, складскую программу) напрямую к оператору связи. Сообщения уходят мгновенно и без вашего участия. Почему ручная отправка тормозит рост бизнеса Небольшой магазин в Бресте отправлял клиентам уведомления о поступлении товара по одному с телефона. Когда ассортимент вырос до 500 позиций, сотрудник тратил полдня на SMS. Появлялись ошибки: перепутанные номера, устаревшие сообщения. Ручной способ не масштабируется. При 50 клиентах в день это ещё терпимо, при 200 — уже сбой. Владелец салона красоты в Минске сначала отправлял напоминания о записи через веб-интерфейс оператора. Когда количество записей достигло 40 в день, он начал забывать отправлять. Клиенты не приходили, выручка падала. Переход на SMPP решил проблему: напоминания уходят автоматически за час до визита. Что такое SMPP-шлюз SMPP — это протокол, через который ваша программа общается с SMS-центром оператора. Вам не нужно заходить в личный кабинет и вводить текст вручную. Система сама отправляет сообщения по заданному сценарию. Например, при изменении статуса заказа в 1С или записи в CRM. Подробнее о протоколе написано в руководстве по SMPP для малого бизнеса Беларуси. Сценарий: салон красоты в Минске Салон с двумя филиалами. Каждый день 60–80 записей. Раньше администратор за полчаса до визита звонил или писал в мессенджер. Это отнимало 1,5 часа. После подключения SMPP-шлюза CRM сама отправляет SMS с напоминанием за час. Неявки сократились с 20% до 8%. Через полгода салон подключил акционные рассылки: информирует о свободных окнах по средам. Клиенты стали приходить чаще. Совет: выбирайте шлюз, который поддерживает двустороннюю связь — клиент может ответить «отменить» или «перенести». Интеграция с CRM описана в статье об интеграции SMS и Viber с CRM для МСБ Беларуси. Сценарий: интернет-магазин в Гродно Магазин электроники принимает 50–70 заказов в день. Раньше менеджер вручную отправлял уведомления о подтверждении, сборке и отправке. Ошибки стоили денег: однажды забыли уведомить клиента, и заказ вернулся на склад. Переход на SMPP через интеграцию с 1С решил проблему. Система отправляет SMS автоматически на каждом этапе. Магазин сэкономил 10 часов в неделю и сократил возвраты. Для небольших магазинов важна гибкость: можно настроить разные шаблоны для разных статусов. Например, «Ваш заказ собран» — один текст, «Отправлен» — другой. Это делается один раз и работает без контроля. Типичные ошибки при переходе на SMPP Не проверяют совместимость с используемой CRM или 1С. Провайдер должен предоставить документацию или готовый модуль. Забывают заложить запас по пропускной способности. Если планируете отправлять 1000 SMS в минуту, а шлюз рассчитан на 200, часть сообщений потеряется. Не тестируют в пиковые нагрузки. Перед запуском отправьте 500 тестовых сообщений и проверьте доставку. Не настраивают мониторинг доставки. Без логов не увидите, что часть SMS не дошла. Пытаются масштабировать старые методы: оставляют ручную отправку для важных сообщений и используют SMPP только для массовых. Это усложняет процесс. Подробнее о типовых проблемах — в статье об ошибках SMS-рассылок для малого бизнеса Беларуси. 3 шага, которые можно сделать сегодня: Подсчитайте среднее количество SMS в день и месяц. Прикиньте, сколько времени уходит на ручную отправку. Выберите провайдера SMPP, который поддерживает интеграцию с вашей CRM или 1С. Запросите тестовый доступ. Настройте одну простую автоматизацию (например, напоминание о записи) и проверьте её в работе. Через неделю добавьте вторую. > Source: https://smpp.by/masshtabirovanie-sms-opovescheniy --- # Как малому бизнесу Беларуси внедрить триггерные SMS-рассылки в 2026 году Триггерные SMS — сообщения, которые отправляются автоматически после действия клиента: бросил корзину, записался на услугу, сделал заказ. Такие рассылки работают без участия сотрудника и повышают конверсию. Для микро и малого бизнеса Беларуси это способ получать повторные продажи без большого рекламного бюджета. Достаточно настроить сценарий один раз — дальше система работает сама. Брошенная корзина: сценарий для интернет-магазина в Минске Магазин косметики «Аромат» в Минске заметил: 60% клиентов добавляют товары в корзину, но не оформляют заказ. Средний чек — 45 BYN. Через час после ухода клиента приходит SMS: «Ваш заказ на 45 BYN ждёт. Оформите — при заказе от 50 BYN доставка по Минску бесплатно». Конверсия в покупку выросла на 15%, средний чек поднялся до 55 BYN за счёт предложения бесплатной доставки. Совет: настройте триггер в CRM или через прямой протокол SMPP. Отправляйте сообщение не позже 2 часов после брошенной корзины. Предложите скидку или бесплатную доставку — это увеличит отклик. Подробнее о настройке автоматизации читайте в руководстве по автоматизации SMS-рассылок для малого бизнеса. Напоминание о записи: сценарий для салона красоты в Гродно Салон красоты «Студия» в Гродно терял 20% записей из-за того, что клиенты забывали о визите. Внедрили два триггера. За 24 часа до записи — «Напоминаем, завтра в 10:00 стрижка. Подтвердите или перенесите». Через 2 часа после визита — «Спасибо, что были у нас. Ждём вас через месяц для коррекции». Неявки снизились до 5%, повторных записей стало на 30% больше. Совет: интегрируйте триггеры с вашей системой записи — Google Календарь, CRM или специализированный софт. Отправляйте не более одного сообщения в день, чтобы не раздражать клиента. Сообщение после визита лучше отправлять через 1–2 часа, когда клиент уже дома. Статусы доставки: сценарий для курьерской службы в Бресте Курьерская служба «Быстрая почта» в Бресте обрабатывала 50 звонков в день с вопросом «Где мой заказ?». Настроили цепочку триггеров. После принятия заказа — «Заказ №123 принят, ожидайте курьера с 14 до 16». Когда курьер выезжает — «Курьер выехал, контакт курьера: +375291234567». После доставки — «Заказ доставлен. Спасибо». Звонков в поддержку стало в 4 раза меньше. Совет: используйте короткие шаблоны без лишних данных. Тестируйте время отправки — сообщение о выезде курьера должно приходить за 10–15 минут до приезда, не раньше. Для таких сценариев подходит прямое подключение по протоколу SMPP — подробнее в статье протокол SMPP для SMS-рассылок. Триггер для дней рождений: сценарий для продуктового магазина в Могилёве Продуктовый магазин «Домашний» в Могилёве собирал даты рождения клиентов при регистрации в программе лояльности. За неделю до дня рождения клиент получал SMS: «С днём рождения! Ваш персональный промокод на скидку 10% действует 7 дней». Средний чек по таким сообщениям — 35 BYN, что на 20% выше обычного. Совет: собирайте даты рождения при первой покупке или подписке. Отправляйте поздравление за 3–5 дней до события, чтобы клиент успел спланировать покупку. Не давайте скидку больше 15% — необоснованные дисконты снижают доход. Типичные ошибки при внедрении триггерных рассылок Отправлять слишком много сообщений одному клиенту за короткое время. Норма — 1–2 сервисных или продающих сообщения в день. Не сегментировать аудиторию. Рассылать одно и то же всем, включая тех, кто только что сделал заказ. Игнорировать время отправки. Сообщения ночью или рано утром вызывают негатив и отписки. Не получать согласие клиента на получение сообщений. Даже триггерные рассылки по брошенной корзине требуют предварительного согласия. Не отслеживать результаты. Без замера конверсии сложно понять, какие сценарии работают. Использовать только продающие сообщения. Клиенты ценят сервисные уведомления (напоминания, статусы) больше, чем скидки. Полный список частых проблем и способы их решения — в статье об ошибках SMS-рассылок для малого бизнеса Беларуси. 3 шага, которые можно сделать на этой неделе: Выберите одно действие клиента, которое хотите автоматизировать: брошенная корзина, напоминание о записи или уведомление о доставке. Настройте сценарий в вашей CRM или через провайдера, поддерживающего протокол SMPP. Так вы сможете отправлять сообщения напрямую из своей системы без ручной загрузки. Запустите пилот на 7 дней. Замерьте количество переходов по ссылке или покупок после получения SMS. Сравните с периодом без рассылки. Триггерные SMS не требуют большого бюджета — нужна только настройка один раз и база клиентов, давших согласие. Для малого бизнеса Беларуси это один из самых быстрых способов повысить лояльность и доход без найма дополнительных сотрудников. Начните с одного сценария, протестируйте его, а затем масштабируйте на другие точки касания с клиентом. > Source: https://smpp.by/kak-malomu-biznesu-belarusi-vnedrit-triggernye-sms-rassylki-v-2026-godu --- # Преимущества использования SMS-рассылок для микро и малого бизнеса в Беларуси: практические советы SMS-рассылки — это эффективный инструмент для коммуникации с клиентами, позволяющий быстро и напрямую донести информацию о новостях, акциях и услугах вашего бизнеса. В этой статье рассмотрим, как микро и малые предприятия в Беларуси могут использовать SMS-рассылки для повышения эффективности своей работы. 1. Высокая открываемость сообщений Исследования показывают, что более 90% SMS-сообщений читаются получателями в течение нескольких минут после получения. Это делает SMS-рассылки одним из самых надежных способов донести информацию до клиентов. Например, небольшая пекарня в Минске может отправить SMS-уведомление о свежей выпечке, и большинство клиентов получат и прочитают его сразу. 2. Экономия времени и ресурсов SMS-рассылки позволяют быстро охватить большую аудиторию без значительных затрат. Для малого бизнеса это особенно важно, так как позволяет эффективно использовать ограниченные ресурсы. Например, салон красоты в Гродно может отправить SMS-напоминание о предстоящем визите, что снизит количество пропущенных записей и повысит доходность. 3. Персонализация и таргетинг С помощью SMS-рассылок можно сегментировать клиентскую базу и отправлять сообщения, соответствующие интересам и потребностям конкретных групп. Например, магазин спортивных товаров в Бресте может отправить SMS-акцию на скидку на зимнюю одежду только тем клиентам, которые ранее покупали товары для зимних видов спорта. 4. Независимость от интернет-соединения SMS-сообщения не требуют наличия интернета, что делает их доступными для широкой аудитории, включая тех, кто использует старые модели телефонов или проживает в районах с ограниченным доступом к сети. Это особенно актуально для небольших городов и сельских населенных пунктов Беларуси. 5. Простота и быстрота внедрения Настроить SMS-рассылку можно быстро и без значительных технических знаний. Существуют специализированные сервисы, которые предлагают готовые решения для малого бизнеса. Например, сервисы массовых SMS-рассылок в Беларуси предлагают удобные интерфейсы и доступные тарифы для небольших компаний. 3 шага, которые можно сделать сегодня: Определите цели вашей SMS-рассылки: информирование о новостях, акциях или напоминания о встречах. Соберите базу контактов клиентов, получивших согласие на получение SMS-сообщений. Выберите подходящий сервис для отправки SMS-рассылок, учитывая стоимость и функциональность. Полезные ссылки: Ошибки SMS-рассылок: что важно знать малому бизнесу Беларуси Протокол SMPP: руководство для малого бизнеса Беларуси SMS-рассылки к Дню строителя: привлечение клиентов для малого бизнеса Беларуси > Source: https://smpp.by/preimuschestva-ispolzovaniya-sms-rassylok-dlya-mikro-i-malogo-biznesa-v-belarusi --- # Ошибки SMS-рассылок: что важно знать малому бизнесу Беларуси Большинство владельцев кафе, магазинов и сервисов в Минске, Гомеле, Бресте и других городах Беларуси используют SMS для связи с клиентами. Но многие делают это неправильно: теряют деньги, раздражают людей и получают жалобы. Ниже — четыре частые ошибки и способы их обойти. Ошибка 1: Рассылать всем одно и то же Владелец магазина одежды в Бресте отправляет одну фразу «Скидка 20%» всем подряд — женщинам, мужчинам, тем, кто покупал вчера, и тем, кто не заходил год. Результат: уведомление воспринимают как спам, доставка падает, отписок растёт. Как сделать. Делите базу по полу, возрасту, региону и истории покупок. Используйте данные из CRM. Например, для клиентов, которые покупали только детскую одежду, запускайте отдельную акцию на детские товары. Подробнее о настройке персонализации в гиперперсонализации SMS и Viber. Ошибка 2: Слишком частые сообщения без ценности Салон красоты в Гомеле отправляет по два SMS в неделю с банальными предложениями. Клиенты привыкают, перестают читать, а потом пропускают реально выгодные акции. Как сделать. Определите оптимальную частоту для своего бизнеса — обычно одно-два сообщения в неделю. Не пишите просто так: каждое SMS должно решать задачу клиента — напомнить о записи, сообщить о персональной скидке, поздравить с днём рождения. Автоматизируйте триггерные сценарии, чтобы не отправлять вручную. Поможет инструкция по автоматизации SMS-рассылок. Ошибка 3: Отправлять с незнакомого номера или через дешёвые сервисы Кафе в Минске использует бесплатный онлайн-сервис, который отправляет с длинного кода. Операторы Беларуси часто блокируют такие сообщения или помечают как спам. Половина клиентов не получает информацию о скидках. Как сделать. Выбирайте провайдера, который работает через прямой протокол SMPP с белорусскими операторами. Это обеспечивает высокую доставку и короткие номера отправителя. О том, как работает протокол, читайте в материале протокол SMPP: руководство для малого бизнеса Беларуси. Ошибка 4: Не проверять результаты рассылок Магазин в Витебске запускает акцию, но не смотрит статистику: сколько сообщений доставлено, сколько клиентов пришли по SMS. Через месяц не понимает, работает рассылка или нет, и тратит деньги впустую. Как сделать. Каждый раз фиксируйте три показателя: доставляемость (доля успешно отправленных), кликабельность (если есть ссылка) и конверсию в продажи. Сравнивайте их с предыдущими кампаниями. Если доставляемость ниже 95% — проверяйте базу на неактивные номера. Если кликабельность низкая — меняйте текст или время отправки. Типичные ошибки: список Отправлять сообщения без согласия клиента. Даже если не спрашивали — база собранная с сайта может быть невалидной. Использовать только один канал (SMS) и не дублировать важное через Viber или email. Писать длинные сообщения: SMS — это 160 или 320 символов, вмещайте главное в одну мысль. Отправлять поздно вечером или рано утром — только злите клиентов. Не чистить базу от «мёртвых» номеров (ошибки доставки, отписки). Не тестировать разные варианты текста на небольшой группе перед массовой рассылкой. 3 шага, которые можно сделать на этой неделе: Сегментируйте вашу клиентскую базу хотя бы по полу и уровню покупки (новичок / постоянный). Настройте один триггерный сценарий — например, поздравление с днём рождения с персональной скидкой. Проверьте доставляемость последних трёх рассылок. Если она ниже 95% — замените провайдера или обновите список контактов. > Source: https://smpp.by/oshibki-sms-rassylok --- # Протокол SMPP: руководство для малого бизнеса Беларуси Вы отправляете много SMS — акции, напоминания о записи, коды подтверждения. Если через веб-кабинет это занимает часы, а сообщения теряются, пора разобраться с протоколом SMPP. Это прямой канал между вашей CRM и сетью оператора. Он даёт скорость: тысяча сообщений уходит за 10–20 секунд. И контроль: вы видите, кому доставили, а кто не получил. Для кафе, салона красоты или интернет-магазина в Минске, Гомеле или Бресте это значит экономию времени и денег. Что такое SMPP и зачем предпринимателю переходить на него SMPP (Short Message Peer-to-Peer) — это протокол, по которому ваша программа общается с SMS-центром. В отличие от веб-интерфейса, где вы заходите в личный кабинет и отправляете сообщения вручную, SMPP работает автоматически и в реальном времени. Подключив его, вы можете отправлять сообщения прямо из 1С, CRM или собственного приложения. Пример из Беларуси. Студия маникюра в Гродно записывает клиентов через Instagram и подтверждает запись SMS. Раньше администратор раз в час отправляла сообщения через сайт – к тому времени клиент уже забывал о записи. После перехода на SMPP подтверждение приходит за 2 секунды. Количество неявок снизилось на треть. Совет. Если вы отправляете от 100 сообщений в день, подключайте SMPP. Спросите у своего провайдера, поддерживает ли он этот протокол. Большинство белорусских сервисов это предлагают по умолчанию. Как подключить SMPP: три реальных шага Подключение не требует программиста. Нужны IP-адрес сервера, порт, логин и пароль – их даёт провайдер. Дальше настройка в вашей системе: в 1С, Woocommerce, amoCRM или даже в скрипте на PHP. Пример из Беларуси. Небольшой магазин стройматериалов в Пинске принимает заказы на сайте. После оформления клиент должен получить SMS с номером заказа. Бухгалтер подключил SMPP к своей 1С через стандартный модуль. Теперь сообщение улетает автоматически, а магазин перестал терять заказы из-за того, что клиент не знал номер. Совет. Попросите провайдера дать тестовый доступ на 100–200 SMS. Запустите пробную рассылку одной группе клиентов. Проверьте скорость доставки и отчёты. Если всё устраивает – переводите на поток. Больше о том, как настроить автоматические сценарии, читайте в статье Автоматизация SMS-рассылок: практическое руководство для малого бизнеса. Сценарии использования SMPP в 2026 году SMPP не только для массовых рассылок. Вот три ситуации, когда он окупается быстрее всего. Транзакционные SMS Коды подтверждения, уведомления о статусе заказа, напоминания о визите. Клиент получает их мгновенно, а вы снижаете нагрузку на персонал. Пример. Стоматология в Могилёве отправляет код для входа в личный кабинет через SMPP. Раньше код шёл 3–5 минут – пациенты жаловались. Сейчас приходит за секунду. Отток с этапа регистрации упал с 15% до 2%. Массовые акции и распродажи Когда нужно быстро оповестить базу в 500–5000 человек о скидке или новом товаре. Через веб-кабинет вы отправили бы их час, а через SMPP – минуты. Пример. Магазин одежды в Витебске запустил летнюю распродажу. За 5 минут ушло 3400 SMS. В первый день пришло на 20% больше покупателей, чем в прошлый раз, когда рассылку делали через личный кабинет (тогда сообщения растянулись на два часа). SMS-лояльность Автоматические поздравления с днём рождения, начисление бонусов, персональные предложения. Всё это можно настроить один раз и забыть. Пример. Кофейня в Бресте в CRM помечает день рождения клиента. В этот день через SMPP приходит SMS: «С днём рождения! Кофе в подарок». Затраты – копейки, а лояльность растёт. Совет. Используйте альфа-имя (например, название вашей компании) вместо номера отправителя. Тогда клиент сразу узнает сообщение и не удалит его как спам. Подробнее о стратегиях для малого бизнеса – в статье SMS-маркетинг для малого бизнеса Беларуси: стратегии и кейсы 2026. Типичные ошибки при работе с SMPP Отправка без согласия. Даже хороший протокол не спасёт от жалоб, если вы спамите. Собирайте разрешение через форму подписки. Забыли пополнить баланс. Рассылка прерывается на середине. Настройте автопополнение или установите алерт при остатке меньше 50 SMS. Не настраиваете отчёты о доставке. SMPP возвращает статус: доставлено, не доставлено, ожидает. Без них вы не узнаете, что половина сообщений потерялась. Смешиваете транзакционные и рекламные потоки. Операторы могут расценивать рекламные SMS как спам и блокировать весь канал. Разведите их в разные соединения. Не тестируете перед массовой отправкой. Ошибка в базе или кодировке может оставить без рассылки 500 клиентов. Отправьте пробную пятёрку самому себе. Стоимость и экономия Многие думают, что SMPP дорогой. На деле он часто дешевле тарифов из веб-кабинета на 10–30% за счёт объёма. Плюс вы не платите за человеко-часы администратора. Для магазина в Калинковичах, отправляющего 2000 SMS в месяц, экономия составит 40–60 рублей в месяц. А если подключить ещё и Viber, эффект будет больше – сравните в статье Эффективные стратегии SMS и Viber-рассылок для малого бизнеса Беларуси в 2026 году. Как проверить, нужен ли вам SMPP Посчитайте, сколько времени уходит на рассылки сейчас. Если администратор тратит 2–3 часа в неделю на копирование номеров и отправку по одному – это потеря денег. Если объём больше 1000 сообщений в месяц – SMPP окупится за один квартал. Запросите у провайдера тестовый доступ и попробуйте отправить 20–30 сообщений своими руками. Обычно это делается за один день. 3 шага, которые можно сделать на этой неделе Подсчитайте, сколько SMS вы отправили за последний месяц. Если больше 1000 – переходите на SMPP. Напишите своему провайдеру и попросите тестовый доступ к SMPP-соединению. Если провайдер не поддерживает – смените провайдера. Настройте один автоматический сценарий: например, подтверждение записи или уведомление о заказе. Протестируйте на 5–10 клиентах и убедитесь, что работает. > Source: https://smpp.by/protokol-smpp --- # SMS-рассылки к Дню строителя: привлечение клиентов для малого бизнеса Беларуси День строителя в Беларуси — 9 августа. В этот день поздравляют и строителей, и всех, кто связан с ремонтом, отделкой, стройматериалами, спецтехникой. Для микро-, малого и среднего бизнеса это шанс напомнить о себе тем, кто сейчас строит или ремонтирует. SMS-рассылка — самый быстрый способ донести предложение до людей, которые постоянно в разъездах и на объектах. Главное — не просто поздравить, а дать повод вернуться. Кому отправлять: сегментация базы клиентов Одна рассылка на всю базу — деньги на ветер. Строители-профессионалы, частные застройщики и дизайнеры ждут разного сообщения. Пример. Магазин стройматериалов в Минске. В базе 1200 номеров. Разбили на три группы: бригады (покупают цемент, газоблоки оптом), частники (краски, обои, ламинат) и дизайнеры (инструменты, фурнитура). Каждой группе отправили своё SMS: профессиональным строителям — скидка 5% на весь чек при заказе от 500 BYN, частникам — 10% на отделочные материалы, дизайнерам — бесплатная доставка образцов. Как сделать. Обновите базу: проверьте, у кого есть номера телефонов. Поставьте метки — «профессионал», «частник» или тип покупки. Используйте историю заказов. Если CRM не ведёте, начните хотя бы с последних 100 клиентов. Подробнее о сегментации — в статье об эффективных стратегиях SMS-маркетинга для малого бизнеса Беларуси. Формат сообщения: поздравление + конкретная выгода Просто «С Днём строителя!» — мало. Человек прочитает и забудет. Нужна причина действовать сейчас. Пример. Автомастерская в Гомеле ремонтирует гидравлику экскаваторов и погрузчиков. 9 августа отправили: «С праздником! Скидка 10% на диагностику гидравлики до 15 августа. Запись по тел. XX». Результат — 17 записей за два дня. Как сделать. Сформулируйте коротко: поздравление, что даёте, срок. Не пишите больше 160 знаков — это одно SMS. Если нужно длиннее, платите за второе, но лучше уложиться в одно. Используйте промокод или фразу «назовите код», чтобы отследить конверсию. Идеи для акций к августу есть в статье «Летние акции в июле: как малому бизнесу Беларуси работать с SMS» — принципы те же. Время отправки и частота Строители встают рано. В 6–7 утра они уже на объекте. Если отправить SMS в 10 утра, оно затеряется в рабочих чатах. Пример. Доставка стройматериалов в Бресте отправила первое SMS 8 августа в 18:00 — как напоминание о завтрашней акции. Второе — 9 августа в 7:30. Конверсия выросла на 40% по сравнению с прошлым годом, когда слали после обеда. Как сделать. Отправляйте за день до праздника (вечером) или в день праздника до 9 утра. Больше двух сообщений в неделю не нужно. Если используете серию, разнесите их на неделю. О подготовке к осенним кампаниям читайте в статье «Сезонные SMS-кампании: подготовка малого бизнеса Беларуси к осени». Типичные ошибки Отправка всей базы без сегментации — люди получают неподходящие предложения и жалуются. Поздравление без выгоды — низкий отклик. Длинное сообщение с несколькими ссылками — велик риск, что SMS разобьётся на части или будет выглядеть как спам. Отправка после обеда — строители уже не читают или заняты. Отсутствие отслеживания — не знаете, сколько клиентов пришло по SMS. Хотя бы считайте звонки по уникальному номеру. Повторная рассылка тем же клиентам через день без новой причины — раздражение и отписки. 3 шага, которые можно сделать на этой неделе Соберите номера клиентов, которые покупали стройматериалы, заказывали ремонт или услуги спецтехники за последние 6 месяцев. Даже 30 контактов дадут результат. Напишите два варианта SMS: один для профессионалов, второй для частников. В каждом — поздравление + предложение со сроком действия до 15 августа. Назначьте отправку на 8 августа в 18:00 и на 9 августа в 7:30. Через неделю проверьте, сколько клиентов воспользовались акцией. Если нужен готовый сценарий поздравления с профпраздником, посмотрите подборку SMS к Дню строителя: как малому бизнесу привлечь клиентов. Там есть шаблоны и советы по тексту. > Source: https://smpp.by/sms-rassylki-k-dnyu-stroitelya --- # SMS-рассылки для малого бизнеса Беларуси в летний спад: 4 сценария В июле — августе продажи многих малых предприятий падают. Уличный трафик снижается, клиенты уезжают в отпуска. SMS-рассылка — быстрый способ напомнить о себе и вернуть часть упущенной выручки. В этой статье — четыре проверенных сценария для бизнеса в Беларуси. Вернуть тех, кто остался в городе: персональные предложения Пример. Владелец кофейни в центре Минска зафиксировал падение выручки на 30% по сравнению с маем. Он отправил SMS 200 постоянным клиентам: «В будни с 12 до 15 скидка 15% на любой бизнес-ланч. Покажите это сообщение». Через три дня загрузка в обеденное время выросла на 20%. Совет: разделите базу на тех, кто ходит регулярно, и тех, кто не был больше месяца. Первым — скидка, вторым — приглашение с подарком. Например: «Ваш первый летний кофе — бесплатно при покупке десерта». Подробнее о том, как вернуть интерес к забытому бизнесу, читайте в статье «Летнее затишье в ритейле: как реанимировать продажи SMS-рассылками». Гео-рассылки по жителям соседних домов — компенсация снижения трафика Пример. Магазин хозяйственных товаров в Калинковичах. В июле поток покупателей упал вдвое. Владелец выбрал 3 улицы в радиусе 500 м от магазина и отправил SMS: «Набор для пикника — скидка 25% только до 20 июля». Затраты на рассылку составили около 30 BYN (1000 сообщений). Выручка с дополнительных продаж — 450 BYN. ROI больше 10. Совет: используйте гео-сегментацию — выберите районы с жилыми домами, где живёт ваша целевая аудитория. Отправляйте не чаще раза в неделю. Больше сценариев — в материале «Как падение уличного трафика в июле влияет на продажи локального ритейла и как компенсировать его точечной гео-рассылкой». Автоматическое сопровождение заказов: меньше невыкупа, больше лояльности Пример. Интернет-магазин спортивных товаров из Могилёва. До внедрения уведомлений доля отказов составляла 30% (каждый третий заказ не выкупали). Настроили простую цепочку: SMS после оформления заказа (номер, срок), напоминание за день до доставки, благодарность после получения. Невыкуп снизился до 18%. Совет: даже без интеграции с CRM можно вручную отправлять стандартные шаблоны. Главное — вовремя. Как именно организовать — в статье «SMS-сопровождение доставки: как снизить долю невыкупа в интернет-магазине». Точечные поздравления с профессиональными праздниками Пример. Парикмахерская в Барановичах. На День металлурга (19 июля) отправила SMS мужчинам из базы: «С праздником! Стрижка + укладка — 10%». Получила 5 записей в день, который обычно был пустым. Средний чек — 25 BYN, дополнительная выручка — 125 BYN. Совет: собирайте данные о профессиях клиентов (можно спросить при записи) и привязывайте акции к их профессиональным датам. В июле таких много: День металлурга, День работников торговли (26 июля), День PR-специалиста (28 июля). Больше примеров по датам — в статье «SMS-маркетинг для малого бизнеса Беларуси: стратегии и кейсы 2026». Типичные ошибки при летних SMS-рассылках Отправка одного и того же текста всей базе без сегментации. Разные клиенты хотят разное. Длинные сообщения (больше 160 символов). Люди читают быстро, поэтому текст должен укладываться в одну SMS. Рассылка в нерабочее время (будние после 20:00, выходные до 10:00). Получатель сразу помечает как спам. Игнорирование статистики: не смотрят, сколько сообщений доставлено, сколько человек кликнули. Нет чёткого призыва: «Приходите», «Позвоните», «Перейдите по ссылке». Без него сообщение бесполезно. Слишком частые рассылки. Одного раза в неделю достаточно для летнего спада. 3 шага, которые можно сделать на этой неделе: Проверьте базу номеров. Удалите тех, кто не реагировал больше полугода. Разделите оставшихся на 3–4 группы (частые, редкие, новые). Выберите один из четырёх описанных сценариев — гео-рассылку, персональную акцию, сопровождение заказа или поздравление. Сформулируйте 2–3 варианта текста. Запустите тестовую кампанию на 100–200 номеров (можно через личный кабинет smpp.by). Через 2–3 дня посмотрите, сколько людей отреагировало. Если отклик выше 5% — масштабируйте. Летний спад — не приговор. При грамотном подходе SMS-рассылка позволяет вернуть часть потерянной выручки с минимальными затратами. Начните с малого: сегментируйте базу, выберите один сценарий и тестируйте. > Source: https://smpp.by/sms-rassylki-dlya-malogo-biznesa-belarusi-v-letniy-spad --- # SMS-маркетинг для малого бизнеса Беларуси: стратегии и кейсы 2026 Летом 2026 года трафик в магазинах Минска, Гомеля и Бреста падает. Люди уезжают на дачи, в отпуска, реже заходят в привычные точки. SMS-рассылка — инструмент, который доставляет сообщение прямо в карман клиента. Без интернета, без подписок на приложение. Для микробизнеса это способ напомнить о себе и получить заказ, пока конкуренты ждут осени. Сценарий 1. Кафе в Могилёве: возврат клиентов через «спящую» базу Владелец небольшого кафе на улице Первомайской заметил, что завтраки перестали покупать даже постоянные гости. Он выгрузил номера тех, кто не приходил больше 45 дней, и отправил одно SMS: «Кофе в подарок к любому завтраку до 12:00». За неделю вернулись 23 человека. Средний чек вырос на 6 рублей. Как сделать. Раз в месяц берите из CRM (или просто из записной книжки) номера клиентов, которые молчат 1–2 месяца. Отправляйте персональное предложение с конкретной выгодой — скидкой, подарком, бесплатной доставкой. Не пишите «скидка 10%», пишите «второй кофе бесплатно». Сценарий 2. Сервис по ремонту в Витебске: сезонное напоминание о ТО Автосервис «Витебск-Мотор» каждый июль терял 30% записи. В 2025 году настроили триггер: SMS за 3 дня до планового ТО по пробегу. Клиент получал сообщение «Вашему авто 10 000 км. Запишитесь на ТО — получите диагностику ходовой бесплатно». За июль запись выросла на 18%. Как сделать. Соберите данные о дате последнего визита или пробеге. Если данных нет — отправьте простое SMS с вопросом: «Пора проверить кондиционер? Запишитесь на диагностику за 15 минут». Сезонная акция работает лучше общего напоминания. Сценарий 3. Небольшой магазин одежды в Гродно: допродажа через SMS после покупки Магазин женской одежды «Лен» отправлял каждому покупателю через 3 дня после оплаты SMS: «Спасибо за покупку! К этому платью подходит шарф из новой коллекции — скидка 20% только для вас». Конверсия в допродажу составила 7%. Само сообщение не выглядело рекламой — оно было персонализированным. Как сделать. После каждой покупки (в магазине или интернет-магазине) отправляйте одно SMS с конкретным товаром-компаньоном. Не «загляните к нам ещё», а «к куртке X подходят перчатки Y — скидка 15%». Используйте данные из чека. Типичные ошибки в SMS-рассылках малого бизнеса Слишком частые сообщения. Больше 2–3 SMS в месяц на одного клиента — и база начинает отписываться. Общие фразы без выгоды. «У нас распродажа» — непонятно, зачем идти. «Куртки —50% только в пятницу» — понятно. Отправка без сегментации. Одно и то же SMS всем — и тем, кто купил вчера, и тем, кто не был год. Первые раздражаются, вторые не реагируют. Игнорирование времени. SMS в 8 утра в субботу — плохо. Лучшее время для розницы — будни с 11 до 13 или с 17 до 19. Отсутствие призыва к действию. «Приходите» — слабо. «Запишитесь по ссылке» — конкретно. Неиспользование имени клиента. Персонализация повышает открываемость на 20–30%. Как считать результат от SMS-рассылки без сложной аналитики Не нужно внедрять дорогие CRM. Простой способ: добавьте в SMS уникальный промокод (например, «ЛЕТО10»). Считайте, сколько раз его применили на кассе или в корзине. Стоимость рассылки поделите на количество использований — получите стоимость одного привлечённого клиента. Если она ниже вашей маржи, канал работает. Подробнее о расчёте эффективности — в статье ROI от SMS-рассылки: как посчитать без сложной аналитики. Практический сценарий: кросс-маркетинг между бизнесами в одном районе В Барановичах цветочный магазин и кондитерская объединились. Цветочный отправлял покупателям SMS с предложением торта со скидкой 10% у соседей. Кондитерская — наоборот. За месяц каждый получил 12 новых клиентов без затрат на рекламу. Подробнее о таких схемах — в материале 5 сценариев кросс-маркетинга: магазины и студии Гродно против летнего спада. Как сделать. Найдите бизнес со смежной аудиторией (не конкурирующий). Договоритесь о взаимном упоминании в SMS. Условия: чёткая выгода для клиента, ограниченный срок акции, обмен контактами без нарушения законодательства. Три шага, которые можно сделать на этой неделе Выгрузите номера клиентов, которые не покупали 30–60 дней. Отправьте одно SMS с подарком или скидкой. Замерьте отклик через 3 дня. Настройте автоматическое SMS после покупки с предложением сопутствующего товара. Используйте данные из чека — не отправляйте всем одинаковое. Посчитайте стоимость одного привлечённого клиента по промокоду. Если она укладывается в ваш бюджет — повторите рассылку на следующей неделе, увеличив базу. Полезные ссылки: Летнее затишье в ритейле: как реанимировать продажи SMS-рассылками, SMS для лояльности: как малому бизнесу Беларуси удержать клиентов, Протокол SMPP — что это? > Source: https://smpp.by/sms-marketing-dlya-malogo-biznesa-belarusi --- # Летнее затишье в ритейле: как реанимировать продажи SMS-рассылками Июль в Беларуси — традиционный спад для магазинов одежды. Люди уезжают на дачи, в отпуска, тратят деньги на поездки, а не на обновление гардероба. В интернет-магазинах падают переходы с рекламы, в офлайн-точках — проходимость. Чтобы не сливать бюджет на баннеры, которые никто не видит, можно работать с собственной базой клиентов через SMS. Это дешевле контекста, а при правильной сегментации даёт отклик, который окупает рассылку за день. Сегментируем базу не по полу, а по поведению Делить клиентов только на мужчин и женщин — слишком грубо. В летнем спасе работают другие срезы. Например, магазин женской одежды в Гродно заметил: клиентки, которые покупали летние платья в мае, в июле не приходят. Им не нужна куртка — им нужна скидка на следующую летнюю коллекцию. Вместо общей акции владелец отобрал тех, кто покупал с мая по июнь, и отправил им SMS с персональной скидкой 15% на новые поступления. Конверсия в покупку — 8% против обычных 2–3% по массовым сообщениям. Практический совет: настройте в CRM правило — если клиент не покупал 45 дней, отправляйте ему персональное предложение с конкретной вещью из его корзины или истории просмотров. Акция для тех, кто «спит» больше 60 дней Самый большой резерв — клиенты, которые ушли 2–3 месяца назад. Магазин мужской одежды в Могилёве запустил такую механику: собрал базу тех, у кого последняя покупка была в апреле-мае, и отправил SMS с предложением «Приведи друга — получи скидку 20% на свою следующую покупку». Затраты на рассылку — 150 рублей. Результат: 32 новых покупателя, пришли по рекомендации, средний чек 180 рублей. Важно не просто раздать скидки, а привязать их к действию. Для тех, кто давно не заходил, можно использовать динамический контент в SMS: вместо общей фразы «у нас скидки» писать «Мария, брюки из вашего списка желаний сейчас на 30% дешевле». Это работает даже в летнее затишье. Спецпредложение для держателей подарочных карт У многих салонов и бутиков лежат неактивированные подарочные сертификаты. Клиент купил сертификат на 100 рублей полгода назад, но так и не пришёл его потратить. Владелец магазина в Бресте нашёл таких 40 человек и написал каждому: «Ваш сертификат на 100 BYN ждёт. Если не используете до конца июля — обменяем на два по 50 BYN для разных людей». Половина пришла в течение недели. Дополнительная выручка — 2000 рублей, из которых 1000 уже была оплачена, а 1000 — новые продажи сверх номинала. Этот сценарий легко внедрить, если в CRM настроены напоминания об активации. Подробнее про такие механики — в статье SMS‑напоминания о подарочных сертификатах и активации бонусов. Не забываем про офлайн-точки в небольших городах Летом люди из Минска часто едут к родителям в Калинковичи или Вилейку. Магазин в Вилейке заметил: если заманить приезжих предложением «Покажи этот SMS — получи 10% на любую покупку», средний чек поднимается до 120 BYN против обычных 65. Базу для такой рассылки можно собрать на кассе: любой покупатель из другого города оставляет номер для скидки. В тихое июльское время это даёт до 15–20 дополнительных продаж в день. Чтобы не отправлять сообщения вручную, используйте автоматические триггеры — сегментация подписчиков по поведению поможет отделять местных от приезжих. Типичные ошибки при летних SMS-рассылках Отправлять одно сообщение всей базе без сегментации. Массовая скидка в 10% не мотивирует — её воспринимают как спам. Игнорировать признак «последняя покупка». Человек купил вчера — ему не нужно предложение «для забытых клиентов». Не привязывать акцию к сроку действия. «Скидка 20%» без даты не создаёт срочности. Писать длинные тексты без конкретики. Вместо «у нас отличные новинки» — «приходите завтра, покажем джинсы новой коллекции». Не проверять, открыт ли номер. Если клиент сменил телефон или заблокировал рассылки, отправка бессмысленна. 3 шага, которые можно сделать сегодня: Скачайте из CRM список клиентов, которые покупали, но не приходили дольше 45 дней. Отправьте им персональное предложение — не общую скидку, а связанную с конкретной вещью или категорией, которую они смотрели. Найдите всех, кто приобрёл подарочный сертификат за последние полгода, но не активировал его. Напомните об этом через SMS с опцией обмена на два сертификата. Настройте триггерное сообщение для покупателей из других городов — предложите скидку при предъявлении SMS в магазине. Собирайте номера на кассе. > Source: https://smpp.by/letnee-zatishe-v-riteyle --- # SMS-сопровождение доставки: как снизить долю невыкупа в интернет-магазине Когда покупатель в Минске, Гомеле или Барановичах оформляет заказ, а потом не забирает его — это потерянные деньги. Вы уже потратили время на сборку, упаковку и, возможно, доставку. SMS-сопровождение доставки — это короткие сообщения, которые напоминают клиенту о статусе и времени прибытия курьера. Они снижают невыкуп, потому что человек не забывает о заказе и может вовремя перенести встречу. Для магазина это прямая экономия: меньше возвратов, меньше повторных отправок. Как работает простая цепочка уведомлений Возьмём магазин товаров для дома в Минске. Без уведомлений невыкуп составлял 25% от всех заказов. После подключения трёх SMS: «Заказ собран», «Курьер выехал», «Курьер будет через 30 минут» — доля невыкупа упала до 10%. Клиенты перестали пропускать доставку, потому что знали точное время и могли быстро ответить, если планы менялись. Совет: настройте автоматическую отправку SMS из вашей системы учёта (1С, CRM) при каждом изменении статуса заказа. Не пишите длинные тексты — достаточно двух строк: «Ваш заказ №123 собран, доставка завтра с 10 до 20. Подтвердите или перенесите: +37529XXXXXXX». Выбор канала и времени SMS — единственный канал, который гарантированно доходит, даже если у клиента выключен мобильный интернет. В Бресте интернет-магазин одежды заметил, что через Viber сообщения прочитывают только 60% получателей, а через SMS — 95%. Они стали отправлять напоминание за 2 часа до прибытия курьера. Результат: невыкуп сократился вдвое. Совет: отправляйте SMS за 2–3 часа до запланированного окна доставки. Не раньше — иначе клиент забудет. Не позже — он не успеет перенести. Добавьте в сообщение короткую ссылку на форму для изменения времени или отмены. Типичные ошибки при сопровождении доставки Отправка одного сообщения в день заказа — клиент его не запоминает. Слишком длинные тексты (более 160 символов) — часть информации теряется, если телефон режет сообщение. Отсутствие возможности ответить — клиент не может перенести доставку, просто не приходит. Отправка уведомлений в нерабочее время (ночью, рано утром) — вызывает раздражение и не читается. Использование одного шаблона для всех городов — не учитывает время в пути по Минску и, например, по Калинковичам. Нет проверки актуальности номера — если клиент сменил номер, деньги на SMS потрачены зря. Как измерить эффект от уведомлений Без цифр непонятно, работает ли схема. Поставьте UTM-метки на ссылки в SMS (например, ?utm_source=sms&utm_medium=delivery) и отслеживайте переходы в систему аналитики. Сравните долю невыкупа за месяц до и месяц после запуска уведомлений. Можно сделать A/B-тест: половине клиентов отправлять одно SMS, половине — два. Узнайте, какой вариант даёт лучший результат. Подробнее о построении системы аналитики для маленького интернет-магазина читайте в статье Сквозная аналитика SMS для маленького интернет-магазина Беларуси: UTM и продажи. Если вы только начинаете, возьмите готовые шаблоны и сценарии для белорусских интернет-магазинов — это сэкономит время на разработку. Варианты описаны в материале SMS‑уведомления о доставке: шаблоны и сценарии для белорусских интернет‑магазинов. 3 шага, которые можно сделать сегодня: Определите, на каком этапе доставки у вас чаще всего теряются заказы (сборка, отъезд курьера, последний час). Настройте в вашей учётной системе (1С, CRM) автоматическую отправку SMS в этих точках — используйте короткие сообщения с контактом для переноса. Запустите тест на 50 заказах и сравните долю невыкупа с предыдущей неделей. Если результат положительный — масштабируйте на все заказы. > Source: https://smpp.by/sms-soprovozhdenie-dostavki --- # Протокол SMPP — что это? SMPP (Short Message Peer-to-Peer) — это стандартный протокол для обмена короткими текстовыми сообщениями (SMS) между устройствами и SMS-центрами операторов мобильной связи. Он был разработан специально для передачи SMS в высоких объёмах и с минимальной задержкой, что делает его идеальным решением для массовых рассылок, уведомлений и других бизнес-коммуникаций. Протокол SMPP работает по принципу клиент-сервер: бизнес-приложение, подключённое к SMS-центру оператора через SMPP, отправляет и получает сообщения быстро и эффективно. Это позволяет автоматизировать процесс взаимодействия с клиентами и партнёрами через SMS. Зачем протокол SMPP бизнесу в Беларуси? 1. Массовые SMS-рассылки Для компаний в Беларуси, которые хотят информировать клиентов о новых товарах, акциях или изменениях в работе, SMPP обеспечивает надёжный канал для массовой отправки сообщений. Этот протокол позволяет отправлять тысячи и даже миллионы SMS-сообщений в кратчайшие сроки. 2. Высокая скорость и надёжность В условиях высокой конкуренции скорость доставки сообщений имеет огромное значение. SMPP позволяет практически мгновенно доставлять уведомления, что повышает вовлечённость клиентов и сокращает время реакции на маркетинговые кампании или сервисные оповещения. 3. Интеграция с CRM и другими системами Протокол SMPP легко интегрируется с корпоративными системами — CRM, ERP и сервисами поддержки. Это обеспечивает автоматическую отправку уведомлений, подтверждений заказов, паролей для входа в личный кабинет и других важных сообщений, не требуя ручного вмешательства. 4. Контроль и отчётность SMPP позволяет получать подробные отчёты о доставке SMS-сообщений, что важно для анализа эффективности коммуникаций и оперативного реагирования в случае проблем с доставкой. 5. Возможность экономии Использование SMPP-протокола напрямую с операторами связи в Беларуси позволяет снизить затраты на SMS-рассылки по сравнению с традиционными сервисами посредников, особенно при больших объёмах сообщений. Заключение Для бизнеса в Беларуси протокол SMPP — это мощный инструмент, который обеспечивает быструю, надёжную и экономичную коммуникацию с клиентами через SMS. Внедрение SMPP помогает повышать лояльность клиентов, улучшать сервис и эффективно проводить маркетинговые кампании. Если вы ищете способ автоматизировать и оптимизировать мобильные коммуникации, SMPP — это решение, которое стоит рассмотреть. > Source: https://smpp.by/protocol-smpp-chto-eto