Почему отчёты Битрикс24 врут: 4 ловушки воронки

CRM считает правильно, только отвечает не на тот вопрос, который вы задаёте. Разбираю четыре места, где воронка обманывает, и как её считать, чтобы по ней можно было принимать решения.

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

Битрикс24 здесь не виноват. Он честно показывает то, что записано. Проблема в том, что вопрос «как работает наша воронка» требует одной логики подсчёта, а стандартные экраны построены под другую. Плюс сами данные в CRM копятся с мусором, который никто не чистит.

Ниже четыре ловушки, на которые я натыкаюсь почти в каждой CRM, и что с ними делать. Примеры — с демо-табло выдуманной компании «Окна-Профи»: 8 менеджеров, около 440 заявок в месяц, все цифры вымышлены.

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

Пример. За месяц через этап «Встреча назначена» прошли 158 сделок. Большинство уже ушли дальше или в отказ. На этапе прямо сейчас осталось 14. Если строить конверсию по срезу, получится, что встреч у вас 14, а не 158, и все проценты дальше поедут.

Срез ещё и зависит от того, когда вы смотрите. В начале месяца на этапах одна картина, в конце — другая, хотя отдел работал одинаково. Сравнивать такие цифры между месяцами нельзя.

Что нужно вместо этого: поток. Сколько сделок прошло через каждый шаг за период и какая доля перешла в следующий.

Так выглядит поток на демо-данных: 441 заявка, 370 взяли в работу (83,9%), встречу назначили 158 (42,7%), провели 120 (75,9%), счёт выставили 82 (68,3%), оплатили 57 (69,5%). Здесь сразу видно слабое место: из «в работе» во встречу доходит меньше половины. По срезу этого не увидеть никак.

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

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

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

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

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

Кассовая: события шага считаются по их собственной дате. В октябре назначили 158 встреч и провели 120, при этом часть проведённых могла быть назначена ещё в сентябре.

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

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

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

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

Что делать:

— Дубли склеивать по телефону и почте до подсчёта. Сделку, закрытую как дубль, из базы воронки убирать совсем, а не считать отказом.

— Повторные продажи вести отдельным направлением или хотя бы отмечать полем. Новые заявки и повторные клиенты — две разные воронки с разной конверсией.

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

Самая частая картина в CRM: поле «причина отказа» необязательное, и треть отказов либо без причины, либо с причиной «прочее». По такому отчёту нельзя понять, почему вы теряете клиентов. А это ровно тот вопрос, ради которого поле заводили.

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

Так выглядит разбор на демо-данных: «Не дозвонились» — 82 сделки (30,6%), «Дорого» — 69 (25,7%), «Выбрали конкурента» — 39 (14,6%), «Передумал» — 34 (12,7%), «Нецелевая заявка» — 25 (9,3%), «Сроки не подошли» — 19 (7,1%). «Прочего» нет, каждая причина ведёт к конкретному действию.

И первая строка тут говорит больше, чем кажется. Почти треть потерь — не потому, что клиенту не понравилась цена, а потому, что до него не дозвонились. Это лечится не скидкой, а регламентом звонков.

Как навести порядок:

— Сделать причину обязательной при переводе в «Провал». В Битрикс24 это настраивается в обязательных полях для стадии.

— Оставить 6–8 причин, которые различают действия. Если у двух причин одинаковое лекарство, их можно склеить.

— «Прочее» либо убрать, либо требовать к нему комментарий и раз в месяц разбирать: что туда попадает часто, то становится отдельной причиной.

— Отделить причины клиента от причин процесса. Первые идут в маркетинг и продукт, вторые — руководителю отдела продаж.

1. Воронка — это поток за период, а не срез на сегодня.

2. Сделка на этапе N считается прошедшей все этапы до него.

3. Заранее выбрать способ: кассовая воронка (события по их дате) или когортная (путь заявок, созданных в периоде), и не смешивать.

4. Дубли убрать из базы, повторные продажи считать отдельно.

5. Причина отказа обязательна, «прочего» почти нет.

6. Конверсию смотреть по каждому шагу и по каждому менеджеру, а не одной цифрой «заявка → оплата».

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

Руками это делается через выгрузку истории стадий и таблицу с формулами: реально, но методику придётся держать в голове и пересчитывать каждую неделю. Мы делаем Маржай: ИИ-Комдир подключается к Битрикс24 только на чтение, считает воронку потоком по истории стадий и каждое утро присылает в Telegram, на каком шаге и у кого провал, — цифры считает код, а не нейросеть.

Подробнее про отчёты по Битрикс24: https://marzhai.com/prodazhi/otchety-bitrix24/?utm_source=vcru&utm_medium=statya&utm_campaign=otchety-b24

А какая из четырёх ловушек встречается у вас чаще всего? Или есть пятая, о которой я не написал? Расскажите в комментариях.