Менеджер встретился с клиентом. Встреча прошла хорошо: клиент задавал вопросы, интересовался решением, попросил сделать расчет. Компания быстро подключила технических специалистов, подготовила технико-коммерческое предложение (ТКП). Менеджер отправил файл, поставил в CRM высокую вероятность сделки. Через неделю клиент сказал: «Смотрим». Через месяц – «Пока согласовываем». Еще через месяц выяснилось, что в проект уже заложено решение другого поставщика.
Что мешает закрыть проектную продажу
Сложную B2B-сделку нельзя воспринимать как более длинную версию обычных продаж: недостаточно позвонить, выявить потребность, провести презентацию и отправить коммерческое предложение. Нужно управлять системой принятия решения. Разберу ключевые моменты, где происходит сбой.
1. Клиент – это не один человек
Одна из самых дорогих ошибок в проектных продажах – считать своим клиентом того человека, с которым удалось установить хороший контакт. Он может искренне поддерживать ваше решение, отвечать на звонки, приглашать на встречи и даже говорить, что «все выглядит хорошо». Но рядом с ним почти всегда есть другие участники: проектировщик, технический специалист, руководитель проекта, представители отделов эксплуатации, закупок, финансового блока и руководство. И у каждого из них своя логика:
- Инженеру важно, чтобы решение работало и не создало ему проблем.
- Руководителю проекта – чтобы не сорвались сроки.
- Отделу эксплуатации – чтобы с этим решением потом можно было жить.
- Отделу закупок – чтобы процедура была соблюдена, а цена выглядела обоснованной.
- Руководству – чтобы риск решения был приемлем.
Иногда человек, который больше всех разговаривает, влияет на конечный выбор меньше остальных. Поэтому недостаточно определить лицо, принимающее решение (ЛПР). Гораздо полезнее понять, какие этапы решение о сделке проходит внутри организации.
- Кто формирует требования?
- Кто сравнивает варианты?
- Кто может остановить решение?
- Кто способен его защитить?
- У кого есть формальные полномочия, а у кого – неформальное влияние?
Пока этой картины нет, менеджер не управляет проектной продажей, а лишь питает надежды.
2. Интерес клиента еще не означает движение сделки
После хорошей встречи с клиентом менеджеру психологически хочется считать, что проект движется. Но интерес и движение – разные вещи. Можно полгода быть в прекрасных отношениях с человеком со стороны клиента и не приблизиться к подписанию контракта ни на один шаг. Поэтому в проектной продаже важно отслеживать, что реально меняется в проекте после последнего контакта с клиентом.
- Появился доступ к новому участнику?
- Согласованы критерии?
- Изменилось техническое решение?
- Получены исходные данные?
- Назначена защита?
- Определен следующий шаг?
Если ничего из этого не происходит – сделка просто стоит.
3. Отправку коммерческого предложение считать окончанием работы
У менеджеров есть странная привычка считать коммерческое предложение финальной точкой работы: получили запрос, подготовили, отправили, ждем. Но оно лишь фиксирует детали предложенного решения. Если продавец не понимает критерии выбора клиента, ограничения проекта, риски и внутреннюю логику согласования, хороший PDF-файл ничего не исправит. Технический специалист может подготовить безупречное решение. Маркетолог – красиво его оформить. Компания – дать конкурентную цену. И все равно проиграть, потому что конкурент работал не с документом, а с системой принятия решения. После отправки ТКП работа не заканчивается, а становится сложнее.
- Кто будет рассматривать предложение?
- С чем его будут сравнивать?
- Какие вопросы возникнут?
- Нужно ли решение защищать перед техническим блоком?
- Попадает ли оно в бюджет?
- Кто способен заменить его на более привычный вариант?
- Что произойдет дальше?
Фраза в CRM «КП отправлено» описывает действие продавца и почти ничего не говорит о состоянии сделки.
4. Не учитывать риск изменения
Лучшее техническое решение может проиграть. Это особенно тяжело принять людям с инженерным складом мышления. Если решение объективно сильнее, кажется логичным, что его должны выбрать. Но клиент делает выбор не в лаборатории, а внутри организации. Новое решение может быть надежнее, быстрее в монтаже или выгоднее в эксплуатации – и все равно проиграть. Причины могут быть разными:
- Привычный вариант уже заложен в проект.
- Проектировщик не хочет переделывать документацию.
- Технический специалист не хочет брать на себя риск замены.
- Закупке проще сравнить три одинаковые позиции.
- Человеку, который должен защищать новое решение перед руководством, никто не дал нормальной аргументации.
В этот момент менеджер часто думает, что клиент сделал выбор только по цене. Не всегда это так. Иногда компания просто не помогла клиенту безопасно принять другое решение. В проектных продажах продавать приходится не только преимущества продукта, но и работать с риском изменения.
5. Разрыв коммуникации на стороне продавца
Сложную проектную продажу редко способен провести один менеджер. Ему нужны технические специалисты, расчетчики, проектный блок, производство, логистика, сервис, иногда юристы и руководство. Для клиента все это – одна компания, ему безразлично, что один отдел не передал информацию другому. Типичный сценарий: менеджер обещал одно, технический специалист понял задачу немного иначе, в КП появилась третья версия, сроки производства никто заранее не проверил, после заключения договора новый руководитель проекта получил документацию, но не получил контекст предыдущих переговоров. Формально каждый выполнил свою часть работы, но для клиента система дала сбой. Поэтому проектные продажи требуют управлять не только внешней картой влияния, но и собственной командой. Иначе поставщик начинает создавать для клиента тот самый риск, от которого обещал его защитить.
6. CRM не отражает реальную динамику сделки
В простой продаже этапы «Контакт», «Встреча», «КП», «Переговоры», «Договор» еще могут что-то объяснять, в проектной – этого мало. Представьте две записи в CRM cо статусом «Переговоры».
- В первой известны участники решения, техническое решение согласовано, бюджет подтвержден, через неделю назначена защита.
- Во второй – менеджер два месяца периодически звонит одному контакту и слышит: «Пока думаем».
В системе они могут находиться на одном этапе, но с точки зрения реальной вероятности сделки между ними пропасть. Поэтому хорошая воронка проектных продаж должна не только показывать, где находится сделка, но и за счет чего она должна перейти дальше.
- Есть ли следующий шаг?
- Кто за него отвечает?
- Когда он произойдет?
- Что сейчас мешает?
- Какой факт подтверждает текущий этап?
Если на эти вопросы нет ответа, процент вероятности в CRM отражает скорее настроение менеджера, чем дает прогноз по продаже.
7. Превращать гипотезы о клиенте в факты
Разбирая сложные сделки, я постоянно слышу формулировки: «Им важна цена», «Технический директор за нас», «Закупка будет давить», «Проект точно состоится», «Конкурент у них слабый». Иногда все это правда. Но сначала стоит проверить источник информации. Клиент сам так сказал? Есть документ? Кто может подтвердить информацию? Или менеджеру просто так кажется?
В проектных продажах гипотезы необходимы. Без них невозможно планировать следующий шаг. Проблема начинается тогда, когда гипотеза незаметно превращается в факт, и на ней строится дальнейшая стратегия. Поэтому разбирая сделки, не стоит сразу выдавать менеджеру советы. Сначала нужно очистить картину.
- Что мы действительно знаем?
- Чего не знаем?
- Что предполагаем?
- Что необходимо проверить?
Очень часто уже после этого становится понятно, какой следующий шаг нужен.
Вывод
Проектные продажи разваливаются постепенно. Когда не поговорили с одним из участников, не проверили одну гипотезу, отправили ТКП без обсуждения, не договорились о следующем действии, пропустили изменение проекта, не передали информацию техническому специалисту или решили, что хороший контакт означает поддержку всей организации. Подождали неделю, еще одну, а через три месяца появляется удобное объяснение: «Проиграли по цене». Как правило, цена оказывается последней видимой точкой в этой длинной цепочке.
Проектные продажи – это не набор приемов убеждения, а управление движением сложного решения через людей, технические требования, риски, деньги, сроки и внутренние процессы двух организаций. Сильный менеджер в этом деле не тот, кто говорит громче всех, и быстрее всех отправляет КП, а тот, кто в любой момент способен ответить на четыре вопроса:
- Где реально находится проект?
- Кто влияет на следующее решение?
- Что мы пока только предполагаем?
- Какой конкретный шаг должен произойти дальше?
Если ответов на них нет, то сделкой пока управляет кто-то другой.
Читайте также:
В проектных продажах очень хорошо применима работа по методологии "Карта гипотез". Это технология стратегирования, которая помогает разрабатывать стратегию, но ее легко переложить на проектую продажу.
Продавец в данном случае долден выяснить какую цель бизнеса клиента должен закрыть продукт, который продавец хочет продать. Т.е. зачем на самом деле покупателю нужен этот продукт и как он будет его использовать, на что он надеется, что благодаря этмоу продукту у него должны случиться какие-то изменения. Т.е. продавец выясняет у клиента все нюансы по сценарию использования и конечному результату, а потом подводит к тому, что его продукт в этом как раз может помочь (а конкурентный продукт не может).
Нужно сформировать в голове клиента представление о том, как наш продукт способствует достижению цели клиента и, если владеет технологией, то можно вместе с клиентом нарисовать стратегическую карту, в которой применение продукта обосновано и встраивается в цепочку стратегических решений компании.
Это сильно помогает в проектных продажах. Подробнее о "Карте гипотез" есть на специальном сайте об этой технологии.
Спасибо, для меня это описание сложных продаж как бизнес процесса с традиционным выделением формальных признаков, поэтому я не мог понять в чём смысл именно этого термина - проектные продажи в вашем случае, но это ваше право.
1. Все мои вопросы — это понять вашу логику с точки зрения решения конкретных бизнес-задач, не уходя в терминологию. Этот тип\класс продаж стоит отдельно и есть разные методологии, со своими особенностями. Эту специфику можно понять только при практическом использовании. С точки зрения тренингового бизнеса это не важно.
2. Специфика этого типа продаж как данность, неопределённость — это условие, а работа с информацией, сбор, анализ, верификация, это объективная реальность, где ошибка при работе с ней стоит конкретных денег и ресурсов. Поэтому для меня сама идея доверять мнению менеджера просто так, криминальна по умолчанию, а верификация информации — это отдельная задача.
3. Этап квалификации для компании, которая занимается корпоративными праздниками или поставками электронными компонентами один и тот же, только для рынка электронных компонентов, нужно классифицировать тип заказа (транзакционные продажи) выделять из потока
4. Лист, анкета квалификации — это артефакт, сам алгоритм его реализации зависит от контекста, но для меня это одно и тоже, в этих двух примерах принцип один, содержание разное, но в обоих случаях это не разовое действие, а встроено в систему работы.
5. Матрица прогресса – это принцип, где артефакт создаётся внутри совместно с компанией при внедрении, важно, чтобы его понижали одинаково обе стороны и его смысл, он реально и сильно влияет на текущую работ. Внедрение технологий — это отдельная проблема, поэтому я использую только функциональную\проектную модель обучения при внедрении.
6. Как проверить информацию, задать вопрос и поверить, если с употреблением умных слов я использую проективную методику верификации информации.
Я в методологии сложных продаж достаточно хорошо разбираюсь и мне было интересно понять Вашу логику и подход
Удачи и учпехов.
Николай, спасибо. Теперь я окончательно понял логику ваших вопросов — вы смотрели не столько на то, что я говорю, сколько на то, как я буду разбирать конкретные ситуации. Получился такой хороший краш-тест :)
Вы мне, кстати, давно известны. Я читал ваши материалы и неоднократно слышал о вас как о специалисте по сложным продажам. Просто сам раньше особо не выходил в публичное профессиональное поле, а сейчас вышел — и сразу попал на такую проверку на прочность :)
Если совсем коротко про мой подход: я практически на всё смотрю как на систему — на клиента, сделку, участников, информацию, обучение менеджера. А факты и гипотезы, карта влияния, встречные действия клиента, следующий шаг — это уже инструменты внутри этой логики.
Спасибо за разговор.
Мне действительно было интересно.
Вадим, спасибо. Сама работа с гипотезами мне близка.
Я бы только добавил, что в сложной сделке гипотезу важно не просто хорошо сформулировать, а проверить: кто внутри клиента её действительно разделяет, какими фактами она подтверждается и приводит ли она к реальному движению сделки.
Иначе можно построить очень красивую картину, которая существует только в голове продавца.
Если понять причину изменения формата "сделки" в цепях поставок B2B, то будут понятны и новации/механизмы APQP:
Было: плановые закупочные транзакции ГОСТированной (не большая номенклатурная изменчивость) продукции достаточно крупными партиями. Можно реализовать управление таким взаимодействием по цепям поставок силами пары специалистов (1) из службы закупок Потребителя (2) из службы Поставок Поставщика. Результат работы за год: много договоров на закупочные транзакции с поставщиками с фиксированными условиями сроков, цены, объемов и качества поставок в каждом. Один из форматов - тендеры на такие закупочные транзакции.
Стало: непрерывные реагирующие логистические транзакции (поставка миксов изделий огромной номенклатуры, минимальные партии при максимально возможной частоте, требования по срокам реагирования существенно меньше времени производства). Задача - интегрировать производство поставщика в такой виртуальный вытягивающий конвейер цепей поставок, чтобы он мог надежно, гибко и эффективно по экономике (не за счет создания огромных запасов) осуществялть такие непрерывные реагирующие логистические транзакции. Для такой интеграции необходима работа большой межфункциональной команды с возможностью транслирования такой интеграции на своих поставщиков/субпоставщиков дальше по цепям поставок. Решения в отношении поставщиков принимает руководитель APQP-команды предприятия-потребителя, взаимодействуя с APQP-командй поставщика. Результат работы: включение поставщика в виртуальный конвейер цепей поставок (одобренный поставщик), который осуществляет непрерывные логистические транзакции, характеристики которых случайны (заранее не известны). Расчет с поставщиком по-факту вытянутых поставок за месяц (сколько и чего получилось поставить, по каким ценам). Т.е. вместо договоров на фиксированные поставки с известными характеристиками, заключается рамочный договор о сотрудничестве с правилами реагирования на случайную последовательность заказов) - никаких тендеров на логистические транзакции с момента одобрения поставщика.
Например, у компании Форд для заключения сделки с новым поставщиком должна была быть выполнена программа Q1 подготовки поставщика к такой интеграции + на постоянной основе у поставщика на производстве "живут" STI инженеры чтобы следить за этой созданной интеграцией по всем аспектам (материалы, технологии, производство, качество,...).
И такие APQP-команды "живут" все время проекта (где проект, наприемер, это "выпуск и продажа по миру автомобиле ФОРД-ФОКУС 5ой платформы" где цель проекта - максимум продаж со справедливым распределением доходов и прибылей по предприяиям цепей поставок)
Владимир,
спасибо, теперь лучше понимаю рамку, которую вы описываете. Если я правильно понял, APQP здесь становится механизмом интеграции уже выбранного или проходящего процедуру одобрения поставщика в систему заказчика.
Но тогда мой вопрос остаётся именно про более раннюю точку. Есть несколько потенциальных поставщиков, требования ещё формируются, внутри заказчика разные участники по-разному видят решение, а будущая APQP-команда поставщика ещё вообще не определена.
Кто и каким инструментом в этой фазе работает с конкуренцией за само решение: понимает позиции участников, влияет на критерии, проверяет экономику и выясняет, какой поставщик в итоге попадёт в эту интеграцию?
Возможно, мы просто говорим о двух разных участках одного процесса: я — о фазе до выбора и одобрения поставщика, вы — о последующей интеграции в цепь поставок?
Так никто не выберет поставщика, если он (1) не сможет интегрироваться и (2) не сделает это лучше/конкурентнее!? Поэтому все общение по "сделке" (рассылка требований, оценка предложений, выбор/одобрение поставщика ...) идет на метриках/оргструктурах/этапах APQP-процесса. Т.е. привычных КП на языке CRM нет.
Отсюда следствие - для всех участников цепей поставок APQP формат должен быть "родным" (поэтому появился международный отраслевой автомобильный стандарт ISO TS 16949)! И этот опыт автомобильной отрасли активно мигрирует в другие отрасли... А если такое массовое распространение этот формат получает, то IT отрасль должна на этом заработать и создать продукт такой формат поддерживающий
Поэтому я и дал комментарий, что CRM как записная книжка для Закупщика/Продавца не может эмулировать этот новый существенно более сложный формат, надо бы на APQP решение переходить/осваивать...
Владимир, теперь понял вашу позицию точнее.
То есть вы говорите уже не о том, что APQP даёт отдельный инструмент вместо карты влияния или работы с участниками сделки. В вашей модели сам выбор и одобрение поставщика изначально встроены в APQP-процесс: требования, взаимодействие межфункциональных команд, оценка способности интегрироваться в цепь поставок и последующее одобрение идут внутри одной системы.
Тогда, похоже, наше расхождение действительно в области применения.
Для автомобильной цепи поставок, где такой формат является родным для заказчика и поставщиков, отдельная «продажа» в привычном понимании действительно может практически растворяться в процессе квалификации и интеграции поставщика.
Я же в статье смотрю шире — на проектные B2B-сделки, где заказчик ещё не построил вокруг потенциальных поставщиков такой единый процесс: промышленное оборудование, строительство, отдельные технические проекты, где требования формируются по ходу, участники имеют разные интересы, а поставщики ещё конкурируют за само решение.
В такой среде вопрос «кто и как влияет на формирование критериев и следующее решение» для меня всё равно остаётся.
Но теперь хотя бы понятно, что мы описываем не столько разные инструменты одной и той же продажи, сколько две разные организационные модели взаимодействия заказчика с поставщиком.
Спасибо, это прояснило вашу логику.
Это не столько автомобильный стандарт, сколько универсальная схема развертывания бизнес-проекта по участникам (цепи поставок) в условиях турбулентноси/неопределенности (автомобилисты просто первыми отработали и стандартизировали (сделали публичным) свой решение, которое оказалось эффективным/рабочим/привлекательным для активного заимствования другими отраслями), когда понятно, что в ходе развертывания и реализации проекта будет гарантированная куча изменений по ходу пьесы и работать придется в условиях огромной изменчивости спроса и постоянно меняющихся персонализированных требований. Т.е. с самого начала проекта разрабатывается виртуальный конвейер (по всей бизнес-цепочке участников), который сможет эффективно обрабатывать непрерывный поток персонализированных заказов (последовательность заказов неизвестна/непредсказуема, объемы спроса будут существенно изменчивы, изменения в продукт и технологию так же будут). Поэтому важна не отдельная логистичская закупка/транзакция (последовательность транзакций), а готовность всей бизнес-цепочки эффективно и согласованно работать в условиях этой будущей изменчивости. И такая цепочка создается на весь жизненный цикл бизнес-проекта: APQP команады участников и процесс живут от начала (разработка концепции) и до конца проекта (завершение поддержки и утилизация выпущенной продукции).
И да, по факту 2 разных набора инструментов и логик для 2х разных бизнес-сред, в которых нужно развернуть проект:
- Классическая стационарная среда, в которой можно с приемлемой для бизнеса точностью осуществлять долгосрочное планирование проекта, в которой можно разбить его на функциональные задачи, спланировать логистические транзакции и отдать управление ими на откуп парам ПродавецПоставщика vs ЗакупщикПотребителя и CRM им для этого взаимодействия в помощь
- Современная турбулентная среда, в которой невозможно осуществлять планирование с необходимой точностью, тогда нужно управлять развертыванием проекта методами реагирования по-факту складывающейся ситуации, поэтому приходится работать межфункциональной командой (нельзя разбегаться по своим "окопчикам", т.к. велик риск "напахать" ненужного/неадекватного) и готовиться к изменчивости. Это APQP подход.
И я своими комментариями всего лишь призываю не допускать классическую ошибку применения инструментов не в своей области эффективного применения. Сейчас ИМХО самая большая тенденция таких ошибок: по привычке применять функциональный подход к развертыванию проектов основанный на планировании (CRM и Закупщик-Продавец как элемент этого подхода) в турбулентной среде.
Спасибо, что корректно среагировали и в итоге правильно поняли мою мысль и тезисы (даже если не совсем с ними согласны)!
Владимир, спасибо. Нахожусь то в поезде, то на объекте, поэтому немного запздал с ответом.
Кажется, теперь как раз проявилось место, где я с Вами всё-таки не соглашусь.
Вы противопоставляете две модели: функциональную — продавец, закупщик, CRM и планирование — и современную межфункциональную, где неопределённостью управляет APQP-команда.
Но здесь, на мой взгляд, слишком сильно упрощена первая сторона сравнения.
В сложных проектных продажах давно существует межфункциональная работа вокруг конкретной возможности: продавец, инженер, проектировщик, сметчик, производство, логистика, руководство — состав зависит от сделки. И работа этой команды начинается задолго до КП.
Я специально полез посмотреть международную терминологию и обнаружил, что то, что я привык называть работой проектной команды по сделке, во многом формализовано как capture management / opportunity management: capture team, карта участников клиента, анализ конкурентов, требования и мотиваторы заказчика, win strategy, customer contact plan, bid/no-bid, вероятность выигрыша.
То есть межфункциональность и работа в неопределённости сами по себе ещё не делают процесс APQP.
APQP, насколько я теперь его понимаю, очень сильный контур там, где нужно спроектировать продукт и процесс, квалифицировать и интегрировать поставщика, управлять качеством, изменениями и запуском.
Capture отвечает на другой вопрос: как выиграть право стать этим поставщиком, когда решение ещё формируется и за него конкурируют несколько компаний.
А дальше эти контуры вполне могут встретиться.
Поэтому я бы не ставил вопрос «CRM или APQP». CRM вообще может быть просто местом хранения информации — хорошим или плохим.
Для меня интереснее другая связка:
capture / проектная продажа → выбор и квалификация → APQP / интеграция → реализация проекта.
И вот такая конструкция уже кажется мне гораздо ближе к реальному сложному B2B, чем деление мира на старые функциональные продажи и новый APQP.
Кстати, спасибо за дискуссию: благодаря ей я наконец узнал международное название части того, что много лет считал просто нормальной командной работой по сложной сделке. :)