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

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

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

Слово «воронка» в Битрикс24 означает две разные вещи.

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

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

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

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

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

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

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

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

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

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

Дальше финальные стадии: одна успешная и несколько неуспешных.

Неуспешные стадии: сколько их делать

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

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

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

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

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

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

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

Там, где событие не фиксируется автоматически, стоит обязательное поле на стадии. Чтобы перевести сделку на «Предложение отправлено» без документа из шаблона, менеджер указывает дату отправки и сумму. Чтобы закрыть сделку как проигранную, нужна причина отказа из списка. Обязательность в сделках настраивается отдельно для каждой воронки, и её легко упустить при добавлении второй. Если стадию меняет робот или бизнес-процесс, значение поля записываем той же автоматизацией и не рассчитываем на проверку, которая срабатывает при ручном переходе. Роботов и бизнес-процессы под такие переходы мы настраиваем как доработку Битрикс24, когда штатных действий не хватает.

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

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

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

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

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

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

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

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

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

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

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

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

Справка Битрикс24 предлагает правило: одна воронка на один отдел или направление. Мы добавляем к нему уточнение: вторую воронку заводим, когда у сделки меняется процесс. Желание разделить отчёт поводом для неё не считаем.

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

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

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

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

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

Воронку под процесс компании мы собираем на внедрении Битрикс24: стадии по событиям, роботы и триггеры на переходах, права на стадии. У завода спецтехники воронки собраны под производственный цикл, роботы двигают сделку и напоминают о ней менеджеру; в замерах кейса потери сделок из воронки — 0 %. Если воронка уже работает, но отчёт по ней расходится с деньгами, начинаем с аудита Битрикс24.

Частые вопросы

Ответы на вопросы, которые нам чаще всего задают по этой теме.