Проектирование мультиворонок CRM Битрикс24

Проектирование мультиворонок CRM Битрикс24

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

Мультиворонки в Битрикс24 — это архитектурное решение, а не просто «ещё одна вкладка».

Архитектура мультиворонок

В Битрикс24 мультиворонки реализованы через механизм направлений (crm_category). Каждое направление — отдельный пространственно изолированный набор стадий. Технически:

• Направления хранятся в таблице b_crm_category
• Стадии каждого направления — в b_crm_status с ENTITY_ID = DEAL_STAGE_{categoryId}
• Сделка принадлежит конкретному направлению через поле CATEGORY_ID в b_crm_deal

Важные ограничения платформы:

• Переместить сделку из одного направления в другое можно только через API (crm.deal.update с изменением CATEGORY_ID) или специальный интерфейс — обычным перетаскиванием нельзя.
• Пользовательские поля создаются для всей сущности «Сделка», а не для конкретного направления. Скрыть поле только для одного направления через стандартный интерфейс нельзя — только через ролевую конфигурацию карточки.
• Автоматизация (роботы) настраивается отдельно для каждого направления.

Когда нужны мультиворонки

Мультиворонки оправданы, если:

1. Разные команды менеджеров работают с разными типами клиентов — каждой команде нужна своя аналитика.
2. Разные циклы продаж — краткосрочные сделки (1–3 дня) и долгосрочные проекты (3–12 месяцев) не должны смешиваться в одном отчёте.
3. Разные наборы обязательных полей — у одного типа сделок нужны реквизиты и договор, у другого только имя и сумма.
4. Разные источники лидов с несовместимой логикой квалификации.

Мультиворонки не нужны, если различие между типами сделок покрывается кастомным полем «Тип» и небольшой вариацией в стадиях.

Проектирование: от бизнес-процессов к архитектуре

Шаг 1. Инвентаризация типов продаж. Вместе с руководством фиксируем все типы сделок компании. Для каждого типа: кто ведёт, каков цикл, чем принципиально отличается от других.

Шаг 2. Критерии разделения. Не каждое различие требует отдельной воронки. Задаём вопрос: если смешать эти типы сделок в одной воронке, что именно сломается? Если ответ — только визуальное неудобство, достаточно поля-фильтра. Если ответ — стадии принципиально разные и автоматизация разная — нужна отдельная воронка.

Шаг 3. Архитектура перехода между воронками. Нередко бизнес-процесс предполагает переход сделки из одной воронки в другую: квалифицированный лид → стандартная сделка → сервисный контракт после закрытия. Это нужно спроектировать явно: через автоматизацию (crm.deal.add в другом направлении при закрытии текущей сделки) или через ручной перенос с документированным процессом.

Шаг 4. Общие и специфические поля. Составляем матрицу: какие поля нужны во всех воронках, какие — только в конкретных. Поля «для всех» создаются один раз. Поля, специфичные для одной воронки, создаются и скрываются через ролевые конфигурации в других.

Шаг 5. Отдельная автоматизация. Роботы и триггеры настраиваются для каждого направления отдельно. Это позволяет иметь разные сценарии уведомлений и задач для разных воронок — именно это и является архитектурным смыслом разделения.

Кейс: три воронки для компании-дистрибьютора

Клиент — оптовый дистрибьютор бытовой химии. Три канала продаж: розничные сети (контракты на поставку), HoReCa (гостиницы, рестораны), интернет-магазины (агрегаторы).

Исходная ситуация: одна воронка «Сделки» с 6 стадиями. Руководитель не мог понять, почему конверсия «нормальная», но выручка не растёт: контракты с розничными сетями (длинный цикл, большой чек) смешивались с быстрыми сделками HoReCa (цикл 3–7 дней, средний чек в 10 раз меньше).

Воронка «Розничные сети» (8 стадий, цикл 30–90 дней): Переговоры → Матрица согласована → Коммерческие условия → Договор на согласовании → Договор подписан → Первая поставка → Регулярные поставки → Расторжение

Воронка «HoReCa» (5 стадий, цикл 3–14 дней): Обращение → КП отправлено → Тестовая поставка → Регулярный заказ → Потеря клиента

Воронка «Маркетплейсы» (6 стадий): Обращение → Анкета заполнена → Документы переданы → Листинг создан → Первые заказы → Активный партнёр

Для воронки «Розничные сети» настроили автоматическое создание задачи «Согласовать цены с коммерческим директором» на стадии «Коммерческие условия». Для воронки «HoReCa» — напоминание менеджеру через 2 дня после отправки КП без ответа.

После внедрения руководитель впервые увидел раздельную конверсию по каналам: розничные сети — 18% из переговоров в контракт, HoReCa — 42%. Стало понятно, куда направлять усилия.

Типичные ошибки при проектировании

Слишком много воронок. Больше 6–8 направлений — уже сложно управлять. Если воронок много, часть из них стоит рассмотреть как смарт-процессы.

Воронки без владельцев. Каждое направление должно иметь ответственного руководителя, который следит за актуальностью стадий и автоматизации.

Забыли про отчётность. Стандартные отчёты Битрикс24 умеют агрегировать данные по нескольким направлениям, но нестандартные срезы потребуют кастомных отчётов через crm.deal.list или BI-инструменты.

Сроки

Проектирование мультиворонночной архитектуры (2–3 направления) — 8–15 рабочих дней: интервью, архитектурная схема, согласование, реализация каждого направления, автоматизация, тестирование и обучение команд.