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