Чтобы стабильно продавать сложные продукты, управляйте циклом сделки в B2B продажах как проектом: фиксируйте бизнес-проблему, ранжируйте стейкхолдеров, проводите управляемый пресейл, заранее собирайте требования для безопасности и согласований, затем защищайте коммерческую логику и план внедрения. Ключ - дисциплина в пресейле в продажах B2B и системная работа с ЛПР в B2B продажах.
Суть сделки за одну страницу
- Определите "зачем": формулировка бизнес-эффекта и критериев успеха до демонстраций и КП.
- Соберите карту влияния: ЛПР, спонсор, пользователи, безопасность, финансы, закупки - у каждого свой риск и свой критерий.
- Ведите пресейл как проект: план артефактов (требования, архитектура, риск-регистры, план пилота) и контроль сроков.
- Коммерцию защищайте цифрами клиента: расчёт ROI/стоимости владения на данных заказчика, плюс пакетирование.
- Согласования - отдельная воронка: заранее готовьте документы и ответы на комплаенс/ИБ/юристов.
- После продажи начинается удержание: SLA, план запуска, роли и метрики поддержки фиксируйте до подписания.
Анатомия цикла продажи сложного решения
Продажа сложных B2B продуктов уместна, когда клиенту нужно снизить операционный или регуляторный риск, внедрить изменения в процесс или ИТ-ландшафт, а цена ошибки высока. Тогда сделка неизбежно становится проектом с участием нескольких ролей и этапами согласования.
Когда метод подходит
- Есть несколько стейкхолдеров и формальная процедура закупки/согласований.
- Нужны интеграции, безопасность, пилот или поэтапный запуск.
- Решение влияет на KPI подразделений или требует изменения процессов.
Когда лучше не запускать "тяжёлую" продажу
- Проблема клиента не подтверждается фактами или не имеет владельца.
- Нет доступа к пользователям/данным для валидации эффекта, а клиент просит только "смету".
- ЛПР отсутствует в контуре, а спонсор не готов закрепить приоритет и ресурсы.
| Проблема | Действие (кто/когда) | Метрика контроля |
|---|---|---|
| Сделка "зависла" на неопределённом этапе | Менеджер фиксирует этапы и артефакты по циклу сделки в B2B продажах, согласует план следующего шага с клиентом на созвоне | Есть дата следующего шага и владелец; список артефактов на этап согласован |
| Клиент хочет демо до постановки задачи | Пресейл/AM проводит короткую диагностическую сессию и формулирует критерии успеха до демо | Записаны 3-5 критериев успеха и ограничения; демо привязано к сценариям |
| Решение воспринимается как "дорого" | Менеджер связывает стоимость с рисками/эффектом и предлагает пакет/этапность | Клиент подтвердил экономическую логику или запросил уточнение входных данных |
Этап пресейла: от квалификации до пилотного внедрения
Сильный пресейл в продажах B2B - это управляемое снижение рисков клиента (технических, организационных, финансовых) через последовательные артефакты. До старта договоритесь, что считается "достаточным доказательством" и кто принимает решение по итогам.
Что понадобится до старта пресейла
- Доступы и контакты: владелец процесса, ИТ/архитектор, ИБ/комплаенс, закупки (или тот, кто их представляет).
- Контекст: описание текущего процесса (as-is), боли, ограничения (сроки, регуляторика, политика ИБ, стек).
- Данные для расчёта эффекта: объёмы операций, затраты времени/ресурсов, стоимость ошибок/простоев (без "оценок с потолка").
- Инструменты: шаблон карты стейкхолдеров, список требований, риск-регистр, план пилота, матрица интеграций.
- Договорённости: NDA/правила обмена данными, формат демонстраций, сроки и владельцы задач со стороны клиента.
Минимальный набор артефактов пресейла
- Квалификация и границы задачи: фиксируйте, что входит/не входит, и критерии успеха, чтобы не превратить пресейл в бесплатную разработку.
- Требования и ограничения: собирайте must-have, should-have, could-have отдельно; сразу помечайте "блокеры" (ИБ/архитектура/данные).
- Решение на уровне архитектуры: схема интеграций, зоны ответственности, предположения и риски (включая зависимость от команды клиента).
- Пилот/PoC: один измеримый сценарий, данные/стенд, критерии приёмки, план отката и правила доступа.
- План внедрения: этапы, роли, сроки, требования к ресурсам и поддержке - чтобы коммерческое предложение было проверяемым.
| Проблема | Действие (кто/когда) | Метрика контроля |
|---|---|---|
| Пресейл "распухает" и не заканчивается | Руководитель продаж вместе с пресейлом фиксирует границы и платные/бесплатные активности, согласует календарь с клиентом | Есть план пресейла с датами, артефактами и владельцами; изменения проходят через согласование |
| ИБ блокирует пилот | Пресейл заранее собирает требования ИБ, предлагает безопасный формат (обезличенные данные, изолированный стенд, on-prem/контур клиента) | Согласован формат доступа и данных; назначен ответственный ИБ |
| Пилот не доказывает ценность | AM формулирует критерии приёмки и метрики эффекта до начала PoC; клиент подтверждает их письменно | Критерии успеха утверждены; есть протокол итогов PoC |
Модель взаимодействия с ЛПР, спонсорами и группой влияния
Перед шагами зафиксируйте ограничения: в сложной сделке важно не "дожимать", а управлять рисками и ожиданиями, иначе решение будет отклонено на согласованиях.
- Риск "нет владельца проблемы": встречи идут, но никто не подтверждает приоритет и ресурсы.
- Риск "теневой ЛПР": формальный ЛПР не принимает решение, а влияние у ИТ/ИБ/финансов.
- Риск "закупка отдельно от пользователя": закупки сравнивают цены, игнорируя стоимость внедрения и риски.
- Риск "непроходимость по ИБ/юристам": блокеры вскрываются слишком поздно.
- Риск "завышенные обещания": ожидания не соответствуют реальным ограничениям данных/интеграций.
-
Соберите карту влияния и критерии для каждой роли
Менеджер фиксирует: кто ЛПР, кто спонсор, кто пользователь, кто блокирует (ИБ/юристы), кто оплачивает. Для каждой роли - что для них успех и чего они боятся.
- Артефакт: одностраничная stakeholder map + список рисков по ролям.
-
Согласуйте со спонсором формулировку проблемы и приоритет
Спонсор подтверждает, что задача важна и ресурсы будут выделены; без этого пресейл часто превращается в бесконечные консультации.
- Шаблон письма (кратко): "Подтвердите, пожалуйста, что цель пилота - ...; критерии успеха - ...; ответственные со стороны вашей команды - ...; целевая дата решения - ...".
-
Проведите с пользователями диагностическую сессию вместо "общего демо"
Пресейл ведёт сессию по сценариям работы и ограничениям данных. Демо показывайте только по утверждённым сценариям - так вы снижаете риск "красивой, но нерелевантной" презентации.
-
Раннее подключение ИТ и ИБ: выявите блокеры до PoC
Назначьте отдельный созвон с архитектором и ИБ: интеграции, контуры, доступы, хранение данных, журналирование, требования к подрядчикам.
- Артефакт: список блокеров и обходных путей (варианты развёртывания, обезличивание, ограничение прав).
-
Подготовьте "пакет решения" для закупок и финансов
Менеджер переводит ценность в язык сравнения: состав поставки, границы, сроки, риски внедрения, опции. Это упрощает согласования и снижает риск демпинга.
-
Закрепите следующий шаг и критерии выхода на решение
Каждая встреча заканчивается: кто делает что, к какой дате, и какой документ/результат считается достаточным для перехода на следующий этап.
| Проблема | Действие (кто/когда) | Метрика контроля |
|---|---|---|
| ЛПР "занят", решения нет | AM договаривается со спонсором о формате решения: короткая защита на 20-30 минут с заранее отправленным одностраничником | Назначена встреча с ЛПР; подтверждён формат решения и список участников |
| Группа влияния против, хотя пользователи "за" | Пресейл проводит отдельные сессии по рискам (ИБ/ИТ/юристы), фиксирует компромиссы и ограничения в документах | Закрыты критические блокеры; есть письменные комментарии/согласования |
| Закупки сводят всё к цене | Менеджер даёт сравнимые пакеты и показывает, что входит/не входит, включая внедрение и поддержку | Клиент сравнивает пакеты по составу; запрос на финальные условия сформулирован |
Коммерческая логика: ценообразование, обоснование ROI и пакетные предложения
- Цена привязана к измеримому объёму (пользователи/транзакции/модули) и ясно описывает правила масштабирования.
- В КП есть границы поставки: что включено, что опционально, что потребует отдельного бюджета.
- Расчёт эффекта использует входные данные клиента или явно помеченные допущения, согласованные письменно.
- Показаны риски, влияющие на сроки/стоимость (качество данных, интеграции, доступность команды клиента) и способы их снизить.
- Предложены 2-3 пакета (например: базовый/расширенный/enterprise) с понятной разницей в ценности и рисках.
- Есть план внедрения по этапам и условия перехода между этапами (gate-критерии).
- Условия поддержки и SLA описаны до подписания, а не "потом в процессе".
- Порядок оплат соответствует рискам: платежи привязаны к результатам этапов, где это возможно.
| Проблема | Действие (кто/когда) | Метрика контроля |
|---|---|---|
| Клиент не верит в ROI | AM проводит рабочую сессию по финансовой модели на данных клиента и фиксирует допущения | Согласован список входных данных/допущений; у клиента есть версия модели для внутренней защиты |
| Сравнение с "дешёвым аналогом" | Менеджер предлагает пакетирование и матрицу состава: функционал, внедрение, интеграции, поддержка, риски | Клиент подтверждает, что сравнивает сопоставимые объёмы/состав |
| Слишком сложное КП, его не читают | Команда готовит одностраничник для ЛПР + приложение для ИТ/ИБ | ЛПР дал обратную связь по одностраничнику; ИТ/ИБ работают по приложению |
Управление рисками, возражениями и этапами согласования
- Ошибка: обещать сроки без проверки доступности данных и интеграций. Как исправить: вводите "условия сроков" и список зависимостей.
- Ошибка: вести переговоры только с одним контактом. Как исправить: расширяйте контур до ЛПР/спонсора/блокеров.
- Ошибка: начинать пилот без критериев приёмки и плана отката. Как исправить: утверждайте критерии и контрольные точки заранее.
- Ошибка: путать возражение "дорого" с отсутствием ценности. Как исправить: возвращайтесь к риску/эффекту, показывайте пакеты и этапность.
- Ошибка: игнорировать закупки до "финала". Как исправить: рано уточняйте процедуру и список документов.
- Ошибка: не фиксировать договорённости письменно. Как исправить: после каждого шага - краткое summary с решениями и владельцами.
- Ошибка: "продавать фичи" вместо сценариев. Как исправить: связывайте фичи с задачами пользователя и критерием успеха.
- Ошибка: не готовить юридические/ИБ документы заранее. Как исправить: держите комплект шаблонов и чек-лист по комплаенсу.
| Проблема | Действие (кто/когда) | Метрика контроля |
|---|---|---|
| Согласование договора затягивается | Менеджер заранее запрашивает список требований юристов/ИБ и запускает параллельно с пилотом | Есть перечень правок и сроков; назначены ответственные с обеих сторон |
| Возражение "у нас уже есть решение" | AM просит критерии сравнения и предлагает короткое сравнение по рискам/стоимости владения/срокам внедрения | Согласованы критерии сравнения; назначена встреча по разбору gap |
| "Сделайте ещё одну доработку в пресейле" | Руководитель пресейла отделяет обязательное для решения от опционального и переводит в платный этап/Change Request | Границы пресейла сохранены; клиент принял формат платной работы или отказался от запроса |
Организация внутренних ресурсов, SLA и план пост-продажной поддержки
Выбор модели зависит от зрелости клиента и критичности решения. Ниже - безопасные альтернативы, которые помогают не сорвать внедрение после подписания.
Вариант 1: Выделенная пресейл-команда + владелец внедрения
- Когда уместно: высокие риски интеграций/ИБ, много стейкхолдеров, длинные согласования.
- Как работает: пресейл отвечает за доказательства и дизайн, delivery owner - за план запуска и ресурсы.
- Как измерять: доля закрытых блокеров до подписания; точность плана внедрения относительно факта.
Вариант 2: "Пилот как этап контракта" с gate-критериями
- Когда уместно: клиент сомневается, нужны доказательства на его данных, но риски нужно ограничить.
- Как работает: пилот оплачивается, имеет критерии успеха и решение "масштабировать/остановить".
- Как измерять: выполнение критериев приёмки; скорость прохождения согласований после пилота.
Вариант 3: Пакет "внедрение + поддержка" с чётким SLA
- Когда уместно: клиенту важна предсказуемость, нет сильной внутренней команды эксплуатации.
- Как работает: фиксируются каналы, времена реакции, окна работ, роли, эскалации, зона ответственности.
- Как измерять: соблюдение SLA; количество критических инцидентов и время восстановления.
Вариант 4: Enablement клиента (обучение и передача знаний)
- Когда уместно: клиент хочет владеть решением внутри, требуется обучение сложным продажам B2B для их команды закупки/внедрения или enablement для админов/пользователей.
- Как работает: обучение по ролям + база знаний + контрольные задания; ответственность за эксплуатацию постепенно переносится на клиента.
- Как измерять: доля обращений, закрытых первой линией клиента; успешность самостоятельных релизов/изменений.
| Проблема | Действие (кто/когда) | Метрика контроля |
|---|---|---|
| После подписания выясняется нехватка ресурсов | Delivery owner до подписания согласует RACI, календарь и обязательства клиента, фиксирует в приложении к договору | Назначены роли и загрузка; утверждён план запуска |
| Клиент ожидает "под ключ", но это не заложено | Менеджер предлагает пакет поддержки/внедрения и явно описывает границы ответственности | Согласован SLA и состав работ; нет разночтений по зоне ответственности |
| Провалы в коммуникации между продажами и delivery | Руководитель запускает handover-встречу и чек-лист передачи: требования, риски, обещания, критерии успеха | Подписан протокол передачи; список рисков принят delivery-командой |
Ответы на типичные сложности при продвижении сложных продуктов
Что делать, если клиент просит КП без встреч и данных?
Дайте диапазон с явными допущениями и предложите 30-45 минут диагностики как условие точного расчёта. Иначе риск неверной цены и сроков будет на вашей стороне.
Как понять, кто реальный ЛПР, если все говорят "мы коллегиально"?
Спросите, кто утверждает бюджет и кто подписывает результат внедрения. Затем проверьте это через закупки или спонсора.
Как ускорить согласования ИБ и юристов?
Подключайте ИБ/юристов до пилота, выдавайте им отдельный пакет документов и фиксируйте список критических требований. Параллелите согласования с пресейлом.
Как проводить пресейл, не превращая его в бесплатный консалтинг?
Ограничьте пресейл артефактами, нужными для решения, и вводите платный пилот/аудит для глубокой проработки. Любая новая задача проходит через согласование границ.
Что отвечать на "дорого", если ценность понятна, но бюджет ограничен?
Предложите этапность, пакетирование и снижение рисков через пилот с gate-критериями. Уберите опции, не влияющие на критерии успеха.
Как не потерять сделку на этапе закупки?
Заранее уточните процедуру и критерии выбора, подготовьте сравнимые пакеты и комплект документов. Закупки должны понимать, за что они платят и что исключено.
Как связать продажи и внедрение, чтобы не сорвать ожидания?
Сделайте обязательный handover: обещания, риски, зависимости, критерии успеха и план запуска. Назначьте одного владельца результата со стороны поставщика.
