Менеджер встретился с клиентом. Встреча прошла хорошо: клиент задавал вопросы, интересовался решением, попросил сделать расчет. Компания быстро подключила технических специалистов, подготовила технико-коммерческое предложение (ТКП). Менеджер отправил файл, поставил в CRM высокую вероятность сделки. Через неделю клиент сказал: «Смотрим». Через месяц – «Пока согласовываем». Еще через месяц выяснилось, что в проект уже заложено решение другого поставщика.
Что мешает закрыть проектную продажу
Сложную B2B-сделку нельзя воспринимать как более длинную версию обычных продаж: недостаточно позвонить, выявить потребность, провести презентацию и отправить коммерческое предложение. Нужно управлять системой принятия решения. Разберу ключевые моменты, где происходит сбой.
1. Клиент – это не один человек
Одна из самых дорогих ошибок в проектных продажах – считать своим клиентом того человека, с которым удалось установить хороший контакт. Он может искренне поддерживать ваше решение, отвечать на звонки, приглашать на встречи и даже говорить, что «все выглядит хорошо». Но рядом с ним почти всегда есть другие участники: проектировщик, технический специалист, руководитель проекта, представители отделов эксплуатации, закупок, финансового блока и руководство. И у каждого из них своя логика:
- Инженеру важно, чтобы решение работало и не создало ему проблем.
- Руководителю проекта – чтобы не сорвались сроки.
- Отделу эксплуатации – чтобы с этим решением потом можно было жить.
- Отделу закупок – чтобы процедура была соблюдена, а цена выглядела обоснованной.
- Руководству – чтобы риск решения был приемлем.
Иногда человек, который больше всех разговаривает, влияет на конечный выбор меньше остальных. Поэтому недостаточно определить лицо, принимающее решение (ЛПР). Гораздо полезнее понять, какие этапы решение о сделке проходит внутри организации.
- Кто формирует требования?
- Кто сравнивает варианты?
- Кто может остановить решение?
- Кто способен его защитить?
- У кого есть формальные полномочия, а у кого – неформальное влияние?
Пока этой картины нет, менеджер не управляет проектной продажей, а лишь питает надежды.
2. Интерес клиента еще не означает движение сделки
После хорошей встречи с клиентом менеджеру психологически хочется считать, что проект движется. Но интерес и движение – разные вещи. Можно полгода быть в прекрасных отношениях с человеком со стороны клиента и не приблизиться к подписанию контракта ни на один шаг. Поэтому в проектной продаже важно отслеживать, что реально меняется в проекте после последнего контакта с клиентом.
- Появился доступ к новому участнику?
- Согласованы критерии?
- Изменилось техническое решение?
- Получены исходные данные?
- Назначена защита?
- Определен следующий шаг?
Если ничего из этого не происходит – сделка просто стоит.
3. Отправку коммерческого предложение считать окончанием работы
У менеджеров есть странная привычка считать коммерческое предложение финальной точкой работы: получили запрос, подготовили, отправили, ждем. Но оно лишь фиксирует детали предложенного решения. Если продавец не понимает критерии выбора клиента, ограничения проекта, риски и внутреннюю логику согласования, хороший PDF-файл ничего не исправит. Технический специалист может подготовить безупречное решение. Маркетолог – красиво его оформить. Компания – дать конкурентную цену. И все равно проиграть, потому что конкурент работал не с документом, а с системой принятия решения. После отправки ТКП работа не заканчивается, а становится сложнее.
- Кто будет рассматривать предложение?
- С чем его будут сравнивать?
- Какие вопросы возникнут?
- Нужно ли решение защищать перед техническим блоком?
- Попадает ли оно в бюджет?
- Кто способен заменить его на более привычный вариант?
- Что произойдет дальше?
Фраза в CRM «КП отправлено» описывает действие продавца и почти ничего не говорит о состоянии сделки.
4. Не учитывать риск изменения
Лучшее техническое решение может проиграть. Это особенно тяжело принять людям с инженерным складом мышления. Если решение объективно сильнее, кажется логичным, что его должны выбрать. Но клиент делает выбор не в лаборатории, а внутри организации. Новое решение может быть надежнее, быстрее в монтаже или выгоднее в эксплуатации – и все равно проиграть. Причины могут быть разными:
- Привычный вариант уже заложен в проект.
- Проектировщик не хочет переделывать документацию.
- Технический специалист не хочет брать на себя риск замены.
- Закупке проще сравнить три одинаковые позиции.
- Человеку, который должен защищать новое решение перед руководством, никто не дал нормальной аргументации.
В этот момент менеджер часто думает, что клиент сделал выбор только по цене. Не всегда это так. Иногда компания просто не помогла клиенту безопасно принять другое решение. В проектных продажах продавать приходится не только преимущества продукта, но и работать с риском изменения.
5. Разрыв коммуникации на стороне продавца
Сложную проектную продажу редко способен провести один менеджер. Ему нужны технические специалисты, расчетчики, проектный блок, производство, логистика, сервис, иногда юристы и руководство. Для клиента все это – одна компания, ему безразлично, что один отдел не передал информацию другому. Типичный сценарий: менеджер обещал одно, технический специалист понял задачу немного иначе, в КП появилась третья версия, сроки производства никто заранее не проверил, после заключения договора новый руководитель проекта получил документацию, но не получил контекст предыдущих переговоров. Формально каждый выполнил свою часть работы, но для клиента система дала сбой. Поэтому проектные продажи требуют управлять не только внешней картой влияния, но и собственной командой. Иначе поставщик начинает создавать для клиента тот самый риск, от которого обещал его защитить.
6. CRM не отражает реальную динамику сделки
В простой продаже этапы «Контакт», «Встреча», «КП», «Переговоры», «Договор» еще могут что-то объяснять, в проектной – этого мало. Представьте две записи в CRM cо статусом «Переговоры».
- В первой известны участники решения, техническое решение согласовано, бюджет подтвержден, через неделю назначена защита.
- Во второй – менеджер два месяца периодически звонит одному контакту и слышит: «Пока думаем».
В системе они могут находиться на одном этапе, но с точки зрения реальной вероятности сделки между ними пропасть. Поэтому хорошая воронка проектных продаж должна не только показывать, где находится сделка, но и за счет чего она должна перейти дальше.
- Есть ли следующий шаг?
- Кто за него отвечает?
- Когда он произойдет?
- Что сейчас мешает?
- Какой факт подтверждает текущий этап?
Если на эти вопросы нет ответа, процент вероятности в CRM отражает скорее настроение менеджера, чем дает прогноз по продаже.
7. Превращать гипотезы о клиенте в факты
Разбирая сложные сделки, я постоянно слышу формулировки: «Им важна цена», «Технический директор за нас», «Закупка будет давить», «Проект точно состоится», «Конкурент у них слабый». Иногда все это правда. Но сначала стоит проверить источник информации. Клиент сам так сказал? Есть документ? Кто может подтвердить информацию? Или менеджеру просто так кажется?
В проектных продажах гипотезы необходимы. Без них невозможно планировать следующий шаг. Проблема начинается тогда, когда гипотеза незаметно превращается в факт, и на ней строится дальнейшая стратегия. Поэтому разбирая сделки, не стоит сразу выдавать менеджеру советы. Сначала нужно очистить картину.
- Что мы действительно знаем?
- Чего не знаем?
- Что предполагаем?
- Что необходимо проверить?
Очень часто уже после этого становится понятно, какой следующий шаг нужен.
Вывод
Проектные продажи разваливаются постепенно. Когда не поговорили с одним из участников, не проверили одну гипотезу, отправили ТКП без обсуждения, не договорились о следующем действии, пропустили изменение проекта, не передали информацию техническому специалисту или решили, что хороший контакт означает поддержку всей организации. Подождали неделю, еще одну, а через три месяца появляется удобное объяснение: «Проиграли по цене». Как правило, цена оказывается последней видимой точкой в этой длинной цепочке.
Проектные продажи – это не набор приемов убеждения, а управление движением сложного решения через людей, технические требования, риски, деньги, сроки и внутренние процессы двух организаций. Сильный менеджер в этом деле не тот, кто говорит громче всех, и быстрее всех отправляет КП, а тот, кто в любой момент способен ответить на четыре вопроса:
- Где реально находится проект?
- Кто влияет на следующее решение?
- Что мы пока только предполагаем?
- Какой конкретный шаг должен произойти дальше?
Если ответов на них нет, то сделкой пока управляет кто-то другой.
Читайте также:
Николай, структуру этапов и тезис про «учить думать, а не скриптам» поддерживаю. Но перекладывание ответственности на абстрактного «руководителя, который не понимает, что требовать» — это снова уход от конкретики.
Руководитель может описать сколь угодно правильный конвейер («Квалификация — Разработка — Выбор — Решение»). Но если на первой ступени у него нет жесткого критерия приемки, конвейер начинает масштабировать брак:
Менеджер провел встречу, заполнил чек-лист экспертного интервью своими впечатлениями и отчитался: «клиент задумывается, этап пройден».
Руководитель поверил отчету и подключил расчетчиков, инженеров и производство.
На этапе закупки выясняется, что у контакта не было полномочий, а ТЗ изначально писалось под конкурента.
Поэтому требовать от менеджера нужно не отчет о проведенном интервью, а подтвержденный встречный факт от организации заказчика: согласованный протокол требований, допуск к согласующим лицам или переданные закрытые исходные данные объекта.
И мы снова возвращаемся к вопросу, на который вы так и не ответили: какой конкретный проверяемый факт со стороны клиента в вашем конвейере подтверждает руководителю, что этап квалификации реально закрыт, а не просто менеджер заполнил карточку своими гипотезами?
Николай, если на защите сделки руководитель опрашивает менеджера и анализирует его субъективные ответы — он оценивает гипотезы сотрудника, а не фактическое продвижение сделки. Менеджер может искренне верить в интерес заказчика, пока компанию используют в качестве ценового прикрытия для сравнительных таблиц.
Давайте вернемся к сути и оставим в стороне вопрос о том, «что менеджер знает».
Прямой вопрос: какой минимальный перечень встречных документов или действий со стороны заказчика (а не внутренних отчетов продавца) вы требуете предъявить на защите сделки, чтобы признать квалификацию завершенной?
Или в вашей системе координат статус сделки фиксируется исключительно по утверждениям менеджера?
Николай, обратите внимание: вы уже несколько комментариев подряд цитируете отдельные фразы и перечисляете названия базовых процедур (анкета, этапы, открытие и закрытие), но последовательно обходите главный практический вопрос.
Наличие регламентов и анкет никем не оспаривается. Вопрос исключительно в содержании:
Анкета может заполняться со слов менеджера («клиент проявил интерес, задача актуальна»), а может фиксировать подтвержденный факт от заказчика (согласована методика расчета, переданы исходные данные, назначен техсовет).
Поэтому давайте вернемся к предмету разговора: какой минимальный подтвержденный факт со стороны клиента в вашей анкете дает руководителю право считать квалификацию закрытой?
Прямой ответ - какой конкретный рынок, какой продукт, какой конретный этап сделки.
Уточняющий вопрос почему клиент должен отчитатся перед продавцом о своих действиях и тратить на это своё время, просто любопытно, хотя логика понятна, но вопрос технической реализации мне любопытен.
Почему в 99 %, я просто ещё ни разу не встречал ситуацию, когда менеджер владеет реальной ситуацией по сделке, а руководитель сам этого не понимает, но при этом мне нужно смотреть на наличие документов, что то подтверждающее.
«Без бумажки ты букашка, а с бумажкой — человек». Это самый большой риск в сложных продажах.
Николай, вот теперь появился предметный вопрос. Давайте конкретно.
Рынок — промышленное оборудование.
Продажа — сложное техническое B2B-решение с длинным циклом.
Этап — квалификация после первичного обследования потребности, до подключения расчетчиков, инженеров и других дорогих ресурсов компании.
И здесь вы, на мой взгляд, подменяете мой тезис двумя крайностями.
Я нигде не утверждал, что клиент должен «отчитываться перед продавцом» и приносить ему папку бумаг.
Встречный проверяемый факт — это не обязательно бумажка.
Например: заказчик предоставил необходимые исходные данные; допустил продавца к техническому специалисту или ЛПР; подтвердил параметры задачи; согласовал следующий шаг и участников; принял решение перейти к технической проработке.
Клиент занимается своей работой. Эти действия возникают естественно, если проект действительно движется.
А теперь самое интересное в вашем ответе.
Вы пишете, что практически не встречали ситуации, когда менеджер владеет реальной ситуацией по сделке.
Тогда возникает ровно обратный вопрос: если менеджер, по вашему собственному наблюдению, часто не владеет реальной ситуацией, почему его рассказ на защите сделки должен быть достаточным основанием для определения ее статуса?
Опытному продавцу действительно не нужен контроль как новичку — здесь я как раз за ситуационное управление.
Но ситуационность определяет глубину контроля, а не отменяет критерии реальности.
Поэтому мой вопрос остается очень простым: по каким внешним признакам руководитель отличает реальную квалифицированную сделку от убедительного рассказа опытного менеджера о ней?
Алексей, мне кажется, что мы сейчас ходим по кругу.
1.Можно ли доверять мнению менеджера на 100 % в сложных продажах нет нельзя. Это просто констатация факта, но мы это можем проверить – по-разному.
2.Ваша логика правильная, но обратите внимание у вас нет принципиально конкретного товарного рынка.Как вы будете протоколировать изменения у клиента в этих двух примерах и оценивать прогресс, мне просто любопытно.
4. Квалификация, что это значит на практике, это конкретный пример. Промышленная компания, очистные сооружения, собственное производство. Перезагрузка отдела продаж, и технических специалистов. После внедрения этого этапа и алгоритма, через год, объём продаж удвоился, а через 1,5 года в компании столкнулись с нехваткой производственных мощностей.
В примере с объектными продажами я не случайно указал товарную группу именно это определяет точку входа в проект, и мне не очень прядено как вы предполагаете защищать техническое решение именно в этом случае, но вы это тактично пропустили. Для меня конкретика это конкретные детали с учётом контекста.
Методология сложных продаж — это отдельная тема, где нет «готовых шаблонов», лично для меня это адаптационный поход для решения конкретных бизнес-задач с помощью разных методик
Проблема не в наличии форм, регламентов или правил, а в том, чтобы этим уметь пользоваться, а это две большие разницы.
Хорошая статья и хотя разобрана чуждая нам техническая специфика (наш бизнес event, MICE b2b. Но бизнес сугубо проектный и всё очень похоже, к сожалению. Перепишу для своих соттружников в event-вариант, автору СПАСИБО!
Николай, вот сейчас разговор, на мой взгляд, действительно стал предметным.
Начну с важной детали из вашего ответа:
«Лист квалификации заполняет менеджер, а его закрывает, подтверждает другой специалист».
Тогда, похоже, наши позиции ближе, чем казалось в начале дискуссии.
Потому что я как раз и говорю о том, что квалификация не должна замыкаться на самооценке менеджера.
Остается главный вопрос: на основании какой информации второй специалист подтверждает закрытие квалификации?
Если он просто ещё раз опрашивает менеджера — мы получаем вторую интерпретацию того же рассказа.
Если он проверяет фактическое состояние клиента, участников, задачи, процесса принятия решения и произошедшие изменения — мы уже говорим практически об одном принципе, только используем разные инструменты.
Теперь к вашим двум примерам.
ИТ, программы лояльности для сетевого ритейла.
Там я бы фиксировал не «универсальный документ», а изменения состояния сделки: появился владелец бизнес-задачи, доступны необходимые данные для расчета экономики, включен ИТ-блок, понятна архитектура согласования, определены критерии пилота, появился следующий совместный шаг.
Продажа спецтехники ГОКу — другой рынок и другие признаки: подтверждена производственная задача, понятен парк/цикл замены, включена техническая служба, определены условия эксплуатации, состоялась техническая проверка или испытание, понятна закупочная процедура и следующий шаг.
Артефакты разные.
Принцип один: мы фиксируем не действие продавца, а изменение состояния сделки.
Поэтому я нигде и не предлагаю универсального чек-листа для всех товарных рынков.
Теперь о терминологии.
Для меня проектная продажа — это продажа, где результат зависит не от одного коммерческого действия продавца, а от прохождения последовательности взаимозависимых решений внутри организации клиента: технических, экономических, организационных и политических.
Поэтому да, методика должна адаптироваться под рынок. Здесь я с вами согласен.
Но именно поэтому мне особенно интересна ваша фраза про второго специалиста.
Что конкретно он должен проверить, чтобы закрыть квалификацию: ответы менеджера или изменения, произошедшие в системе клиента?
Мне кажется, именно здесь проходит настоящая граница между нашими подходами — либо выяснится, что её вообще нет.
Александр, спасибо!
И для меня как раз особенно ценно, что вы увидели эту же механику в event/MICE.
Отрасли и продукт могут быть совершенно разными, но в проектной продаже очень часто повторяется одна и та же управленческая проблема: внутри компании продавца кажется, что сделка движется, а реальное изменение на стороне клиента не произошло.
Поэтому мне близка мысль смотреть не столько на отрасль, сколько на саму архитектуру сделки: кто участвует, какие решения должны быть приняты, что уже изменилось у клиента и какой следующий шаг действительно подтверждает движение.
Если перепишете под event-вариант — будет особенно интересно посмотреть, какие признаки движения сделки вы считаете ключевыми именно в MICE.