В понедельник менеджер открывает Битрикс24 и видит новые задачи: позвонить клиенту, напомнить о расчёте, проверить оплату. Часть клиентов уже ответила. Один отказался вчера. По другой заявке коллега договорился о звонке на четверг.
Это условный пример CRM, в которой включили автоматические действия, но забыли описать, когда они больше не нужны. Начинать настройку роботов полезно с одного правила: что произошло, кому теперь действовать и при каком условии действие отменяется.
Как устроена связка робота и триггера
В Битрикс24 робот выполняет действие на определённой стадии: например, создаёт задачу или уведомляет сотрудника. Триггер отслеживает событие и может перевести элемент на связанную с ним стадию. Это базовое различие описано в официальной справке о роботах и триггерах.
Из этих возможностей можно собрать разные процессы. Доступность конкретных действий зависит от инструмента и тарифа, поэтому перед настройкой нужно сверить возможности своего портала. Ниже предложены рабочие сценарии, а не обещание готовых настроек для любой версии Битрикс24.
Сначала опишите один заказ без названий кнопок
Представим небольшую компанию по установке кондиционеров. Пришло обращение, администратор уточнил задачу, согласовал замер, подготовил расчёт и передал монтажникам подтверждённый заказ. У каждого перехода есть основание.
Для начала выберем самое первое действие. Правило может звучать так:
Когда новая заявка поступила в рабочее время и получила ответственного, создать задачу уточнить адрес объекта и требуемую услугу. Повторное получение той же заявки не создаёт ещё одну задачу.
До реализации остаётся решить, как назначается ответственный, что происходит после окончания рабочего дня и как распознаётся повтор. Эти вопросы определяют поведение автоматизации. Расположение кнопки в интерфейсе их не решает.
Пять сценариев, с которых можно выбрать первый
1. Новое обращение получает следующий шаг
В карточке есть ответственный и задача на первичный разбор. Если назначить сотрудника не удалось, обращение попадает в отдельный список для проверки, а руководитель видит исключение.
Проверьте, что повторный запрос с сайта не создаёт дубликат. Если заявки передаёт интеграция, защита от повторов должна быть предусмотрена и в ней. Само наличие робота этого не гарантирует.
2. Расчёт отправлен, контакт запланирован
После отправки расчёта сотрудник согласует с клиентом следующий контакт. Автоматизация может помочь поставить внутреннюю задачу на этот момент. Если клиент уже ответил, сотрудник должен увидеть актуальное действие, а старое напоминание требуется закрыть или отменить по принятому правилу.
Начните с внутренней задачи. Автоматическая рассылка клиентам требует отдельно решить, кому уместно писать, по какому каналу и когда переписку нужно остановить.
3. Сделка задержалась, но причина видна
Долгое пребывание на стадии может означать ожидание замера, согласованный перерыв или пропущенный шаг. Предлагаемое правило должно различать эти ситуации. Например, напоминать о сделке, у которой нет будущего согласованного действия.
Уведомление «Проверьте сделку» мало помогает. В задаче полезно указать, что выяснить: актуальность обращения, ожидаемый документ или причину переноса. Подготовить стадии и правила поможет разбор настройки Битрикс24 для небольшой команды.
4. Подтверждённый заказ передаётся исполнителю
Передача полезна, когда монтажник получает необходимые сведения: адрес, согласованный объём, время и контакт для организационных вопросов. Если обязательных данных нет, процесс должен показать, что нужно дополнить.
Переход по стадии сам по себе не подтверждает оплату или готовность выезда. Основания для передачи заказа нужно определить отдельно и проверять по надёжному источнику.
5. Отказ останавливает лишние действия
Когда клиент отказался, старые задачи на продажу могут стать неактуальными. Заранее определите, какие из них прекращаются, кто проверяет незавершённые обязательства и что сохраняется в истории.
Одного перемещения карточки может оказаться недостаточно, если задачи уже созданы или отложенное действие продолжает ждать запуска. В справке Битрикс24 есть отдельный разбор отключения роботов и действий бизнес-процессов. Поведение созданных задач и отложенных запусков проверяйте в своём сценарии.
Проверьте правило на неудобных случаях
До включения на рабочих клиентах создайте отдельный тестовый сценарий с условными данными. Уберите реальные адреса отправки и внешние действия, которые не входят в проверку. Затем пройдите путь целиком:
- Обращение пришло дважды. У него осталась одна актуальная задача.
- Ответственный отсутствует. Карточка видна тому, кто разберёт исключение.
- Клиент ответил раньше напоминания. Следующий шаг соответствует ответу.
- Сделку вернули на предыдущую стадию. Повторное действие объяснимо и не создаёт бесконечный цикл.
- Клиент отказался, пока напоминание ожидало запуска. Ненужный контакт остановлен.
Это критерии проверки предложенного процесса, а не описание штатного поведения любого робота. Часть правил может потребовать условий, отдельных полей, бизнес-процесса или доработки интеграции. Возможность реализации нужно подтвердить до запуска.
Оставьте сотруднику понятный способ вмешаться
Согласуйте, кто меняет правило, как временно останавливает его и где смотрит причину действия. После запуска возьмите несколько реальных карточек и проверьте их вместе с сотрудником: помогла ли задача сделать следующий шаг, что пришлось исправлять вручную, какие уведомления оказались лишними.
Счётчик срабатываний показывает активность механизма. Пользу лучше оценивать по тому, получают ли обращения нужный следующий шаг и не появилась ли у команды дополнительная работа по очистке дублей.
Для первого внедрения выберите одно повторяющееся действие. В работе с процессами и системами студия «дальше.» может разобрать его на реальном обезличенном примере: начало, ответственный, нужные данные, исключения и проверка результата. Такой разбор даст основание решить, достаточно ли штатного правила Битрикс24 или потребуется другой способ.
