Интеграция SMS-сервиса SMS.ru с Битрикс24

Почему интеграция SMS.ru с Битрикс24 ломается на потоке

Интеграция SMS.ru с Битрикс24 почти всегда стартует одинаково: пара роботов в CRM, отправка кода подтверждения из формы и уведомление менеджеру о новой сделке. На малых объёмах это работает без нареканий, поэтому интеграцию и сдают как готовую. Проблемы начинаются, когда через тот же канал идут массовые рассылки по базе, статусные уведомления клиентам и служебные оповещения сотрудникам — то есть когда разовая отправка превращается в поток.

Первое узкое место — отсутствие очереди сообщений. Битрикс24 отправляет события синхронно: робот вызывает внешний сервис и ждёт ответа. Если провайдер отвечает медленно или возвращает ошибку, транзакция зависает, а при массовой отправке часть запросов просто не доходит. Второе — дубли уведомлений: событие срабатывает повторно при смене стадии сделки, обновлении карточки или ретрае, и клиент получает два-три одинаковых SMS.

Третье — лимиты провайдера: при превышении допустимой скорости отправки сообщения не уходят, но в CRM остаётся отметка «отправлено», и потерянное уведомление никто не замечает.

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

Что даёт связка CRM и SMS-шлюза

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

Скорость доставки и доля успешных отправок — первые метрики, по которым видно эффект. При отправке через шлюз с прямыми подключениями к операторам сообщение уходит за секунды, а отчёт о доставке приходит обратным вызовом и фиксируется в CRM. Если номер недоступен или отклонён оператором, система помечает попытку как неуспешную и запускает повтор по заданному правилу — доля доставленных сообщений растёт без ручного контроля со стороны менеджеров.

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

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

Проверить эффект можно по трём срезам: среднее время от события до доставки, доля успешных отправок за период и число обращений, закрытых без участия менеджера. Эти метрики собираются из журнала и выгрузок шлюза, поэтому сравнение «до и после» опирается на факты, а не на ощущения.

Способы подключения: сравнение вариантов

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

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

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

Как мы ведём внедрение интеграции SMS.ru Битрикс24

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

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

1. Аудит сценариев. Разбираем текущие правила и роботов, отмечаем события-триггеры и ответственных, убираем дублирующие уведомления.
2. Схема потоков. Согласуем карту: событие → условие → шаблон → получатель → журнал. Заказчик видит логику до начала настройки.
3. Настройка подключения. Регистрируем отправителя, привязываем его к порталу, настраиваем права и лимиты по направлениям.
4. Шаблоны сообщений. Готовим тексты под каждый сценарий с подстановкой полей сделки и лида, следим за длиной и читаемостью.
5. Тестовая отправка. Прогоняем каждое событие на тестовых сущностях: проверяем доставку, корректность подстановок и запись в историю.
6. Нагрузочная проверка. Смотрим поведение при массовой рассылке и при недоступности оператора — настраиваем повторные попытки и уведомление администратора.
7. Передача в эксплуатацию. Фиксируем регламент, обучаем сотрудников и оставляем журнал для разбора спорных отправок.

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

Артефакты: что остаётся в вашем контуре

После сдачи работ у вас остаётся не «доступ к личному кабинету подрядчика», а полный комплект в вашем контуре: конфигурация, шаблоны, правила и документация. Ниже — что именно мы передаём и зачем каждый артефакт нужен при эксплуатации.

• Конфигурация подключения — параметры интеграции с SMS.ru в Битрикс24: привязка к порталу, ключи доступа, лимиты отправки, настройки очередей и повторных попыток при сбое провайдера.
• Шаблоны сообщений — тексты для каждого сценария (подтверждение записи, напоминание, код входа, статус заявки) с переменными подстановки и правилами персонализации по полям CRM.
• Правила маршрутизации — логика, какое событие CRM или бизнес-процесса запускает отправку, кому уходит сообщение, в каких случаях дублируется на резервный канал и как обрабатывается отписка.
• Журналы отправки и доставки — выгрузка статусов по каждому сообщению: принято провайдером, доставлено, отклонено, ошибка. Нужны для разбора спорных ситуаций и сверки с клиентами.
• Регламент эксплуатации — пошаговые инструкции для вашей команды: как добавить новый шаблон, изменить маршрут, проверить баланс и отчётность, что делать при массовом сбое доставки.
• Схема интеграции — визуальная карта связей между Битрикс24, бизнес-процессами и SMS-сервисом: где хранятся ключи, где логи, какие точки отказа и как они изолированы.
• Инструкция по передаче доступов — порядок и перечень прав, которые оформляются на ваши учётные записи, чтобы интеграция не зависела от подрядчика.

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

Если понадобится расширить сценарии — добавить канал, изменить логику маршрутизации или подключить новый шаблон — вы делаете это по документации самостоятельно. Опишите задачу, и мы вернёмся с оценкой и планом передачи материалов под ваш контур.

