Воронка B2B-продаж

Происхождение и история термина

Исторический пример развития модели в B2B — работа D’Haen и Van den Poel 2013 года. Авторы описывали уже существующую воронку отбора покупателей и отмечали разнобой в названиях её стадий. В их схеме сначала рассматривается широкий круг организаций, затем подходящих кандидатов отбирают по заданным признакам, квалифицируют для контакта и доводят до покупки. Квалификация здесь означает оценку того, насколько кандидат подходит для дальнейшей работы. ^[1]

Авторы дополнили эту последовательность обратной связью: сведения об удачных и неудачных попытках должны участвовать в следующем отборе. В этой работе воронка описывает повторяющийся процесс, а не только сужение списка. Это конкретный этап развития подхода, а не дата изобретения B2B-воронки. В современных инструкциях Salesforce и HubSpot модель применяется к записям о сделках и их стадиям. ^{[1, 2, 4]}

Суть и механизм

В B2B нужно различать покупателя, участников решения и саму покупку. В Salesforce возможность продажи связана с организацией, а контактные роли показывают людей, участвующих в этой возможности. Контакт отвечает на вопрос «с кем общаемся», сделка — «какую продажу обсуждаем». Это позволяет учитывать нескольких собеседников, не превращая каждого из них в отдельный ожидаемый доход. ^[2]

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

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

Виды и классификации

OpenStax описывает процесс на стороне организации-покупателя: осознание проблемы, описание потребности, техническая спецификация, поиск поставщиков, запрос предложений, выбор поставщика, согласование порядка заказа и оценка исполнения. При обычной повторной закупке часть этой работы может не понадобиться; новая сложная покупка, напротив, может потребовать всех восьми этапов. ^[3]

Стадии продавца отражают другую задачу. В примере Salesforce поиск и квалификация потенциального клиента сменяются предложением, переговорами и закрытием с успешным либо неуспешным результатом. Само руководство подчёркивает, что у компаний процессы различаются. Поэтому восемь этапов закупки из учебника не следует автоматически превращать в восемь колонок отдела продаж. ^{[2, 3]}

Для анализа полезно различать два представления. Текущий список показывает, сколько сделок находится на каждой стадии сейчас. Отчёт о переходах показывает, какие записи прошли выбранные события. Например, HubSpot строит такие отчёты с использованием дат входа в стадии; настройка периода относится к датам событий, а не обязательно к дате создания сделки. ^[4]

Как применяется на практике

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

Российский пример реализации — Битрикс24. Карточка сделки содержит сведения о продаже, сумму и этапы; вкладка истории позволяет увидеть дату, автора, тип и описание изменения. Система также позволяет завершить сделку до прохождения всех стадий. Поэтому при анализе нужно заранее решить, обязателен ли каждый промежуточный этап: последовательная схема из учебного примера не описывает все возможные маршруты в программе. ^[5]

Для проверки записи полезно отделять событие от оценки. «Предложение отправлено» описывает действие продавца; «покупатель согласовал условия» — другой результат. В нашем примере подмена второго первым завысила бы число сделок, действительно готовых к договору. CRM, то есть система управления взаимоотношениями с клиентами, хранит внесённые сведения; выбранное условие перехода остаётся частью правил учёта. ^{[1, 5]}

Как измерить или проверить

Конверсия между стадиями показывает долю записей, прошедших нужный переход. Отчёты HubSpot позволяют анализировать такие переходы для контактов, компаний или сделок; выбор объекта и обязательных стадий влияет на состав результата. ^[4] Ниже — отдельная учебная схема редакции с фиксированной группой и последовательным прохождением этапов.

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

Для перехода из стадии A в B делим число сделок из выбранной группы, достигших B после A, на число её сделок, достигших A, и умножаем на сто процентов. В примере получаем сорок процентов от квалификации до предложения, пятьдесят процентов от предложения до договора и двадцать процентов от квалификации до договора. Последняя величина относится к исходным ста сделкам, а не только к сорока получившим предложение.

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

Для денежной оценки HubSpot умножает сумму сделок стадии на назначенную ей вероятность. ^[4] В учебном примере миллион рублей при вероятности двадцать процентов даёт взвешенную сумму двести тысяч рублей. Эта величина не означает частичную оплату миллионного договора: она получена умножением. Смысл прогноза зависит от обоснованности выбранной вероятности, поэтому стандартный процент программы нельзя принимать за доказательство будущего поступления денег.

Ошибки, ограничения и спорные вопросы

Названия стадий не обеспечивают сопоставимости. D’Haen и Van den Poel показывают, что даже взаимный порядок терминов «лид» и «потенциальный клиент» в разных работах различается. ^[1] Поэтому при объединении отчётов нужны определения стадий и правила включения записей, а не только совпадающие подписи.

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

Правовой аспект

Данные о представителе компании могут быть персональными, если относятся к определённому или определяемому человеку: критерий установлен пунктом 1 статьи 3 закона № 152-ФЗ. Части 2 и 5 статьи 5 требуют определённых законных целей обработки и соразмерности состава данных этим целям. Использована редакция закона от 26.07.2026. ^[6] Продажа другой организации не устраняет вопрос о данных её сотрудников. Это общий правовой контекст; основание обработки и устройство конкретной CRM требуют отдельной юридической оценки.

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

Связанные термины

• voronka-prodazh
• b2b-marketing
• crm-sistema
• lid
• konversiya