Налаштування автоматичного надсилання листів із CRM Бітрікс24

Чому автоматичне надсилання листів із CRM ламається

Автоматичне надсилання листів із CRM тримається на зв'язці трьох речей: шаблону, умови запуску та даних, які підставляються в поля. Ламається зазвичай не шаблон, а умова — правило в Bitrix24 прив'язане до стадії угоди, а не до події.

Через це автоматичне надсилання листів спрацьовує повторно щоразу, коли угода повертається на попередню стадію: клієнт отримує другий лист, а про зайве повідомлення в листуванні дізнається вже від нього самого.

Дублікати повідомлень і зміна відповідального — друга часта пара збоїв. Коли угоду переводять на іншого співробітника, частина правил продовжує надсилати листи на попередню адресу або на загальну скриньку відділу.

Адресат у шаблоні підставляється за відповідальним, а не за учасником угоди, тому лист іде не тому, хто фактично веде роботу.

Третій сценарій — зависла черга. Лист потрапив у чергу, але надіслати його не вдалося: адреса не заповнена, домен відхиляє прийом, у шаблоні залишилося порожнє поле підстановки. Запис не зникає й не надсилається, а наступні листи вишиковуються за ним і теж не доходять.

Збій надсилання з CRM при цьому ніде не спливає — у картці угоди його не видно, тому про проблему дізнаються, коли клієнт уже чекає відповіді.

Розбираємо, як це закривається: дивимося, на чому зав'язані правила, перебудовуємо умови запуску й додаємо контроль доставки.

Що дає налаштування: вимірюваний ефект для відділу продажів

Автосповіщення змінюють не сам факт листування, а момент, коли воно починається. Лист іде тієї ж секунди, як створено лід або змінилася стадія угоди, — без паузи на те, щоб менеджер відкрив картку й згадав про неї.

Час першої відповіді перестає залежати від завантаження конкретного співробітника: звернення, що надійшло ввечері або у вихідний, отримує підтвердження одразу, а не наступного ранку.

Частка звернень, що проходять без ручної участі, — найчесніший показник порядку в налаштуваннях. Коли шаблон прив'язаний до стадії й підставляє дані угоди, типовий лист не пишуть руками: менеджер підтверджує надсилання або одразу переходить до змістовної частини розмови.

Швидкість реакції на лід стає однаковою у сильного й у нового співробітника — бо визначає її правило в системі, а не особиста дисципліна.

Загублені заявки зникають там, де раніше рвалися ланцюжки. Заявка з сайту, лист на загальну скриньку, звернення з месенджера — усе перетворюється на лід і розподіляється за відповідальним, а не осідає в непрочитаному.

Якщо відповідальний недоступний, спрацьовує ескалація: повідомлення йде керівникові, і угода не залишається без руху.

Ефект автоматизації видно не в гарних листах, а в тому, що контроль перестає бути ручним.

Час першої відповіді та кількість заявок без реакції вимірюються звітом, а не самовідчуттям команди, — і за цими цифрами вже зрозуміло, де налаштування працює, а де потрібне доопрацювання логіки, полів або прав доступу.

Способи запуску: сценарії, роботи й пакетні розсилки

Лист із CRM запускається не «загалом», а з конкретного приводу, і спосіб запуску задає три речі: як швидко піде повідомлення, що в нього можна підставити й як система переживе масову зміну даних. Нижче — варіанти, між якими реально вибирають на проєкті, та обмеження кожного.

Логіка вибору проста: поодинокі листи прив'язують до події або стадії, а все, що йде сотнями, виносять у пакетний запуск з окремою перевіркою прав і частоти. На практиці способи комбінують і додають правило зупинки — щоб клієнт не отримав два листи про одне й те саме.

Порядок впровадження: аудит, схема, налаштування, перевірка, передача

Роботу починаємо з інвентаризації, а не з правки шаблонів: якщо одразу ввімкнути нові тригери поверх наявних, клієнт починає отримувати два-три листи про одну подію, а частина з них іде без урахування стадії угоди. Тому спочатку фіксуємо, що вже працює й які події взагалі мають породжувати лист.