Кейс: поток уведомлений без потерь

Клиент — сервисная компания с потоком заявок из форм на сайте, чатов и телефонии. Уведомления о новых обращениях уходили через самописный шлюз: часть сообщений терялась при всплесках нагрузки, статусы доставки нигде не фиксировались, а операторы узнавали о заявке с задержкой. Разбираем, что дала интеграция SMS.ru с Битрикс24 и как изменились метрики.

Что было до

Событие из формы попадало в очередь, но обработчик не имел повторных попыток: при ошибке отправки сообщение просто исчезало. Доля доставленных держалась на уровне около 82%, время прохождения очереди в пиковые часы доходило до 12-15 минут. Операторы переспрашивали клиентов и вручную дублировали уведомления — за месяц набиралось несколько десятков обращений в поддержку по «не пришло SMS».

Что изменили

Связали CRM с сервисом через штатные бизнес-процессы и роботов: событие создания лида или сделки запускает отправку, а статус доставки возвращается обратно в карточку. Добавили очередь с повторными попытками и разделением на приоритеты — критичные уведомления уходят первыми, рассылки не блокируют их. Шаблоны вынесли в отдельные правила, чтобы менять текст без правки логики.

Метрики после

Повторные попытки закрыли класс потерь при кратковременных сбоях, а фиксация статусов убрала слепую зону: теперь видно, дошло ли сообщение и на каком шаге оно застряло. Операторы перестали дублировать уведомления вручную — освободилось время на обработку заявок, а не на переспрос.

Чем отличается штатный модуль от собственного обработчика?

Штатный модуль — это готовый коннектор из маркетплейса: он ставится в пару кликов, сразу получает настройки подключения и умеет отправлять сообщения по событиям, которые предусмотрел автор. Пока сценарий типовой — подтверждение заявки, уведомление о смене статуса сделки, напоминание о встрече — этого достаточно, и мы честно говорим об этом заказчику, а не продаём разработку там, где хватит коробки.

Ограничение начинается там, где логика перестаёт быть типовой. Штатный модуль не знает, что клиенту нельзя писать в нерабочие часы, что для одного сегмента нужен один шаблон подписи, а для другого — другой, что повторная отправка при ошибке должна идти по своему расписанию. Обойти это можно только костылями поверх модуля, и каждый такой костыль живёт до следующего обновления.

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

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

Есть и обратная сторона: собственный обработчик — это код, который нужно сопровождать, тестировать и документировать. Поэтому выбор мы делаем по сценарию, а не по привычке: если хватает штатного модуля — ставим его и не усложняем систему; если логика упирается в его рамки — пишем свой и берём ответственность за его работу.

Частые технические сомнения

Интеграция SMS.ru с Битрикс24 почти всегда упирается в четыре вопроса: что будет при исчерпании лимита, как устроена повторная отправка, где искать историю сообщений и насколько больно менять провайдера. Ниже — как это закрывается на уровне настройки, а не обещаний.

Как работает повторная отправка при сбое провайдера?

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

Где хранится история отправок и что в ней есть?

Журналирование ведём в самом Битрикс24 и в логах интеграции: номер, шаблон, статус, время отправки, ответ провайдера, идентификатор сообщения. По этим данным можно разобрать любой инцидент — от «клиент не получил код» до расхождения в отчётности по рассылке. Логи ротируются, чтобы не раздувать базу, но глубина хранения покрывает период сверки с оператором.

Насколько сложно заменить SMS-провайдера?

Логика отправки вынесена в отдельный слой: правила и шаблоны в Битрикс24 остаются, меняется только модуль-отправитель и формат ответа нового сервиса. Перенос занимает меньше времени, чем первичная настройка, потому что очереди, ретраи и журналирование уже описаны. Перед переключением прогоняем тестовые отправки на оба сервиса параллельно и сверяем статусы доставки.

Опишите вашу задачу — вернёмся с оценкой и планом: какие лимиты выставить, как настроить очереди и что попадёт в журнал.

Обсудим вашу задачу

Чтобы оценка была точной, а не «средней по рынку», нам нужно понять ваш текущий сценарий отправки. Опишите, откуда приходят события — сделки, счета, лиды, статусы доставки, — какие шаблоны уже используются и что именно не устраивает: сообщения не доходят, дублируются, теряются статусы или всё держится на ручной отправке. Этого достаточно, чтобы вернуться с оценкой и планом внедрения, а не с общими словами.

Что стоит приложить к описанию задачи:

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

По этим вводным мы соберём план: какие сценарии автоматизируем, как настроим шаблоны и правила повторов, как свяжем статусы доставки с карточками в Битрикс24, чтобы менеджер видел результат в привычном интерфейсе. Отдельно пропишем, что делаем на этапе запуска и как проверяем, что сообщения уходят корректно, — тестовый контур на реальных событиях до включения на всю базу.

Опишите задачу в свободной форме — вернёмся с оценкой сроков и планом работ по вашему сценарию.