Интеграция 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, затем проверить очередь, статусы доставки и защиту от дублей.