1. Аудит повідомлень. Вивантажуємо всі чинні сценарії, шаблони й адреси відправників, зіставляємо їх із реальними бізнес-процесами. Зазвичай після цього вимикається помітна частка сценаріїв, які дублюють один одного або спрацьовують на застарілих стадіях.
2. Схема маршрутів листів. Збираємо карту «подія → отримувач → шаблон → скринька відправника», окремо позначаємо копії та службові адреси. Схема узгоджується до налаштування — так правки в логіці коштують години роботи, а не переробки всього контуру.
3. Налаштування тригерів. Прив'язуємо надсилання до стадій угоди, строків і дій клієнта, задаємо умови спрацювання, затримки й винятки. Перевіряємо, що повторна подія не породжує повторний лист.
4. Тестовий прогін. Прогоняємо сценарії на тестових угодах: дивимося доставку в зовнішні поштові сервіси, коректність підстановки полів, вкладення й кирилицю в темах і іменах файлів.
5. Контроль на робочому контурі. Перші дні ведемо надсилання на обмеженому потоці й звіряємо журнал: відсікаємо хибні спрацювання, поки вони не стали звичкою співробітників.
6. Передача документації. Віддаємо регламент маршрутів, реєстр шаблонів і правила їх зміни, щоб ваша команда правила тексти й умови самостійно.

Що залишається у вас: шаблони, журнал надсилання, регламенти

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

• Шаблони листів — по одному на кожен сценарій, з темою, підписом і підстановкою полів картки: ім'я, етап угоди, відповідальний, контакт. До кожного — коротка замітка, які змінні звідки беруться й що не можна видаляти з тіла, інакше лист піде порожнім.
• Карта сценаріїв — таблиця «подія → отримувач → шаблон → затримка → повтор». Відразу видно, де йде лист клієнту, де повідомлення співробітнику й які ланцюжки перетинаються між собою.
• Правила доступу — які ролі бачать поштові скриньки, хто має право правити шаблон, що відбувається з надсиланням при звільненні відповідального й передачі угоди.
• Інструкція для менеджерів — одна-дві сторінки: як надіслати лист вручну, що не змінювати в тілі, куди звертатися, якщо клієнт повідомив, що нічого не отримав.
• Порядок розбору помилок — де дивитися журнал надсилання, як відрізнити друкарську помилку в адресі від відмови поштового сервера отримувача, кому йде повідомлення про збій і в які строки розбирається.
• Контрольний набір перевірок — тестове надсилання на свої адреси перед публікацією, перевірка зовнішніх скриньок і листів із вкладеннями.
• Регламент змін — хто погоджує правку тексту, як фіксується нова редакція й як відкотитися до попередньої, якщо нове формулювання знизило відгук.

З цим набором система залишається керованою: правки не ламають сценарії, збої видно в журналі, а передача завдань усередині команди не потребує заново розбирати логіку розсилок.

Кейс: як ми прибрали завислі повідомлення у відділі продажів

Цей кейс впровадження почався зі скарг відділу продажів: повідомлення про нові заявки приходили із затримкою або не приходили взагалі, а автоматичне надсилання листів у Bitrix24 працювало як чорна скринька.

На піках — під час рекламних кампаній і масових розсилок — частина листів ішла в чергу й там зависала. Менеджери дізнавалися про заявку через 30-40 хвилин або з повторного дзвінка клієнта, який уже встиг написати конкуренту.

Розбір інциденту

Підняли журнал надсилання за два тижні й побачили картину: повідомлення про заявки та масові розсилки йшли в один потік.

Під час піку в кілька сотень листів за хвилину черга зростала швидше, ніж розбиралася, а у разі збою надсилання лист просто губився — повтору не передбачалося, помилка осідала в логах і нікого не турбувала.

Що змінили

Розвели потоки: повідомлення за заявками й угодами отримали окрему чергу з пріоритетом, розсилки — свою. Додали повтор у разі збою з наростаючою паузою, статус для кожного листа в журналі й оповіщення, якщо в черзі накопичується більше заданого порогу.

Метрики до й після

