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