Что это означает на практике
Воронка полезна не как картинка из CRM, а как модель ограничений. Даже небольшое улучшение bottleneck может дать больше эффекта, чем сильный рост на неограничивающем этапе. Например, удвоение лидов не поможет, если sales capacity уже перегружена. Для анализа нужны не только проценты, но и абсолютные значения, длительность стадий, причины потерь и стоимость изменений.
Почему здесь легко ошибиться
У вопроса «Как увеличить продажи с помощью B2B-воронки?» есть практический смысл только тогда, когда он связан с наблюдаемым решением. Не стоит делать вывод по одному признаку. Например, сигнал «выручка стоит, хотя трафик растёт;» важен в связке с «конверсия между стадиями сильно различается;», а результат разумно проверять через stage conversion;, time in stage; и pipeline value;. Такой подход защищает от локальной оптимизации: показатель может улучшиться, а коммерческий результат — нет. Поэтому сначала фиксируется baseline, затем изменение процесса, и только потом сравнивается downstream-эффект.
Когда вопрос особенно важен
- выручка стоит, хотя трафик растёт;
- конверсия между стадиями сильно различается;
- pipeline стареет;
- много SQL, мало opportunities;
- win rate низкий в одном сегменте;
- sales cycle становится длиннее.
Как действовать
- Нарисуйте фактическую воронку за один и тот же период/когорту.
- Добавьте конверсии, деньги и время стадий.
- Посчитайте потенциальный эффект улучшения каждого перехода.
- Выберите bottleneck с высокой ценностью и управляемостью.
- Запустите одну-две гипотезы.
- Проверьте downstream: локальная метрика не должна ухудшать общий результат.
Практический пример
Если 100 MQL дают 60 SQL, но только 12 opportunities, то рост MQL на 30% создаст дополнительную нагрузку, а не обязательно продажи. Возможно, сильнее улучшить discovery, квалификацию и next step, подняв SQL → opportunity с 20% до 30%.
Как принять решение
Как интерпретировать эту матрицу
- Мало MQL. Работайте с спросом/targeting. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
- MQL → SQL слабый. Критерии и обработка. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
- SQL → opportunity слабый. Discovery/value fit. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
- Opportunity → won слабый. Pricing, proof, risk, competition, process. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
Что измерять
- stage conversion;
- time in stage;
- pipeline value;
- win rate;
- sales cycle;
- lost reasons;
- expected revenue impact of bottleneck.
Как читать метрики
Сами по себе stage conversion; и time in stage; ещё не доказывают эффект. Их нужно сравнивать с исходным уровнем, учитывать сегмент и смотреть, что происходит дальше по процессу. Если локальная метрика улучшается, а expected revenue impact of bottleneck. ухудшается или не меняется, это повод проверить, не оптимизируется ли система на удобный, но слабый proxy-показатель.
Типичные ошибки
- оптимизировать процент без абсолютных денег;
- смешивать разные когорты;
- игнорировать время;
- улучшать вход в воронку при перегруженных продажах;
- не фиксировать причины lost.
Где есть ограничения
Воронка упрощает сложную реальность: сделки могут возвращаться на стадии, иметь несколько продуктов и участников. Но даже упрощённая модель полезна, если определения стабильны.
Что проверить руководителю перед изменениями
- Что именно должно измениться, если ответ на вопрос «Как увеличить продажи с помощью B2B-воронки?» внедрён правильно?
- Какой baseline по показателю «stage conversion;» у нас есть сейчас?
- Кто владеет следующим действием и где оно фиксируется?
- Как мы отличим улучшение процесса от случайной волатильности?
- Какой сигнал заставит остановить или пересобрать гипотезу?
План проверки на ближайшие 30 дней
- Зафиксировать текущий процесс и исходные данные до изменений.
- Проверить два наиболее явных сигнала: «выручка стоит, хотя трафик растёт;» и «конверсия между стадиями сильно различается;».
- Внедрить первые 1–2 шага из плана, не меняя одновременно всю систему.
- Через согласованное окно сравнить stage conversion;, time in stage; и downstream-результат.
Короткий чек-лист
- ✓ есть чёткое определение результата, который хотим улучшить;
- ✓ есть данные до изменений — baseline;
- ✓ критерии одинаково понимают участники процесса;
- ✓ есть владелец следующего действия;
- ✓ эффект проверяется не одной метрикой, а по всей воронке;
- ✓ понятно, когда гипотезу нужно остановить или пересмотреть.