Смарт-процессы в Битрикс24: когда нужны и когда ломают отчётность

Смарт-процессы — инструмент Битрикс24, который чаще всего понимают неверно. Их заводят, когда стандартных сущностей CRM не хватает, и в заметной доле порталов, которые мы смотрим на аудитах, получают разорванную воронку: конверсия от заявки до денег перестаёт считаться одним отчётом.

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

Что такое смарт-процесс

В CRM Битрикс24 есть четыре стандартные сущности: лид, сделка, контакт и компания. Смарт-процесс — собственная пятая, шестая и следующие сущности компании: со своими полями, своей воронкой стадий, своими правами и своей автоматизацией. Выглядит он так же, как сделки, — канбан, список, карточка — и ведёт себя почти так же. Перед проектированием проверьте, что функция доступна на вашем портале.

Типичные применения: производственный заказ, рекламация, договор на согласовании, сервисная заявка, заявка на найм. Всё, у чего есть собственный жизненный цикл и что при этом к продаже не относится.

На условии «не продажа» и происходит развилка, где ошибаются чаще всего.

Три ошибки, которые ломают отчётность

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

Смарт-процесс вместо стадии сделки

Сценарий выглядит логично. В воронке продаж после стадии «Счёт выставлен» идёт производство: заказ надо изготовить, проверить и отгрузить. Производство — работа другого отдела, поэтому его выносят в отдельный смарт-процесс.

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

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

Смарт-процесс не связан со сделкой

Даже когда сущность выделена правильно, её часто забывают привязать. Смарт-процесс может ссылаться на сделку, компанию и контакт. Если связи нет, в портале появляется параллельная база.

Симптомы узнаваемые. Менеджер ищет по номеру заказа и не находит клиента. Руководитель не может ответить, сколько рекламаций пришло от клиентов одного рекламного канала. Любой отчёт упирается в то, что связать записи можно только вручную по названию, а названия у всех разные.

Связь ставится один раз при проектировании и почти не занимает времени. Восстанавливать её задним числом на нескольких тысячах записей — отдельная работа на дни.

Согласование перенесли, автоматику не настроили

Смарт-процессы часто заводят под согласования: договор, скидку, отпуск, закупку. Логика верная, у согласования свой цикл. Дальше настраивают стадии, раздают доступ и просят команду вести записи.

Через месяц на стадии «На согласовании» висят десятки записей: часть закрыта в переписке, часть забыта. Список без автоматики ведут ровно до тех пор, пока о нём помнят.

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

Как связать сделку и смарт-процесс роботами

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

Сделка доходит до стадии «Подписание договора», и робот «Создать элемент смарт-процесса» заводит договор в нужной воронке и на первой стадии. Название берётся из сделки, сумма копируется, ответственным назначается руководитель юристов, а опция «Связать с текущим элементом» ставит ссылку на сделку прямо в карточку договора. В карточке сделки договор появляется на своей вкладке. Следом робот «Изменить элемент» записывает ID нового договора в служебное поле сделки, его можно скрыть из карточки.

Дальше по этому ID работают остальные роботы. На стадии согласования робот «Получить информацию об элементе смарт-процесса» забирает из договора сумму и товары, и клиент получает письмо с актуальными данными. Сделка успешна — робот «Изменить элемент смарт-процесса» переводит договор в «Договор подписан». Сделка провалена — договор закрывается или удаляется вместе с ней. Искать элемент надёжнее по полю «ID»: по неуникальному значению робот возьмёт первый найденный элемент и может связать не тот договор.

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

Права и отчётность: решить до первых записей

У смарт-процесса своя матрица прав, которая не наследует настройки сделок. Если о ней забыть, получается один из двух перекосов. Доступ открыт всем, и рекламации или кадровые заявки видит весь отдел продаж. Или доступ закрыт так, что сотрудник, которому назначена запись, не может её открыть, и работа ждёт администратора. Решать стоит три вопроса: кто видит чужие записи, кто меняет стадию, кто удаляет. Как мы строим роли от структуры компании, описано в разборе прав доступа в Битрикс24.

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

Три вопроса перед созданием

Прежде чем заводить новую сущность, мы отвечаем на три вопроса.

• Есть ли у объекта собственный жизненный цикл, который не совпадает со сделкой? Может ли он начаться без сделки или продолжиться после её закрытия?
• Нужны ли ему свои права доступа, отличные от прав на сделки?
• Будет ли по нему отдельная отчётность, которая не сводится к отчёту по продажам?

Три «да» означают, что сущность отдельная. Если отрицательных ответов два или три, смарт-процесс не нужен: хватит стадии, поля или отдельной воронки сделок.

Как мы работаем со смарт-процессами

На аудитах частая картина — несколько смарт-процессов, из которых в работе половина, остальные заведены под задачи, которые давно решаются иначе. По одному их разбирать не стоит: смотрим структуру портала целиком и решаем, что вернуть в воронку сделки, что связать, что отключить. Начинать с этого удобно через аудит Битрикс24.

Новые сущности, связи, права и роботов на стадиях мы настраиваем в работах по доработке Битрикс24; если портал только собирается, структуру сущностей проектируем до первой настройки. Вход — бесплатный созвон, после него присылаем план; состав и стоимость — в смете после созвона.