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


