Воронка продаж в Битрикс24: как проектировать стадии, чтобы конверсия в отчёте совпадала с деньгами

Что Битрикс24 называет воронкой

Слово «воронка» в Битрикс24 означает две разные вещи, и их легко перепутать.

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

Вторая — отчёты. В разделе CRM → Аналитика → Оперативная аналитика → Воронка продаж лежат два отчёта, классическая и конверсионная воронка. Они строятся по стадиям первой, но считают по-разному.

Стадия должна фиксировать событие

Стадии по умолчанию я почти никогда не оставляю. Стадия «В работе» ничего не говорит о том, что произошло со сделкой: менеджер позвонил, отправил предложение или просто открыл карточку.

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

«Новая заявка» — сделка создана формой, звонком или чатом. Подтверждает сама система.

«Контакт состоялся» — был разговор или ответ клиента в переписке. Подтверждает запись звонка или сообщение в таймлайне.

«Предложение отправлено» — документ сформирован из карточки и ушёл клиенту. Подтверждает документ в таймлайне.

«Счёт выставлен» — в сделке есть счёт. Подтверждает сам счёт в карточке.

«Оплачено» — деньги пришли на расчётный счёт. Подтверждает учётная система.

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

У такой воронки есть полезное свойство: большую часть переходов можно отдать автоматике. Меньше ручных переходов, меньше расхождений.

Переходы делает система

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

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

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

Там, где событие не фиксируется автоматически, стоит обязательное поле на стадии. Чтобы перевести сделку на «Предложение отправлено» без документа из шаблона, менеджер должен указать дату отправки и сумму. Чтобы закрыть сделку как провальную, нужна причина отказа из списка. В сделках обязательность настраивается отдельно для каждой воронки, это легко упустить при добавлении второй.

Где начинается воронка: лиды или сразу сделки

Перед стадиями сделки нужно решить, откуда воронка вообще считается. В Битрикс24 два режима работы CRM. В простом, который включён по умолчанию, любое обращение сразу становится сделкой и контактом или компанией. В классическом сначала создаётся лид, и в сделку его конвертируют, когда клиент признан реальным. Переключается режим в разделе CRM → Лиды или Сделки → шестерёнка → «Режим работы CRM», классический доступен не на всех тарифах.

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

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

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

Две воронки в отчётах: классическая и конверсионная

Эту разницу стоит знать до того, как показывать воронку собственнику.

Классическая воронка учитывает только те стадии, которые сделка фактически прошла. Если менеджер перетащил сделку из «Новой» сразу в «Успешную», промежуточные стадии эту сделку в отчёте не учтут. Отчёт показывает, какие стадии пропускают чаще всего.

Конверсионная воронка для выигранных сделок показывает все промежуточные стадии, даже если сделка их перескочила. Для проигранных промежуточные стадии не учитываются. Отчёт показывает, после каких стадий сделки чаще закрываются неуспешно.

Есть особенность, о которой справка Битрикс24 предупреждает отдельно. Если сделку сначала перенесли в провальную стадию, а потом в успешную, в конверсионной воронке её не будет. Если наоборот, из успешной в провальную, она в отчёт попадёт.

На практике это даёт диагностику прямо из двух отчётов. Если классическая воронка показывает провал на средних стадиях, а конверсионная выглядит ровной, менеджеры перескакивают стадии. Это проблема ведения сделок в CRM, продажи при этом могут идти нормально. Если провал виден в обоих отчётах, клиенты действительно отваливаются на этой стадии, и смотреть надо в разговоры.

Когда переходы делает автоматика, классическая и конверсионная воронки сближаются. Для меня это один из признаков, что воронка настроена.

Когда нужна вторая воронка

Справка Битрикс24 предлагает простое правило: одна воронка на один отдел или направление. С ним я согласен, с одной оговоркой.

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

Передача между воронками настраивается туннелем продаж: на стадии одной воронки сделка копируется или перемещается в другую. Для передачи из продаж в производство или доставку я обычно выбираю копирование. В продажах сделка остаётся закрытой с суммой, во второй воронке живёт копия с тем же клиентом. Суммы в копиях я обнуляю или исключаю из отчёта по выручке, иначе одна продажа посчитается дважды.

Права доступа настраиваются для каждой воронки отдельно, и сотрудник видит только те воронки, где у него есть право хотя бы на чтение сделок.

Стадии, которые проходят за секунды

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

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

У производственных компаний сделка после оплаты живёт ещё месяц, и воронка там устроена сложнее. Какие отчёты по такой воронке Битрикс24 даёт из коробки, а какие приходится собирать, я разбирал в статье об отчётах в Битрикс24 для производства.