Маркетинг B2B IT, SaaS и AI-компаний

Технологические команды обычно отлично знают продукт, но часто описывают его через функции: интеграции, модели, скорость, API, dashboard. Покупатель же сравнивает не функции сами по себе, а изменение текущего процесса, риск миграции и ожидаемый результат. Особенно это заметно в AI-категориях, где почти каждый конкурент использует одинаковые слова «умный», «автоматический», «агентный». Поэтому маркетинг должен сделать рынок конкретнее: кто ICP, какой use case, какой trigger, какая альтернатива и почему решение заслуживает перехода со status quo.

Экономика зависит от модели: self-service SaaS, sales-assisted SMB, enterprise software и AI-services имеют разные воронки. Для enterprise важны pipeline, sales cycle, win rate, CAC, expansion; для PLG — activation, retention, conversion to paid, expansion и unit economics. Нельзя смешивать эти модели в одном dashboard. Если компания продаёт крупным B2B-клиентам, 1000 регистраций могут быть менее ценны, чем 10 qualified opportunities.

Сегментация полезна только тогда, когда меняет действия. Если две группы отличаются названием отрасли, но имеют один buying process, одинаковую экономику и одинаковые критерии выбора, отдельные страницы и кампании могут быть лишними. Наоборот, один и тот же формальный сегмент часто стоит разделить по use case, срочности, масштабу задачи или зрелости клиента. В V5 после финальной архитектуры сайта такие сегменты можно будет связать с кейсами, исследованиями и словарём, но сейчас я намеренно не добавляю внутренние ссылки.

• User. Оценивает удобство и practical utility.
• Champion. Продвигает решение внутри компании.
• Technical buyer. Проверяет архитектуру, интеграцию и безопасность.
• Economic buyer. Решает вопрос бюджета и приоритета.
• Procurement/legal/security. Могут определять скорость enterprise-сделки.

Одна из главных причин провала сложного B2B-маркетинга — коммуникация только с человеком, который оставил заявку. Контакт может быть инициатором, но не иметь бюджета; закупки могут влиять на коммерческие условия, но не определять технический fit; пользователь может любить решение, но не управлять риском. Поэтому контент и sales enablement полезно проектировать под несколько ролей. Это не означает создание пяти одинаковых презентаций: меняются вопросы, доказательства и язык ценности.

• Search capture по сформированному demand.
• Category education для новых/неочевидных категорий.
• Founder/expert-led content и исследования.
• Outbound по trigger-based ICP.
• ABM для enterprise accounts.
• Partners/integrations/ecosystem as distribution.

Поиск и performance хорошо работают там, где клиент уже сформулировал потребность. Но в новых, сложных или проектных категориях часть рынка ещё не ищет продукт напрямую. Тогда нужны исследования, экспертный контент, кейсы, outbound, ABM, партнёрства и работа с trigger events. Полезно разделять бюджет и ожидания: search capture отвечает на существующий demand, а category/problem education помогает сформировать критерии выбора.

• Use-case pages вместо общего списка функций.
• Comparison/alternative content по реальным конкурентным сценариям.
• Security/integration documentation как часть sales enablement.
• Case studies с baseline и measurable outcome.
• ROI/TCO calculators там, где можно прозрачно задать assumptions.
• First-party research: benchmarks, anonymized usage or sales data.

Для LLM и SEO такой контент тоже сильнее generic-статей, потому что он содержит first-party опыт, структуру решения, ограничения и конкретные критерии. Важно не публиковать материал только ради количества URL. Один глубокий case/use-case hub обычно полезнее десятка текстов, где меняется лишь название услуги. Особенно ценны материалы, которые sales-команда реально отправляет клиентам в процессе сделки: это хороший признак, что контент отвечает на коммерческий вопрос, а не только на SEO-интент.

