Воронка продаж строительной компании: какие стадии сделать от заявки до договора

Для строительной компании я бы строил воронку не из действий вроде `Звонок → Встреча → Расчёт`, а из достигнутых состояний сделки: `Звонок назначен → Квалификация пройдена → Встреча назначена → Передано на расчёт → Коммерческое предложение отправлено → Договор отправлен → Договор подписан → Аванс получен`.

Главный принцип: стадия показывает, что уже произошло со сделкой, а задача или дело - что сотруднику нужно сделать дальше.
Если в строительной компании воронка выглядит так:
Новая заявка → Звонок → Квалификация → Встреча → Расчёт → Договор подписан

то на первый взгляд всё понятно.
Но когда по такой воронке начинает реально работать отдел продаж, она перестаёт отвечать на важный вопрос руководителя: что сейчас происходит с каждой сделкой?
Например, в стадии Звонок лежат две сделки. Что это значит?
Менеджер ещё не звонил? Уже звонил и не дозвонился? Поговорил с клиентом? Договорился перезвонить завтра?
Из названия стадии этого не понять.

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

Не Звонок, а Звонок назначен.
Не Квалификация, а Квалификация пройдена.
Не Встреча, а Встреча назначена.
Не Расчёт, а Передано на расчёт.
Не Договор, а Договор клиенту отправлен или Договор подписан.

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

Почему стадии “Звонок”, “Встреча” и “Расчёт” создают проблему

Возьмём стадию Звонок.

В ней могут одновременно находиться совершенно разные сделки:

• по одной ещё никто не звонил;
• по второй звонили, но клиент не ответил;
• с третьим клиентом поговорили и договорились созвониться вечером;
• четвёртого уже квалифицировали, но сделку не передвинули дальше.

Для управления это четыре разных состояния. CRM показывает одно.

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

То же самое происходит со стадиями Встреча, Расчёт, Коммерческое предложение, Договор.
Поэтому я стараюсь формулировать стадию так, чтобы из неё было понятно, что уже сделано.

Какой принцип я использую при проектировании воронки

У каждой сделки есть текущее состояние.
Между текущим и следующим состоянием сотрудник выполняет какое-то действие.

Сама стадия при этом не должна превращаться в задачу.
Например:
Необработанная заявка
Сотруднику нужно связаться с клиентом.

Звонок назначен
Сотруднику нужно провести следующий разговор.

Квалификация пройдена
Нужно договориться о следующем содержательном шаге, например о встрече.

Передано на расчёт
Нужно получить расчёт и подготовить предложение клиенту.

Получается простая логика:
стадия фиксирует результат, а работа сотрудника происходит между стадиями.

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

Пример воронки для компании, которая строит дома

Конкретный набор стадий всегда зависит от того, как работает сама компания.
Но для примера я бы начал с такой схемы:

1. Необработанная заявка
2. Звонок назначен
3. Квалификация пройдена
4. Встреча назначена
5. Встреча проведена - если это отдельное контролируемое состояние, на котором нужно получить от клиента больше данных для КП.
6. Передано на расчёт
7. Коммерческое предложение отправлено
8. Реквизиты получены
9. Договор клиенту отправлен
10. Договор подписан
11. Аванс получен

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

Необработанная заявка

Это начальное состояние.
Заявка уже появилась, но результат первого контакта ещё не получен.

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

Звонок назначен

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

Другой сценарий: клиент ответил, но сейчас ему неудобно разговаривать “Давайте завтра после шести”.
Результат тот же: Звонок назначен.

Или клиент поговорил с менеджером, но хочет сначала обсудить строительство дома с супругой и вернуться к разговору в пятницу.
Опять Звонок назначен.

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

Если задача компании связана с массовым исходящим обзвоном, отдельно рабочий цикл оператора мы разбирали в статье «100 звонков в день в Битрикс24: как организовать холодные звонки».

Квалификация пройдена

Дальше нужно понять, подходит ли запрос клиента компании.

Критерии у каждой строительной компании свои.
Например, условная компания может:

• строить только дома определённого типа;
• работать только в Москве и Московской области;
• ограничивать удалённость объекта от МКАД;
• брать проекты только от определённого бюджета;
• строить только одноэтажные дома;
• устанавливать минимальные требования к участку.

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

Если базовые критерии пройдены: Квалификация пройдена.

Встреча назначена

После квалификации в строительстве дома часто нужен более подробный разговор.

Встреча может проходить:

• в офисе;
• на построенном или строящемся объекте;
• на участке клиента;
• онлайн;
• в другом согласованном формате.

Для воронки важнее не место, а состояние: Встреча назначена.
Руководитель видит, что клиент уже квалифицирован и следующий содержательный контакт согласован.

Нужна ли отдельная стадия “Встреча проведена”

Не обязательно. Если после встречи менеджер сразу передаёт материалы на расчёт, я бы не добавлял промежуточную стадию только ради того, чтобы отметить сам факт встречи.
Маршрут может выглядеть так: Встреча назначена → Передано на расчёт.

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

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

Передано на расчёт

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

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

• расчёт занимает много времени,
• не хватает исходных данных,
• непонятна ответственность между подразделениями.

Одна стадия не даст ответ на вопрос, почему возникла проблема.
Но она покажет, где проблема проявляется.

Коммерческое предложение отправлено

Расчёт готов, клиент получил предложение.
Стадия: Коммерческое предложение отправлено.
Это точнее, чем просто КП или Коммерческое предложение.

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

Сделка может вернуться назад

Клиент получил коммерческое предложение и попросил что-то изменить.
Например:

