Антон Дегтярёвсмарт-процессы в битрикс24: что это и когда они нужны
В 4 из 10 аудитов слышу один и тот же вопрос — «а зачем нам смарт-процесс, если есть сделки?». Отвечаю на 3 конкретных кейсах из практики — заявки на ремонт, согласование договоров, отпуска сотрудников. Ниже — где смарт-процесс реально экономит время, а где это лишняя сущность, которая только всё усложняет.
что такое смарт-процесс простыми словами
Смарт-процесс — это отдельная сущность в Битрикс24 с собственными стадиями, полями и правами доступа, которая живёт не в модуле CRM (лиды, сделки, контакты), а в разделе «CRM-формы» или в блоке автоматизации. По структуре она похожа на сделку: та же канбан-доска, те же стадии слева направо, те же роботы на переходах между статусами. Разница — в назначении. Сделка всегда о продаже: там есть сумма, воронка, контакт-плательщик. Смарт-процесс — универсальная обёртка под любой процесс без привязки к продаже: заявка на отпуск, заказ пропуска, согласование договора, тикет в техподдержку.
На моих проектах смарт-процесс чаще всего называют «второй CRM внутри Битрикс24» — и это довольно точное определение. Вы получаете полноценный трекер объектов со своей воронкой, но без коммерческой логики сделок.
Частый вопрос на аудите — «а нельзя просто добавить поля в сделку и не городить огород?». Технически можно, но тогда в одной воронке смешиваются продажи и сервис: отчёт по конверсии в продажу засоряется заявками на ремонт, а фильтры и права доступа приходится городить костылями. Смарт-процесс с самого начала разделяет эти два потока данных — и отчётность по каждому остаётся чистой.
когда смарт-процесс — правильный инструмент
Смарт-процесс нужен, когда у вас есть повторяющийся поток однотипных объектов, которые проходят через несколько стадий, и у каждого объекта — свой набор полей, не похожий на поля сделки. Три признака, что вам подходит именно смарт-процесс, а не бизнес-процесс (БП) или доработка сделки:
1) Объектов много и они однотипны — заявки на ремонт, договоры на согласование, обращения в поддержку. 2) Нужна визуальная канбан-доска по стадиям, а не просто линейная цепочка действий. 3) Разным ролям нужен разный доступ — например, юрист видит только «на согласовании», а бухгалтер — только «на оплате».
Если объектов немного (до 5–10 в месяц) — обычно хватает доработанной сделки с дополнительными полями. Смарт-процесс окупается, когда поток стабильный и превышает 15–20 объектов в месяц на процесс.
из чего состоит смарт-процесс
Три обязательных элемента: стадии (статусы, через которые движется объект — их задаёте сами, обычно 4–7 штук), поля (произвольный набор — текст, список, дата, привязка к сотруднику или контрагенту), роботы (автоматические действия на входе в стадию или по условию — назначить ответственного, отправить уведомление, создать задачу, изменить поле).
Дополнительно можно подключить: SLA (контроль сроков — сколько объект может находиться в стадии, прежде чем сработает эскалация), права доступа по ролям, вебхуки для интеграции с внешними системами, CRM-форму для приёма заявок с сайта напрямую в процесс.
три сценария из моей практики
Заявки на сервисное обслуживание. У клиента с оборудованием на гарантии — до 40 заявок в месяц. Стадии: «принята» → «диагностика» → «ожидание запчасти» → «в работе» → «закрыта». Робот на входе в «ожидание запчасти» ставит задачу снабженцу и шлёт уведомление клиенту. Среднее время закрытия заявки упало с 9 до 5 дней — просто потому, что этапы стали видимыми, а не терялись в почте.
Согласование договоров. Юротдел получает 15–20 договоров в месяц на визирование. Стадии: «получен» → «на проверке юриста» → «правки» → «на подписи» → «подписан». Каждая стадия — с ответственным и SLA 2 рабочих дня. Раньше договор мог «зависнуть» на 3 недели без единого напоминания — теперь при просрочке стадии руководитель получает уведомление автоматически.
HR-заявки на отпуск и больничный. Стадии: «подана» → «согласование руководителем» → «согласование HR» → «одобрена». Робот при подаче создаёт задачу непосредственному руководителю с дедлайном 1 день. Раньше HR вёл это в отдельной таблице — сейчас всё в одном интерфейсе с историей.
Во всех трёх кейсах эффект одинаковый: не сама автоматизация экономит время, а то, что статус объекта становится видимым всем участникам процесса одновременно. Руководитель больше не спрашивает «на каком этапе договор» — он открывает канбан и видит это сам.
как я настраиваю смарт-процесс — по шагам
Шаг 1 — фиксирую реальные стадии процесса на созвоне с заказчиком, а не придумываю их сам. Обычно получается 5–7 стадий после первой итерации, потом сокращаем до 4–5 — лишние стадии только замедляют работу.
Шаг 2 — проектирую поля: что обязательно на входе (заявитель, тип запроса, срочность), что заполняется по ходу (комментарий исполнителя, дата закрытия), что скрыто от части ролей.
Шаг 3 — настраиваю роботов на переходах между стадиями: уведомления, автоназначение ответственного, создание связанных задач.
Шаг 4 — включаю SLA на критичных стадиях, чтобы просрочки были видны руководителю, а не терялись.
Шаг 5 — тестирую на 10–15 реальных объектах перед тем, как переводить всю команду, — это экономит минимум неделю переделок.
типичные ошибки при настройке
Слишком много стадий с самого начала — команда путается, где искать объект, и часть заявок «залипает» без движения. Начинайте с 4–5 стадий, добавляйте по мере необходимости.
Смарт-процесс без ответственных на каждой стадии — тогда объект просто лежит, и никто не отвечает за просрочку. Ответственный должен быть назначен автоматически роботом, а не «по умолчанию на менеджера».
Копирование полей сделки один в один — в смарт-процессе часто нужны совсем другие поля, а лишние поля из CRM только загромождают карточку и путают сотрудников.
Отсутствие связи с задачами — если по объекту нужно реальное действие исполнителя (не просто смена статуса), а робот не создаёт задачу, процесс выглядит формальным и его быстро забрасывают.
Запуск сразу на всю компанию без пилота — если протестировать смарт-процесс на 5–10 реальных объектах перед общим переходом, вылезающие недочёты (не хватает поля, стадия лишняя) чинятся за час. Без пилота их находят уже после того, как половина команды успела завести объекты неправильно, и переделка занимает в разы дольше.
смарт-процесс или обычный бизнес-процесс — что выбрать
Бизнес-процесс (БП) — это линейная последовательность автоматических действий без визуальной канбан-доски: подходит для внутренних сценариев без большого потока объектов, например разовое согласование командировки. Подробно о настройке БП я разбирал в статье про бизнес-процессы в Битрикс24.
Смарт-процесс — когда объектов много, нужна визуальная доска и разным ролям — разный доступ. Если сомневаетесь — начните с БП: он проще и быстрее в настройке. Переходите на смарт-процесс, когда поток вырос и линейный БП стал неудобным для отслеживания статусов вручную.
сколько это стоит и сколько занимает по времени
Настройка простого смарт-процесса (4–5 стадий, до 10 полей, 3–5 роботов) занимает у меня 1–2 рабочих дня вместе с тестированием на реальных данных заказчика. Процесс со сложной логикой — SLA, интеграция с внешней системой через вебхук, права доступа по ролям — от 3 до 5 дней.
Отдельно закладываю время на обучение команды: 30–40 минут демонстрации плюс неделя сопровождения, пока сотрудники не привыкнут искать заявки в новом интерфейсе вместо почты или мессенджера. Именно на этой неделе чаще всего всплывают недостающие поля и стадии — и их проще донастроить сразу, чем откладывать.
Если у вас уже настроены роботы и триггеры на сделках, часть логики можно переиспользовать — я разбирал рабочие сценарии в статье про роботов и триггеры Битрикс24. А если процесс связан с приёмом заявок и их дальнейшей квалификацией, полезно посмотреть на правила квалификации лидов — логика стадий там пересекается со смарт-процессами.
как контролировать эффективность процесса после запуска
Смарт-процесс без отчётности превращается в свалку карточек — стадии есть, а понять, где узкое место, невозможно на глаз. Я вывожу три отчёта на первый месяц: среднее время в каждой стадии (показывает, где объекты застревают), количество просроченных SLA по ответственным (кто не успевает, а не «команда в целом»), количество объектов, закрытых без итогового статуса «успешно» (брак процесса — например, заявка закрыта как «отменена клиентом» слишком часто, значит на входе плохо квалифицируют).
Через месяц смотрю на эти цифры вместе с заказчиком и донастраиваю: если стадия «согласование» стабильно держит объект дольше 3 дней при SLA в 2 — либо ответственный перегружен, либо стадию нужно дробить на две. Без этой сверки смарт-процесс работает, но не улучшается — а именно в улучшении по факту и есть смысл его внедрения, а не просто в переносе бумажного процесса в интерфейс.