Воронка и квалификация¶
Как читать эту страницу:
Эта страница связывает всё воедино: что делает маркетинг, как работают продажи, что происходит в продукте.
Структура страницы:
- Три уровня квалификации — MQL, SQL, PQL
- Реверс-анализ — движение от факта покупки назад к продукту
- Карта JTBD конкурентов — как Планфакт, АДЕСК и другие строят свои воронки
- Три стратегии — Повторить, Улучшить, Отстроиться
От продаж к продукту: как связать Job Stories с воронкой¶
Большинство команд работают с воронкой последовательно: привлекли → квалифицировали → продали. Но самое ценное — читать эту цепочку в обратную сторону: от факта покупки назад к продукту.
Три уровня квалификации¶
MQL (Marketing Qualified Lead) — человек проявил интерес: скачал материал, подписался на рассылку, зарегистрировался на вебинар. Маркетинг считает, что он похож на потенциального клиента.
Вопрос, на который отвечает MQL: кого мы привлекаем и чем?
SQL (Sales Qualified Lead) — продажники пообщались и подтвердили: у человека есть задача, бюджет, полномочия и сроки. Вопрос SQL: кто реально готов покупать и почему?
Вопрос, на который отвечает SQL: кто реально готов покупать и почему?
PQL (Product Qualified Lead) — человек попробовал продукт (триал, демо, бесплатный тариф) и совершил действия, которые предсказывают покупку.
Вопрос, на который отвечает PQL: что в продукте приближает к оплате?
Реверс-анализ Kub24: От покупки — назад к продукту¶
От SQL к MQL¶
Что мы знаем из сессии:
Из 90-минутной сессии: 8 сегментов клиентов (аватаров), проектный бизнес даёт основной поток, торговля с товарами — уникальное преимущество. Switching-клиенты от Планфакта — важный сегмент. Но точного портрета "кто реально купил" нет — нужен анализ закрытых сделок в CRM.
Гипотезы для проверки:
- Какие должности, размер компании, отрасль у закрытых сделок за последний квартал?
- Что стало триггером обращения — переросли Планфакт, ушли от таблиц, нужен товарный учёт?
- Совпадает ли это с тем, кого привлекает маркетинг (два сайта, разное позиционирование)?
Что проверить в ProductFlow Blitz:
Анализ CRM: из каких источников приходят покупатели? Какие боли озвучивают на первом касании? Как отличаются сегменты, которые покупают, от тех, кто не конвертится?
От SQL и MQL к PQL¶
Какие действия в продукте предсказывают покупку:
Гипотезы на основе сессии и анализа конкурентов:
| Действие в продукте | Почему важно | Аналог у конкурентов |
|---|---|---|
| Подключил банковскую выписку | Переход от демо-данных к реальным — критический момент | Планфакт: 70% конвертации после загрузки выписки |
| Создал первый проект/точку продаж | Начал использовать учёт по проектам — основная Job Story | АДЕСК: настройка проектов — ключевое действие онбординга |
| Выставил 3+ счета | Активное использование core-функции | Kub24: выставление счетов за 20 сек — сильная сторона |
| Пригласил второго пользователя | Командная работа — признак серьёзности намерений | Универсальный PQL-сигнал для B2B SaaS |
| Настроил учёт обязательств (метод начисления) | Использовал уникальное УТП против Планфакта | Планфакт не закрывает — switching-триггер |
Что проверить в ProductFlow Blitz:
Аналитика продукта: какие действия совершали в триале те, кто заплатил? Какие — те, кто не конвертился? Есть ли разница между сегментами (проектный бизнес vs торговля)?
От PQL к функциональности¶
Критерий приоритизации:
Каждая задача в бэклоге должна отвечать на вопрос: влияет ли она на PQL-метрику? Если нет — это в лучшем случае удержание, в худшем — шум.
Примеры решений на основе PQL:
- PQL: подключение банковской выписки → Упростить импорт из таблиц в один шаг (снижаем барьер переключения от Excel)
- PQL: создание первого проекта → Готовые шаблоны для типовых отраслей (IT-агентство, строительство, торговля)
- PQL: настройка учёта обязательств → Объяснение на сайте "Почему метод начисления важен" + сравнение с Планфактом
Анти-примеры (не влияют на PQL):
- Интеграция с 1С — просили 3 крупных клиента, но не влияет на PQL-метрику основного сегмента
- Telegram-бот (как у АДЕСК) — nice-to-have, но не ключевое действие активации
Карта JTBD конкурентов¶
Зачем анализировать воронки конкурентов:
На ранних стадиях своих данных может быть мало. Конкуренты уже потратили деньги и время, чтобы выяснить, кто покупает, почему и как. Эта информация в значительной степени публична.
Что мы узнали из анализа выше:
- Планфакт: SQL = проектный бизнес с кассовыми разрывами | MQL = агрессивный контент про деньги | PQL = экспертное внедрение + загрузка выписки
- АДЕСК: SQL = digital-агентства | MQL = контент для IT-предпринимателей | PQL = AI-классификация + Telegram-бот
- Финансист: SQL = средний бизнес с финдиректором | MQL = профессиональный контент | PQL = сложный онбординг с обучением
- Нескучные финансы: SQL = компании без CFO | MQL = экспертиза vs софт | PQL = консультация на реальных данных
Инсайты для Kub24:
- Планфакт выигрывает не функционалом, а коммуникацией — агрессивные кейсы "найдут 500 тыс. долгов", экспертное внедрение, акцент на результате
- АДЕСК выигрывает в digital-сегменте через AI и удобство — автоматизация с первого дня, Telegram-бот
- Пространство между Планфактом и Финансистом размыто — Kub24 позиционируется "сложнее Планфакта, проще Финансиста", но это не отражено в коммуникации
Три стратегии работы с картой¶
Когда карта JTBD конкурентов составлена, по каждой задаче клиента можно выбрать одну из трёх стратегий. К разным конкурентам и разным Job Stories можно применять разные стратегии.
Повторить — задача уже подтверждена рынком, клиенты привыкли её покупать. Это необходимый минимум — то, без чего вас не будут рассматривать. Здесь не нужно изобретать, нужно соответствовать.
Пример из других рынков: Если конкурент закрывает базовую функцию (выставление счетов), её нужно повторить на уровне рынка. Иначе клиенты не будут рассматривать продукт.
Улучшить — конкурент закрывает нужную задачу, но делает это посредственно. Это видно по негативным отзывам, кривому онбордингу, частым вопросам в поддержку. Точечное улучшение при небольших затратах — часто самый выгодный ход.
Пример из других рынков: Конкурент показывает отчёты, но клиенты не понимают их. AI-интерпретация отчётов — точечное улучшение посредственного решения.
Отстроиться — задача, которую никто не закрывает, или сегмент, который все игнорируют. Это пространство для уникального позиционирования. Самый рискованный, но и самый прибыльный вариант, если задача подтвердится.
Пример из других рынков: Все конкуренты работают с проектным бизнесом. Торговля с товарным учётом — незанятая ниша.
Применение к Kub24:
Конкретные стратегии для каждой Job Story и каждого конкурента формулируются на основе реальных данных о клиентах, их поведении в продукте и причинах выбора. Это работа для ProductFlow Blitz, где анализируются записи звонков, CRM и аналитика воронки.
Что дальше¶
Карта JTBD конкурентов — это отправная точка, а не конечный результат. Она даёт гипотезы, с которыми можно войти в цепочку «квалификация → продукт» и начать проверять их на своих данных.
В ProductFlow Blitz эти гипотезы превращаются в эксперименты.
Каждый инсайт из анализа воронки — это не просто наблюдение, а потенциальная точка роста. Планфакт выигрывает коммуникацией? Проверим, как кейсы влияют на конверсию. АДЕСК берёт удобством? Протестируем, насколько AI-классификация ускоряет активацию. Switching-клиенты от Планфакта не видят себя на сайте? Запустим отдельный лендинг и измерим результат.
Эксперименты — это способ дёшево и быстро проверить, что работает, а что нет. Вместо того, чтобы строить стратегию на догадках, вы получаете данные. Вместо того, чтобы спорить о приоритетах, вы измеряете влияние на бизнес.
Переходите к разделу Эксперименты, чтобы увидеть, как гипотезы из воронки превращаются в конкретные тесты с измеримыми результатами.