Частка доставлених повідомлень зросла з 82% до 99,4%. Час від появи заявки до листа менеджерові скоротився з 30-40 хвилин у пік до кількох секунд.

Завислі повідомлення перестали бути регулярним явищем: поодинокі випадки видно в журналі й розбираються за сигналом за хвилини, а не пошуком у логах за півдня. Стабільність надсилання тепер вимірюється, а не обговорюється на нарадах.

Чим відрізняється сценарій за подією від розсилки за розкладом?

Різниця в тому, що слугує запуском листа. Сценарій за подією спрацьовує від дії клієнта або зміни картки: заповнена форма, перехід угоди на нову стадію, відповідь на лист, перехід за посиланням.

Розсилка за розкладом запускається за календарем і не залежить від поведінки отримувача — вона йде призначеного дня.

У Bitrix24 логіка тригера збирається з трьох частин: умова, затримка й шаблон листа. Умова перевіряє поля й події, затримка задає паузу (лист іде не одразу, а якщо реакції так і не було), шаблон підставляє дані угоди в текст.

Розклад влаштований простіше: набір листів із кроком за днями, який веде клієнта за заздалегідь відомим маршрутом.

Вибір режиму диктує завдання. Потрібна реакція на дію — реєстрація, запит рахунку, незавершена заявка — беріть подію: лист приходить у момент інтересу й рідше потрапляє в спам.

Потрібні планові контакти з клієнтом у рівному ритмі — навчання після покупки, нагадування про закінчення послуги, серія прогріву — працює розклад, бо прив'язати його в картці немає до чого.

На практиці режими не протиставляють, а комбінують: розклад дає каркас контактів, подія додає реакцію. Важливо розвести умови, щоб клієнт не отримав два листи одного дня — у налаштуваннях це вирішується перевіркою факту попереднього надсилання й порядком виконання правил.

Часті сумніви: дублі, потрапляння в спам, права доступу

Дублі — майже завжди наслідок логіки, а не збою: кілька роботів спрацьовують на одній стадії угоди, ручний запуск іде поверх автоматичного, імпорт історії повторно проганяє вже надіслані повідомлення.

Клієнт отримує два листи поспіль, менеджер перестає довіряти повідомленням і починає перевіряти воронку вручну.

Другий ризик — репутація домену. Якщо листи йдуть напряму з робочої пошти без налаштованої аутентифікації відправника, частина осідає в спамі в отримувача, і це б'є по всіх майбутніх розсилках одразу. Масові ручні надсилання з картки погіршують картину, тому їх обмежують за обсягом і частотою.

Листи будуть потрапляти в спам?

Ризик знімається налаштуванням домену: аутентифікація відправника, окремий піддомен для сервісних повідомлень і ліміти на масові розсилки. Перші надсилання перевіряємо на контрольних скриньках у кількох поштових службах.

Чи збережеться в менеджерів ручне надсилання?

Так, але в заданих межах: шаблон, ліміт отримувачів і частота задаються роллю. Живий контакт із клієнтом залишається, а репутація домену не руйнується.

Обговоримо завдання: що надіслати для точної оцінки

Щоб оцінка робіт спиралася на факти, а не на припущення, нам достатньо кількох ввідних по проєкту. За ними видно обсяг налаштування, кількість сценаріїв і місця, де потрібна зв'язка з 1С або зовнішнім сервісом надсилання.

• Перелік подій, за якими має йти лист: зміна стадії угоди, новий лід, виставлений рахунок, нагадування відповідальному.
• Поштові скриньки й домени для надсилання, а також обмеження з боку поштового провайдера на обсяг і частоту листів.
• Чинні шаблони: чи потрібне доопрацювання, як оформлено підпис, чи є вимоги до брендування.
• Які поля CRM підставляються в лист і які дані мають тягнутися з 1С.
• Адресати: лише клієнти, лише співробітники або обидва напрями одразу.
• Права доступу — хто редагує шаблони, хто бачить журнал надсилань і історію за угодою.
• Що не влаштовує зараз: листи йдуть вручну, губляться між етапами або потрапляють у спам.

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