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

Самый частый вопрос новичка в автоматизации Битрикс24 — «мне нужен робот или бизнес-процесс?». Ответ не в том, что один инструмент лучше другого, а в том, что они решают разные по природе задачи, и выбор не того инструмента для конкретной ситуации — самая частая причина, почему автоматизация в компании превращается в нагромождение полумер. Разберём разницу на уровне архитектуры, а не только интерфейса, и дадим чёткие критерии выбора.

Что технически представляет собой робот CRM

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

Что технически представляет собой бизнес-процесс

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

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

Пять признаков, что вам достаточно робота

Не усложняйте, если сценарий укладывается в простые правила: путь сделки линейный (одна воронка, без ветвления на типы клиентов), решение принимает один человек или не принимает никто (просто напоминание или уведомление), не требуется официальный лист согласования с историей, действие привязано к конкретной стадии конкретной сущности, а не к нескольким связанным сущностям одновременно, и логика умещается в 3-5 последовательных шагов. Пример: «когда сделка попадает на стадию Оплата ожидается, через 2 дня отправить клиенту напоминание по email, через 5 дней поставить менеджеру задачу позвонить» — классический робот, не нужен процесс.

Пять признаков, что нужен полноценный процесс

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

Пример неправильного выбора: когда пытаются натянуть робота на сложную задачу

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

Пример избыточного усложнения: когда простую задачу тащат в процесс

Обратная ситуация — компания настроила полноценный процесс из 12 блоков для напоминания клиентам о продлении подписки, включая условия по региону, менеджеру и сумме подписки, хотя по факту логика была одинаковой для 95% случаев: «за 14 дней до окончания подписки напомнить клиенту, за 3 дня — напомнить менеджеру». Итог — процесс тормозил при массовом запуске (сотни подписок одновременно), было сложно вносить простые правки (изменить текст письма занимало переоткрытие всей схемы), а реальной пользы от 12 блоков не было, потому что 11 из них никогда не срабатывали. Замена на два простых робота с условием по региону сократила время выполнения в разы и упростила поддержку.

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

Правило одного ветвления. Как только в сценарии появляется второе принципиальное ветвление по результату (не просто задержка по времени, а разные пути в зависимости от решения человека или значения поля), пересаживайтесь с роботов на конструктор процессов. Попытка выразить два и более ветвлений через комбинацию условий внутри робота почти всегда приводит к путанице и багам, которые тяжело диагностировать.

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

Курс школы: Пакет «Автоматизация»: роботы и бизнес-процессы в Битрикс24 — от 29 990 ₽

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

Да, и часто это оптимальный вариант — простые линейные части сценария (уведомления, задачи с задержкой) оставляют на роботах CRM, а сложную развилку (согласование скидки, привязка к производству, эскалация) выносят в отдельный бизнес-процесс, который запускается роботом или напрямую по условию на стадии. Такой гибридный подход снижает нагрузку на систему (процессы технически тяжелее роботов и расходуют больше ресурсов при массовом запуске) и облегчает поддержку — простое меняет обычный сотрудник в интерфейсе карточки, сложное трогает администратор в конструкторе.

Как оценить производительность и не перегрузить портал

При больших объёмах (тысячи сделок в месяц) стоит учитывать, что каждый активный экземпляр процесса потребляет ресурсы сервера, и слишком большое количество одновременно работающих сложных процессов может замедлять портал в целом. Роботы в этом смысле легче. Практическое правило — для массовых типовых операций (напоминания, обычные уведомления) использовать роботов, а полноценные процессы запускать точечно, только там, где реально нужна ветвящаяся логика с участием нескольких людей.

Смарт-процессы как третий инструмент

Отдельно от роботов и обычных бизнес-процессов на сделках стоит третий инструмент — смарт-процессы, то есть собственные пользовательские сущности со своей воронкой стадий, полями и правами доступа, не привязанные к стандартным CRM-объектам (сделка, лид, контакт). Их выбирают, когда предметная область не укладывается в готовую модель CRM: рекламации, заявки на закупку, кандидаты на вакансию, заказы на производство. Технически смарт-процесс поддерживает и роботов на своих стадиях, и полноценные бизнес-процессы конструктора — то есть это не альтернатива робото-процессному выбору, а отдельный вопрос о том, в какой сущности вести данные.

Как ошибка выбора инструмента накапливается со временем

Отдельная опасность неверного выбора в самом начале — она не проявляется сразу. Робот, натянутый на сценарий с реальным ветвлением, первые недели работает терпимо, потому что случаев с развилкой было немного и их разбирали вручную. Проблема нарастает постепенно: чем больше объём операций проходит через неподходящий инструмент, тем больше накапливается исключений, которые обрабатываются в обход системы, и тем сложнее оказывается впоследствии перенести логику на правильный инструмент — потому что к этому моменту уже накопилась историческая база данных в старой структуре, а сотрудники привыкли к текущим (кривым) обходным путям. Отсюда практический вывод — при малейшем сомнении, справится ли робот с сценарием на горизонте 6-12 месяцев роста объёма, разумнее сразу закладывать более гибкий инструмент, даже если сейчас хватило бы и простого.

Стоимость поддержки: ещё один критерий выбора

Помимо изначальной настройки, стоит учитывать разницу в стоимости последующей поддержки. Робота может подправить практически любой сотрудник с доступом к настройкам сделки — изменить текст уведомления, поменять задержку, добавить ещё одно действие занимает 5-10 минут без специальных навыков. Изменение полноценного процесса требует понимания всей блок-схемы целиком, потому что условия и переменные связаны между собой, и правка одного блока без понимания остальной логики нередко ломает соседние ветки. Если в компании нет постоянного администратора Битрикс24, а обслуживание отдано на аутсорс с оплатой за каждое обращение, это прямые деньги — лишний повод не плодить сложные процессы там, где хватило бы простого робота.

• Смарт-процесс — своя сущность и воронка для данных, которые не укладываются в готовую модель CRM
• Робот и конструктор процессов работают и внутри смарт-процессов, выбор между ними не меняется от типа сущности
• Ошибка выбора инструмента не проявляется сразу, а накапливается вместе с объёмом операций
• Стоимость поддержки процесса выше стоимости поддержки робота — учитывайте это при выборе, если нет штатного администратора

Итоговый ориентир для принятия решения

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