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

Что это такое без маркетинга

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

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

Ключевое слово — «не является продажей». Именно на нём и происходит развилка, где чаще всего ошибаются.

Главная ошибка: смарт-процесс вместо стадии сделки

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

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

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

Вторая ошибка: смарт-процесс не связан со сделкой

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

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

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

Третья ошибка: перенесли согласование, но не автоматизировали

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

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

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

Права: отдельная сущность — отдельная матрица доступа

У смарт-процессов своя система прав, не наследующая настройки сделок. Про это забывают, и получается один из двух перекосов.

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

Разбирать права стоит сразу при создании сущности, а не после первой утечки или первой жалобы. Вопросов там три: кто видит чужие записи, кто может менять стадию, кто может удалять.

Отчётность: планировать заранее

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

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

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

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

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

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

Три «да» означают, что сущность действительно отдельная. Один-два — что вы усложняете там, где достаточно донастроить существующее.

Если смарт-процессы уже наплодили

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

Настройку бизнес-процессов и автоматизаций делаю отдельной работой — /uslugi/avtomatizaciya-biznes-processov/. Когда непонятно, с чего начинать, разумнее сначала посмотреть портал целиком: /uslugi/audit-bitrix24/.