Автоматизация в Битрикс24: роботы и бизнес-процессы отдела продаж
После запуска CRM хочется переложить на систему все повторяющиеся действия: задачи, письма, передачу заказа, согласование предложения. Но сначала надо ответить на другой вопрос: какое событие действительно требует действия и кто разбирает исключение. Если отдел ещё спорит, когда сделка готова к передаче, робот только быстрее воспроизведёт этот спор в карточках.
Автоматизация в Битрикс24 строится на роботах, триггерах и бизнес-процессах. Робот выполняет действие на стадии CRM, триггер отслеживает событие и переводит элемент на стадию, а бизнес-процесс позволяет организовать последовательность действий и согласований. Выбор зависит от задачи, условий запуска и участия людей. Ниже разберём, как выбрать небольшой рабочий сценарий, настроить правила и принять результат.
Робот, триггер или бизнес-процесс
Роботы подходят для повторяющихся действий, привязанных к стадии: создать задачу, подготовить документ, отправить письмо. У них есть настройки времени, очереди и условий. Поэтому наличие проверки поля само по себе не означает, что нужен дизайнер бизнес-процессов. Сначала посмотрите, можно ли выразить правило доступными настройками конкретного робота.
Триггер решает другую задачу. Он отслеживает событие, например изменение данных или действие клиента, и меняет стадию. Дальше на новой стадии может работать робот. Событие и действие удобно описывать отдельно: «что произошло» и «что теперь должна сделать система». Иначе в одну длинную настройку попадут разные причины перехода и разные результаты.
Бизнес-процесс нужен, когда важен управляемый маршрут: получить решение сотрудника, дождаться результата, продолжить по соответствующей ветке. Но слово «сложный» не критерий выбора. Сценарий из нескольких роботов тоже может быть сложным для сопровождения. Сравнивайте прозрачность правила, доступные действия, права и способ проверки, а не количество блоков на схеме.
| Задача | Что рассмотреть | Что проверить |
|---|---|---|
| Действие при переходе на стадию | Робот | Очередь, время, условие и поля действия |
| Переход после события | Триггер | Какое событие отслеживается и куда переводится элемент |
| Согласование с участием человека | Бизнес-процесс | Кто принимает решение и что происходит при отказе |
| Передача сделки в другую воронку | Туннель продаж | Копирование или перемещение и новый ответственный |
| Нестандартный учёт работы | Смарт-процесс | Нужна ли отдельная сущность, а не ещё одна стадия |
Передачу между воронками отдельно разбирает статья про туннели продаж. Если работа вообще не укладывается в обычную сделку, полезнее изучить смарт-процессы Битрикс24. Эти инструменты дополняют автоматизацию, но не отменяют необходимость описать результат.
Не переносите названия и ограничения из другой CRM по памяти. Например, статья про роботов в amoCRM относится к другой платформе. Даже похожее действие может иметь другой порядок запуска, набор параметров или зависимость от подключённого канала.
Что описать до настройки
Возьмите одно действие, которое сотрудники повторяют и могут объяснить одинаково. Запишите его обычными словами. Например: «После подтверждения состава заказа ответственный получает задачу подготовить предложение; в задаче указан срок и ссылка на сделку». Если менеджеры называют разные условия готовности заказа, сначала согласуйте их.
Для такого правила нужен небольшой паспорт. Он помогает обнаружить пробелы до того, как в карточках появятся лишние задачи. Особенно важны источник данных и исключение. Поле «дата доставки» нельзя подставлять в сообщение, если его ещё никто не заполнил. Уведомление о проблеме тоже бесполезно, если получатель не отвечает за её устранение.
Отдельно определите, что считается выполнением. Факт создания задачи ещё не означает, что менеджер подготовил предложение. Факт отправки письма не подтверждает, что клиент его получил и прочитал. Автоматизацию принимают по тому действию, которое она действительно выполняет, а дальнейший результат остаётся частью процесса продаж.
| Пункт | Что записать | Зачем это нужно |
|---|---|---|
| Событие | Переход на согласованную стадию | Отделить запуск от действий сотрудника |
| Условие | Какие поля уже должны быть заполнены | Не запускать действие на неполных данных |
| Действие | Какую задачу или документ создать | Согласовать видимый результат |
| Ответственный | Кто выполняет и кто принимает исключение | Не оставить уведомление без владельца |
| Время | Сразу, после действия или в нужный момент | Не смешивать срок задачи и время запуска |
| Повторный вход | Что делать при возвращении на стадию | Заранее обсудить повторные действия |
| Приёмка | Какая тестовая карточка и результат нужны | Проверить правило одинаково всеми участниками |
Паспорт не должен превращаться в техническую документацию на десятки страниц. Для небольшого сценария достаточно понятного описания и нескольких тестов. Важно, чтобы руководитель мог прочитать правило и понять, почему действие появится именно в этой сделке.
Если стадии обозначают действия вроде «позвонить» и «написать», а не состояние продажи, настройка может оказаться неудобной. Начните с этапов сделки в CRM. Правила запуска легче проверять, когда стадия имеет однозначный смысл. Приоритеты всей очереди автоматизаций описаны в статье что автоматизировать первым.
Три сценария для отдела продаж
Рассмотрим условные примеры. Они показывают логику проектирования и не являются описанием проекта клиента. Доступность конкретного робота, полей и канала проверяется в вашем Битрикс24.
Первый сценарий - задача на подготовку предложения. Сделка попадает на стадию, где состав заказа уже подтверждён. Робот создаёт задачу с понятным названием, ответственным и сроком. Менеджеру не надо вспоминать, какой следующий шаг предусмотрен регламентом. Но он по-прежнему проверяет содержание предложения и договаривается с клиентом.
Второй сценарий - сообщение после согласованного события. Например, после перехода заказа к доставке нужно сообщить клиенту дальнейший порядок работы. Прежде чем выбирать робота, проверьте, откуда берутся адрес, способ связи и согласованный срок. Если часть данных отсутствует, лучше определить отдельный путь для уточнения, чем отправить шаблон с пустыми значениями.
Третий сценарий - согласование нестандартных условий. Менеджер передаёт руководителю предложение и основание отклонения от обычного порядка. Процесс должен различать одобрение, отказ и запрос уточнений. У сотрудника должно быть понятное действие после каждого решения. Просто уведомить руководителя и продолжить сделку автоматически - другой сценарий, который не подтверждает согласование.
| Сценарий | Результат системы | Участие человека | Исключение |
|---|---|---|---|
| Подготовка предложения | Создана задача с нужной ссылкой | Менеджер готовит и проверяет предложение | Не определён исполнитель или срок |
| Сообщение о следующем шаге | Выполнено настроенное действие отправки | Менеджер проверяет актуальность условий | Нет контакта либо поля для шаблона |
| Согласование условий | Зафиксировано движение по маршруту | Руководитель принимает решение | Отказ, уточнение, отсутствие согласующего |
Для каждого примера сначала проверьте одну карточку вручную. Если сотрудники не могут пройти её по правилам без автоматизации, рано собирать цепочку. Вручную проще увидеть, какое поле появляется позже, кто реально принимает решение и где нужен возврат.
Не включайте сразу все действия на всех стадиях. При небольшом изменении легче установить причину ошибки и объяснить команде новую работу. Следующее правило добавляют после того, как текущий сценарий понятен участникам и подтверждён приёмкой. Это порядок внедрения, а не обещание определённого срока или роста продаж.
Как настроить запуск и проверить результат
Для настройки роботов откройте нужный элемент CRM и вкладку «Роботы». Выберите стадию и подходящее действие. Общие параметры роботов включают очередь, время и условия выполнения; остальные параметры зависят от действия. Названия отдельных полей сверяйте со справкой и интерфейсом своего портала.
Очередь определяет, должен ли робот ждать предыдущие действия или работать независимо. Если следующий шаг использует результат предыдущего, это надо учесть в последовательности. Например, получать данные созданной задачи имеет смысл после её создания. Само расположение блоков рядом ещё не заменяет проверку зависимостей.
Время запуска и крайний срок задачи - разные настройки. Один параметр определяет, когда система начнёт действие, другой - когда сотрудник должен закончить работу. Если перепутать их, задача может появиться слишком поздно. Проверяйте оба значения на тестовой карточке, а не только текст названия робота.
Условия описывают, в каких карточках требуется действие. Предварительно заполните тестовые поля и проверьте два случая: условие выполнено и не выполнено. Особое внимание уделите пустому полю. Оно может означать отсутствие данных, а не отрицательный ответ. Как именно конкретное условие обрабатывает пустое значение, устанавливают проверкой настройки.
После сохранения откройте карточку элемента и вкладку «Роботы»: там можно проверить статус выполнения. Сопоставьте статус с реальным результатом: появилась ли нужная задача, заполнено ли поле, назначен ли правильный сотрудник. Если действие обращается к внешнему каналу, отдельно проверяйте доступность подключения и результат на его стороне.
Для бизнес-процесса согласуйте шаблон, параметры, переменные и константы. Например, согласующего можно задавать в настройках, но порядок замены отсутствующего руководителя должен быть понятен людям. Настройка шаблонов в CRM доступна администраторам и сотрудникам с соответствующим правом изменения настроек CRM.
Роботы и бизнес-процессы доступны не на всех тарифах. Не выбирайте план только по наличию раздела: проверьте нужные действия и ограничения под конкретный сценарий. Если робот был изменён в дизайнере бизнес-процессов или туда добавили действие, отсутствующее в интерфейсе роботов, дальнейшее редактирование выполняют в дизайнере. Это важно записать для сопровождающего специалиста.
Условия меняются - перед работой сверяйте со справкой разработчика.
Как испытать исключения и повторный вход
Успешная тестовая сделка показывает только основной маршрут. Перед рабочим запуском проверьте случаи, которые сотрудники встречают без идеального набора данных. Именно здесь становится ясно, поможет правило или создаст ещё одну очередь проблем.
Повторный переход на стадию заслуживает отдельного теста. Сделку могут вернуть на уточнение и снова перевести вперёд. Не предполагайте, что действие автоматически выполнится только один раз. Запишите желаемое поведение и проверьте его: повторить задачу, использовать прежнюю, пропустить действие или передать решение человеку. Способ реализации зависит от доступных действий и данных.
Также проверьте изменение поля после запуска. Правило могло использовать значение, которое было актуально в момент выполнения. Автоматическая синхронизация уже созданного документа или отправленного сообщения не следует из самого наличия робота. Если данные могут меняться, согласуйте порядок исправления результата.
| Случай | Ожидаемый результат | Что зафиксировать |
|---|---|---|
| Условие выполнено | Нужное действие выполнено | Карточка, статус, созданный объект |
| Условие не выполнено | Действие не выполняется | Поля и причина выбора ветки |
| Обязательное поле пустое | Согласованный путь уточнения | Кто получает проблему |
| Возврат и повторный вход | Поведение соответствует правилу | Повторился ли объект и почему |
| Исполнитель недоступен | Есть понятный порядок передачи | Кто принимает исключение |
| Внешний канал не отвечает | Сбой обнаруживается владельцем | Где видна ошибка и как восстановить |
| Отказ согласующего | Сделка не выглядит одобренной | Следующий шаг менеджера |
После теста сохраните короткий протокол: что проверяли, какая карточка использовалась и где виден результат. Он пригодится при изменении стадии, поля или шаблона. Отметка «всё работает» без примера не помогает разобраться, если позже результат изменился.
Не удаляйте рабочие данные ради проверки. Для испытаний используйте согласованные тестовые карточки, отделите их от реальных обращений и отчётов. Сообщения клиентам при тестировании требуют отдельного контроля получателя: учебная проверка не должна выглядеть как рабочее уведомление покупателю.
Кто поддерживает автоматизацию после запуска
Автоматизация меняется вместе с регламентом. Переименовали стадию, изменили шаблон предложения, добавили новый отдел - проверьте связанные правила. Даже если настройка технически продолжает запускаться, её смысл может уже не соответствовать работе команды.
Владелец процесса отвечает за то, что правило нужно и понятно. Администратор или интегратор отвечает за согласованную настройку и разбор технических причин. Исполнитель проверяет рабочий результат, а руководитель разбирает исключения. Эти обязанности могут выполнять одни и те же люди, но сами задачи стоит назвать отдельно.
| Роль | Что делает | Когда подключается |
|---|---|---|
| Владелец процесса | Утверждает запуск, результат и исключения | До настройки и при изменении регламента |
| Администратор или интегратор | Настраивает, проверяет права и зависимости | При запуске, ошибке и изменении |
| Исполнитель | Проверяет задачу или документ в работе | На каждом предусмотренном шаге |
| Руководитель | Принимает спорное решение | При отказе, отсутствии данных или конфликте |
| Ответственный за приёмку | Сохраняет результаты тестов | Перед запуском и после значимых изменений |
Полезно вести перечень действующих правил: название, стадия, задача, владелец, зависимые поля и место редактирования. Такой перечень помогает не добавить вторую автоматизацию поверх первой. Он также показывает, какие действия уже не нужны после изменения процесса.
После запуска смотрите не на число роботов, а на использование результата. Созданные задачи должны читаться и завершаться по правилам, документы - проверяться, исключения - доходить до ответственного. Если сотрудники обходят действие вручную, выясните причину до расширения цепочки. Иногда следует изменить регламент, иногда - отключить лишнее правило.
Следующий шаг
Начните с одного устойчивого действия и сформулируйте его результат. Затем проверьте доступный инструмент, создайте тестовую карточку и пройдите основной маршрут вместе с исключениями. Только после этого распространяйте правило на рабочие сделки.
Если процесс пока неоднозначен, подойдёт диагностика отдела продаж. Если правила уже согласованы, можно обсудить автоматизацию продаж под конкретный сценарий. Когда требуется связать стадии, данные и обучение команды, задача входит в внедрение Битрикс24. У результата заранее определяют критерии приёмки, а затем проверяют работу сотрудников с новой настройкой.
Частые вопросы
Нужен ли программист для роботов?
Многие действия настраиваются в интерфейсе. Но доступность нужного сценария надо проверить: индивидуальная интеграция или нестандартная логика может требовать разработки. Сначала опишите задачу и данные, затем выбирайте способ реализации.
Любое условие требует бизнес-процесса?
Нет. У роботов тоже есть условия выполнения. Бизнес-процесс рассматривают, когда нужен соответствующий маршрут, набор действий и участие сотрудников, а не только проверка поля.
Чем триггер отличается от робота?
Триггер отслеживает событие и переводит элемент на стадию. Робот выполняет настроенное действие на стадии. Эти инструменты могут работать последовательно в одном сценарии.
Как понять, сработал ли робот?
Откройте карточку элемента CRM и вкладку «Роботы», проверьте статус. Затем сопоставьте его с реальным результатом: задачей, полем или документом. Одного названия правила для приёмки недостаточно.
Доступны ли роботы на любом тарифе?
Нет, доступность зависит от тарифа. Проверяйте конкретное действие и ограничения по официальной справке и своему порталу, прежде чем включать сценарий в план внедрения.
Почему настройки остались только в дизайнере?
После изменения робота в дизайнере бизнес-процессов или добавления отсутствующего в интерфейсе роботов действия дальнейшее редактирование производится в дизайнере. Зафиксируйте это в документации сценария.
Можно ли считать повторный запуск безопасным?
Поведение надо испытать на возврате сделки и повторном входе. Не предполагайте автоматическую защиту от повторной задачи или сообщения. Желаемый результат задают в правилах приёмки.
С чего начать, если автоматизаций уже много?
С перечня действующих правил и их владельцев. Выберите один проблемный маршрут, проверьте его данные, запуск и результат. Не добавляйте новые действия, пока причина текущего сбоя не понятна.
Источники
Внедрение Битрикс24 — как мы помогаем с этим на практике.
Читайте также
Термины из статьи
Поможем навести порядок в продажах
Начнём с диагностики: покажем, где теряются заявки и что даст CRM именно в вашем случае — без обещаний «роста в разы».