• company fit;
• use case;
• current workflow/alternative;
• size of affected team/process;
• technical prerequisites;
• role/champion;
• trigger/urgency;
• budget/process maturity;
• next step: discovery/demo/pilot.

Для enterprise SaaS маркетинг должен помогать продавцу двигать buying committee, а не только «назначать демо». После discovery у сделки должны появиться problem statement, measurable outcome, champion, technical path, economic justification и next step. Demo стоит персонализировать под use case, а не показывать весь интерфейс. Пилот должен иметь заранее согласованные success criteria. RevOps нужен, чтобы связать marketing source с opportunity, pipeline, won и expansion.

• account/company и сегмент;
• use case или тип задачи;
• fit / qualification status;
• роль контакта и известные участники buying committee;
• opportunity value или диапазон, если уже подтверждён;
• текущая стадия по прогрессу клиента;
• next step и дата следующего действия;
• причина lost/disqualification из ограниченного справочника;
• источник спроса и дата первого содержательного контакта.

• AI account research и intent enrichment;
• lead/account scoring;
• автоматический call summary и CRM capture;
• RAG для sales enablement и proposal support;
• personalization of outbound drafts with human review;
• analysis of churn, lost reasons and support themes.

AI не должен быть отдельной витриной. Полезный сценарий начинается с процесса и baseline: сколько времени занимает операция, какая цена ошибки, какие данные доступны и что остаётся человеку. Простые детерминированные действия лучше оставлять обычной автоматизации, а LLM/агентов использовать там, где есть неструктурированный текст, документы, контекст или необходимость выбрать следующий шаг. Для дорогих решений нужен human-in-the-loop и журналирование действий.

Метрики нужно читать как систему. Рост лидов не является успехом, если падает qualified rate. Низкий CPQL не гарантирует хорошую экономику, если opportunities маленькие. Большой pipeline не равен forecast, если сделки старые и без next step. Поэтому executive-уровень должен видеть деньги и движение по стадиям, а channel metrics — оставаться диагностическим слоем для команды.

1. Недели 1–2: win/loss + customer research, ICP/use case map.
2. Недели 3–4: positioning и motion per segment.
3. Месяц 2: обновить ключевой контент, qualification, demo/pilot process.
4. Месяц 3: запустить demand + outbound/ABM и собрать unified pipeline metrics.

• ✓ ясный ICP и 2–4 приоритетных сегмента/use cases;
• ✓ единые критерии qualification и причины lost;
• ✓ понятный набор core offers / value hypotheses;
• ✓ обновлённые ключевые материалы и sales enablement;
• ✓ CRM/pipeline, который можно использовать для решений;
• ✓ минимум 2–3 проверенных канала или motion с понятной экономикой;
• ✓ список гипотез, которые нужно остановить, а не продолжать по инерции.

• описывать только features;
• копировать SaaS benchmarks другой модели;
• путать users и buyers;
• масштабировать acquisition до PMF;
• называть любой trial лидом;
• не учитывать security/procurement;
• делать AI-обещания без evaluation и boundaries.

Моя роль в таких проектах — помочь перевести технический продукт в market logic: ICP, PMF, positioning, GTM, demand generation, qualification, sales enablement и коммерческую аналитику. Технические claims и architecture я проверяю совместно с product/engineering-командой.

Я не заменяю CTO, product manager или security architect. Особенно для AI-продуктов важно не обещать production reliability, accuracy или безопасность без тестирования и данных.

Первые признаки — не обязательно мгновенный рост закрытой выручки. В длинном B2B раньше меняются leading indicators: выше доля целевого спроса, быстрее обработка, меньше хаотичных статусов, лучше MQL/SQL, растёт created pipeline, сокращается aging, а причины lost становятся конкретнее. После прохождения полного sales cycle уже можно честно оценивать win rate, CAC, валовую прибыль и повторную ценность. Если ранние метрики улучшаются, а downstream — нет, это повод пересмотреть гипотезу, а не объявлять успех.