Воронка продаж Битрикс24: где теряются сделки
Сделки в Битрикс24 почти никогда не теряются в одном месте — они застревают на границах стадий и дублируются при повторных обращениях. Воронка продаж Битрикс24, собранная «по логике отдела», обычно воспроизводит привычные этапы, но не описывает, чем именно одна стадия отличается от другой. В итоге зависшие сделки выглядят как активные, а потеря сделок обнаруживается на сверке с оплатами, когда вернуть клиента уже сложно.
Первая типовая причина — размытые границы стадий сделки. Если переход не привязан к проверяемому событию (отправлено предложение, получен контакт согласующего, подписан документ), менеджер двигает карточку по ощущению. Отчёт по этапам перестаёт отражать реальность: прогноз завышен, а в зависших сделках копятся те, что не двигаются месяцами.
Вторая — обязательные поля не на том шаге. Требование заполнить всё при создании карточки заставляет либо заводить сделку позже, либо ставить заглушки, которые потом никто не чистит. Настройка воронки продаж работает, когда данные запрашиваются там, где они появляются: источник и контакт — на первом касании, условия и сроки — на согласовании.
Третья — отсутствие правил возврата. Без них сделка после отказа клиента остаётся в продвинутой стадии, а повторное обращение заводится второй карточкой, и часть задач теряется между дублями. Разбираем, как это закрывается настройкой воронки: проверяемыми критериями перехода, полями на своих шагах и сценариями возврата сделки назад.
Что даёт пересборка: эффект в измеримых показателях
Пересборка воронки в Битрикс24 меняет не «удобство интерфейса», а время, за которое сделка проходит путь от первого обращения до счёта. Раньше менеджер переносил карточку вручную, дублировал данные в таблицы и согласовывал скидку в переписке — на каждой стадии терялись часы. После того как переходы между этапами, обязательные поля и ответственных привязали к правилам, карточка двигается сама, а менеджер занимается клиентом.
Что даёт автоматизация продаж в измеримых величинах:
- Скорость обработки обращения — заявка с сайта, почты и телефона попадает в одну карточку без ручного ввода, а первый ответ перестаёт зависеть от того, кто дежурит.
- Конверсия по стадиям — видно, на каком шаге отваливается больше всего сделок; чаще узкое место — согласование или выставление счёта, а не переговоры.
- Доля зависших сделок — правило «нет активности дольше заданного срока → задача и напоминание» возвращает в работу то, что раньше тихо лежало в базе.
- Время восстановления после сбоя процесса — если обмен с внешней системой отвалился, заявки не теряются: очередь доигрывается, а ответственный получает уведомление.
Прозрачность отдела продаж — следствие того же: руководитель видит воронку в реальном времени, а не собирает отчёт по итогам месяца из чужой таблицы. Уходит целый класс отказов — забытые сделки, обращения без ответственного, этапы, которые никто не контролирует.
Схемы воронки: вариант, ограничения, когда подходит
Схема воронки задаёт не только вид карточки сделки, но и правила переходов, обязательные поля на стадии, права ролей и роботов, которые двигают сделку без участия менеджера. Поэтому схему выбирают до наполнения базы: смена варианта на живых данных обнуляет сопоставимость этапов и ломает отчётность за прошлые периоды.
Разнородность сделок — главный критерий выбора. Если продукт один и цикл у всех клиентов одинаков, лишние воронки только дробят аналитику; если направлений несколько, общая воронка усредняет сроки и конверсию до бессмысленных значений.
| Схема воронки | Когда подходит | Ограничения |
|---|---|---|
| Одна общая воронка | Один продукт, одинаковый цикл сделки, единый отдел продаж | Разные сегменты смешиваются: средний срок и конверсия считаются «в среднем», правила переходов приходится делать мягкими |
| Воронки по направлениям, в том числе для нескольких продуктов | Разные продукты, циклы и сценарии квалификации | Требуется синхронизация справочников и полей; сравнение направлений — только сводными отчётами, а не одной диаграммой |
| Воронка с этапами квалификации и возврата | Длинный цикл, сделки зависают, часть клиентов возвращается после отказа | Больше стадий — выше цена ошибки: без дисциплины заполнения и настроек роботов воронка зарастает «мёртвыми» сделками |
Правила переходов фиксируем явно: какие поля обязательны на стадии, где запрещён перескок этапов, какая задача ставится роботом и через сколько дней сделка уходит в возврат или отказ. Такой каркас делает воронку и рабочим инструментом менеджера, и источником достоверных данных для прогноза.
Этапы внедрения: от аудита до передачи в работу
Порядок этапов здесь не формальность: каждый следующий шаг опирается на результат предыдущего, и пропущенное звено возвращает проект к ручной правке по факту. Ниже — последовательность, по которой мы ведём внедрение воронки продаж в Битрикс24.
- Аудит воронки продаж. Выгружаем стадии, поля и историю сделок, считаем, сколько сделок зависает на каждом этапе и кто последним менял карточку. На выходе — карта проблем: дубли полей, стадии без правил перехода, отчёты, которые никто не читает.
- Проектирование стадий. Собираем схему под реальный цикл сделки: сколько стадий нужно, какие поля обязательны на каждой, где действие выполняет автоматика, а где решение остаётся за человеком.
- Настройка прав доступа. Роли под задачи: менеджер ведёт свои сделки, руководитель видит отдел, служебные поля закрыты от правок. Удаление карточек и смену стадии задним числом ограничиваем отдельно.
- Сборка автоматизации. Роботы, триггеры и задачи внутри стадий: напоминание при простое, задача после согласования, уведомление ответственного при смене этапа.
- Проверка на тестовом контуре. Прогоняем сценарии на копии портала: сделка проходит все стадии, отчёты сходятся, права не мешают работе. Схему правим до переноса, а не после.
- Обучение и регламент. Показываем команде новую логику на их же сделках и отдаём короткие инструкции: какое поле когда заполняется и что делать с нестандартной сделкой.
- Передача в эксплуатацию. Переносим настройки на рабочий портал, первые недели сверяем отчёты и снимаем спорные места по фактическим сделкам.
Каждый этап закрывается артефактом — схемой, матрицей прав или регламентом, поэтому результат можно принять по частям.
Что заказчик получает на руки после внедрения
После внедрения логика воронки перестаёт держаться на памяти интегратора — она зафиксирована в документах, по которым отдел продаж работает самостоятельно. Ниже перечень того, что передаётся заказчику в финале проекта.
- Схема воронки продаж — стадии и условия перехода между ними, обязательные поля на каждом шаге, привязка автоматики: автозадачи, уведомления, смена ответственного при простое сделки.
- Матрица прав доступа — какие роли видят, меняют и удаляют сделки, кто выгружает базу и правит настройки; разграничение идёт по отделам, а не «на всех сразу».
- Регламент работы со сделками — что менеджер делает на каждой стадии, в какой срок, какие данные обязан заполнить до перехода дальше.
- Инструкция для менеджеров — пошаговые сценарии под роли: завести сделку, перевести по стадии, вернуть из отказа, приложить документ, передать сделку коллеге.
- Политики доступа и журнал проверок — кто и когда менял настройки воронки, история правок полей и статусов, порядок плановых сверок.
- Документация по системе — карта связей с 1С, телефонией и почтой, описание роботов, правила обработки ошибок при обмене.
Документы пишутся под ваш процесс, а не под шаблон, и проверяются на реальных сделках до сдачи. Когда этапы или ответственные меняются, схему и регламент обновляем — сотрудники остаются на актуальной версии, а не на устных договорённостях.
Кейс: пересобрали стадии и убрали зависшие сделки
Отдел продаж с распределённой командой: шесть менеджеров в трёх городах, общий поток обращений из сайта, почты и мессенджеров. В Битрикс24 воронка продаж к моменту разбора состояла из 12 стадий — три из них менеджеры перепрыгивали, а пять не содержали обязательных полей. Сделка уходила в «Успех» без даты оплаты и решения по отгрузке, и в отчёте руководителя такие продажи месяцами числились активными.
Что изменили в стадиях и правах
Стадии сократили до семи, у каждой появился признак перехода и обязательные поля: дата следующего касания, ответственный, источник, сумма. Права перестроили так, что перевод дальше без заполнения полей невозможен, а возврат в предыдущую стадию делает только руководитель и с комментарием. Добавили этап согласования договора с чек-листом и робота: пять дней без активности — задача менеджеру, десять — эскалация руководителю.
Метрики до и после
Доля сделок без движения снизилась с 34% до 11% — теперь у каждой видно точку остановки и ответственного за следующий шаг. Средний срок сделки сократился с 47 до 29 дней, конверсия из обращения в счёт выросла почти на пятую часть.
Число сделок, по которым в отчёте нет данных, свели к нулю. Стадия перестала быть ярлыком и стала точкой контроля: зависшие сделки видно на второй день, а не в конце месяца, когда менеджер уже не помнит контекста разговора.
Что делать, если сделки уже ведутся по своим правилам
Да, переход делают на работающей системе, без остановки отдела. Порядок такой: сначала на Битрикс24 достраивают дополнительные воронки рядом с действующей — задают стадии, права, обязательные поля — и только после прогона на тестовом контуре переносят сделки. До дня переключения менеджеры работают в прежнем режиме.
Настройка существующей системы начинается с инвентаризации, а не с чистки: какие стадии реально используются, где сделки зависают, какие поля заполняются, а какие уже никто не ведёт. Старые статусы не удаляем — закрываем для ручного выбора, но оставляем доступными, чтобы карточки не теряли связь с историей.
Перенос сделок идёт порциями по ответственному или по датам, со сопоставлением статусов и сохранением даты создания, суммы, привязки к контакту и компании. Каждая карточка получает внешний идентификатор: повторный запуск выгрузки не создаёт дублей, а спорные записи попадают в отчёт и добираются отдельно — без ручного разбора всего массива.
Отчётность ломается не от переноса, а от неполных промежуточных стадий. Поэтому на переходный период справочники и причины отказа держим согласованными в обеих схемах: видно, где сделка была раньше и где она сейчас, и воронка продаж остаётся сшитой, а не распадается на два несвязанных набора цифр.
Когда сверка сходится, отдел переключается на новые контуры, а прежние остаются архивом для аудита.
Технические вопросы по стадиям, правам и отчётам
Стадии, права и отчёты в системе связаны: правка одной сущности меняет поведение остальных. Собрали пять сомнений, которые чаще всего всплывают на этапе проектирования, с короткими ответами по существу.
Можно ли показать сотруднику только часть стадий?
Да. Доступ настраивается ролями и профилями: свой отдел видит воронку целиком, смежные подразделения — только нужные участки и поля карточки. Ограничения задаются на уровне прав, а не ручной фильтрацией в отчётах, поэтому их нельзя обойти из интерфейса.
Что изменится в отчётах, если переименовать или переставить стадии?
История по сделкам сохраняется, но отчёты с фильтром по конкретной стадии придётся пересобрать: часть метрик привязана к идентификатору стадии, а не к её названию в интерфейсе. Поэтому изменения вносим по регламенту и сразу проверяем сданную отчётность.
Как заявка с сайта попадает сразу в нужную стадию?
Форма передаёт набор полей, по которым срабатывает условие распределения: источник, направление, тип запроса. Заявка создаётся в стартовой стадии, дальше перемещается автоматически, ответственный назначается по правилу. Если форм несколько, каждую связываем со своим сценарием, чтобы потоки не смешивались.
Нужно ли каждому направлению делать отдельную воронку?
Это зависит от того, различаются ли этапы и ответственные. Если да, отдельная воронка даёт чистую конверсию по направлению. Если процессы совпадают, лучше одна воронка с разделением по полям — иначе отчёты придётся сводить вручную.
Возврат сделки на прежнюю стадию ломает статистику?
Нет, это штатный сценарий: сделка уходит назад, в карточке сохраняется причина, а конверсия считает повторные проходы отдельно от первичных. Без обязательной причины возврата такие сделки размывают картину, поэтому поле стоит закрепить в форме.
Обсудим задачу: состав работ и порядок старта
Разбор начинается с разговора по делу, а не с обзорной презентации: чтобы вернуться с оценкой и планом работ, нам нужно увидеть вашу текущую воронку продаж в Битрикс24 — стадии, роботов, права, интеграции. Чем больше контекста на входе, тем точнее оценка и тем меньше уточнений на этапе внедрения.
- Доступ к порталу на чтение или к тестовому контуру, где можно воспроизвести текущие настройки воронки.
- Перечень воронок и направлений с указанием, какие из них живые, а какие остались от прежних схем.
- Описание процесса продажи от лида до сделки: кто и на каком шаге меняет стадию, что считается результатом этапа.
- Список автоматизации: роботы, триггеры, бизнес-процессы, шаблоны писем и задачи, которые уже работают.
- Интеграции, влияющие на стадии: телефония, почта, формы на сайте, обмен с 1С и внешними сервисами.
- Роли и права по отделам — от них зависит, какие переходы между стадиями доступны какой команде.
Мы разбираем историю сделок, смотрим, где они залипают и на каком переходе теряется больше всего, и сверяем это с логикой стадий. На выходе вы получаете схему воронки, карту автоматизации и план работ по этапам с понятным порядком старта: сначала проектирование стадий на тестовом контуре, затем перенос на рабочий портал без остановки продаж. Опишите задачу — вернёмся с оценкой и планом работ.
