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


