Роботы или бизнес-процессы в Битрикс24: что выбрать

Роботы и бизнес-процессы Битрикс24 решают разные части задачи автоматизации. Робот удобен, когда сделка достигла конкретной стадии и нужно поставить задачу, отправить уведомление или изменить данные. Триггер наблюдает за событием, например оплатой, и может переместить элемент на другую стадию. Бизнес-процесс описывает более длинный маршрут с участниками, условиями, ожиданием решения и журналом действий.

Официальная справка по автоматизации продаж показывает, что настройка роботов и триггеров идёт в CRM на уровне стадий. Она же предупреждает: после редактирования робота в дизайнере бизнес-процессов или добавления недоступного в интерфейсе действия последующие изменения могут потребовать работы уже в дизайнере. Поэтому выбор инструмента — ещё и выбор того, кто сможет поддерживать сценарий через полгода.

Робот, триггер и бизнес-процесс: роли

Представьте сделку «Согласование КП». Робот может поставить менеджеру задачу с дедлайном и отправить клиенту письмо. Триггер может отследить заданное событие и перевести сделку дальше. Бизнес-процесс может последовательно запросить согласование скидки у руководителя, затем проверку условий у финансовой команды и только после положительных решений создать документ. Это разные виды логики, хотя в интерфейсе они могут соседствовать.

В справке Битрикс24 о триггерах указано, что они отслеживают действия клиентов и изменения в CRM и переводят элемент на стадию. Доступность конкретных инструментов зависит от тарифа и настроек. Перед проектом проверьте их в вашем портале, а не переносите схему из другого аккаунта без тестирования.

Матрица выбора: сложность против поддержки

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

Но и бизнес-процесс не следует применять к каждому уведомлению. Лишний шаблон создаёт больше точек отказа и требует администратора, который знает его устройство. Граница может проходить посередине: короткие действия на стадиях оставляют роботам, а отдельный процесс запускают только при необходимости согласования. Такая схема должна иметь явный вход и выход.

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

Четыре типичных сценария

Новая сделка требует реакции

Робот создаёт задачу владельцу и напоминает о сроке. Если клиент оплатил счёт, триггер переводит сделку на следующую стадию. Срок ответа клиенту лучше измерять отдельным SLA, не смешивая его со сроком самой задачи.

Скидка выше внутреннего порога

Сделка должна пройти согласование. Руководитель видит причину скидки, сумму и условия. При отказе менеджер получает задачу на исправление; при утверждении следующий участник готовит документ. Это кандидат для бизнес-процесса, потому что важны решения людей и маршрут возврата.

Регулярная проверка просроченных задач

Если нужна простая реакция на стадию или срок, достаточно робота и отчёта. Если процесс включает подбор замещающего сотрудника, разные правила по отделам и подтверждение руководителя, оцените отдельный бизнес-процесс. Не вводите сложность, пока не описали исключения на бумаге.

Работа со смарт-процессом

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

Что проверять в документации до запуска

Автозапуск бизнес-процесса можно настроить при добавлении или изменении элемента CRM, но у него есть важные исключения. По справке Битрикс24 создание через импорт CSV/XLS или другим бизнес-процессом не запускает такой шаблон автоматически. Это особенно важно для миграции данных и цепочки процессов. Не проектируйте критичный шаг, пока не проверили его на тестовой карточке, созданной тем же способом, что и в производстве.

Проверьте тариф, права администратора и сотрудников, доступные действия, временные зоны и ограничения интеграций. Некоторые роботы обращаются к внешним сервисам или создают документы; ошибки внешнего сервиса не должны оставлять сделку в состоянии «готово», если обязательное действие не выполнено. Для критичных операций нужен способ увидеть отказ и повторить действие без дубля.

Проектирование процесса до кликов в интерфейсе

Опишите карточку сценария на одной странице: событие запуска, входные поля, условия, владелец, действие, результат, исключение и способ проверки. Укажите, что произойдёт при повторном входе на стадию или повторном изменении поля. Если робот отправляет документ клиенту, повторный запуск может создать второй экземпляр; предусмотрите признак уже выполненного действия.

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

Составьте схему зависимостей. Два робота, меняющих одно поле, или робот и процесс, меняющие стадию друг за другом, могут создать цикл. Граница ответственности должна быть явной: например, бизнес-процесс записывает утверждённый статус, а робот только отправляет уведомление при этом статусе. Не дублируйте одни и те же действия «на всякий случай».

Безопасный порядок внедрения

1. Базовая схемаСогласовать стадии, входные поля и роли с владельцем процесса.
2. Тестовый контурПроверить обычный путь, отказ, повторный запуск и отсутствие участника.
3. ПраваПроверить действия от имени реальных сотрудников, а не только администратора.
4. Ограниченный запускВключить сценарий на небольшой группе элементов и собрать ошибки.
5. КонтрольНазначить ответственного за журнал, задержки и изменения правил.

При проверке используйте конкретные тестовые карточки, а не только «сценарий сохранился». Создайте сделку вручную, через форму и через интеграцию, если все эти входы есть в жизни. Пройдите как положительный, так и отрицательный маршрут. Если клиентское сообщение или документ реально отправляется наружу, тестируйте на безопасных адресах и номерах.

Как понять, что автоматизация помогает

Смотрите длительность этапов, долю процессов с просроченным согласованием, число ручных исправлений, повторные отправки и случаи, когда карточка осталась без владельца. Одного подсчёта сработавших роботов недостаточно: робот может работать без ошибок, но создавать ненужные задачи. Соберите обратную связь менеджеров через две–четыре недели после запуска.

Меняйте правила версионированно: что именно изменилось, кто согласовал и как проверить результат. В крупных схемах полезна карта автоматизаций по стадиям и объектам CRM. Она предотвращает ситуацию, когда новый робот добавляют поверх старого, потому что никто не помнит, где скрыта прежняя логика. Про общую организацию процессов можно прочитать в статье о смарт-процессах Битрикс24.

Ошибки, которые дорого обходятся

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