Как настроить смарт-процессы в Битрикс24 с нуля

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

Когда нужен смарт-процесс, а когда хватит сделки

Первый вопрос, который нужно себе задать: у этой сущности есть свой жизненный цикл, отличный от цикла продажи? Если да — нужен смарт-процесс. Пример: компания сдаёт в аренду строительное оборудование. Сделка на аренду закрывается в CRM, когда клиент подписал договор и внёс оплату. Но дальше начинается отдельный процесс — выдача оборудования, контроль срока возврата, приёмка после использования, выставление штрафа за просрочку. Это не стадии сделки, это отдельная сущность «Аренда» со своим жизненным циклом, который может пережить закрытие сделки и даже начаться заново с тем же клиентом много раз.

• Нужен отдельный жизненный цикл, не совпадающий со стадиями продажи — явный признак смарт-процесса
• Сущность может существовать без привязки к конкретной сделке — например, рекламация может прийти и через год после продажи
• Нужны специфичные поля и стадии, которые не имеют смысла для 90% обычных сделок компании
• Ожидается большое количество однотипных записей с чёткой структурой — заявки, наряды, тикеты, единицы техники

Создание смарт-процесса: пошагово

Раздел CRM → добавить раздел → «Смарт-процесс» → «Создать новый». На старте система попросит задать название в единственном и множественном числе (например, «Рекламация» / «Рекламации») — это влияет на все интерфейсные подписи, и менять название после того, как в процессе накопится сотня записей, неудобно, поэтому лучше сразу обсудить название с командой, которая будет с ним работать.

1. 1.Задайте название сущности в единственном и множественном числе и иконку раздела для визуального отличия от других смарт-процессов
2. 2.Настройте стадии жизненного цикла — обычно 5-7 стадий, не больше, иначе воронка становится нечитаемой
3. 3.Добавьте пользовательские поля: для рекламации это может быть «Номер заказа», «Причина обращения», «Категория дефекта», «Сумма компенсации»
4. 4.Настройте связи с другими сущностями CRM: привязку к сделке-источнику, контакту, компании
5. 5.Настройте права доступа отдельно от прав на сделки и лиды — они не наследуются автоматически
6. 6.Добавьте роботов и триггеры на ключевые стадии по аналогии с воронкой продаж

Пример: смарт-процесс «Наряды на выезд» для сервисной компании

Компания с 15 выездными мастерами настраивает смарт-процесс «Наряд» со стадиями: «Новый», «Назначен мастер», «В пути», «На объекте», «Работы завершены», «Закрыт клиентом», «Оплачен». Поля: «Адрес объекта», «Тип оборудования», «Мастер», «Плановое время визита», «Фактическое время начала и окончания работ». На стадии «Назначен мастер» настроен робот, отправляющий мастеру push-уведомление в мобильном приложении с адресом и временем визита. При переходе на стадию «На объекте» триггер фиксирует геолокацию через мобильное приложение, если мастер физически рядом с адресом — это не встроенная магия, а комбинация смарт-процесса с полем геометки и мобильным приложением, о которых мы говорим подробнее в статье про мобильный CRM для выездных сотрудников.

Стадии vs статусы: как не запутать логику

Частая ошибка на старте — пытаться уместить в стадии сразу два разных измерения: «этап работы» и «результат». Например, стадии «В работе», «Успешно», «Отказ», «Ожидание клиента» намешаны в одну линейную воронку, из-за чего непонятно, что было раньше — «Ожидание клиента» до отказа или после. Правильный подход: линейные стадии описывают только этап процесса («Новый» → «В работе» → «Завершён»), а финальный результат («Успех» / «Отказ» / «Отменён клиентом») выносится в отдельное поле-справочник или в две-три финальные стадии в конце воронки, а не перемешивается с промежуточными этапами.

Настройка карточки смарт-процесса под конкретную роль

По умолчанию карточка нового смарт-процесса показывает все добавленные поля подряд в том порядке, в котором их создавали, что неудобно для сотрудника, который работает с сущностью каждый день и вынужден прокручивать карточку в поисках нужного поля среди десятка второстепенных. Стоит потратить время на настройку детейл-формы: сгруппировать поля по смысловым блокам (например, «Информация о клиенте», «Технические детали», «Финансовая часть»), скрыть блоки, не нужные конкретной роли, и вынести самые часто используемые поля наверх карточки. Пять минут, потраченные на такую перестановку, экономят сотруднику реальные секунды при каждом открытии карточки, а за месяц работы с сотнями записей это превращается в заметную экономию времени всей команды.

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

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

Автоматизация внутри смарт-процесса

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

Курс школы: Роботы, триггеры и умные сценарии в Битрикс24 — от 14 990 ₽

Миграция данных: как перенести историю из сделок в новый смарт-процесс

Частая ситуация: компания полгода вела рекламации как отдельные сделки с пометкой в названии «РЕКЛАМАЦИЯ», а затем решила завести полноценный смарт-процесс — и встал вопрос, что делать с уже накопленными записями. Прямого автоматического переноса данных из сделок в смарт-процесс через интерфейс нет, поэтому перенос делается через выгрузку в таблицу (CRM → Сделки → Экспорт с нужным фильтром) и последующую загрузку в новый смарт-процесс через импорт с сопоставлением полей. Перед переносом стоит решить: переносить ли только открытые записи, оставив закрытые архивом в старых сделках, или переносить всю историю целиком — второе честнее для отчётности, но требует более аккуратного сопоставления полей, включая даты создания, чтобы не исказить статистику по срокам обработки за прошлые периоды.

Отчётность по смарт-процессам

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

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

Готовые шаблоны смарт-процессов и создание с нуля

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

Типичные ошибки при внедрении смарт-процессов

• Смарт-процесс создаётся как копия сделки «на всякий случай», без реального анализа, отличается ли жизненный цикл — в итоге получается вторая CRM внутри CRM с дублирующейся логикой
• Слишком много стадий, намешанных из этапов и результатов — воронка становится нечитаемой уже через месяц использования
• Права доступа не настроены отдельно и по умолчанию открыты всем сотрудникам компании, включая тех, кто не должен видеть, например, суммы компенсаций по рекламациям
• Связь с CRM-сущностями настроена технически, но не выведена на видимые вкладки карточек — сотрудники не пользуются данными, которые формально уже есть в системе
• Автоматизация настроена без предварительной схемы, из-за чего изменения в смежных модулях (склад, задачи) происходят непредсказуемо для команды
• Название сущности выбрано неудачно на старте и требует переименования после того, как накопились сотни записей и привычки сотрудников

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

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

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

Чек-лист запуска смарт-процесса

1. 1.Подтверждено, что у сущности действительно отдельный жизненный цикл, а не просто набор дополнительных полей к сделке
2. 2.Стадии описывают только последовательные этапы, а результаты и причины вынесены в отдельные поля
3. 3.Название и иконка согласованы с командой заранее, до массового ввода данных
4. 4.Права доступа настроены отдельно от CRM и проверены на тестовом пользователе
5. 5.Связи с другими сущностями настроены и выведены на видимые вкладки карточек
6. 6.Автоматизация задокументирована схемой: какая стадия что меняет в каких модулях