Налаштування ланцюжків листів у Bitrix24: автоматизація CRM-маркетингу

Ланцюжки листів у Бітрікс24: де ламається автоматизація

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

Друге джерело — дублі контактів у CRM та листи, що йдуть без сегмента. Заявка з телефону та заявка з пошти створюють дві картки: сценарій прив’язаний до однієї, а листування живе в іншій, і частина бази просто випадає з автоматизації crm-маркетингу.

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

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

Що змінюється після впровадження сценаріїв листів

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

• Час першої відповіді. Вітальний лист з умовами та посиланням на календар йде в перші хвилини після заявки, включаючи неробочі години: клієнт не чекає, поки менеджер звільниться.
• Обробка лідів у CRM. У кожного звернення з’являється відповідальний і наступний крок за таймером — угоди без активності перестають мовчки лежати на початковій стадії.
• Повернення клієнтів у воронку. Звернення, за якими відклали рішення або не додзвонилися, повертаються листом за подією в картці і знову потрапляють у роботу.
• Навантаження на менеджерів продажів. Підтвердження, нагадування та запит зворотного зв’язку йдуть автоматично; менеджер телефонує тим, хто вже відкрив лист і виявив інтерес.
• Звітність за розсилками. Видно відкриття, переходи та відповіді за кожним кроком ланцюжка — зрозуміло, на якому дотику угоди губляться і які тексти працюють.

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

Формати запуску: ланцюжки, події, ручні відправлення

У Бітрікс24 лист клієнту запускається трьома механізмами, і різняться вони не оформленням, а тим, що слугує умовою відправлення: час, зміна угоди або дія співробітника.

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

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

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

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

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

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

1. Аудит даних і поточних сценаріїв. Розбираємо базу контактів: дублі, невалідні адреси, відписки, поля для сегментації, історію угод. Дивимося, які розсилки вже йдуть вручну і де вони перетинаються.
2. Проєктування схеми комунікації з клієнтом. Фіксуємо логіку: який тригер запускає ланцюжок, скільки в ньому листів і з якими паузами, що відбувається при відкритті, відповіді та відписці, де ланцюжок зупиняється.
3. Складання сценаріїв. Налаштовуємо тригери за етапами угоди, шаблони листів, змінні підстановки, правила сегментації, захист від повторних відправлень і ліміти на частоту.
4. Тестове відправлення листів. Проганяємо кожну гілку на тестових контактах: підстановка полів, потрапляння в спам, вигляд на мобільних, коректність пауз, зупинка ланцюжка при відповіді.
5. Перенесення сценаріїв на робочу базу. Включаємо частинами: спочатку один сегмент, дивимося доставлюваність і відгук, потім розширюємо. Помилка в логіці не йде на всю базу одразу.
6. Передача регламентів. Віддаємо карту ланцюжків, опис тригерів, інструкцію з правки текстів і правила, за якими сценарій змінюють без розробника, плюс набір метрик для контролю.

Комплект налаштувань, схем та інструкцій для команди

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

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

• Карта сценаріїв: які ланцюжки запускаються, за якою подією в CRM, скільки в кожному кроків, які між ними затримки і що перериває відправлення.
• Правила сегментації бази: за якими полями контакту та стадіями угоди ділиться аудиторія, хто потрапляє в кожен сегмент і куди йде клієнт, коли перестає йому відповідати.
• Схема воронки: зв’язок стадій угоди з кроками розсилки, точки виходу, умови зупинки та логіка повторного включення контакту в потік.
• Документація з розсилок: шаблони листів, список змінних, що підставляються, теми та відправники — з позначками, що можна правити безпечно, а що пов’язано з логікою сценарію.
• Інструкція для маркетолога: як додати крок, змінити текст або затримку, як прогнати ланцюжок на тестовому контакті та перевірити, що лист пішов потрібному сегменту.
• Регламент обробки відповідей: як відповіді, відписки та небажані адреси повертаються в CRM, хто і в які терміни їх обробляє і що вважається закритим зверненням.
• Журнал змін і порядок відкату: як повернути попередню версію сценарію, якщо нова логіка повелася інакше, ніж очікувалося на тесті.

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

Кейс: як скоротили ручні розсилки та втрати заявок

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

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

Що змінили в сценаріях

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

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

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

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

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

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

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

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

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

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

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

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

Тому на практиці це не вибір «або-або»: сценарій закриває роботу з базою та повторні продажі, розсилка — разові приводи.

Часті технічні сумніви перед запуском

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

Чи можна одразу підключити вже зібрану базу?

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

Чому падає відкриваність листів?

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

Як розділити комунікацію за відділами та правити сценарії самостійно?

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

Обговоримо завдання та повернемося з оцінкою і планом

Щоб оцінка проєкту автоматизації спиралася на факти, а не на «здається, там усе просто», розмову починаємо з поточного контуру розсилок. Нижче — що варто підготувати, щоб за один прохід побачити сценарії, обмеження та точки ризику.

• Доступи: окрема тестова копія CRM, права адміністратора в ній і на робочому контурі, доступ до домену та поштового сервісу, з якого йде відправлення.
• Карта воронки: етапи угоди, поля-зобов’язання, на яких переходах має йти лист і які умови виключають контакт — відкрита угода, відмова, повторне звернення.
• Поточні ланцюжки листів: шаблони, змінні підстановки, інтервали між кроками та статистика за відкриттями й переходами — вона показує, де сценарій втрачає людей.
• Обмеження комунікації: ліміт дотиків на клієнта, тихі години, категорії контактів, яким писати не можна, вимоги щодо згоди та відписки.
• Суміжні системи: сайт, облікова система, телефонія, зовнішній сервіс розсилок — і те, як вони обмінюються даними з CRM сьогодні.
• Регламент: хто погоджує текст, хто запускає ланцюжок, хто веде стоп-лист і розбирає скарги.

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

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