• увеличить площадь террасы;
• поменять материал;
• пересчитать комплектацию;
• изменить часть проекта.

Сделка не потеряна, но и переходить к договору пока рано.
Поэтому она может вернуться: Коммерческое предложение отправлено → Передано на расчёт.

После перерасчёта: Передано на расчёт → Коммерческое предложение отправлено.

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

Реквизиты получены

Когда клиент принял решение двигаться дальше, компании могут понадобиться данные для договора.
Если получение реквизитов - самостоятельная часть процесса, её можно выделить: Реквизиты получены.
Из названия снова понятно, что результат уже достигнут.
Не Получить реквизиты.
Не просто Реквизиты.
Именно Реквизиты получены.

Договор клиенту отправлен

Следующее состояние: Договор клиенту отправлен.
Документ подготовлен и передан клиенту.
Теперь руководитель видит, сколько сделок уже дошли до согласования договора, а менеджер понимает, какой результат требуется дальше.

Договор подписан

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

Аванс получен

Для рассматриваемого примера я бы закончил воронку продаж на: Аванс получен.
Почему не продолжать эту же воронку дальше?
Потому что после аванса меняется сама работа.
До этого момента задача была продать проект и довести клиента до коммерческого результата.

После этого начинается исполнение договора:

• проектирование;
• подготовка;
• закупки;
• строительство;
• контроль этапов;
• сдача объекта.

У этого процесса другие задачи, сроки и ответственные.
Поэтому я бы не строил одну бесконечную воронку:
Заявка → Звонок → Встреча → Договор → Аванс → Фундамент → Стены → Кровля → Сдача.

Продажи и производство лучше рассматривать как два связанных, но разных процесса.
В Битрикс24 я бы разделял их соответственно: продажа заканчивается в момент, который компания считает коммерческим результатом, после чего начинается отдельный производственный процесс.

Для другой компании граница может проходить не по авансу, а по другому событию. Это нужно определять по реальной организации работы.

Что делать с проигранными сделками

У воронки должен быть не только успешный конец.
Часть клиентов не купит.
Важно не оставлять такие сделки бесконечно лежать на промежуточных стадиях и не закрывать их без причины.

Полезно фиксировать, почему продажа не состоялась.
Например:

• не подходит бюджет;
• не подходит география;
• нужна другая технология;
• клиент выбрал другого подрядчика;
• проект отложен;
• клиент перестал выходить на связь.

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

Что получает менеджер

При такой структуре сотруднику не нужно каждый раз вспоминать большую блок-схему.

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

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

При этом сама стадия не заменяет звонки, задачи и дела в Битрикс24, даты следующего контакта и напоминания.
У них другая функция.
Стадия отвечает на вопрос “что уже произошло?”, а задача - “что нужно сделать?”.

Смешивать эти две сущности обычно и приводит к стадиям вроде Позвонить, Отправить КП, Подготовить договор.

Что получает руководитель

Руководитель открывает воронку и видит не абстрактные действия, а распределение сделок по понятным состояниям:

• сколько заявок ещё не обработано;
• сколько клиентов ждут следующего звонка;
• сколько прошли квалификацию;
• сколько встреч назначено;
• сколько сделок находится на расчёте;
• сколько коммерческих предложений уже у клиентов;
• сколько договоров отправлено;
• сколько подписано;
• сколько клиентов внесли аванс.

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

Воронка не объясняет причину автоматически.
Но хорошая воронка показывает, где её искать.

Не каждая деятельность должна становиться стадией

При проектировании воронки легко уйти в другую крайность и попытаться превратить в стадию каждое действие менеджера.
Позвонил.
Написал сообщение.
Отправил презентацию.
Уточнил площадь.
Созвонился повторно.
Напомнил о встрече.

Если каждое действие превращать в отдельную колонку, воронка станет сложнее самого процесса.

Поэтому я бы проверял каждую потенциальную стадию двумя вопросами:

1. Изменилось ли после этого состояние сделки?
2. Нужно ли руководителю отдельно видеть и контролировать это состояние?

Если нет, вероятнее всего, это задача или действие, а не стадия.

Как перенести эту логику в Битрикс24

Я бы не начинал настройку с роботов и автоматизации.

Сначала нужно описать сам процесс:

• где начинается продажа;
• какие состояния сделки действительно важны;
• какой результат означает переход дальше;
• где возможен возврат назад;
• какие причины проигрыша нужно фиксировать;
• где заканчиваются продажи и начинается исполнение.

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

Если сотрудники будут работать по новой логике впервые, отдельно стоит продумать обучение сотрудников работе в Битрикс24, чтобы правила переходов и следующий шаг одинаково понимались всей командой.

Этот принцип работает не только в строительстве

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

Но принцип не привязан к отрасли.
Есть начало процесса.
Есть несколько значимых состояний.
Между ними сотрудники выполняют работу.
Есть успешное завершение.
Есть неуспешное завершение.

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

Тот же принцип можно реализовать в Битрикс24, другой системе, Excel или даже на физической доске с карточками.
Если логика процесса не определена, программа её не исправит.
Сначала нужно понять, какие состояния бизнеса мы хотим видеть. Потом уже выбирать способ их автоматизации.

Как в итоге может выглядеть воронка строительной компании

Рабочий пример:
Необработанная заявка
↓
Звонок назначен
↓
Квалификация пройдена
↓
Встреча назначена
↓
Передано на расчёт
↓
Коммерческое предложение отправлено
↓
Реквизиты получены
↓
Договор клиенту отправлен
↓
Договор подписан
↓
Аванс получен

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

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

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