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