Триггерные рассылки Битрикс24: где рвётся цепочка
Триггерные рассылки Битрикс24 проектируются как часть воронки: событие в карточке меняет стадию, стадия запускает автоматические письма по событию. Пока схема на бумаге, всё сходится. На живом потоке сделок цепочка рвётся в местах, которые не видны в конструкторе роботов — и клиент не получает ни письма, ни звонка.
Первое узкое место — условия перехода статуса, которые считаются незакрытыми. Правило ждёт заполненного поля сделки или подтверждения от клиента, но фактически сработать не может, и сценарий уведомлений просто остаётся в режиме ожидания. Второе — пустые и нестандартные поля карточки: подстановка в шаблон письма берёт значение из реквизита, которого нет, и отправка откладывается или уходит с пустыми строками.
Дальше вмешивается ручная работа. Менеджер переводит сделку в следующую стадию через список, минуя форму, — часть правил при этом не срабатывает, а часть запускается дважды. При наложении нескольких сценариев на одну стадию конфликтующие правила глушат друг друга: первое письмо уходит, второе уже не проходит проверку условий.
Оборачивается это тем, что узкое место в воронке продаж возникает до первого разговора с менеджером. Клиент, который оставил заявку, ждёт подтверждения сутки-двое, остывает или уходит к тем, кто ответил быстрее. Отдел продаж узнаёт о проблеме от самого клиента, а не из системы, и тратит время на ручные догоняющие письма вместо сделок.
Ниже разбираем, как это закрывается: где смотреть журнал отправки, как проверять условия перехода и как разводить сценарии уведомлений между стадиями, чтобы письма не отправлялись дважды и не терялись.
Что даёт автоматизация писем по событиям в сделках
Ручные напоминания клиентам держатся на памяти менеджера: пока сделок десятки, это работает, дальше часть шагов просто не доходит до адресата. Автоматизация писем по событиям в Битрикс24 убирает эту зависимость — письмо уходит по факту смены стадии, выставления счёта, ответа клиента или паузы в переписке, а не по остатку внимания исполнителя.
Скорость ответа менеджера начинает измеряться настройкой, а не дисциплиной отдела: в ручном режиме первое касание занимает от нескольких часов до суток, при работе по событиям — минуты. Отклик на действие клиента приходит, пока интерес ещё живой, и это сразу видно в доле ответов на первое письмо.
Доля потерянных обращений падает по другой причине: событие срабатывает независимо от загрузки, отпуска или смены ответственного. Сделку передали другому сотруднику — цепочка продолжилась по тому же регламенту, и ни одно обращение не осталось без ответа из-за человеческого фактора.
Ручная нагрузка считается просто: сколько писем в день сотрудник писал сам и сколько из них были повторами по одному поводу. После перевода на события остаются только те сообщения, где действительно нужен человек — обсуждение условий, нестандартный запрос, спорный срок.
Предсказуемость коммуникации — итоговый эффект: у каждой сделки одинаковый набор шагов и понятный журнал, кто и когда получил письмо. Перед запуском фиксируем критерии: какие события берём, сколько ждём ответа до напоминания, кто получает уведомление при сбое отправки.
Режимы рассылок: событие, расписание, условие
Режим запуска определяет, когда уходит письмо: сразу после события в CRM, в назначенный момент или после накопления условий. От этого зависит и поведение рассылки при смене статуса сделки, и то, сколько ручной работы остаётся менеджеру. Ниже — четыре режима и их ограничения, которые чаще всего всплывают уже в работе.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Запуск по событию | Смена стадии сделки, новый лид, первое обращение | Срабатывает один раз на событие; массовый импорт контактов даёт дубли |
| Запуск по расписанию | Регулярные подборки, напоминания, возврат «уснувшей» базы | Не знает контекста: одному адресу уйдёт одно и то же письмо |
| Условные сценарии рассылки | Дожим по накопленным признакам: не открыл, не ответил, сумма сделки | Нужен корректный расчёт условий и защита от повторных отправок |
| Комбинированные цепочки | Событие, затем пауза, проверка условия, повторный контакт | Сложнее отлаживать, обязательна схема цепочки |
Комбинированный режим — не отдельный механизм, а сборка из базовых: письмо уходит по событию, дальше пауза, проверка условия и второй шаг. Для нескольких воронок продаж правила изолируют по воронке и стадии, иначе лид получит письмо из чужого сценария. Каждый режим прогоняем на тестовой воронке до включения — это дешевле, чем останавливать рассылку после первых жалоб.
Внедрение по шагам: от схемы до запуска
Внедрение триггерных писем в Битрикс24 начинаем не с шаблонов, а с инвентаризации того, что уже работает. В аккаунте обычно живут роботы на стадиях, бизнес-процессы и старые правила: часть дублирует друг друга, часть молчит из-за невыполненного условия, и увидеть это можно только по журналу отправок.
- Аудит сценариев — выгружаем правила, роботов на стадиях и шаблоны, сверяем с журналом: где дубли, где письмо не уходит, где адресат уже отписался.
- Схема событий — таблица «событие → условие → шаблон → задержка → ответственный». На ней видно пересечения: сделка попадает и в письмо по стадии, и в рассылку по сегменту.
- Настройка правил отправки — условия срабатывания, стоп-условия (клиент ответил, сделка закрыта, отписка) и ограничение частоты: не больше одного письма на контакт за заданный период.
- Шаблоны и переменные — подстановка полей сделки и контакта, проверка, что при пустом значении письмо не уходит с пустым местом в тексте.
- Тестовая отправка — прогон на тестовых сделках: создаём дубли карточек, двигаем стадии, проверяем подстановку, часовые пояса, попадание в спам и работу ссылки отписки.
- Проверка отказоустойчивости — поведение при отсутствии адреса, повторном заходе сделки на ту же стадию, ручной смене ответственного.
- Передача настроек и обучение — схема, доступы, инструкция, разбор с сотрудниками; первую неделю сверяем журнал с планом.
Пакет передачи: схемы, правила, регламенты
Пакет передачи — это не папка с файлами «на всякий случай», а набор документов, по которым новый администратор или менеджер воспроизводит работу рассылок без обращения к нам. Ниже — что именно остаётся у заказчика после сдачи контура триггерных рассылок.
- Карта сценариев — схема сценариев с точками запуска: какое событие в CRM или на сайте поднимает рассылку, какие условия проверяются перед отправкой, в какой ветке письмо уходит, а в какой пользователь выпадает из цепочки.
- Регламент отправки — правила запуска: временные окна, лимиты на количество писем в сутки одному адресату, правила повторной отправки после открытия или клика, условия остановки серии при покупке или отписке.
- Шаблоны писем и переменные — сами шаблоны с подстановками из полей сделки, контакта и компании, чтобы маркетолог правил текст, не ломая логику подстановки.
- Матрица прав доступа к настройкам — кто может создавать и включать сценарий, кто только правит шаблон, кто видит статистику: права доступа к настройкам разводятся по ролям, а не выдаются всем администратором.
- Инструкция для менеджеров — короткий документ по частым действиям: как поставить рассылку на паузу для конкретного клиента, как исключить адрес из серии, что делать при жалобе на спам.
- Порядок изменений — документация по рассылкам ведётся в одном месте: правка сценария проходит проверку на тестовом контакте, а версия правил фиксируется, чтобы понимать, почему письмо ушло именно так.
Такой пакет снимает зависимость от конкретного исполнителя: сценарии, регламент отправки и права описаны достаточно, чтобы команда заказчика правила их самостоятельно, а мы подключались только на сложных изменениях.
Кейс: до и после — отказы, отклик, нагрузка
Проект — поставщик промышленного оборудования: 250–300 обращений в месяц, отдел из пяти менеджеров, вся работа с клиентом в Битрикс24. Рассылки висели на событии «создан лид» и не учитывали возврат клиента: человек с уже открытой сделкой получал письмо первого касания повторно, а отписавшиеся оставались в выборке. Доля отказов писем держалась около 17%, и почтовые провайдеры всё чаще отправляли поток в спам целиком.
Что ломалось до правок
- Триггер срабатывал на создание сущности, а не на смену стадии — при повторном обращении письма дублировались.
- Отписки попадали в журнал, но не исключались из будущих выборок.
- После автоответа заявка ложилась в общий список без ответственного: клиент ждал живого менеджера 5–6 часов.
Что изменили и что стало
Условие срабатывания перенесли на смену стадии и появление нового канала обращения, перед отправкой добавили проверку по базе. Отписки и закрытые сделки вынесли в отдельный список исключений, потоки сервисных и маркетинговых сообщений разделили с разными подписями домена. Для новых заявок настроили эскалацию: не взял менеджер в течение 15 минут — уведомление уходит руководителю и переадресуется свободному.
Доля неудачных отправок упала с 17% до 2–3%, жалобы на спам практически исчезли, а среднее время обработки заявки сократилось с 5–6 часов до 25–30 минут. Ручная отправка — около 40 сообщений в день — ушла в триггеры полностью: каждый менеджер освободил почти два часа на звонки и подбор оборудования.
Что делать, если часть сценариев уже настроена вручную
Начинаем с инвентаризации рассылок: выгружаем все роботы, триггеры, автоматические правила CRM, шаблоны писем и бизнес-процессы, которые касаются сделок и лидов. По каждому правилу фиксируем условие запуска, аудиторию, канал и дату последней правки. Часто уже на этом этапе видно, что часть уже настроенных сценариев не срабатывала ни разу, а половина дублирует друг друга по одной и той же стадии.
Дубли и конфликты разбираем по эффекту: если по одной сделке уходит два письма с интервалом в минуту, клиент читает второе как навязчивость, а в карточке появляется ложная активность. Такие пары сводим в один сценарий с общим условием и одной точкой входа — вместо двух спорных правил остаётся одно предсказуемое.
Перенос ручных правил делаем без остановки продаж: старое правило не удаляем, а переводим в выключенное состояние, новый сценарий запускаем на теневом сегменте. Часть сделок идёт по новой логике, часть по прежней — сравниваем срабатывания и содержимое писем. Расхождение становится поводом доработать условие, а не отключать всё разом; откат — одно действие, прежнее правило включается обратно.
Дальше переключаем блоками, от стадии к стадии, с паузой на проверку выборки. Битрикс24 хранит историю изменений роботов, поэтому видно, кто и когда менял логику — при разборе конфликтов это экономит часы.
Частые сбои: спам, дубли, повторные касания
Триггерная рассылка в Битрикс24 ломается обычно не в конструкторе, а на границе с почтовым сервером и на повторных событиях. Заказчик видит симптом — письмо в спаме, два одинаковых письма подряд, повторное касание после возврата сделки назад — и делает вывод, что автоматизация не работает.
Почему письма уходят в спам, хотя текст не похож на рекламу?
Домен отправки не подтверждён: без записей SPF, DKIM и DMARC почтовые провайдеры не доверяют отправителю, даже если адрес корпоративный. Второй фактор — ограничения отправки: при резком старте с нового домена режут объём и частоту, поэтому задаём лимит писем в час, разводим потоки по поддоменам и прогреваем репутацию постепенно.
Клиент получает два письма подряд — это сбой или настройка?
Настройка. Триггер нередко висит и на создании элемента, и на изменении, а сделка за время работы меняет ответственного и поля. Ставим условие «статус изменился на нужный», добавляем служебное поле-флаг «письмо отправлено» и отсекаем повторы по идентификатору сделки.
Сделка вернулась на прошлый этап — письмо уйдёт повторно?
Да, если срабатывание идёт по текущему значению статуса: возврат и повторный переход запускают триггер заново — так и появляются дубли писем. Мы привязываем отправку к отметке времени последнего касания и ведём журнал шагов, поэтому откат статуса сделки не даёт дубля.
Перед запуском прогоняем сценарии на тестовом ящике: смену статуса, откат назад, повторное открытие сделки, смену ответственного — и сверяем журнал отправок с ожидаемой логикой.Обсудим задачу и вернёмся с планом работ
Чтобы оценка внедрения опиралась на факты, а не на предположения, разбор задачи начинаем с исходных данных. Созвон занимает около часа: смотрим структуру воронок, карточки сущностей и то, какие события портал уже фиксирует сам, а какие придётся добавлять.
Подготовить заранее стоит следующее — этого достаточно, чтобы мы вернулись с планом работ по рассылкам, а не с уточняющими вопросами:
- доступы к порталу с правами администратора и отдельный тестовый контур, если он уже заведён;
- перечень событий-источников: смена стадии сделки, брошенная заявка, просроченная задача, повторное обращение;
- сегменты и признаки, по которым делим контакты, — откуда берутся эти поля в карточке;
- каналы доставки: почта, мессенджеры, сообщения внутри портала;
- тексты писем и шаблоны либо логика, по которой их нужно собрать;
- ограничения по частоте: сколько сообщений в сутки допустимо одному контакту и в какие часы отправляем;
- внешние системы — 1С, телефония, сайт, склад: что уже связано и какими полями обменивается;
- метрики, по которым будете судить о результате: открытия, переходы, дошедшие до сделки.
Присылайте список в любом виде — таблицей, заметками или скриншотами карточек. Мы сверим его с текущей конфигурацией портала, покажем, какие данные уже есть, а какие придётся завести, и вернёмся с планом работ: этапы, порядок запуска, точки проверки. Логику прогоним на тестовом контуре, чтобы до включения на живых клиентах видеть, какие события срабатывают и что уходит в рассылку.
