Роботы и триггеры Битрикс24: механика автоматизации потока сделок и источники дублей задач

Ручная обработка входящих: где поток сделок теряет деньги

Начну с масштаба ручной работы, которую автоматизация вообще призвана закрыть. По внешним разборам, до 58% компаний не отвечают на входящие заявки, а средняя скорость реакции измеряется десятками часов — порядка 42 и больше. Это оплаченный трафик, за который уже заплачено на этапе рекламы, но по нему никто не позвонил.

Скорость первого касания прямо влияет на то, доведёте ли вы заявку до квалификации. В том же англоязычном разборе ответ в течение 5 минут повышает шанс квалифицировать обращение примерно в 21 раз против ответа через 30 минут. Цифры взяты из зарубежного материала, и переносить их на российский рынок один в один я бы не стал — применимость нужно проверять локальными замерами. Но направление зависимости понятное: чем дольше заявка ждёт менеджера, тем дешевле она стоит на выходе.

Именно здесь автоматическое распределение заявок роботом и триггером снимает ручную задержку: заявка попадает на ответственного и получает первое действие без ожидания, пока кто-то откроет вкладку. Дальше — механика, как это устроено в Битрикс24.

Робот на стадии и триггер на событие

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

Любая автоматизация в CRM раскладывается на три части: событие, условие-фильтр и действие. Событие — заявка, смена стадии, звонок. Условие — правило, при котором мы вообще что-то делаем. Действие — назначить ответственного, поставить задачу, обновить поле, отправить письмо. Когда связка условие↔действие настроена неаккуратно, робот выполняет действие там, где не должен, — это типовая причина «лишних» срабатываний, которые потом кто-то руками разгребает.

Цепочки роботов: порядок, момент и условие срабатывания

В Битрикс24 у цепочки роботов три управляющих параметра, и от них зависит, будет поток предсказуемым или нет.

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

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

Откуда берутся дубли задач

Теперь к тому, почему аккуратно собранная автоматизация начинает плодить дубли. Механизмов три, и все они про порядок и момент.

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

Второй — создание сделки через вебхук с внешней формы или интеграции. Поля заполняются постепенно, и робот успевает сработать раньше, чем условие выполнилось. Результат — робот либо не запускается, либо ставит лишнюю задачу по неполным данным. Рекомендованное решение — задержка выполнения около 10 минут, чтобы поля успели дозаполниться до проверки условия.

Третий — правка автоматизации на ходу. Уже запущенные элементы продолжают идти по старому сценарию, потому что процесс использует настройки на момент запуска. Вы поправили логику, а сделки, которые вошли в воронку раньше, ведут себя по-прежнему. Лечится это завершением активного процесса и повторным запуском. Пропустишь шаг — получишь смесь старого и нового поведения на одной воронке.

Здесь же полезно отделять дубли задач от дублей клиентов: это разные проблемы с разными причинами, и решать их надо по отдельности. Если у вас параллельно болит вопрос дублей контактов и компаний, я разбирал его в материале про перенос данных в Битрикс24 без дублей.

Отладка и контроль срабатывания

Битрикс24 показывает статус каждого робота цветом, и это первый инструмент диагностики. Зелёный — выполнен, красный — ошибка, белый круг — ожидание, белый без иконки — не сработал. По этой раскраске видно, где цепочка встала, без чтения логов построчно.

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

Что автоматизация даёт потоку сделок

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

Цена промедления считается по тем же внешним разборам: после 60 минут вероятность дозвониться падает почти в 10 раз, а реакция в первую минуту связана с заметным ростом конверсии. Быстрая автоматическая реакция удерживает заявку на той стороне зависимости, где она ещё конвертируется. Упорядоченные цепочки и контроль повторного срабатывания сохраняют это преимущество: без них дубли задач возвращают ручную разборку и съедают выигрыш от скорости.

Когда автоматизацию нужно вынести за пределы стандартной сделки — под сервис, отгрузку, согласование — работают уже смарт-процессы; где они помогают и где ломают отчётность, я разбирал в отдельной статье про смарт-процессы Битрикс24.

Если нужно собрать роботов и триггеры так, чтобы они ускоряли поток сделок и не плодили дубли задач, это делается на этапе внедрения Битрикс24 — с упорядоченными цепочками, корректными условиями и проверкой на отладчике до выхода на боевые сделки. Как Бизнес-партнер 1С-Битрикс я собираю автоматизацию именно от логики потока, а не от количества роботов на стадии.