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