Чому інтеграція SMS.ru з Бітрікс24 ламається на потоці
Інтеграція SMS.ru з Бітрікс24 майже завжди стартує однаково: пара роботів у CRM, надсилання коду підтвердження з форми та повідомлення менеджеру про нову угоду. На малих обсягах це працює без нарікань, тому інтеграцію й здають як готову.
Проблеми починаються, коли через той самий канал ідуть масові розсилки по базі, статусні повідомлення клієнтам і службові оповіщення співробітникам — тобто коли разове надсилання перетворюється на потік.
Перше вузьке місце — відсутність черги повідомлень. Бітрікс24 надсилає події синхронно: робот викликає зовнішній сервіс і чекає на відповідь. Якщо провайдер відповідає повільно або повертає помилку, транзакція зависає, а при масовому надсиланні частина запитів просто не доходить.
Друге — дублікати повідомлень: подія спрацьовує повторно при зміні стадії угоди, оновленні картки або ретраї, і клієнт отримує два-три однакових SMS.
Третє — ліміти провайдера: при перевищенні допустимої швидкості надсилання повідомлення не йдуть, але в CRM залишається відмітка «надіслано», і втрачене повідомлення ніхто не помічає.
Ціна таких збоїв вища, ніж здається. Клієнт не отримує код підтвердження і йде з форми, менеджер дізнається про заявку із запізненням, а розсилка по базі доходить до половини адресатів — при цьому звіт показує успішне надсилання.
Розбираємо, як це закривається на рівні архітектури: черга, дедуплікація подій, контроль статусів доставки та обробка помилок провайдера.
Що дає зв'язка CRM і SMS-шлюзу
Зв'язка будується на обміні подіями: зміна стадії угоди, нова заявка, нагадування про зустріч — CRM формує подію, шлюз надсилає повідомлення, а статус доставки повертається назад у картку.
Менеджер не перемикається між вікнами і не переносить номери вручну — тригер спрацьовує в момент зміни запису, тому клієнт отримує повідомлення протягом хвилини після дії, а не наприкінці робочого дня.
Швидкість доставки та частка успішних відправок — перші метрики, за якими видно ефект. Під час відправки через шлюз із прямими підключеннями до операторів повідомлення йде за секунди, а звіт про доставку надходить зворотним викликом і фіксується в CRM.
Якщо номер недоступний або відхилений оператором, система позначає спробу як неуспішну і запускає повтор за заданим правилом — частка доставлених повідомлень зростає без ручного контролю з боку менеджерів.
Єдиний журнал повідомлень знімає головний біль підтримки: усе листування по клієнту — підтвердження запису, нагадування, коди — лежить в одній стрічці поруч з історією угоди. Під час розбору звернення видно, що саме і коли пішло клієнту, чи доставлено його, і чи була відповідь. Це прибирає суперечки «ми вам писали» і скорочує час на з'ясування обставин.
Автоматизація повідомлень знімає з менеджерів рутину: шаблони підставляють ім'я, номер замовлення, дату і суму з полів картки, а масові розсилки по сегменту запускаються зі списку контактів. Звільнений час іде на угоди, а не на копіювання тексту.
Окремо налаштовується маршрутизація вхідних відповідей — повідомлення від клієнта потрапляє в той самий канал і не губиться.
Перевірити ефект можна за трьома зрізами: середній час від події до доставки, частка успішних відправок за період і кількість звернень, закритих без участі менеджера.
Ці метрики збираються з журналу і вивантажень шлюзу, тому порівняння «до і після» спирається на факти, а не на відчуття.
Способи підключення: порівняння варіантів
Є три робочі схеми, і вибір між ними визначається не зручністю, а тим, які події мають надсилатися в SMS і наскільки критична доставка. Штатний модуль підходить для типових сценаріїв: зміна стадії угоди, нагадування про завдання, повідомлення відповідальному.
Власний обробник потрібен там, де логіка залежить від кількох сутностей одночасно — наприклад, SMS надсилається лише при сумі угоди вище порогу та відсутності активності за останні дні.
Проміжний сервіс виправданий, коли SMS надсилають кілька систем, а шаблони та журнал відправлень мають жити в одному місці.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Штатний модуль | Типові повідомлення за подіями CRM, потрібен швидкий запуск | Логіка обмежена налаштуваннями; при нестандартних умовах доводиться підлаштовувати процес під модуль |
| Власний обробник | Повідомлення залежать від кількох полів, ролей і етапів угоди | Потребує супроводу при оновленнях; помилки в умовах видно лише за фактом недоставки |
| Проміжний сервіс | SMS надсилають CRM, сайт і облікова система; потрібен єдиний журнал і шаблони | З'являється додатковий вузол: потрібен контроль доступності та повторних спроб |
Обмеження підключення спільні для всіх трьох схем: ліміт на довжину повідомлення та вартість сегментів, затримка між постановкою в чергу та фактичною доставкою, обов'язкова нормалізація номерів до міжнародного формату.
Окремо варто врахувати, що при масових розсилках оператор може обмежити швидкість — це лікується чергою з регульованим темпом відправлення, а не збільшенням кількості одночасних запитів.
На практиці найчастіше беруть комбінацію: штатний модуль закриває типові повідомлення, а нестандартні сценарії виносимо в окремий обробник із спільним журналом. Такий гібрид дає передбачувану доставку без переписування всього контуру повідомлень при кожній зміні процесу продажів.
Як ми проводимо впровадження інтеграції SMS.ru Бітрікс24
Впровадження інтеграції починається не з налаштування, а з аналізу того, де в Бітрікс24 вже живуть повідомлення: ліди, угоди, рахунки, завдання, нагадування менеджерам.
На цьому етапі ми фіксуємо, які події взагалі мають надсилатися в SMS, а які логічніше залишити в месенджері або на пошті — інакше клієнт отримує дублі й відписується.
Далі вибудовуємо схему потоків: який робот або бізнес-процес викликає відправлення, де зберігається шаблон, що відбувається при відмові оператора. Тільки після цього підключаємо сервіс і переходимо до перевірок.
- Аудит сценаріїв. Розбираємо поточні правила й роботів, позначаємо події-тригери та відповідальних, прибираємо дублюючі повідомлення.
- Схема потоків. Узгоджуємо карту: подія → умова → шаблон → отримувач → журнал. Замовник бачить логіку до початку налаштування.
- Налаштування підключення. Реєструємо відправника, прив'язуємо його до порталу, налаштовуємо права та ліміти за напрямами.
- Шаблони повідомлень. Готуємо тексти під кожен сценарій із підстановкою полів угоди та ліда, стежимо за довжиною й читабельністю.
- Тестове відправлення. Проганяємо кожну подію на тестових сутностях: перевіряємо доставку, коректність підстановок і запис в історію.
- Навантажувальна перевірка. Дивимося поведінку при масовій розсилці та при недоступності оператора — налаштовуємо повторні спроби й повідомлення адміністратора.
- Передача в експлуатацію. Фіксуємо регламент, навчаємо співробітників і залишаємо журнал для розбору спірних відправлень.
Кожен крок закінчується узгодженням: якщо на етапі схеми з'ясовується, що сценарій не потрібен, ми прибираємо його до налаштування, а не після запуску. Так впровадження інтеграції не перетворюється на переробку бойового порталу.
Артефакти: що залишається у вашому контурі
Після здачі робіт у вас залишається не «доступ до особистого кабінету підрядника», а повний комплект у вашому контурі: конфігурація, шаблони, правила та документація. Нижче — що саме ми передаємо і навіщо кожен артефакт потрібен при експлуатації.
- Конфігурація підключення — параметри інтеграції з SMS.ru у Бітрікс24: прив'язка до порталу, ключі доступу, ліміти відправлення, налаштування черг і повторних спроб при збої провайдера.
- Шаблони повідомлень — тексти для кожного сценарію (підтвердження запису, нагадування, код входу, статус заявки) зі змінними підстановки та правилами персоналізації за полями CRM.
- Правила маршрутизації — логіка, яка подія CRM або бізнес-процесу запускає відправлення, кому надходить повідомлення, у яких випадках дублюється на резервний канал і як обробляється відписка.
- Журнали відправлення та доставки — вивантаження статусів за кожним повідомленням: прийнято провайдером, доставлено, відхилено, помилка. Потрібні для розбору спірних ситуацій і звірки з клієнтами.
- Регламент експлуатації — покрокові інструкції для вашої команди: як додати новий шаблон, змінити маршрут, перевірити баланс і звітність, що робити при масовому збої доставки.
- Схема інтеграції — візуальна карта зв'язків між Бітрікс24, бізнес-процесами та SMS-сервісом: де зберігаються ключі, де логи, які точки відмови і як вони ізольовані.
- Інструкція з передачі доступів — порядок і перелік прав, які оформлюються на ваші облікові записи, щоб інтеграція не залежала від підрядника.
Кожен артефакт оформлено так, щоб ним міг користуватися ваш штатний спеціаліст без звернення до нас. Конфігурація та правила версіонуються, шаблони зберігаються у редагованому вигляді, регламент описує типові операції та точки ескалації.
Якщо знадобиться розширити сценарії — додати канал, змінити логіку маршрутизації або підключити новий шаблон — ви робите це за документацією самостійно. Опишіть задачу, і ми повернемося з оцінкою та планом передачі матеріалів під ваш контур.
Кейс: потік сповіщень без втрат
Клієнт — сервісна компанія з потоком заявок із форм на сайті, чатів і телефонії.
Сповіщення про нові звернення надходили через самописний шлюз: частина повідомлень губилася під час сплесків навантаження, статуси доставки ніде не фіксувалися, а оператори дізнавалися про заявку із затримкою. Розбираємо, що дала інтеграція SMS.ru з Бітрікс24 і як змінилися метрики.
Що було до
Подія з форми потрапляла в чергу, але обробник не мав повторних спроб: у разі помилки надсилання повідомлення просто зникало. Частка доставлених трималася на рівні близько 82%, час проходження черги в пікові години сягав 12-15 хвилин.
Оператори перепитували клієнтів і вручну дублювали сповіщення — за місяць набиралося кілька десятків звернень до підтримки щодо «не прийшло SMS».
Що змінили
Пов'язали CRM із сервісом через штатні бізнес-процеси та роботів: подія створення ліда або угоди запускає надсилання, а статус доставки повертається назад у картку.
Додали чергу з повторними спробами та розподілом на пріоритети — критичні сповіщення надходять першими, розсилки не блокують їх. Шаблони винесли в окремі правила, щоб змінювати текст без правки логіки.
Метрики після
| Показник | До | Після |
|---|---|---|
| Частка доставлених повідомлень | ~82% | 98-99% |
| Час проходження черги в пік | 12-15 хв | до 1 хв |
| Звернення до підтримки щодо SMS | десятки на місяць | поодинокі |
Повторні спроби закрили клас втрат під час короткочасних збоїв, а фіксація статусів прибрала сліпу зону: тепер видно, чи дійшло повідомлення і на якому кроці воно застрягло. Оператори перестали дублювати сповіщення вручну — звільнився час на обробку заявок, а не на перепитування.
Чим відрізняється штатний модуль від власного обробника?
Штатний модуль — це готовий конектор з маркетплейсу: він встановлюється за пару кліків, одразу отримує налаштування підключення і вміє надсилати повідомлення за подіями, які передбачив автор.
Поки сценарій типовий — підтвердження заявки, повідомлення про зміну статусу угоди, нагадування про зустріч — цього достатньо, і ми чесно говоримо про це замовнику, а не продаємо розробку там, де вистачить коробки.
Обмеження починається там, де логіка перестає бути типовою. Штатний модуль не знає, що клієнту не можна писати в неробочі години, що для одного сегмента потрібен один шаблон підпису, а для іншого — інший, що повторне надсилання при помилці має йти за своїм розкладом. Обійти це можна лише костилями поверх модуля, і кожен такий костиль живе до наступного оновлення.
Власний обробник ми збираємо на стороні платформи: події, правила маршрутизації, шаблони і журнал надсилань — наші.
Гнучкість сценаріїв тут повна: умова за часом, за відповідальним, за сумою угоди, за історією звернень — усе це налаштовується і змінюється без очікування чужого релізу. Правка займає години, а не цикл узгоджень з вендором.
Головна відмінність проявляється на оновленнях платформи. Штатний модуль залежить від того, як швидко автор адаптує його до нової гілки: після великого апдейту надсилання може стати, і ви дізнаєтеся про це від клієнтів, а не від моніторингу.
Власний обробник спирається на документовані точки розширення, тому оновлення платформи його не ламають — ми перевіряємо сумісність до викату і тримаємо журнал надсилань з повторною доставкою.
Є й зворотний бік: власний обробник — це код, який потрібно супроводжувати, тестувати і документувати.
Тому вибір ми робимо за сценарієм, а не за звичкою: якщо вистачає штатного модуля — ставимо його і не ускладнюємо систему; якщо логіка впирається в його рамки — пишемо свій і беремо відповідальність за його роботу.
Часті технічні сумніви
Інтеграція SMS.ru з Бітрікс24 майже завжди впирається в чотири питання: що буде при вичерпанні ліміту, як влаштована повторна відправка, де шукати історію повідомлень і наскільки боляче змінювати провайдера. Нижче — як це закривається на рівні налаштування, а не обіцянок.
Що відбувається, коли вичерпано ліміт відправки?
Ліміт задається на рівні сервісу і на рівні правила в Бітрікс24: добовий обсяг, частота на один номер, обмеження на масові розсилки.
При досягненні порогу нові повідомлення не «з'їдаються» мовчки — вони стають у чергу і йдуть після скидання лічильника, а подія фіксується в журналі із зазначенням причини відмови.
Критичні повідомлення (коди підтвердження, статуси заявок) виводимо в окрему чергу з пріоритетом, щоб маркетингові розсилки не блокували транзакційні.
Як працює повторна відправка при збої провайдера?
Налаштовуємо ретраї з наростаючою паузою: перша спроба, потім повтор через короткий інтервал, далі — рідше, до заданої кількості спроб. Якщо провайдер повернув помилку доставки, повідомлення позначається як недоставлене і не дублюється при наступному запуску правила.
Окремо відстежуємо статус доставки за ідентифікатором повідомлення — так видно, чи дійшло SMS до абонента чи зависло на стороні оператора.
Де зберігається історія відправок і що в ній є?
Журналювання ведемо в самому Бітрікс24 і в логах інтеграції: номер, шаблон, статус, час відправки, відповідь провайдера, ідентифікатор повідомлення. За цими даними можна розібрати будь-який інцидент — від «клієнт не отримав код» до розбіжності у звітності щодо розсилки. Логи ротуються, щоб не роздувати базу, але глибина зберігання покриває період звірки з оператором.
Наскільки складно замінити SMS-провайдера?
Логіка відправки винесена в окремий шар: правила і шаблони в Бітрікс24 залишаються, змінюється лише модуль-відправник і формат відповіді нового сервісу. Перенесення займає менше часу, ніж первинне налаштування, тому що черги, ретраї та журналювання вже описані.
Перед перемиканням проганяємо тестові відправки на обидва сервіси паралельно і звіряємо статуси доставки.
Опишіть вашу задачу — повернемося з оцінкою та планом: які ліміти виставити, як налаштувати черги і що потрапить у журнал.
Обговоримо ваше завдання
Щоб оцінка була точною, а не «середньою по ринку», нам потрібно зрозуміти ваш поточний сценарій надсилання.
Опишіть, звідки надходять події — угоди, рахунки, ліди, статуси доставки, — які шаблони вже використовуються і що саме не влаштовує: повідомлення не доходять, дублюються, губляться статуси або все тримається на ручному надсиланні. Цього достатньо, щоб повернутися з оцінкою та планом впровадження, а не із загальними словами.
Що варто додати до опису завдання:
- поточний сценарій: де і як зараз формується повідомлення — вручну, роботом або бізнес-процесом;
- які події мають запускати надсилання і за якою умовою — зміна стадії, оплата, призначення відповідального;
- список шаблонів і змінних, які в них підставляються: номер, ім'я клієнта, номер замовлення, посилання;
- вимоги до доставки: чи потрібен контроль статусу, повтор при збої, обмеження за часом надсилання;
- обсяги: приблизна кількість повідомлень на день і пікові навантаження — розсилка по базі або поодинокі повідомлення;
- доступи та обмеження: хто відповідає за акаунт сервісу, чи є згода клієнтів на розсилку, чи потрібне маркування рекламних повідомлень;
- побажання щодо звітності: де дивитися історію надсилань і як розбирати недоставлені.
За цими ввідними ми зберемо план: які сценарії автоматизуємо, як налаштуємо шаблони та правила повторів, як зв'яжемо статуси доставки з картками в Бітрікс24, щоб менеджер бачив результат у звичному інтерфейсі.
Окремо пропишемо, що робимо на етапі запуску і як перевіряємо, що повідомлення надсилаються коректно, — тестовий контур на реальних подіях до включення на всю базу.
Опишіть завдання у вільній формі — повернемося з оцінкою термінів і планом робіт за вашим сценарієм.
