Проектирование воронок продаж в CRM Битрикс24

Проектирование воронок продаж в CRM Битрикс24

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

Архитектура воронок в Битрикс24

В Битрикс24 воронки реализованы через STAGE_SEMANTIC_ID — семантическое значение стадии: P (in progress), S (success), F (fail). Каждая стадия принадлежит одной из трёх категорий. Стадии хранятся в таблице b_crm_status, привязаны к типу сущности через ENTITY_ID (например, DEAL_STAGE для сделок, STATUS для лидов).

В многоворонночной модели (от версии Битрикс24 с поддержкой направлений) каждое направление (crm_category) имеет свой набор стадий. Технически это реализовано через отдельные ENTITY_ID вида DEAL_STAGE_1, DEAL_STAGE_2 и т.д., где число — ID направления.

Почему воронку нужно проектировать, а не «просто создать»

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

Кроме того, стадии воронки непосредственно влияют на:

• Триггеры и автоматизацию — действия выполняются при входе/выходе из стадии.
• Бизнес-процессы — запускаются по смене стадии.
• Отчёты и аналитику — конверсия между стадиями считается именно по модели воронки.
• Права доступа — можно ограничить, кто вправе переводить сделку в определённую стадию.

Если воронку «нарисовали быстро» и потом переделывали — все накопленные данные по конверсии стадий обнуляются. Это болезненно для отдела продаж, который уже месяц работал с CRM.

Процесс проектирования

Интервью с продажами. Начинаем с разговора с руководителем отдела продаж и 2–3 менеджерами. Задача — восстановить реальный процесс продажи: с момента первого контакта до оплаты и повторной покупки. Важно зафиксировать: где принимается решение о продолжении работы со сделкой, кто принимает это решение, что является доказательством перехода на следующий шаг.

Определение типов сделок. Если компания продаёт разные продукты или работает с разными сегментами клиентов — воронки будут разными. Процесс продажи услуги поддержки и продажа разовой поставки — это разные воронки, пусть и в одной CRM.

Карта стадий. Для каждой стадии фиксируем:

• Название и смысл (что значит «быть в этой стадии»)
• Критерий входа (что должно произойти)
• Ответственный (или роль)
• Максимальное время в стадии до эскалации
• Возможные переходы (в какие следующие стадии можно перейти)

Стадии отказа. Отдельная история — «проигрышные» стадии. Их нужно проектировать как классификатор причин отказа: «Отказ — нет бюджета», «Отказ — ушли к конкуренту», «Отказ — не наш клиент». Это не косметика — это данные для анализа потерь.

Кейс: воронка для B2B-продаж программного обеспечения

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

Решение: спроектировали три воронки.

Воронка 1 — Прямые продажи (7 стадий, цикл 14–30 дней): Лид квалифицирован → Выявление потребности → КП направлено → КП согласовано → Счёт выставлен → Оплата получена → Лицензия передана

Воронка 2 — Тендерные закупки (9 стадий, цикл 30–120 дней): Тендер обнаружен → Принято решение участвовать → Документация подготовлена → Заявка подана → Ожидание результатов → Победа → Договор подписан → Поставка → Закрыто

Воронка 3 — Продление лицензий (4 стадии, цикл до 30 дней): Уведомление направлено → В работе → Счёт выставлен → Продлено

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

Через два месяца после внедрения клиент получил первые прогнозы выручки с точностью ±15% — против прежнего «примерно столько же, как в прошлом месяце».

Автоматизация стадий

Автоматизация в Битрикс24 настраивается через роботов (b_crm_automation_trigger, b_crm_automation_action) — это упрощённый вариант бизнес-процессов. Каждый робот привязан к конкретной стадии конкретной воронки. При проектировании важно зафиксировать: какие роботы работают на входе в стадию, какие — при задержке, какие — на выходе.

Сроки

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