Проектные продажи без воды

Аннотация

В сложной B2B-продаже сделка редко решается одной встречей, одним ЛПР или последним раундом переговоров. Решение проходит через проектировщиков, технических специалистов, бюджет, закупку, подрядчиков, монтаж и эксплуатацию. Иногда продажа проиграна ещё до того, как продавец увидел тендер.

Эта книга предлагает смотреть на сложную сделку как на проект: видеть людей, технику, деньги, время, риски и следующий проверяемый шаг. Внутри — десять практических «часов», реальные обезличенные кейсы, расчёты, карты влияния и рабочий паспорт сделки.

Книга адресована менеджерам сложных B2B-продаж, инженерам и техническим специалистам, которые участвуют в коммерческой работе, а также руководителям, развивающим проектные команды.

Примечание к кейсам. Названия предприятий, компаний и участников в книге не раскрываются. В отдельных расчётных примерах цифры изменены и округлены, при этом логика и методика расчёта сохранены. Технические решения всегда должны проверяться по документации, договору и условиям конкретного проекта.

Как пользоваться этой книгой

Не пытайтесь запомнить всё. Возьмите одну живую сделку — лучше ту, где сейчас остаются вопросы. После каждого часа возвращайтесь к ней и дополняйте паспорт сделки: задача, люди, стадия проекта, техника, экономика, конкуренты, риски и следующий шаг.

«Час» в этой книге — не обещание ровно шестидесяти минут чтения. Это один практический блок. Его смысл появляется не тогда, когда глава прочитана, а когда вы проверили её на собственной сделке.

Не заполняйте пробелы догадками. Если чего-то не знаете, так и запишите: «неизвестно». Неизвестное — это не слабость, а следующая задача.

В конце книги собран короткий рабочий комплект: паспорт сделки, карта влияния, чек-лист встречи и разбор победы или проигрыша. К ним можно возвращаться уже после чтения.

Вместо предисловия

Эта книга не о том, как правильно улыбаться клиенту, куда положить руки на переговорах и какой фразой отвечать на «дорого». Не потому, что всё это совсем бесполезно. Продавцу действительно надо уметь разговаривать, задавать вопросы, работать с возражениями и проводить встречу. Просто в сложной B2B-продаже этого очень быстро становится недостаточно.

Можно прекрасно провести переговоры и всё равно проиграть сделку. Можно подготовить сильное коммерческое предложение и проиграть. Можно убедить инженера, попасть в проект, оказаться в спецификации — а оборудование в итоге поставит конкурент.

Когда я только начинал заниматься продажами, мне, как и многим, было проще смотреть на сделку линейно. Есть клиент, у него есть потребность, мы предлагаем решение, работаем с возражениями, договариваемся о цене и закрываем продажу. Для многих простых сделок такая схема вполне работает. Но чем крупнее становились проекты, тем меньше реальность была похожа на эту аккуратную последовательность.

Вместо одного клиента появлялась целая система участников: одни отвечали за технику, другие — за проект, деньги, закупку, монтаж и дальнейшую эксплуатацию. Чем крупнее становилась сделка, тем меньше работала привычная картина «один клиент — одно решение».

Все они вроде бы обсуждали одно и то же оборудование, но фактически каждый смотрел на него со своей стороны. Инженеру важно, чтобы решение технически работало. Проектировщику — чтобы его можно было обосновать и заложить в документацию. Подрядчику надо понимать, как это монтировать и не сорвёт ли решение сроки. Эксплуатация думает о надёжности и ремонте. Закупка сравнивает цену и условия. Финансы смотрят на бюджет. Руководитель проекта отвечает уже не за отдельную железку, а за результат всего проекта.

В какой-то момент я понял, что привычное слово «продажа» слишком упрощает то, чем мы на самом деле занимаемся.

Сложная сделка — это проект.

У неё есть цель, сроки, участники, ресурсы, ограничения и риски. Есть то, что мы знаем точно, и то, о чём пока только догадываемся. Есть люди, которые помогают решению двигаться, и люди, способные его остановить. Есть действия, после которых ситуация действительно меняется, а есть десятки звонков и встреч, создающих только ощущение бурной работы.

Поэтому хороший менеджер проектных продаж для меня — не тот, кто лучше всех умеет «дожимать». Он должен видеть всю систему: где находится проект сейчас, кто реально влияет на решение, что уже произошло до нашего появления, какое решение заложено, есть ли деньги, кто будет покупать, кто будет монтировать, что думает эксплуатация, где конкурент и что должно произойти дальше, чтобы сделка действительно сдвинулась.

Большая часть провалов в проектных продажах случается не потому, что продавец неудачно ответил на последнее возражение. Иногда сделка была проиграна за несколько месяцев до тендера. Просто продавец понял это только тогда, когда увидел цену конкурента.

Эта книга выросла именно из таких ситуаций. Здесь не будет попытки описать вообще всё, что существует в продажах. Мне не хочется делать ещё один учебник на несколько сотен страниц, который человек поставит на полку после первых тридцати. Гораздо интереснее дать несколько принципов, после которых менеджер по-другому посмотрит на собственные сделки.

Поэтому книга разбита на десять часов. Это десять разговоров о товаре, клиенте, проекте, объекте, деньгах, спецификации, встречах, управлении сделкой, реализации и обучении. Час здесь — не обещание ровно шестидесяти минут чтения. Это один практический блок, после которого стоит вернуться к своей реальной сделке и поработать уже с ней.

Книга написана прежде всего для менеджера, который ведёт сложные B2B-сделки, но у неё есть ещё два естественных читателя. Инженеру или техническому специалисту она помогает увидеть коммерческую сторону проекта, а руководителю — понять, как разбирать сделки и развивать людей без постоянного «ну что там?». Поэтому в одних главах я говорю с продавцом, в других — с руководителем или инженером. Это не смена аудитории, а три взгляда на одну и ту же систему.

Читать их лучше не как теорию. Возьмите одну настоящую сделку из своей CRM — желательно ту, в которой сейчас не всё понятно. После каждой главы возвращайтесь к ней и проверяйте не то, что записано в карточке, а то, что происходит в реальности.

Возможно, вы увидите, что сделка намного сильнее, чем казалось. Возможно — наоборот. Иногда полезнее вовремя понять, что возможности почти нет, чем ещё полгода честно переносить дату следующего звонка.

Паспорт сделки

На время чтения заведите один рабочий лист. Это не новая форма отчётности, а карта одной живой сделки. Держите в ней только то, что помогает действовать:

• задача клиента и применение решения;
• стадия проекта, контрольные даты и источник информации;
• участники, их интересы, влияние и отношение к решению;
• техническое решение, ограничения, документация и комплектность;
• экономика, бюджет и маршрут закупки;
• конкуренты: где они находятся в проекте, на кого опираются, чем сильнее и где мы уязвимы;
• риски и неизвестное;
• последний подтверждённый факт и следующий шаг: кто, что и к какой дате делает;
• результат реализации и урок для следующей сделки.

После каждого часа вы будете добавлять в этот паспорт один слой. Не заполняйте пустоты догадками: неизвестное так и помечайте.

Начнём с самого очевидного — с товара.

Час первый. Перестаньте продавать товар

Клиент говорит: «Мне нужен профиль». Продавец открывает каталог, уточняет размер, количество, срок поставки и начинает считать цену. В обычной торговле в этом нет ничего плохого: клиент знает, что ему требуется, продавец помогает это получить.

Но в технической продаже именно здесь иногда возникает первая ошибка. Продавец принимает название товара за задачу клиента.

Профиль сам по себе человеку почти никогда не нужен. Он хочет собрать конструкцию, закрепить оборудование, провести коммуникации, смонтировать узел, закончить участок или сдать объект. Профиль — только средство. Разница кажется словесной, пока не начинается реальный проект.

Если клиент просто хочет докупить сто метров уже известного ему профиля, не надо устраивать двухчасовое «выявление потребностей». Но если из этого профиля собирается опорная конструкция под оборудование, разговор уже другой. Появляются нагрузки, основание, геометрия, рабочая документация, требования монтажа, люди, которые будут собирать систему, и сроки, к которым всё это должно заработать.

Один и тот же запрос может означать совершенно разные продажи. В первой ситуации человеку действительно нужен товар. Во второй — решение задачи.

Запрос клиента и его задача — не одно и то же

У продавца есть естественное желание как можно быстрее получить определённость. Клиент назвал изделие — прекрасно, можно готовить коммерческое предложение. Особенно когда вокруг план продаж, звонки, CRM и ещё десять запросов.

Но в проектной продаже иногда полезно не торопиться. Что человек собирается сделать? Где это будет установлено? Есть ли рабочая документация? Кто проектировал решение? Кто будет монтировать? Какое оборудование устанавливается? Какие ограничения существуют на объекте? Есть ли уже принятое техническое решение?

Это не значит, что надо механически задавать клиенту весь список. Одна из неприятных привычек после некоторых тренингов — задавать вопросы потому, что «сейчас этап выявления потребности». Клиент пришёл за конкретной вещью, а его начинают допрашивать так, будто он пытается пересечь государственную границу.

Вопрос нужен не для выполнения методики. Он нужен тогда, когда ответ действительно меняет наше понимание ситуации. Хороший технический продавец отличается не количеством заданных вопросов. Он умеет вовремя понять, достаточно ли уже информации для нормального решения или мы всё ещё продаём почти вслепую.

У технического специалиста есть большое преимущество: он умеет видеть применение. Когда обычный продавец слышит название оборудования, инженер начинает автоматически достраивать вокруг него систему. Если это насос, появляются режимы работы, подключение, обслуживание и резервирование. Если крепление — основание, нагрузка и узел. Если шкаф автоматики — место установки, кабельные трассы, эксплуатация и смежные системы.

Для сложной B2B-продажи это огромная сила. Поэтому мне всегда немного странно противопоставление «инженер или продавец». В проектной продаже техническая и коммерческая части не конкурируют друг с другом. Просто одной инженерной компетенции недостаточно так же, как недостаточно одной коммуникабельности.

Инженер может прекрасно подобрать решение, но не понимать, кто у клиента способен его утвердить. Продавец может великолепно провести встречу, но не заметить техническую причину, из-за которой предложение никогда не примут. Сильная проектная продажа начинается в том месте, где эти две компетенции соединяются.

Я не против скриптов. Начинающему человеку они зачастую действительно нужны. Когда он впервые должен позвонить незнакомому клиенту или провести встречу, странно требовать мастерской импровизации. Нужна опора: как представиться, как начать разговор, какие вопросы задать, как перейти к следующей теме.

Скрипт помогает перестать бояться самого разговора. Проблема начинается тогда, когда учебная конструкция остаётся с человеком навсегда. Проектировщик, главный механик, закупщик и собственник не будут разговаривать по одному сценарию. Более того, два главных механика на разных предприятиях могут иметь совершенно разные задачи: один занимается модернизацией, другой пытается не допустить очередной остановки старого оборудования.

Поэтому скрипт — начальная точка, а не вершина профессии. Сначала человек учится разговаривать по структуре, а потом должен научиться понимать, когда от неё отойти.

Обратная сторона инженерной экспертности

У хорошего инженера есть одна профессиональная ловушка: ему хочется быть правым. Особенно когда перед ним человек, который технически знает меньше.

Клиент что-то сказал неточно, инженер его поправил. Потом ещё раз. Через несколько минут начинается спор, а продавец уже защищает техническую истину, которую клиент, возможно, вообще не собирался оспаривать. Формально инженер может быть абсолютно прав. Только продажа от этого почему-то не движется.

Я видел сильных технических специалистов, которые буквально перегружали клиента собственной экспертностью. Они хотели рассказать всё, объяснить каждую деталь и ответить даже на вопрос, который ещё никто не задал. Но экспертность — это не объём информации, который вы способны выдать человеку. Она ещё и в способности понять, сколько информации ему сейчас действительно требуется.

Иногда самый профессиональный ответ звучит очень просто: «Я сейчас точно не отвечу. Уточню у технического специалиста и вернусь». Такой ответ не уменьшает доверие. Нередко наоборот.

Сначала надо понять, кем должен стать инженер

Не каждого инженера вообще нужно превращать в полноценного менеджера по продажам. Есть специалисты, которым нравится глубоко работать с продуктом и техническими решениями. Есть presale-инженеры, помогающие коммерческой команде. Есть люди, много работающие с проектными институтами. А есть инженеры, которым со временем становится тесно исключительно в технической роли и хочется самим вести большие сделки. Для каждой траектории нужен свой набор навыков.

Инженеру сопровождения важно научиться понятно презентовать решение, разговаривать с проектировщиками, читать документацию, задавать хорошие технические вопросы и переводить собственную экспертизу на понятный собеседнику язык. Если человек хочет сам вести проектные продажи, этого уже мало. Появляются деньги, переговоры, карта участников, закупка, экономика решения, управление возможностью и длинным циклом сделки.

Поэтому вопрос «как научить инженера продавать?» слишком широкий. Сначала надо понять, куда именно мы хотим его привести.

Где заканчивается товар и начинается решение

Разница особенно хорошо видна на реальном объекте. Там быстро выясняется, что продукт существует не сам по себе, а внутри рабочей документации, строительной части, монтажа и ответственности нескольких сторон.

Можно идеально подобрать изделие и всё равно получить плохой результат, если оно применено не в тех условиях или если фактическая ситуация на площадке отличается от исходных данных. Поэтому техническому продавцу важно не только знать каталог, но и понимать, где проходит граница его решения и что находится вокруг него.

При этом продавец не должен брать на себя проектирование, монтаж или чужую ответственность. Наоборот, профессионал должен вовремя увидеть, когда нужен проектировщик, инженер, подрядчик или дополнительное согласование. Именно в этом смысле инженерная продажа не заканчивается выбором изделия.

Техническое решение должно быть понятно не только инженеру

Допустим, мы действительно нашли прекрасное инженерное решение. Оно надёжнее, быстрее монтируется и удобнее в эксплуатации. Этого всё ещё недостаточно.

Главный механик может прекрасно понимать преимущество, но финансовый директор увидит увеличение бюджета. Проектировщик поддерживает решение, а закупка получает спецификацию и сравнивает три цены. Подрядчику продукт нравится, но он не заложил нужную стоимость работ.

Поэтому техническое решение должно уметь разговаривать на разных языках. С инженером — о технической задаче. С производством — о производительности и простоях. С финансовым директором — о деньгах. С руководителем проекта — о сроках и рисках. С закупкой — о цене, комплектности и условиях.

Сам продукт от этого не меняется. Меняется та часть его ценности, которую должен увидеть конкретный человек. И здесь мы уже вплотную подходим к проектному мышлению.

Что проверить после первого часа

1. Какую задачу решает клиент — за пределами названия товара?
2. Каких технических данных не хватает для честного предложения?
3. Где заканчивается ваша компетенция и кого надо подключить?

Обновите паспорт сделки: запишите задачу клиента, применение решения, известные ограничения и ближайшее действие по проверке данных.

Час второй. Клиент — это система

Когда продавца учат искать ЛПР, ему предлагают довольно удобную картину: найдите человека, который принимает решение, поймите его интересы, убедите его — и сделка пойдёт дальше. Для простой продажи этого иногда действительно достаточно. В крупной B2B-сделке такая логика быстро начинает ломаться.

В одной крупной проектной сделке, по моим подсчётам, получалось около двенадцати-тринадцати участников, которые прямо или косвенно влияли на результат. Кто-то отвечал за техническую часть, кто-то за проект, кто-то за деньги, закупку или монтаж. Были и люди, которые формально почти ничего не решали, но без их поддержки движение становилось намного сложнее.

Поэтому выражение «найти ЛПР» я воспринимаю как полезное упрощение для начала обучения. В реальной сложной продаже одного человека, который единолично принимает всё решение, может вообще не существовать. Гораздо полезнее задать другой вопрос: какую часть решения контролирует каждый участник? Именно с этого начинается нормальная карта сделки.

Один продукт покупают разные люди

Представим обычную проектную ситуацию. Проектировщику надо понять, можно ли решение заложить в документацию и насколько легко потом его защитить. Главный инженер смотрит на техническую состоятельность. Сметчик проверяет стоимость и комплектность. Закупка сравнивает предложения и условия. Подрядчику важно, насколько решение реально смонтировать в срок. Эксплуатация думает уже о надёжности, ремонтах и дальнейшем обслуживании. Финансовая служба видит бюджет, а руководитель проекта отвечает за общий результат. Все они могут обсуждать один продукт, но фактически у каждого свой критерий хорошего решения.

Именно поэтому техническая презентация, которая прекрасно работает с инженером, может почти ничего не дать при встрече с руководителем проекта. А аргумент о снижении эксплуатационных затрат, важный главному механику, не обязательно решит вопрос закупщика, которому сегодня надо уложиться в утверждённый бюджет.

Задача продавца не в том, чтобы каждому рассказывать совершенно новую историю. Основа решения остаётся одной. Но надо понимать, какую часть этой истории должен увидеть конкретный человек.

Должность даёт гипотезу, но не ответ

Должностями удобно пользоваться как первой ориентировкой. От главного инженера мы ожидаем внимания к технической стороне, от закупки — к цене и условиям, от финансового директора — к деньгам, от собственника — к бизнесу и развитию. Но два человека с одинаковой должностью могут обладать совершенно разным влиянием.

На одном предприятии главный инженер фактически контролирует почти все серьёзные технические решения. На другом конкретным проектом глубоко занимается руководитель проекта, а главный инженер подключается только в ключевых точках. В одной компании закупка получает готовую спецификацию и проводит процедуру. В другой закупщик способен серьёзно повлиять на выбор поставщика.

Поэтому должность — это начало разговора, а не готовая карта. Надо понимать, что для человека важно именно сейчас, за что он отвечает, кому сам должен объяснять решение, чего опасается и где у него есть реальные полномочия. Только после этого должность превращается в роль внутри сделки.

Организационная схема показывает, кто кому подчиняется. Карта влияния показывает, кто реально способен изменить решение. Иногда эти две картины совпадают. Иногда — совсем нет.

Человек с высокой должностью может почти не участвовать в выборе конкретного оборудования, а специалист среднего уровня глубоко вести техническую часть и фактически определять, какие решения вообще попадут на следующий этап.

Бывает и наоборот. Команда месяцами прорабатывает проект, всё выглядит согласованным, а потом появляется руководитель более высокого уровня, задаёт один вопрос — и вся конструкция начинает двигаться в другую сторону.

Менеджер обычно описывает такую ситуацию словами: «Неожиданно появился ещё один человек». Я бы сформулировал иначе: мы просто не до конца построили карту сделки.

Это не всегда можно предотвратить. В больших проектах действительно появляются новые участники, меняются люди и структура ответственности. Но если неожиданные фигуры возникают постоянно, значит, продавец работает в основном с теми, кого уже видит, и слишком мало пытается понять систему вокруг них.

Есть ещё одно заблуждение: будто входить в компанию обязательно надо сверху. Сначала директор, потом заместители, потом руководители подразделений.

В жизни первый контакт часто находится совсем в другом месте. Это может быть инженер, снабженец, специалист ПТО, прораб, проектировщик или человек на объекте, с которым вообще удалось познакомиться благодаря текущей технической задаче.

В этом нет ничего плохого. Важно не с какой ступени началась работа, а способен ли менеджер постепенно восстановить всю систему вокруг неё.

Разговаривая с одним участником, можно совершенно естественно узнавать, кто ещё включён в процесс. Кто отвечает за проект? С кем согласуется техническое решение? Кому дальше передают документацию? Кто формирует заявку? Кто будет принимать результат? Кто потом будет эксплуатировать систему?

Так одна фамилия постепенно превращается в карту. Причём для этого совсем не обязательно задавать клиенту вопрос в духе: «Назовите мне всех лиц, принимающих решение». Нормальный рабочий разговор сам даёт достаточно информации, если продавец умеет её замечать.

Проектировщик покупает возможность нормально спроектировать

Продавцы иногда относятся к проектировщику так, словно его задача — взять каталог поставщика и аккуратно переписать нужную позицию в проект.

У проектировщика совсем другая ответственность. Ему надо выпустить документацию, обосновать техническое решение, пройти согласование и не создать проблему, которую потом придётся переделывать.

Есть ещё один фактор: проект выпускается сегодня, а оборудование могут покупать значительно позже. Поэтому проектировщик далеко не всегда хочет слишком жёстко привязывать решение к конкретному производителю.

Если это понимать, меняется и разговор. Вместо просьбы «заложите нас» появляется вопрос: что можно дать проектировщику, чтобы с нашим решением ему было удобно работать? Расчёт, узел, чертёж, технические характеристики, нормальную спецификацию, поддержку при согласовании. Фактически мы продаём ему не оборудование. Мы продаём возможность спокойно выполнить свою часть проекта.

На строительном объекте огромный объём информации проходит через ПТО. Рабочая документация, графики, объёмы, изменения, исполнительная часть, данные о том, какие работы идут сейчас и что должно появиться следующим.

Это не означает, что ПТО всегда принимает коммерческое решение. Но для продавца оно может стать очень сильным информационным узлом.

Если работать только с закупкой, мы видим момент покупки. Если разговаривать ещё и с техническими и производственными участниками, начинаем видеть, почему эта покупка вообще возникла, на какой стадии находится объект и что потребуется дальше. Так продавец перестаёт реагировать только на готовые запросы и начинает понимать проект заранее.

Закупщик часто получает продукт уже в конце длинной цепочки. Перед ним спецификация, техническое задание или заявка. Его задача — обеспечить закупку на подходящих условиях. Поэтому разговор закономерно сводится к цене.

Продавцы иногда раздражаются: «Им ничего не важно, кроме того, чтобы купить дешевле». Но в большинстве случаев человек просто выполняет свою функцию.

Проблема возникает не тогда, когда закупка спрашивает о цене. Проблема возникает, если к этому моменту ценность решения существует только в голове самого продавца.

Если техническая часть не проработана, комплектность непонятна, эксплуатация не видит преимуществ, а экономика решения нигде не зафиксирована, закупщик действительно получает несколько предложений, очень похожих друг на друга. Тогда цена становится главным видимым различием. Поэтому часть переговоров с закупкой выигрывается задолго до самой закупки.

Подрядчику нужен результат, который можно реализовать. Красивое техническое решение, которое сложно или невозможно нормально смонтировать, для него быстро превращается в проблему.

Особенно когда сроки уже идут, люди стоят на площадке, заказчик спрашивает выполнение, а непонятный узел не позволяет двигаться дальше.

Поэтому подрядчик смотрит на систему иначе, чем проектировщик. Его интересуют комплектность, доступность, понятные узлы, скорость монтажа, техническая поддержка и возможность быстро решить вопрос на объекте.

Проектировщик создаёт решение на бумаге. Подрядчик отвечает за то, чтобы оно появилось в реальности. Это два разных взгляда на одну и ту же продажу.

Эксплуатация остаётся с оборудованием намного дольше почти всех остальных участников проекта. Проектировщик выпустил документацию. Подрядчик закончил монтаж. Проектная команда сдала объект. А эксплуатация осталась.

Для главного механика, энергетика или другого технического специалиста становятся особенно важны надёжность, ремонтопригодность, запасные части, сервис и последствия остановки.

Поэтому аргумент, который для закупки кажется второстепенным, здесь может оказаться главным. Разница в закупочной цене может быть сравнительно небольшой, а стоимость серьёзного простоя — совсем другой.

Но этот разговор невозможно провести, если продавец даже не знает, кто будет отвечать за оборудование после ввода.

Карта коммерческого контура

В простой сделке карта участников может уместиться на половине листа. В крупной компании или холдинге одной оргструктуры быстро становится мало. Формально у вас есть юридические лица, заводы, подразделения, проектные офисы и службы закупок. Реально же решение может проходить ещё через внешний проектный институт, корпоративную техническую функцию, генподрядчика, профильного подрядчика и отдельную процедуру технической оценки.

Мне приходилось строить такие карты для очень большого корпоративного контура. Рабочий файл выглядел почти пугающе: множество предприятий, проектных организаций, подразделений, подрядчиков и закупочных маршрутов. Показывать такую карту целиком кому-то со стороны бессмысленно. Ценность была не в количестве прямоугольников, а в том, что на ней становился виден маршрут решения.

Я разделял связи на основные и второстепенные. Основная линия показывала, как движется конкретная потребность: от подразделения, где она возникла, через приоритизацию и бюджет, проектирование, техническую оценку, закупку и дальше к реализации. Второстепенные линии показывали не «менее важных людей», а дополнительный контур влияния: корпоративные функции, соседние подразделения, проектные институты, сервисные организации, подрядчиков, тех, кто согласует или способен затормозить решение.

Потребность → приоритизация и бюджет → проектирование → техническая оценка → закупка → подрядчик → эксплуатация.

На реальном проекте эта линия почти никогда не бывает идеально прямой. Заявка может родиться в цехе, бюджет собираться на другом уровне, техническое задание уйти во внешний институт, техническая оценка вернуться в корпоративный центр, а закупку проведёт совсем другая организация. Поэтому я подписывал не только людей и компании, но и сами связи: «заявка», «ТЗ», «согласование», «техническая оценка», «торги». Тогда карта начинает отвечать не только на вопрос «кто здесь есть», но и на вопрос «что между ними происходит».

Ещё один полезный приём — отмечать качество знания. У меня было три рабочих состояния: знаем и понимаем, знаем, но не понимаем реальную роль, не знаем. Это дисциплинирует. Фамилия в телефоне ещё не означает, что вы понимаете влияние человека. А пустое место на карте лучше красивой догадки, потому что оно превращается в конкретную задачу.

Не надо копировать структуру всего холдинга. Карта должна быть ровно настолько большой, насколько требует текущая возможность. Если ваша продажа проходит через три организации и семь человек — отлично. Если через двадцать подразделений и несколько юридических лиц, придётся рисовать больше. Смысл один: отделить формальную структуру от реального коммерческого контура сделки.

Подробно разделять факты, гипотезы и неизвестное мы будем в восьмом часу, когда перейдём от карты участников к управлению самой возможностью. Здесь достаточно одного правила: не заполняйте пробелы уверенностью только потому, что на схеме некрасиво оставлять пустое место.

Что проверить после второго часа

1. Кто реально влияет на техническое, финансовое и закупочное решение?
2. Где у вас факт, а где только гипотеза о роли или отношении человека?
3. Какой важный участник пока отсутствует на карте?

Обновите паспорт сделки: добавьте карту участников с их интересами, влиянием и статусом информации.

Час третий. Найдите проект раньше закупки

Когда у закупщика на столе уже лежат три коммерческих предложения, продавцу легко кажется, что борьба только начинается. Иногда к этому моменту основная борьба уже закончилась.

Техническое решение могло быть выбрано несколько месяцев назад. Проектировщик выпустил документацию, сметчик посчитал стоимость, бюджет согласовали, подрядчик понял, что ему предстоит покупать, а закупка теперь просто собирает предложения и сравнивает условия.

Продавец входит в сделку на самом заметном для него этапе — когда появляется запрос цены. Отсюда возникает иллюзия, что именно запрос и является началом продажи.

В проектных продажах всё устроено иначе. Запрос цены часто означает, что значительная часть решений уже принята без нас.

В проект можно войти слишком поздно

Меня иногда спрашивают, на какой стадии лучше начинать работу по проекту. Мне ближе другой вопрос: когда уже поздно?

Понятие «слишком рано» в проектных продажах достаточно условно. Если проект только планируется, это не означает, что менеджеру надо каждую неделю беспокоить клиента. Работа просто будет иметь другую интенсивность.

Сегодня достаточно узнать, что проект существует, кто им занимается и когда появится следующий значимый этап. Через несколько месяцев можно вернуться, получить новые данные и двигаться дальше.

Главное преимущество раннего входа — не возможность как можно дольше общаться с клиентом. Главное преимущество — время для действий.

Можно понять техническую задачу, познакомиться с нужными людьми, помочь проектировщику, подготовить расчёт, проверить экономику, разобраться с будущими подрядчиками.

Поздний вход выглядит совсем иначе. Вам присылают готовую спецификацию и просят дать цену до пятницы. В документе уже стоит чужое решение, под которое ваше оборудование ещё надо попытаться адаптировать. Участвовать можно и на этом этапе, но количество доступных вариантов уже сильно уменьшилось.

Особенно хорошо это видно на тендерах. Менеджер видит объявленную процедуру и говорит: «Появилась новая возможность». Я бы сначала спросил: кто работал с этой возможностью раньше?

Если техническое задание явно сформировано вокруг конкретного решения, заказчик не хочет обсуждать альтернативу, а конкурент давно работает с проектом, надо честно оценить шансы.

Участие в тендере тоже стоит денег. Нужны инженерные часы, расчёты, документы, согласования, работа коммерческой команды. Если всё это делается ради процедуры, где вероятность победы близка к нулю, компания просто тратит ресурс.

Это не значит, что в поздние тендеры нельзя заходить. Иногда есть возможность предложить сильную альтернативу, изменить решение или выиграть за счёт условий. Но проектные продажи не должны превращаться в фабрику коммерческих предложений для проектов, которые месяцами формировали другие.

Отмотайте закупку назад

Описанный дальше маршрут — типовая карта, а не обязательная последовательность. Состав документации, порядок согласований, роли и закупочная процедура зависят от проекта, договора и организации заказчика.

Чтобы понять, где на самом деле начинается возможность, полезно мысленно отмотать готовую закупку назад. Закупщик получил заявку. До заявки была спецификация. До спецификации — рабочая документация. До документации — техническое решение. До технического решения существовали исходные данные, задача и проектирование. А ещё раньше кто-то вообще решил, что надо построить, реконструировать или модернизировать объект. Вот это и есть проектный маршрут.

Инвестиционная задача → исходные данные → проектирование → рабочая документация → бюджет → закупка → реализация.

Продавцу необязательно присутствовать с момента рождения инвестиционной идеи. Но он должен понимать путь от текущей стадии до момента, когда его продукт реально понадобится. В проектной продаже время становится таким же коммерческим параметром, как цена или характеристики оборудования.

ГПР можно читать как коммерческую карту

График производства работ создавался не для продавцов. Для строителя это инструмент управления стройкой. Но для проектного менеджера он даёт очень полезную информацию о будущем спросе.

Если сегодня идёт устройство фундамента, а мой продукт понадобится только при монтаже инженерных систем через восемь месяцев, я понимаю сразу две вещи. Поставки сегодня не будет, но через восемь месяцев будет поздно начинать знакомство.

Значит, сейчас надо выяснить, кто проектирует нужный раздел, кто будет выполнять работы, когда выйдет рабочая документация, какое решение рассматривается и когда появится закупка.

Так график строительства превращается в коммерческую карту. Продавец смотрит не только на то, какие работы выполняются сегодня, но и на то, какие потребности появятся завтра.

Именно поэтому техническому менеджеру полезно понимать хотя бы базовую логику строительства. Не для того, чтобы заменить прораба, а чтобы чувствовать время собственной продажи.

Официальный график есть не всегда

Конечно, никто не обязан выдавать продавцу полный график проекта. И это не критично. Опытный менеджер может многое понять по самому объекту: какие работы идут, кто уже находится на площадке, какие материалы завозятся, какие подрядчики появились, какой участок готовят следующим.

Иногда короткий разговор с начальником участка даёт больше, чем несколько недель переписки. Если прораб говорит, что инженерные сети заходят через месяц, для проектного продавца это уже конкретная информация. Теперь можно проверять подрядчика, рабочую документацию, спецификацию, состояние закупки. Объект начинает восприниматься не как адрес, а как последовательность будущих коммерческих событий.

Проект и объект — не одно и то же

Большой проект часто состоит из множества объектов, участков и систем. У каждого могут быть свои подрядчики, сроки, документация и потенциал.

Если продавец записал всё это одной строкой «крупный проект», он пока почти ничего не понял.

Нужно спускаться ниже. Какие объекты входят в проект? Где есть наши применения? Кто проектирует конкретный участок? Кто будет выполнять работы? Когда появится потребность? Каков примерный объём? Один участок может дать серьёзную поставку, другой вообще не иметь отношения к нашему продукту.

Поэтому проект даёт общий контекст, а объект и применение превращают его в конкретную коммерческую возможность.

Очень легко увидеть стоимость строительства в миллиарды и мысленно записать себе огромную продажу. Связи между этими цифрами может вообще не быть.

В гигантском проекте ваше применение иногда стоит относительно немного. И наоборот, на небольшом участке может находиться сложное и дорогое оборудование. Поэтому общий бюджет проекта полезен для понимания масштаба, но он не равен вашему потенциалу.

Мне нравится более практичная цепочка: проект, объект, применение, спецификация, деньги. Пока не найдено применение, разговор о потенциале часто остаётся слишком абстрактным.

Если продукт можно заложить на стадии проектирования, проектировщик становится одним из самых важных ранних контактов. Не потому, что он всегда принимает окончательное решение, а потому, что он формирует техническую основу, с которой потом будут работать остальные.

Приходить к нему в последний момент с предложением переделать уже готовую документацию только ради своей марки — слабая позиция. Человек несколько месяцев работал над проектом, проходил согласования, отвечал на замечания, а теперь поставщик просит изменить решение ради собственной продажи.

Совсем иначе выглядит работа, когда поставщик появился в момент, когда техническая задача ещё открыта. Он может дать расчёт, узел, подбор, исходные данные, помочь разобраться со сложным применением. Тогда он не просит проектировщика «вписать бренд». Он приносит инженерную ценность.

Здесь продавцы иногда впадают в противоположную крайность. Продукт появился в проекте — и сделка почти мысленно записана в победы.

На самом деле после проектировщика начинается ещё длинный путь. Решение попадёт в смету. Потом в бюджет. Появятся подрядчики. Закупка будет сравнивать предложения. Кто-то предложит аналог. Кто-то захочет оптимизировать стоимость.

На этом этапе достаточно увидеть маршрут дальше: техническое решение ещё должно пройти через стоимость, бюджет и закупку. К тому, почему сама спецификация ничего не гарантирует, мы отдельно вернёмся в шестом часу.

Деньги появляются раньше закупщика

Именно поэтому я не ограничивал бы раннюю работу только технической частью. Хорошее решение может быть полностью поддержано инженерами и всё равно погибнуть из-за бюджета. Если наш вариант дороже, лучше понимать это заранее. Возможно, надо показать снижение трудозатрат, более быстрый монтаж, стоимость владения, снижение рисков или эксплуатационные преимущества. Когда экономика впервые появляется за два дня до тендера, возможностей для защиты уже мало.

Получается, что ранний вход нужен не только для проектирования. Он нужен, чтобы провести решение через техническую и экономическую логику ещё до момента, когда всё сведётся к закупочной цене.

Не каждый ранний проект заслуживает одинакового внимания

Если проект найден на ранней стадии, это не значит, что теперь менеджер должен тратить на него максимум времени.

Один проект действительно активно развивается. Другой пока заморожен. Третий большой, но наш продукт понадобится только через год. Четвёртый уже почти ушёл конкуренту. Интенсивность работы должна быть разной.

Я не вижу смысла еженедельно звонить клиенту, если следующий важный этап наступит через два месяца. Лучше заранее определить контрольную точку и понять, что надо сделать до неё.

Проектные продажи плохо сочетаются с активностью ради активности. Важно не сколько действий совершил менеджер, а зачем каждое действие происходит именно сейчас.

Как выглядит ранняя работа

Допустим, мы узнали, что через год планируется новый производственный корпус. Пока нет ни заявки, ни спецификации, ни закупки. Это не означает, что делать нечего.

Надо понять общий контур: кто заказчик, кто проектирует, какая стадия, где потенциально применяется наш продукт, когда начнётся строительство, кто может быть подрядчиком.

После этого появляются вполне конкретные задачи. Выйти на проектировщика, проверить применение, получить исходные данные, подготовить решение, проверить экономику, понять участников будущей реализации.

Реальный проект в любом случае будет меняться, но у менеджера появляется маршрут. Это намного полезнее записи «перспективный проект, держим на контроле».

Что проверить после третьего часа

1. На какой стадии находится проект и чем это подтверждено?
2. Какой маршрут пройдёт решение до закупки?
3. Какое событие определяет момент, когда ваш продукт действительно понадобится?

Обновите паспорт сделки: внесите стадию, контрольные даты, источник информации и ближайшую точку входа.

Час четвёртый. Выйдите из кабинета

Есть вещи, которым можно хорошо научить продавца в переговорной комнате. Можно разобрать структуру встречи, потренировать вопросы, обсудить возражения, научиться готовить презентацию. Всё это полезно.

Но часть проектных и объектных продаж становится понятной только после того, как человек сам оказывается на проходной предприятия или строительной площадке.

В кабинете продавец находится в безопасной среде. Он знает тему занятия, примерно понимает, что сейчас произойдёт, и может в любой момент получить подсказку тренера. На объекте ему могут отказать ещё до встречи, не оформить пропуск, потребовать документы, которых нет, отправить за каской. А человек, ради которого он ехал два часа, может вообще оказаться занят.

Если встреча всё-таки состоится, клиент почти наверняка задаст не тот вопрос, который был в учебном сценарии.

Именно поэтому полевые продажи для меня — отдельный профессиональный навык. Не потому, что там действуют какие-то секретные техники. Просто поле быстро убирает всё искусственное и оставляет человека один на один с реальной ситуацией.

Компания сначала должна дать возможность работать в поле

Менеджеру легко поставить задачу: «Езди на объекты». Но для входа на серьёзные площадки зачастую нужны пропуска, предварительное обучение, спецодежда, документы, иногда оформление автомобиля. На режимных объектах действуют ограничения на фото, телефоны, планшеты и другую технику.

У меня самого была ситуация, когда на объекте выяснилось, что планшет с собой проносить нельзя. Его пришлось временно оставить. Ничего страшного не произошло, но такие истории быстро учат уважать правила площадки.

Особенно странно требовать от менеджера активной полевой работы, если сама компания не обеспечила ему нормальный доступ.

Это касается не только пропусков. Продавцу нужны понятный продукт, рабочие цены, техническая поддержка, документы, возможность быстро получить расчёт и выполнить то, что он пообещал клиенту.

Если менеджер хорошо провёл встречу, вернулся в офис и две недели ждёт внутри своей компании обычное коммерческое предложение, проблема находится уже не только в продавце. Поле очень быстро показывает качество всей системы.

Приехать на объект и отметить в CRM «встреча состоялась» недостаточно. У поездки должен быть смысл.

Иногда после неё появляется новый участник, документ, техническая информация, понимание стадии, договорённость о расчёте или демонстрации. Иногда результат отрицательный: проект остановлен, наш продукт не нужен, конкурента уже выбрали. Отрицательный результат тоже полезен, если он уменьшил неопределённость.

Гораздо хуже, когда человек весь день ездит по территории, вечером записывает несколько визитов, а сам не может объяснить, что изменилось хотя бы в одной возможности.

Я не считаю, что руководитель должен устраивать после каждого визита допрос. Но движение работы должно быть видно не только по километрам и количеству встреч.

На площадке особенно хорошо видно, насколько менеджер понимает контекст. Какой этап сейчас идёт? Кто реально работает? Какой подрядчик отвечает за нужный участок? Что уже смонтировано? Какие материалы завозятся? Есть ли рабочая документация? Соответствует ли то, что построено, тому, что было заложено в проекте? Последний вопрос бывает самым интересным. Именно на объекте проектный чертёж впервые встречается с реальностью.

На бумаге поверхность может быть ровной. На площадке она имеет перепады. В проекте стоит одно оборудование, а фактически пришла другая модификация. Размеры немного изменились. Смежная система заняла пространство, которое считалось свободным.

До этого момента все могли быть правы. Проектировщик правильно спроектировал по исходным данным. Поставщик правильно подобрал решение. Подрядчик приехал монтировать по рабочей документации. А дальше появляется бетон.

Чертёж и бетон разговаривают на разных языках

Один из шефмонтажей фальшпола хорошо показал эту разницу. До выезда задача была понятной: есть рабочая документация, есть монтажная система, надо разобрать с подрядчиком последовательность сборки, показать основные узлы и помочь начать работу.

На объекте оказалось, что основание имеет заметные перепады, а часть фактических условий отличается от исходных.

Можно было ограничиться инструкцией по сборке. Показать, где поставить профиль, как соединить элементы, и считать техническую консультацию выполненной. Но вопрос подрядчика был шире.

Если система устанавливается на неровное основание, надо понимать фактические отметки, возможности регулировки и предел, после которого уже нельзя просто «подкрутить конструкцию». Кроме того, возникает вопрос ответственности: если подрядчик начал монтаж на неподготовленной строительной части, а позже готовый пол не совпал с требуемой отметкой, кто будет исправлять результат?

Поэтому пришлось говорить не только о монтаже, но и о фиксации фактического состояния строительной части до начала работ.

В одной маленькой ситуации сошлись рабочая документация, техническое решение, ответственность подрядчика, генподрядчик и реальный объект. Такое очень трудно почувствовать по презентации.

Менеджер не обязан становиться проектировщиком и тем более брать на себя чужую техническую ответственность. Но если он продаёт инженерные решения и совсем не ориентируется в рабочей документации, значительная часть проекта для него остаётся закрытой.

Чертёж помогает понять, где находится оборудование, как оно связано со смежными системами, какие размеры заложены и где именно появляется наш продукт.

Это важно не ради статуса «я умею читать чертежи». Рабочая документация создаёт общий язык с участниками проекта.

С монтажником можно открыть конкретный узел. С подрядчиком обсудить участок. С проектировщиком уточнить решение. С руководителем проекта показать место, где возникло отклонение.

Продавец всё равно не будет знать ответы на все технические вопросы. И это нормально. Но желательно хотя бы понимать, какой вопрос сейчас надо задать инженеру.

Не изображайте инженера, если вы им не являетесь

Несколько лет технических продаж дают человеку огромный объём прикладного опыта. Постепенно он начинает понимать стройку, оборудование, монтаж и документацию. Именно здесь появляется опасность почувствовать себя специалистом вообще во всём.

Я спокойно отношусь к фразе «не знаю, уточню». Иногда это самый профессиональный ответ, который можно дать клиенту. Особенно на объекте, где ошибка может привести не к неудачной презентации, а к реальной переделке.

Опыт должен помогать продавцу лучше понимать ситуацию и задавать более точные вопросы, а не создавать иллюзию всезнания. Уверенно произнесённая техническая ерунда на объекте стоит намного дороже, чем пауза на уточнение.

Проектировщика и закупку продавец обычно знает хорошо. Монтажников иногда замечают только после поставки. Но именно монтажник первым физически работает с решением.

Если система непонятная, документация слабая, сборка сложная, а на вопрос никто не отвечает, отношение к продукту формируется очень быстро.

Поэтому шефмонтаж для меня — это не просто передача инструкции. Надо разобрать чертежи, показать последовательность сборки, собрать первый образец, объяснить ключевые узлы и убедиться, что люди понимают, как дальше работать самостоятельно. Иногда дополнительный час в начале экономит несколько дней переделок.

Есть здесь и долгосрочный коммерческий смысл. Подрядчики переходят с объекта на объект. Монтажники запоминают решения, с которыми было удобно работать, и те, с которыми больше не хотят сталкиваться. Технический опыт одной реализации постепенно начинает влиять на будущие продажи.

Шефмонтаж начинается до приезда

Состав шефмонтажа и полномочия специалиста определяются договором, документацией и его компетенцией. При необходимости специалист фиксирует выявленные отклонения в рамках согласованной процедуры; решения за проектировщика, подрядчика или заказчика он не принимает.

Само слово «шефмонтаж» иногда воспринимают слишком узко: специалист приехал и рассказал, как собирать. Для нормальной работы желательно ещё до выезда понять, готова ли строительная часть, получить актуальную рабочую документацию, проверить данные по оборудованию и заранее узнать требования по доступу на объект.

Потом уже идёт сама площадка: разметка, контроль основных отметок, первый участок, разбор последовательности монтажа, ответы на вопросы.

И обязательно надо смотреть на изменения. Проект мог жить несколько месяцев. Размеры изменились. Оборудование заменили. Строительная часть выполнена немного иначе. Где-то система спокойно это компенсирует, где-то нужен проектировщик, а где-то монтаж лучше вообще не начинать до устранения проблемы. В этом смысле шефмонтаж показывает, насколько проектное решение выдерживает встречу с фактическими условиями объекта.

Кабинет нужен, но его недостаточно

Я не противопоставляю теорию и поле. Нельзя отправить неподготовленного человека на серьёзный промышленный объект и считать, что жизнь сама его всему научит. В кабинете надо изучить продукт, структуру встречи, типовые вопросы, документацию и основные ситуации.

Но потом человек должен столкнуться с настоящим клиентом. Получить реальный отказ. Пройти проходную. Самому начать разговор. Ответить на неожиданный вопрос. Увидеть объект и понять, что реальность немного сложнее учебной модели.

Только тогда знания начинают превращаться в навык. А подробно о том, как именно учиться на таких живых ситуациях, мы вернёмся в последнем часу книги.

Что проверить после четвёртого часа

1. Что на объекте нужно увидеть, измерить или подтвердить лично?
2. Какая версия документации сейчас актуальна?
3. Кто отвечает за решение при обнаружении отклонений?

Обновите паспорт сделки: запишите фактическое состояние объекта, расхождения с документацией и согласованное действие.

Час пятый. Переведите технику в деньги

Инженер может доказать, что решение лучше. Продавцу этого недостаточно. В какой-то момент в сделке всё равно появляется человек, который задаёт простой вопрос: сколько это стоит и зачем компании платить больше?

Вот здесь техническая аргументация должна превратиться в экономическую. Не в красивую формулу ради презентации и не в попытку доказать, что дорогое всегда лучше. Надо показать, что именно меняется в деньгах, времени, производительности, обслуживании или рисках, если клиент выбирает одно решение вместо другого.

Для меня в этом и состоит смысл нормального технико-экономического обоснования. Оно не обязательно должно быть огромным документом с десятками вкладок. Иногда достаточно одной честной и понятной логики, если она действительно связана с работой предприятия.

Клиент покупает не характеристику, а результат

Техническому специалисту естественно разговаривать характеристиками: ресурс, материал, производительность, точность, способ монтажа, класс защиты, удобство обслуживания. Всё это важно, но само по себе ещё не объясняет бизнесу, зачем менять существующее решение или платить больше. Надо сделать следующий шаг и спросить: что изменится после покупки?

Если новое оборудование позволяет выполнять операцию быстрее, насколько сокращается время? Если реже требует обслуживания, сколько остановок можно избежать? Если монтажная система дороже в закупке, но требует меньше операций и людей, что происходит с общей стоимостью монтажа? В этот момент продукт перестаёт быть набором характеристик. Он начинает участвовать в экономике клиента.

Кейс: считать не инструмент, а технологию

На одном производственном предприятии мы вместе с технологами сравнивали пневматическую и аккумуляторную технологию. Если смотреть только на цену инструмента, аккумуляторный вариант выглядел заметно дороже. Но пневматический гайковёрт не существует сам по себе. За ним стоят компрессор, электроэнергия, воздушная сеть, шланги, обслуживание, ремонты и ограничение мобильности оператора.

Поэтому мы посчитали не два инструмента, а две технологии. В реальном расчёте использовались данные предприятия: режим работы, наработка компрессоров, стоимость электроэнергии, расходы на обслуживание и требуемый парк инструмента. Затем решение проверяли на производственной операции, а не только в Excel. На одной из операций испытания показали примерно двукратное сокращение цикла, но для меня важнее было другое: технологи увидели связь между техническим решением и экономикой участка.

Ниже я сознательно меняю и округляю цифры, чтобы не публиковать внутренние данные предприятия. Логика расчёта остаётся той же. Допустим, компрессорная схема вместе с электроэнергией и обслуживанием стоит около 1,52 млн рублей в год. Зарядка и эксплуатационные расходы аккумуляторного парка — около 0,19 млн. Разница по текущим расходам составляет примерно 1,33 млн рублей в год. Если дополнительная первоначальная инвестиция в аккумуляторный парк относительно существующей схемы составляет около 2 млн рублей, простой срок окупаемости получается около полутора лет.

Это упрощённая модель. В настоящем ТЭО надо учитывать всё существенное именно для данного предприятия: замену батарей, ремонт, резервный парк, срок службы, режим смен, стоимость простоя и, если проект этого требует, стоимость денег во времени. Но сам принцип простой: цена изделия — только одна строка в экономике применения.

И это уже совсем другой разговор с клиентом. Не «наш инструмент современнее», а «что произойдёт с технологией, производительностью и затратами участка, если изменить способ выполнения операции».

Директор по производству и закупщик могут смотреть на один продукт и видеть совершенно разные вещи.

Для закупки разница между двумя предложениями может составлять двести тысяч рублей. Для производственника важнее, сколько продукции выпускается за смену, как часто возникает простой и хватает ли людей для выполнения плана.

Главный механик будет думать о надёжности, ремонте и доступности запасных частей. Руководитель проекта — о сроках и риске переделки. Финансовый директор — о бюджете, графике платежей и общей экономике.

Поэтому выражение «для клиента это выгоднее» слишком общее. Для кого именно выгоднее и за счёт чего?

Проектный продавец должен понимать не только общую экономику решения, но и то, какая её часть важна конкретному человеку.

Цена продукта и стоимость решения — не одно и то же

Допустим, первое предложение стоит миллион рублей, второе — миллион двести. Если больше никакой информации нет, вся дискуссия естественно вращается вокруг разницы в двести тысяч.

Теперь добавим монтаж. Для первого решения нужно больше операций и рабочего времени. Затем обслуживание. Возможно, часть компонентов придётся менять чаще. Потом простой оборудования и стоимость выезда сервисной команды. Картина начинает меняться.

Но это не означает, что более дорогое решение автоматически становится выгоднее. После расчёта вполне может оказаться, что дешёвый вариант действительно рациональнее. И это нормальный результат.

ТЭО не должно быть способом любой ценой доказать превосходство собственного продукта. Его задача — сделать сравнение честнее.

Если расчёт показывает, что у нашего решения нет достаточной экономической ценности в конкретном применении, лучше понять это самому, чем пытаться убедить клиента при помощи придуманных цифр.

В сложных B2B-продажах полезно смотреть не только на стоимость покупки, но и на последствия неправильного решения.

Для одного продукта ошибка означает просто заменить позицию через несколько дней. Для другого — переделывать уже выполненный монтаж. На производстве отказ оборудования способен остановить участок. В проекте ошибка может привести к сдвигу срока и конфликту нескольких подрядчиков.

Поэтому, когда клиент говорит: «У вас дороже на сто тысяч», важно понимать, с чем эти сто тысяч вообще сравниваются.

Если потенциальная ошибка стоит десять тысяч, нет смысла переплачивать миллион ради её предотвращения. Если один день остановки стоит значительно больше разницы в цене, экономика становится другой.

Но стоимость ошибки нельзя придумывать за клиента. Лучше считать вместе с ним на реальных данных или хотя бы на согласованном диапазоне. Тогда аргумент принадлежит не только продавцу.

Кейс: дороже за штуку — дешевле в конструкции

На другом предприятии мы вместе с технологами испытывали два варианта механического крепления по металлу. Один крепёж стоил дороже за штуку. Если бы закупка сравнила только прайс, на этом разговор можно было закончить. Но испытания показали разницу в количестве точек, браке и времени на одну конструкцию. До экономики решение сначала прошло техническую проверку: способность работать по реальному металлу, качество монтажа и устойчивость соединения.

Цифры ниже также изменены, но формула сохранена. Пусть вариант А стоит 12 рублей за штуку, вариант Б — 8. На одну конструкцию требуется 84 крепления варианта А и 116 варианта Б. У первого на испытании не было брака, у второго для примера примем 25 отбракованных креплений на конструкцию. Монтаж одной конструкции занимает 14 и 19 минут соответственно. При стоимости часа работы 230 рублей расчёт на тысячу конструкций выглядит уже иначе.

Дешёвый элемент оказался дороже в применении. Именно поэтому техническое испытание и ТЭО надо соединять. Сначала мы доказываем, что решение работает. Потом считаем, что его применение меняет в процессе и в деньгах.

Финансовый директор быстро проверяет качество аргументации

Разговор с финансами хорошо отрезвляет технического специалиста. Можно долго рассказывать о прекрасной конструкции, но финансовому директору надо понимать, что происходит с деньгами.

У проекта есть бюджет. Есть инвестиционные лимиты, графики платежей, иногда банковские гарантии, отсрочки и ограничения по капитальным затратам. Если в бюджете заложен миллион, а наше решение стоит миллион двести, человек не может просто изменить цифру потому, что техническому отделу понравился продукт. Нужно объяснение.

Может быть, дополнительные двести тысяч сокращают последующие расходы. Возможно, решение уменьшает время монтажа или стоимость обслуживания. Иногда можно изменить схему оплаты. В другой ситуации потребуется поднять вопрос на более высокий управленческий уровень и доказать, зачем вообще пересматривать исходный бюджет. Технический аргумент при этом никуда не исчезает. Он просто должен пройти следующий уровень проверки.

CAPEX и OPEX полезны только тогда, когда за ними есть реальная логика

Можно научить продавца словам CAPEX и OPEX, но от этого он не начинает лучше считать экономику клиента.

Смысл довольно простой. Одни деньги компания тратит на создание или модернизацию актива, другие — на его дальнейшую работу.

Если оборудование дешевле купить, но значительно дороже обслуживать, сравнивать только стартовую цену недостаточно. Если оборудование дороже, а экономия возникает только через двадцать лет, клиент тоже имеет право спросить, зачем ему переплачивать сейчас.

Универсального правильного ответа здесь нет. Есть конкретный срок проекта, конкретный режим эксплуатации и конкретная экономика предприятия.

Именно поэтому продавцу полезно не бросаться экономическими терминами, а понимать, где на самом деле находятся деньги.

Иногда продавец пытается доказать окупаемость исключительно техническими характеристиками оборудования. Но деньги могут находиться совсем в другом месте: в монтаже, логистике, комплектности, количестве операций, числе рабочих, сервисе, времени ответа или уменьшении переделок.

Представим подрядчика, у которого десять человек остановились из-за непонятного узла. Зарплата идёт, срок проекта продолжает идти, смежные работы ждут.

Один поставщик отвечает через три дня. Второй подключает технического специалиста в тот же день и помогает решить вопрос. Продукты могут быть очень похожи. Коммерческая ценность поставщиков — уже нет. Такую вещь трудно красиво указать одной строкой в каталоге. Она подтверждается только реальной работой.

Фраза «наша система быстрее монтируется» звучит хорошо, пока клиент не спрашивает: насколько быстрее? Вот здесь начинается полезная работа.

Надо взять реальный участок, сравнить количество операций, понять состав бригады, оценить время и стоимость рабочего часа. Иногда более дорогой материал действительно позволяет заметно сократить трудозатраты. Тогда у продавца появляется не рекламный лозунг, а расчёт.

Вместо «монтаж быстрее» можно говорить о конкретном количестве человеко-часов. Это уже аргумент, который способен пройти от монтажника к руководителю проекта, а дальше — к финансам.

Когда говорят «технико-экономическое обоснование», легко представить сложную финансовую модель. Иногда такая модель действительно нужна. Но начало почти всегда намного проще. Сначала надо понять, какой экономический параметр вообще меняется благодаря нашему решению.

Если производительность — насколько? Если обслуживание — какие расходы уменьшаются? Если простой — сколько он стоит? Если монтаж — сколько операций и часов экономится? Если ресурс — насколько реже происходит замена? После этого уже можно строить таблицы.

Обратный путь работает плохо. Самая бесполезная модель — та, где продавец сначала открывает Excel, а потом самостоятельно придумывает все исходные данные.

Это одна из самых опасных привычек. Продавец хочет показать выгоду и говорит: «У вас рабочий получает примерно столько-то», «простой наверняка стоит миллион», «вы экономите двадцать процентов». Откуда цифры? Обычно выясняется, что это приблизительная оценка поставщика.

На внутреннем тренинге она может выглядеть убедительно. На встрече с человеком, который действительно знает экономику предприятия, модель разваливается очень быстро.

Поэтому если мне нужна стоимость простоя, я стараюсь узнать её у клиента. Если точную цифру не дают, можно согласовать диапазон. Если нужна стоимость рабочего часа, лучше считать её вместе. Совместно принятая цифра намного сильнее цифры, которую поставщик принёс в своей презентации.

«Дорого» не всегда означает проблему цены

Когда клиент говорит «дорого», продавцу хочется сразу защищать цену или просить скидку. Но эта фраза может означать очень разные вещи.

В бюджете действительно нет денег. Клиент не понял ценность. Он сравнивает разную комплектность. Конкурент предложил дешевле. Закупщик просто начинает обычный торг. Или экономический эффект решения действительно недостаточен. Поэтому сначала полезно понять, с чем именно сравнивают нашу цену.

Иногда после одного уточняющего вопроса оказывается, что проблема вообще не в цене. А иногда становится ясно, что цена действительно является проблемой и никакая презентация её не отменит. Оба ответа полезны.

Скидка не должна заменять работу продавца

Скидки нужны. Есть рынок, объём, условия сделки, стратегические клиенты и переговоры. Иногда снижение цены абсолютно обосновано. Проблема появляется тогда, когда скидка становится единственным ответом продавца на любое сомнение клиента.

Если каждый разговор о цене заканчивается просьбой руководителю дать ещё пять процентов, менеджер постепенно учит клиента одному: достаточно немного подождать, и предложение станет дешевле.

В проектных продажах это особенно обидно. Компания могла месяцами работать с проектировщиком, делать расчёты, ездить на объект, помогать подрядчику, а в конце продавец сам превращает всю проделанную работу в спор о последнем проценте.

Иногда этот процент всё равно придётся отдать. Но сначала надо понимать, за что мы вообще торгуемся.

Экономическая логика должна появиться до закупки

Если техническое решение дороже, обсуждать его экономику лучше задолго до последнего раунда торгов. С инженером можно говорить о последствиях отказа. С производством — о производительности. С подрядчиком — о трудозатратах. С эксплуатацией — о сервисе и ресурсе. С руководителем проекта — о сроках и переделках.

Когда эти кусочки постепенно собираются вместе, финансовому директору или закупке уже не приходится впервые слышать объяснение ценности на финальном этапе.

Решение приходит к ним подготовленным. Это не отменяет переговоров по цене, но сильно меняет их качество.

Иногда премиальная цена просто не оправдана

Есть ситуация, о которой продавцы говорят неохотно. Не всякое более дорогое решение можно экономически защитить.

Можно иметь хороший бренд, сильную техническую поддержку и прекрасный продукт. Но именно в данном применении клиент не получает результата, который оправдывает разницу. В этом случае не надо придумывать фантастическую стоимость ошибки или искусственно раздувать риски. Возможно, это просто не лучшее применение для нашего продукта.

Понимание таких границ делает продавца сильнее. Он начинает видеть не только то, где товар можно продать, но и то, где его преимущества действительно стоят денег для клиента. Вот здесь инженерная компетенция и коммерческая логика начинают работать вместе.

Что проверить после пятого часа

1. Из чего складывается стоимость решения для клиента, кроме цены продукта?
2. Какие экономические выводы подтверждены его данными?
3. Где цена действительно решает, а где она прикрывает другой риск?

Обновите паспорт сделки: добавьте экономику решения, исходные данные, допущения и человека, который их подтвердит.

Час шестой. Спецификация — ещё не победа

Попасть в проект приятно. Несколько месяцев работали с проектировщиком, делали расчёты, готовили узлы и технические материалы, а потом наконец увидели своё решение в документации. В этот момент очень легко внутренне записать сделку в победы. Но спецификация ещё ничего не поставила на объект.

Между строкой в проекте и реальной поставкой остаются смета, бюджет, подрядчики, закупка, возможные аналоги и изменения самого проекта. Если продавец после попадания в документацию перестаёт сопровождать решение, через несколько месяцев он вполне может увидеть на площадке продукт конкурента.

Проектировщик заканчивает свою работу раньше продавца

Проектировщик способен сыграть огромную роль в техническом выборе. Он может помочь сформировать решение, заложить его в документацию и аргументировать применение. Но потом проект движется дальше.

Спецификация попадает к заказчику и сметчикам. Определяется бюджет. Появляется генподрядчик. Затем профильные подрядчики, закупка и реальная стройка.

И в какой-то момент кто-нибудь обязательно спросит: обязательно ли покупать именно то, что было заложено? Особенно если альтернативный вариант стоит дешевле.

Это не означает, что проектировщик плохо защищает собственное решение. Просто его зона ответственности не равна всей коммерческой цепочке. Именно поэтому попадание в проект — сильная позиция, но не окончательная победа.

Решение меняют по вполне рациональным причинам

Продавцу легко воспринимать замену как несправедливость. Мы работали, помогали проектировщику, считали, готовили техническую часть, а потом кто-то решил поставить другое. Но причины замены бывают совершенно нормальными.

Проект выпустили год назад, цены изменились. Нужного продукта нет в наличии. Появился новый подрядчик. Бюджет сократили. Заказчик начал оптимизацию. Срок поставки исходного решения не устраивает стройку. Бывает и проще: закупка видит две похожие позиции и спрашивает, зачем платить больше.

С точки зрения продавца это может выглядеть как обесценивание всей предыдущей работы. На самом деле это просто следующий этап продажи. Если решение действительно нельзя заменить без потери результата, надо уметь это объяснить.

Защищать надо техническую логику, а не название производителя

Самая слабая защита спецификации — надеяться, что конкретное название бренда само по себе остановит замену.

Намного устойчивее решение, у которого понятна техническая логика. Почему выбраны именно эти параметры? Что является критичным? Что можно заменить без проблем, а что нельзя? Какова комплектность? Что изменится в монтаже или эксплуатации при выборе другого варианта? Тогда разговор об аналоге перестаёт быть спором производителей. Появляется инженерное сравнение.

Мне близка именно такая позиция. Защита спецификации не должна держаться на искусственно завышенной цене, закрытости или попытке любой ценой не пустить конкурента. Она должна держаться на технической необходимости, понятной комплектности и честной экономике.

Если альтернативное решение действительно выполняет ту же задачу и выгоднее клиенту, это надо уметь признать. Если же более низкая цена появилась потому, что из системы просто исчезла часть необходимых элементов, надо показать это предметно.

Комплектность способна полностью изменить сравнение

В технических продажах два коммерческих предложения часто выглядят одинаковыми только на первой странице. Одно стоит миллион. Второе — восемьсот тысяч. Закупка видит экономию.

Но дальше выясняется, что в первом предложении учтена вся система, а во втором отсутствует часть комплектующих.

В сложных монтажных решениях это особенно заметно. Цена складывается не из одного изделия, а из профилей, соединителей, крепежа, опорных элементов и других компонентов. Поэтому фраза «у конкурента не всё учтено» слишком слабая.

Нужно открыть две комплектации и сравнить их по существу. Какой элемент отсутствует? Для чего он нужен? Можно ли без него реализовать решение? Если можно — значит, возможно, мы действительно заложили лишнее. Если нельзя — первоначальное сравнение цен было некорректным.

Такая работа полезна и клиенту, и продавцу. Она возвращает разговор из области эмоций в область фактов.

Смета превращает техническое решение в бюджет

Проектные продавцы много говорят о проектировщиках и закупке, но иногда недостаточно внимания уделяют тому, что находится между ними. Смете.

Я сам разбирался со сметной логикой и работал с GRAND-Сметой не потому, что собирался становиться профессиональным сметчиком. Мне важно было понимать, как техническое решение превращается в деньги проекта.

Какая позиция попала в расчёт? Учтена ли комплектность? Соответствует ли стоимость реальному решению? Не потерялись ли важные элементы? Какая сумма в итоге уходит в бюджет?

Можно выиграть техническую часть и обнаружить намного позже, что финансово решение никто нормально не подготовил. Тогда проблема возвращается в самый неудобный момент — перед закупкой.

Есть понятный соблазн заложить в проект максимально высокую цену. Кажется, что потом будет проще: бюджет уже большой, а мы дадим скидку.

Иногда такая логика работает. Но у неё есть обратная сторона. Слишком дорогая позиция начинает привлекать внимание. Её хочется оптимизировать, заменить, разбить или вообще удалить.

Искусственно занижать цену тоже плохо. Если проект согласовали исходя из одной стоимости, а к реальной закупке поставщик приходит с цифрой значительно выше, возникает закономерный вопрос: зачем тогда была нужна ранняя оценка?

Поэтому проектная цена должна быть настолько реалистичной, насколько это вообще возможно на данной стадии. С разумным запасом на известные риски, но без фантазии.

После попадания в проект мне важно понимать, что с решением происходит дальше. Выпущена ли рабочая документация? Прошла ли согласование? Есть ли позиция в смете? Кто будет генподрядчиком? Определён ли субподрядчик? Когда появится закупка? Кто способен инициировать замену? Это уже не работа с одним документом. Это сопровождение маршрута решения.

Поэтому проектный продавец не должен исчезать после фразы «нас заложили». Проект продолжает двигаться, и вместе с ним должна двигаться работа поставщика.

Один проектировщик не защитит всю поставку

Хорошие отношения с проектировщиком — сильная вещь. Но нельзя ожидать, что человек будет следующие полтора года лично защищать нашу позицию на всех уровнях.

После выхода документации его работа по этому участку может практически закончиться. А дальше появляются совсем другие участники.

Проектировщик способен подтвердить техническую логику. Эксплуатация — объяснить значимость надёжности. Подрядчик — рассказать о монтаже. Руководитель проекта — оценить влияние решения на общий срок.

Чем сложнее сделка, тем слабее она держится на одном союзнике. Устойчивость появляется тогда, когда ценность решения понимают несколько важных участников.

Когда решение доходит до стройки, подрядчику надо его реализовать. У него есть срок, люди и бюджет.

Если система кажется сложной, нужного материала нет или знакомое решение можно получить быстрее, возникает желание заменить. Продавцу легко отреагировать эмоционально: «Они ломают проект». Полезнее сначала понять причину. Цена? Наличие? Срок? Непонятный монтаж? Недостаток документации? Люди не знают систему?

Иногда хорошее техническое сопровождение снимает проблему быстрее любого коммерческого давления. Если подрядчик видит, что поставщик отвечает, помогает и понимает реальную площадку, мотивация искать замену может заметно уменьшиться.

Конкурент — часть маршрута сделки

Конкурента полезно видеть не как название в поле CRM, а как ещё одного участника проекта. Где он появился раньше нас? На каком уровне уже закрепился? Какое техническое решение предлагает? Кто у клиента ему доверяет и почему? Что он делает лучше нас, а где у него возникает риск? И самое важное: что из этого мы знаем фактически, а что просто рассказываем себе после проигранного тендера?

На одном объекте мы осознанно пошли в борьбу за часть поставки, где у заказчика уже был действующий поставщик с хорошей историей на предыдущих очередях. Наше решение технически допустили, мы понимали участников и всё равно проиграли. Причина была не мистической: для этого участка клиент не увидел достаточного смысла менять хорошо зарекомендовавшую себя систему при более привлекательной цене действующего поставщика. Такой проигрыш полезнее объяснения «нас слили». Он показывает, где конкурент действительно сильнее и где не надо выдумывать ценность, которой для клиента нет.

Поэтому в паспорте сделки я бы фиксировал не только название конкурента, а его положение в проекте: решение, союзников, сильную сторону, нашу уязвимость и следующий факт, который надо проверить. Тогда конкурентный анализ становится частью работы, а не посмертным объяснением результата.

Аналог надо проверять, а не объявлять

Слово «аналог» в технических продажах иногда используют слишком легко. Похож размер — аналог. Есть та же функция — аналог. Стоит дешевле — тем более аналог. На самом деле эквивалентность надо проверять по тем параметрам, которые критичны именно для применения.

Совпадают ли основные характеристики? Меняется ли монтаж? Нужна ли переделка узла? Сохраняется ли комплектность? Есть ли эксплуатационные ограничения? Выполняется ли расчётное требование? После такой проверки иногда становится ясно, что альтернативное решение действительно подходит. Хорошо.

А иногда оказывается, что замена одной строки тянет за собой изменение целого участка системы. И это уже вполне предметная причина сохранить исходное решение.

Проект живёт. Исходные данные могут поменяться. Оборудование заменили, нагрузки изменились, строительная часть получилась другой, появился новый технологический режим. В такой ситуации бессмысленно защищать старую спецификацию только потому, что там стоит наше название. Надо снова спросить: что требуется проекту сейчас?

Если под новые условия подходит другое наше решение — меняем. Если по объективным причинам лучше решение конкурента, профессиональнее признать это, чем пытаться продавить неподходящий продукт. Долгосрочное доверие технического клиента обычно ценнее одной случайной позиции.

Спецификация — не медаль за выполненную работу. Это важная контрольная точка большого маршрута, после которой решение снова зависит от людей, денег, документов и конкретных действий.

Что проверить после шестого часа

1. Где сейчас находится решение: в документации, смете, бюджете или уже в закупке?
2. Кто и по какой причине способен инициировать замену?
3. Сопоставима ли комплектность вариантов при сравнении?

Обновите паспорт сделки: внесите маршрут решения, угрозы замены и следующее действие по защите технической логики.

Час седьмой. Встреча должна что-то изменить

В проектных продажах очень легко перепутать активность с движением. Менеджер звонит, ездит на встречи, отправляет презентации и коммерческие предложения. CRM заполнена, календарь плотный, работа явно идёт. Только сама сделка может месяцами оставаться в том же состоянии.

Поэтому мне не очень нравятся цели вроде «познакомиться» или «обсудить сотрудничество». Это допустимые действия, но они почти ничего не говорят о результате.

После хорошей встречи должно измениться наше понимание сделки или сама сделка. Иначе мы просто хорошо поговорили.

Цель встречи появляется до входа в кабинет

Не каждую встречу надо превращать в сложную операцию с длинным планом. Но в большой сделке менеджер хотя бы должен понимать, зачем идёт к конкретному человеку.

«Рассказать о компании» — слабая цель. «Понять, кто отвечает за техническое решение, получить исходные данные и договориться о следующем техническом разборе» — уже намного сильнее.

Такая цель сразу влияет на подготовку. Становится понятно, какие вопросы нужны, какие материалы взять и что считать результатом.

Одна встреча редко закрывает всю проектную продажу. Обычно она должна открыть следующий участок работы: получить чертёж, выйти на главного инженера, согласовать демонстрацию, провести расчёт, познакомиться с проектировщиком. Небольшие шаги постепенно складываются в большую сделку.

Следующий шаг должен соответствовать реальности

Есть обратная крайность — пытаться любой ценой закончить встречу большим обязательством клиента. Первая техническая встреча, а продавец уже пытается закрыть договор.

В сложном проекте это часто просто не соответствует стадии. Если впереди проектирование, расчёт, смета, согласование и закупка, нельзя перепрыгнуть весь маршрут одной красивой презентацией.

Следующий шаг должен быть достаточно небольшим, чтобы клиент действительно мог его сделать, и достаточно значимым, чтобы после него состояние сделки изменилось. И это не обязательно всегда действие клиента.

Иногда мы объективно ждём внешнего события: выпуска документации, решения комиссии, определения подрядчика. В таком случае нормальным следующим шагом может быть контакт после конкретной даты. Но важно понимать, почему именно тогда и что к этому моменту должно измениться.

«Позвонить через неделю» — слабая запись. «Через неделю выходит новая ревизия РД; проверить спецификацию» — уже управление.

У технических продавцов бывает интересная привычка. Они задают вопрос, получают ответ, который не совпадает с их ожиданием, и тут же начинают объяснять клиенту, почему тот неправильно думает.

«Насколько для вас важна скорость монтажа?» — «Не очень. Сейчас важнее цена». — «Нет, вы просто не учитываете...» Возникает естественный вопрос: зачем тогда вообще спрашивали?

Если продавец уже заранее знает правильный ответ, можно сразу читать презентацию. Вопрос имеет смысл только тогда, когда мы готовы принять полученную информацию и уже после этого разбираться, что она означает.

Одинаковая презентация не означает одинаковую встречу. С инженером логично глубже обсуждать применение, ограничения и техническую документацию. С закупкой — условия, комплектность, сроки и правила сравнения. С руководителем проекта — влияние на общий срок, бюджет и риск реализации.

Если за столом одновременно сидит несколько ролей, особенно опасно просто открыть первый слайд корпоративной презентации и начать читать её по порядку.

Иногда лучше в начале спросить, какой вопрос для собравшихся сейчас главный. Так быстро становится видно, что действительно волнует людей, кто задаёт направление разговору и к кому остальные обращаются при спорных моментах. Многосторонняя встреча сама помогает уточнять карту влияния, если продавец не занят исключительно собственной презентацией.

Возражение сначала надо понять

Клиент говорит: «У конкурентов дешевле». Продавец мгновенно начинает рассказывать о качестве, сервисе и опыте компании. А можно сначала спросить, одинаковая ли комплектность сравнивается, и выяснить, что предложения вообще разные.

Или уточнить, насколько разница критична для решения. Иногда закупщик обязан обсудить цену, но техническое решение уже имеет сильную поддержку.

То же самое с фразой «нам надо подумать». О чём именно? Кто должен участвовать? Какой информации не хватает? Когда должна появиться определённость? Не надо отвечать на возражение раньше, чем стало понятно его содержание.

«У нас есть поставщик» — нормальная информация

Фраза «у нас уже есть поставщик» иногда воспринимается продавцом как закрытая дверь. Я вижу в ней скорее полезную информацию. Значит, продукт покупают. Есть применение. Есть действующее решение и опыт эксплуатации.

Можно узнать, что в нём устраивает клиента, где возникают сложности, нужен ли второй источник, есть ли новые проекты, в которых решение ещё не выбрано.

Не надо нападать на конкурента. Если клиент много лет успешно с ним работает, скорее всего, у него есть причины. Уважение к сильному конкуренту вообще полезно. У него можно многому научиться.

Но существующий поставщик не означает, что у компании никогда больше не возникнет новая задача. Особенно в проектных продажах.

Хорошая встреча иногда заканчивается закрытием возможности

После качественного разговора может выясниться, что сделки не будет. Нет бюджета. Проект остановлен. Наше решение технически не подходит. Конкурент уже находится в намного более сильной позиции. Это неприятно, но полезно. Менеджер получил новую реальность и перестал тратить ресурс на фантазию.

Поэтому я не измерял бы качество встречи только позитивным движением. Если после разговора стало ясно, почему возможность надо закрыть, это тоже результат. Отрицательный факт обычно полезнее положительной иллюзии.

Я стараюсь записывать ключевую информацию, пока разговор ещё свежий. Не стенограмму. Важно другое: что узнали, какие новые люди появились, что подтвердилось, какая гипотеза оказалась неправильной, что обещал клиент и что обещали мы. Особенно полезен вопрос: что изменилось по сравнению с состоянием сделки до встречи? Он быстро показывает разницу между реальной работой и активностью ради активности.

CRM при этом не должна превращаться в наказание. Если после каждого визита менеджер сорок минут заполняет ненужные поля, довольно быстро в системе появляются формальные ответы. Нужно сохранять то, что помогает продолжать работу.

«Поддерживать контакт», «дожимать клиента», «ждать решения» — это не очень хорошие следующие шаги. Сильнее звучит конкретное действие, привязанное к человеку или событию: получить план участка для расчёта, после выпуска новой ревизии проверить спецификацию, провести встречу с главным механиком по стоимости простоя, направить проектировщику расчёт и получить технический комментарий.

Тогда и руководителю проще обсуждать сделку. Вместо «ну что там?» появляется предметный вопрос: расчёт отправили, что ответил проектировщик? Так управляется не настроение продавца, а реальное движение.

Встреча — часть сделки, а не отдельное искусство

Можно прекрасно провести переговоры и почти ничего не получить, если перед нами не тот человек, неправильная стадия проекта или вообще непонятная техническая задача.

Поэтому подготовка к встрече начинается не со списка красивых вопросов. Она начинается с понимания сделки.

Где мы находимся? Кто перед нами? Что уже известно? Чего мы не знаем? Какое изменение сейчас действительно важно? После этого появляются вопросы, презентация и переговорная тактика. Тогда сама встреча перестаёт быть выступлением продавца и становится рабочим инструментом управления проектом.

Что проверить после седьмого часа

1. Что конкретно изменилось после последней встречи?
2. Какой следующий шаг согласован, с кем и к какой дате?
3. Какая новая информация изменила вашу картину сделки?

Обновите паспорт сделки: зафиксируйте результат встречи и один проверяемый следующий шаг.

Час восьмой. Не спрашивайте менеджера: «Ну что там?»

В сложной сделке руководителю хочется получить простой ответ: когда деньги? Но чем длиннее и серьёзнее проект, тем реже на этот вопрос можно честно ответить одной датой.

Менеджер работает с возможностью несколько месяцев. Внутри уже есть проектировщик, технический специалист, подрядчик, закупка, руководитель проекта. Что-то согласовано, что-то только обсуждается. Часть информации подтверждена, часть существует со слов клиента, а некоторые вещи продавец пока просто предполагает.

Руководитель открывает CRM и спрашивает: «Ну что там?» Менеджеру тоже хочется ответить коротко: «Всё хорошо, двигаемся».

Проблема в том, что слово «двигаемся» почти ничего не означает. В седьмом часу мы уже договорились оценивать встречу по изменению, которое она внесла. На уровне управления логика та же: мне важен не общий оптимизм менеджера, а состояние возможности и то, что конкретно изменилось с прошлого разбора.

CRM показывает запись, а не реальность

Без CRM управлять большим количеством клиентов и проектов действительно сложно. Но наличие карточки сделки ещё не означает наличие управляемого процесса.

Допустим, в системе стоит этап «переговоры». За этим названием могут скрываться совершенно разные ситуации. В одной сделке техническое решение уже согласовано, есть бюджет и известен подрядчик. В другой менеджер один раз поговорил с закупкой, не знает проектировщика и даже не уверен, будет ли проект реализован. Обе возможности формально находятся на одном этапе, но их качество совершенно разное.

Поэтому название стадии даёт только ориентир. Для нормального управления надо понимать состояние самой сделки: что уже произошло, что подтверждено, где находится решение, кто участвует, что мешает движению и что должно произойти следующим. Вот тогда CRM начинает помогать, а не просто хранить историю активности.

Воронки обычно рисуют слева направо: новый клиент, квалификация, предложение, переговоры, договор. Реальные проекты так аккуратно не ходят.

Бюджет могут снять. Проект отправить на переработку. Подрядчика заменить. Техническое решение пересмотреть. Человека, с которым мы работали полгода, перевести на другую должность. В такой ситуации сделка действительно откатывается назад, и это надо признавать.

Нет смысла сохранять этап «финальные переговоры» только потому, что месяц назад он соответствовал реальности. Если после изменения проекта техническую работу надо начинать почти заново, именно это и должно быть видно руководителю. Иначе CRM показывает хорошую картинку, а продавец живёт уже в другой реальности.

В длинной продаже очень быстро смешиваются разные виды информации. Проектировщик сказал, что отправит документацию на согласование. Это содержание разговора. Менеджер после встречи пишет: «Проектировщик за нас». Это уже интерпретация. Продавец считает, что главный инженер поддержит решение. Это гипотеза. Кто утверждает инвестиционный бюджет, он пока вообще не знает. Это неизвестное.

Если всё это записать одинаковым тоном, через месяц даже сам менеджер может забыть, где был факт, а где собственное предположение.

Мне поэтому нравится простая дисциплина: отделять подтверждённую информацию от гипотез. Не для бюрократии, а для качества решений.

Фраза «закупка запланирована на октябрь» звучит уверенно. Но если на самом деле один специалист сказал: «Наверное, осенью», прогноз должен выглядеть иначе. Чем крупнее сделка, тем дороже обходится такая разница.

Иногда система управления будто требует, чтобы хороший менеджер знал всё: ЛПР определён, бюджет подтверждён, дата закупки известна, конкурент понятен, вероятность стоит, все поля заполнены. На практике такая требовательность часто производит не качественные данные, а красивые догадки.

Если менеджер честно говорит: «Я пока не понимаю, кто утверждает бюджет», у нас появляется задача. Надо это выяснить. Если он просто поставил фамилию первого подходящего директора и закрыл поле в CRM, задача исчезла только на экране. Поэтому неизвестное не надо прятать. Его надо использовать как программу дальнейшей работы.

В сложной продаже невозможно знать всё. Важно понимать, чего именно мы пока не знаем и насколько это критично.

Факт → гипотеза → следующее действие → контрольная точка → новый факт. Такой цикл полезнее попытки один раз навсегда выставить сделке «правильную» вероятность.

Большой сделке нужен паспорт

Одной карточки CRM для серьёзной возможности мне обычно мало. Нужен рабочий контур, в котором видна конструкция сделки целиком.

Название не принципиально. Можно назвать его паспортом сделки, картой проекта или Capture Tool. Важнее то, что внутри.

Какой проект? Какие объекты и применения нас интересуют? Каков реальный потенциал? На какой стадии находится проект? Кто участвует в решении? Кто с кем связан? Какое техническое решение рассматривается? Есть ли мы в проекте или спецификации? Кто конкуренты? Что происходит с бюджетом и подрядчиками? Какой следующий значимый этап? И ещё один вопрос, который часто забывают: какая помощь нужна менеджеру от собственной компании? Потому что большая продажа редко является работой одного человека.

Менеджер приносит проект на десять миллионов и говорит: «Вот моя сделка». Я бы не спешил радоваться десяти миллионам. Что находится внутри этой суммы?

В большом проекте могут быть несколько объектов, десятки применений, разные подрядчики и разные сроки. Один участок уже ушёл конкуренту. Второй находится в проектировании. Третий будет закупаться только через год. Четвёртый вообще не подходит под наше решение. Если сложить всё это одной суммой, компания начинает мысленно считать деньги, которых пока нет.

Поэтому большие возможности полезно дробить до понятного уровня: проект, конкретный объект, применение и потенциальная поставка.

Тогда становится видно, где действительно существует продажа, а где пока только большой общий бюджет стройки.

Многие CRM предлагают поставить вероятность сделки: двадцать процентов, пятьдесят, восемьдесят. Сам по себе процент ничего плохого не делает. Проблема в том, откуда он берётся.

«Клиент хороший, поставлю семьдесят». «Вроде договорились, пусть будет восемьдесят». Так появляется видимость математики без самой математики.

Я бы лучше смотрел на признаки качества возможности. Есть ли реальная техническая задача? Понятен ли путь к бюджету? Известны ли основные участники? Есть ли доступ к ним? Понимаем ли конкурента? Что происходит с документацией? Есть ли действие со стороны клиента? Насколько ясен следующий этап? Чем больше этих вещей подтверждено, тем качественнее сделка.

Процент можно оставить как ориентир, но не надо превращать его в обещание будущего. Проектная продажа не становится предсказуемой от того, что вместо «скорее всего» мы написали «73 процента».

Руководителю нужны другие вопросы

Вместо общего «ну что там?» намного полезнее спросить: что изменилось с прошлого разговора? Какой новый факт появился? Какая старая гипотеза оказалась неверной? Кого мы нашли на карте сделки? Кого всё ещё не хватает? Что изменилось у конкурента? Где сейчас находится техническое решение? Как выглядит следующий значимый шаг? И обязательно: что мешает менеджеру и какая помощь нужна от компании? Последний вопрос иногда меняет весь разбор.

Продавец не может подготовить предложение, потому что неделю ждёт технический расчёт. Не может выполнить обещание клиенту, потому что внутри компании не согласуют цену. Ему нужен инженер на сложную встречу или решение руководителя по нестандартным условиям.

Если начальник каждый раз только спрашивает результат, но не помогает убрать внутренние препятствия, он контролирует человека, а не управляет продажей.

В большой сделке бывают ситуации, когда участие руководителя действительно нужно: сложные коммерческие переговоры, встреча с собственником, конфликт, нестандартные условия, особенно важный проект. Нормально подключаться. Ненормально каждый раз забирать сделку у менеджера.

Если руководитель постоянно ведёт самые сложные разговоры сам, команда быстро привыкает приносить ему любую проблему. Продажи вроде идут, но система становится зависимой от одного человека.

Поэтому после совместного участия полезно всегда разделять две задачи: что мы сделали для сделки и чему при этом научился сам менеджер.

Иногда ради результата руководитель действительно должен взять часть разговора на себя. Но следующий похожий эпизод сотрудник уже должен уметь пройти самостоятельнее.

Есть компании, где общая встреча по воронке постепенно превращается в публичный экзамен. Менеджер рассказывает про сделку, руководитель ищет ошибки, остальные ждут своей очереди. Обучения в такой атмосфере немного. Человек начинает защищаться. Не анализировать реальность, а объяснять, почему он всё сделал правильно.

Совместный разбор полезен, когда обсуждается не личность менеджера, а конструкция сделки: что известно, чего не знаем, какой риск, какие есть варианты, где слабое место, что бы попробовали другие.

Тогда одна реальная возможность становится учебным материалом для всей команды, и никто не обязан изображать подсудимого.

Руководитель не обязан знать ответ заранее

Ещё одна управленческая ловушка — необходимость немедленно выдавать решение. Менеджер говорит: «Не могу выйти на нужного человека». Руководитель сразу объясняет, кому звонить и что говорить. Так быстрее.

Но если постоянно делать только так, сотрудник начинает приносить наверх не сложные развилки, а вообще все решения.

Иногда полезнее сначала спросить: что уже пробовал? Почему считаешь этого человека важным? Какие есть другие пути? Что известно о структуре компании? Какой вариант видишь сам?

Часто менеджер сам приходит к хорошему решению. Иногда даже к более сильному, чем предложил бы руководитель.

Это хороший результат. Задача управления не в том, чтобы каждый день доказывать команде собственный опыт. Сильная система должна постепенно учиться думать без постоянной подсказки сверху.

Контрольные точки лучше постоянного давления

В проекте могут быть периоды, когда объективно ничего быстро не происходит. Выпускается документация, утверждается бюджет, определяется подрядчик.

Бессмысленно каждые три дня спрашивать менеджера, не случилось ли чудо. Но так же бессмысленно забывать о проекте на полгода. Поэтому я предпочитаю контрольные точки.

Если новая ревизия документации должна выйти через месяц, фиксируем это событие и заранее понимаем, что проверяем после выпуска. Если в следующем квартале выбирают подрядчика, определяем, что хотим сделать до этого момента.

Так ожидание становится управляемым. Менеджера не заставляют создавать искусственную активность, а руководитель не теряет сделку из поля зрения.

Можно построить настолько подробную CRM, что менеджер начнёт работать прежде всего на неё. Если после каждой встречи надо заполнить десятки полей, часть рабочего дня постепенно уходит на администрирование. Потом сотрудник понимает, что половину этих данных никто никогда не использует, и начинает заполнять их формально. Поэтому я за достаточность.

Если информация помогает принять решение, провести разбор, понять прогноз или продолжить работу — она нужна. Если поле существует только потому, что когда-то кто-то решил его добавить, стоит спросить, приносит ли оно какую-нибудь пользу.

Система должна помогать менеджеру думать о сделке, а не доказывать, что в компании есть CRM.

Что проверить после восьмого часа

1. Какой факт подтверждает движение сделки сейчас?
2. Какой риск главный и кто отвечает за его проверку?
3. Какая помощь руководителя действительно нужна менеджеру?

Обновите паспорт сделки: назначьте контрольную точку — событие, ответственного и дату проверки.

Час девятый. Поставка ничего не заканчивает

Для продавца заказ выглядит естественным финалом. Договор подписан, оборудование отгружено, деньги попали в план. Можно переключаться на следующую возможность. Для клиента в этот момент всё только становится настоящим.

До поставки существовали презентации, обещания, расчёты и чертежи. Теперь всё это должно приехать на объект, быть смонтировано, запущено и начать работать. И именно здесь особенно хорошо видно, насколько обещания поставщика соответствуют его реальным возможностям.

Клиент покупает не факт отгрузки

Внутри компании процессы удобно разделены. Продажи отвечают за договор, логистика за поставку, инженеры за технические вопросы, сервис за обслуживание. Для управления это нормально. Клиент видит одну компанию.

Если оборудование приехало без нужной комплектности, ему малоинтересно, какой отдел ошибся. Если подрядчик не может разобраться с узлом, ему не помогает фраза «это уже не продажи». Если система не запускается, закрытый в CRM заказ не решает его проблему. Поэтому я осторожно отношусь к позиции «мы своё поставили».

Формально обязательства действительно могут быть ограничены договором. Но коммерчески такая граница иногда обходится очень дорого.

Если клиент покупал рабочий результат, а не просто коробку, поставка является только одной стадией этого результата.

К этому моменту часть участников сделки меняется. Проектировщик может уже почти не участвовать. Закупка свою функцию выполнила. Зато появляются монтажники, начальники участков, специалисты по ПНР, сервис и эксплуатация.

Для продавца это важный момент: карта клиента не заканчивается на тех людях, которые помогли получить заказ.

Теперь можно увидеть, как решение ведёт себя в реальной работе. Насколько понятна документация? Хватает ли комплектности? Возникают ли проблемы при монтаже? Насколько быстро компания отвечает на вопросы? Что думают люди, которые будут эксплуатировать оборудование? Эта информация ценна не только для конкретного объекта. Она возвращается в следующие продажи.

Иногда лучший сервис — вовремя остановить работу

На реальном объекте условия не всегда совпадают с тем, что ожидалось по проекту. Размеры меняются, основание имеет отклонения, приходит другая модификация оборудования, смежные системы занимают пространство.

В такой ситуации поставщику психологически проще показать, что его продукт способен решить всё. Но иногда профессиональный ответ заключается в другом: сначала надо зафиксировать проблему и только потом продолжать монтаж. Это особенно важно там, где ошибка приводит к переделке, простою и спору об ответственности.

Хороший технический поставщик не обязан брать на себя чужие функции. Но он должен понимать границу между нормальной адаптацией решения и ситуацией, когда продолжение работ создаёт новый риск.

На объекте многие вещи сначала кажутся очевидными. Все видят отклонение. Все понимают, что размер изменился. Все согласны, что участок подготовлен не полностью. Через несколько недель начинается спор, и выясняется, что каждый помнит разговор по-своему. Поэтому проектная и исполнительная дисциплина нужна не ради самой бумаги. Она фиксирует исходную реальность.

Если подрядчику передают помещение или участок под монтаж, полезно зафиксировать его фактическое состояние и существенные отклонения. Конкретная форма документа зависит от проекта и договорённостей сторон, но сам принцип простой: проблема, существовавшая до начала работ, не должна впервые появляться в обсуждении уже после завершения монтажа.

Продавец не обязан становиться специалистом строительного контроля или юристом. Но практический опыт помогает вовремя спросить: это состояние где-нибудь зафиксировано? Иногда один такой вопрос предотвращает намного более дорогой конфликт.

Проектировщик видит документацию. Закупка — цену и условия. Руководитель проекта — срок и результат. Монтажник видит, насколько с системой удобно работать руками.

Можно ли понять узел? Всё ли приехало? Сколько операций надо сделать? Есть ли нормальная инструкция? Кто ответит на вопрос, если реальный объект отличается от рисунка? Если с продуктом удобно, это запоминают. Если каждый узел приходится угадывать, тоже.

И не стоит считать монтажника человеком, который никак не влияет на будущие продажи. Подрядчики переходят с объекта на объект. Люди меняют компании, работают с новыми заказчиками и обсуждают знакомые решения. Сегодня монтажник не выбирал поставщика. На следующем проекте его мнение уже могут спросить.

ПНР — момент истины

ПНР требуется не для каждого продукта; её состав, результат и ответственность сторон определяются конкретной системой и договором. Для многих видов оборудования поставка сама по себе почти ничего не означает без запуска. Шкаф стоит на объекте. Оборудование подключено. Система собрана. Но пока всё это не работает в нужном режиме, клиент ещё не получил конечный результат. Именно поэтому пусконаладка — не просто технический хвост договора.

Здесь появляется реальная эксплуатация. Возникают смежные системы, фактические режимы, ошибки исходных данных, настройки и вопросы персонала. Многие вещи, которые прекрасно выглядели на стадии проекта, проходят здесь последнюю проверку. И одновременно возникают новые коммерческие возможности: дополнительное оборудование, модернизация, сервис, запасные части, обучение персонала. Продавец, который исчез после отгрузки, их просто не видит.

Сервис начинается в момент проблемы

Почти каждая компания говорит о хорошем сервисе. Клиент понимает его качество только после первой серьёзной проблемы.

Пока всё работает, разница между поставщиками не всегда заметна. Она проявляется, когда оборудование остановилось, подрядчик не понимает узел или объекту срочно нужен технический ответ.

Одна компания несколько дней пересылает письмо между подразделениями. Другая быстро определяет ответственного и начинает разбираться. Для следующей продажи этот опыт способен оказаться важнее первоначальной скидки.

В сложном B2B доверие формируется долго, но иногда разрушается одним эпизодом. Клиент может забыть половину аргументов из презентации, но хорошо помнить, кто реально помог, когда возникла проблема.

Рекламации неизбежны. Иногда проблема на стороне клиента, иногда монтажа, логистики или продукта. Иногда ошиблась наша компания.

Мне не близка позиция, при которой первая задача продавца — доказать, что мы точно ни при чём.

Если ошибка действительно наша, лучше признать это и начать решать. Это не означает автоматически соглашаться с любой претензией. Причину всё равно надо установить.

Но есть большая разница между «разбирайтесь сами, мы не виноваты» и «вижу проблему, сейчас подключим нужных специалистов и разберёмся, где причина». Вторая позиция показывает не признание любой вины, а ответственность за процесс решения. Для клиента это очень заметно.

На объекте время имеет стоимость. Если бригада остановилась и ждёт технического решения, люди продолжают получать зарплату, график идёт, смежные работы могут зависеть от этого участка. Поэтому скорость технической поддержки — вполне реальная часть коммерческой ценности. Её трудно доказать рекламной фразой «оперативно отвечаем на вопросы». Такие вещи подтверждаются только опытом.

Если клиент трижды получил нормальный ответ в тот же день, он знает качество поддержки. Если трижды ждал неделю — тоже знает. Некоторые преимущества вообще невозможно продать презентацией. Их можно только показать работой.

Монтажник расскажет, что было неудобно собирать. Эксплуатация через некоторое время покажет, как продукт ведёт себя в реальном режиме. Руководитель проекта объяснит, где поставщик помог сроку, а где создал дополнительную проблему. Эту обратную связь нельзя оставлять только у менеджера.

Хороший продавец должен приносить её обратно в компанию. Что изменить в документации? Где не хватает комплектности? Какой вопрос на объекте повторяется? Что конкурент делает удобнее? Какое преимущество оказалось действительно ценным? Тогда поле начинает развивать не только продавца, но и сам продукт.

Есть большая разница между фразой «наша система удобна в монтаже» и реальным объектом, где подрядчик её нормально собрал. Второе уже является опытом.

Если позволяют правила конфиденциальности и объекта, такой опыт можно превращать в кейс, фотографию, технический пример или обезличенную историю. Где-то фотографировать нельзя вовсе, и это нормально. Ценность кейса не обязательно в названии заказчика. Важно показать путь: была задача, появились ограничения, решение адаптировали, система была реализована.

Для следующего клиента это обычно понятнее рекламного обещания. И сам продавец после нескольких таких реализаций начинает по-другому разговаривать. Он знает продукт уже не по каталогу, а по реальному применению.

Повторная продажа начинается с понимания развития клиента

После хорошей поставки не обязательно сразу спрашивать: «Что ещё вам продать?» Гораздо полезнее посмотреть, что происходит вокруг.

Есть ли соседние участки с похожей задачей? Планируется ли расширение? Какие новые проекты готовятся? Где дальше будет работать подрядчик? Есть ли эксплуатационная потребность? Так новая возможность естественно вырастает из старой.

Сегодня мы помогли на одном объекте. Завтра подрядчик идёт на следующий. Через год предприятие модернизирует другой участок. Проектировщик использует знакомое решение в новом проекте. Проектная продажа начинает работать как сеть, а не как последовательность независимых холодных стартов.

Плохой опыт распространяется так же быстро

У этого механизма есть обратная сторона. Сорванный срок, неполная комплектность, отсутствие поддержки и плохое поведение поставщика тоже путешествуют с людьми. Прораб переходит на другой объект. Руководитель проекта меняет компанию. Монтажник рассказывает коллегам. И на следующей встрече новый продавец слышит: «Мы с вами уже работали». Иногда после этой фразы презентация уже почти ничего не способна исправить. Поэтому репутация технического поставщика создаётся не только до договора. Очень часто — именно после.

Инженерная продажа не заканчивается выбором продукта

До покупки техническая работа сосредоточена на подборе и обосновании. После покупки появляются монтаж, шефмонтаж, ПНР, эксплуатация и сервис. Для меня это естественное продолжение инженерной продажи.

Но проектная продажа всё равно шире. Она держит весь маршрут: людей, проектирование, деньги, закупку, техническое решение и реализацию.

Не надо делать из продавца универсального специалиста, который сам всё проектирует, монтирует и ремонтирует. Его задача другая: понимать общий контур и вовремя подключать нужных людей.

Есть сложный инженерный вопрос — нужен инженер. ПНР — специалист по ПНР. Договорная проблема — юрист. Нестандартное решение — руководитель.

Сила менеджера не в том, что он знает всё. Она в том, что клиент не остаётся один между внутренними отделами поставщика.

Где заканчивается сделка

Коммерчески конкретная поставка когда-то заканчивается. Обязательства выполнены, деньги получены, договор закрыт. Но отношения с клиентом продолжают жить.

Оборудование работает. Возникает сервис. Появляется новая задача. Подрядчик идёт на другой объект. Предприятие начинает модернизацию. Поэтому длинную B2B-продажу мне проще представить не как прямую линию, а как цикл.

Проектирование приводит к поставке, поставка — к реализации, реализация — к эксплуатации, эксплуатация создаёт опыт, а хороший опыт формирует доверие и следующую возможность. Когда этот цикл работает, следующую продажу уже не приходится начинать с нуля.

Что проверить после девятого часа

1. Что должен получить клиент кроме факта поставки?
2. Какие риски монтажа, запуска или эксплуатации находятся в пределах вашего договора и компетенции?
3. Как информация реализации вернётся в продажи, продукт и сервис?

Обновите паспорт сделки: добавьте критерий завершения реализации, ответственных и возможный следующий проект.

Сквозной кейс. От закрытой двери до системы поставок

Этот кейс я намеренно обезличиваю. Название предприятия, поставщика, проектного института и людей здесь не важно. Важно другое: это не собранная из нескольких историй легенда. Последовательность событий относится к одному большому промышленному проекту, где мне удалось увидеть почти весь маршрут проектной продажи — от первого сопротивления до системы, которая продолжила работать после передачи проекта другому менеджеру.

Нас не ждали

Я работал по территории и отслеживал крупные инвестиционные проекты ещё до появления конкретных заявок. Когда стало понятно, что начинается большой металлургический проект, я поехал на объект. Масштаб строительства был таким, что потенциально внутри существовало много разных применений, но это ещё не означало, что нас там ждут.

Первая реакция была довольно холодной. Поставщика знали по предыдущему опыту, репутация была не лучшей, часть решений уже считалась определённой. Нам фактически сказали: здесь всё уже заложено, необходимости в вас нет.

Спорить с прошлым бессмысленно. Я попросил только одну вещь — дать возможность показать, что компания изменилась и что мы теперь способны делать. Провели презентацию, ответили на серьёзные технические вопросы, познакомились с руководителем проекта. Это не открыло сразу все двери, но дало право на следующий разговор.

Вместо одного ЛПР появилась система

Дальше стало видно, насколько бесполезно в такой продаже искать одного «главного человека». У заказчика были руководитель проекта и руководитель строительства, собственные проектировщики, технические службы и главный энергетик. Отдельно работал крупный внешний проектный институт. Позже подключались закупка, генподрядчик и несколько подрядчиков. Одну часть решения согласовывали одни люди, другую проектировали другие, а покупал в итоге иногда вообще третий контур.

Поэтому работа стала похожа не на воронку, а на карту. Надо было понимать, откуда приходит техническое задание, кто формирует решение, кто его согласует, где появляется стоимость, кто проводит закупку и кто в реальности будет монтировать. Это как раз тот случай, когда обычная оргсхема мало помогает: юридические лица и должности объясняют подчинённость, но не показывают маршрут конкретного решения.

Доверие началось не с большой поставки

Заказчик не обязан верить поставщику только потому, что тот хорошо провёл презентацию. Поэтому первые шаги были небольшими. Мы привозили отдельные позиции, давали образцы, проводили демонстрации, собирали небольшие участки монтажной системы и смотрели, как решение ведёт себя на объекте.

На площадке проводили и натурные испытания крепежа. В одном из них химический анкер испытывали непосредственно в основании объекта: испытательная нагрузка была примерно на треть выше расчётной, отказ не зафиксировали. Для книги важны не конкретные килоньютоны, а сам принцип. До испытания у нас было утверждение поставщика: «решение подходит». После испытания появился документированный факт, который видели представители заказчика.

С главным энергетиком разбирали и другие применения. Что-то проверяли буквально руками: монтажные решения, элементы фальшпола, огнестойкие материалы. По одному из материалов делали наглядное испытание огнём. Такие эпизоды выглядят мелкими на фоне миллиардного проекта, но именно из них постепенно складывается техническое доверие.

Перелом произошёл в проектном институте

После работы на объекте мы получили контакты внешнего проектного института. Там нас тоже не встретили с распростёртыми объятиями. Сначала требовалось подтверждение от заказчика: действительно ли он готов рассматривать наши решения. Подтверждение получили, и почти сразу возникло совпадение обстоятельств, которое стало важным для всей сделки.

Проектный институт был загружен, а по одному из участков существовала сложная техническая задача: оборудование надо было разместить на рамах с большим пролётом. Стандартный подход не давал удобного решения. Мы предложили тяжёлую монтажную систему и взяли инженерную проработку на себя.

В этот момент в институт приехал руководитель проекта заказчика. Он увидел меня там и фактически свёл стороны за одним столом. На совещании с ГИПами вопрос прозвучал уже не как «можете продать профиль?», а как «можете помочь проектировщикам сделать эти решения?». Я ответил, что можем.

У нашей компании были необходимые компетенции и допуски для такой инженерной работы. Проектный институт даже обсуждал возможность оформить отдельный договор, но в итоге мы пошли по другой схеме: техническую проработку выполняли без отдельной оплаты, а ответственность за проектную документацию оставалась у института. Мы готовили расчёты, узлы и исходные технические решения, институт их проверял, дорабатывал при необходимости и выпускал документацию под своей ответственностью и своими штампами. Это принципиальная граница: поставщик помогал проектировать применение, но не подменял проектный институт.

После первого сложного решения работа стала системной. Проектировщик получал техническое задание, передавал нам часть вопросов по нашему применению, мы готовили инженерную часть, возвращали её институту, дальше решение согласовывалось с заказчиком. Так продукт перестал быть отдельным товаром и стал частью проектного процесса.

В проект надо попасть вместе с деньгами

На этом можно было бы успокоиться: решения начали появляться в проекте. Но строка в чертеже ещё ничего не покупает. Поэтому мы работали не только с проектировщиками и ГИПами. Давали цены на материалы и комплектацию, разбирались, как решения проходят в сметную и бюджетную часть.

Для меня это был важный урок. Если поставщик помогает проектировать дорогую систему, но не помогает проекту понять её стоимость, проблема просто переносится на конец маршрута. Через несколько месяцев закупка увидит неожиданную сумму и начнёт оптимизировать то, что технически уже согласовано. Гораздо сильнее, когда техническое решение и его экономика появляются рядом.

Закупка всё равно сравнила рынок

Когда проект дошёл до закупки, ранняя работа не дала нам права диктовать цену. Торги оставались торгами. Закупщики понимали, какое решение находится в проекте, но совершенно справедливо хотели проверить рынок и увидеть, насколько наше предложение выше или ниже альтернатив.

Разговор о цене тогда был довольно прямым. Я объяснял: отдельный профиль, крепёж или другой элемент действительно можно найти дешевле. Но сравнивать надо одинаковую задачу. В нашем предложении были инженерная проработка, проверенная комплектность, технические документы, испытания и сопровождение. Если разобрать систему на случайный набор более дешёвых деталей, кто-то всё равно должен будет заново взять ответственность за их совместимость и результат.

Это не означало, что можно поставить любую цену. Мы оставались конкурентными и торговались. Более того, надо было учитывать экономику всей цепочки. В отдельных поставках покупателем становился генподрядчик, и у него тоже должна была оставаться нормальная коммерческая мотивация работать с решением, а не искать обходной путь. Поэтому цену нельзя было сразу опустить до собственного минимума поставщика, а потом удивляться, почему следующий участник цепочки пытается заменить продукт.

Спецификация потребовала сопровождения на стройке

После закупки история не закончилась. Для подрядчиков проводили техническое сопровождение и шефмонтаж, потому что именно они должны были превратить документацию в реальную конструкцию. И здесь однажды произошёл очень показательный случай.

От подрядчика пришёл плохой отзыв по части системы. Сначала это выглядело как проблема нашего решения. Когда начали разбираться на месте, выяснилось, что один из элементов заменили на дешёвый сторонний аналог. Формально конструкция выглядела почти той же, но качество заменённого компонента оказалось другим. После этого к заменам стали относиться намного осторожнее.

Для меня эта история хорошо показывает, почему спецификация — не победа. Между проектом и результатом всегда существует реализация. Если поставщик вообще не знает, что реально приехало на объект и что из этого собрали, он может получить претензию за систему, которой на площадке уже фактически нет.

Выиграли не всё — и это нормально

В этом же проекте была часть поставки, которую мы не выиграли. По одному из направлений у заказчика уже работал сильный конкурент, его решение хорошо показало себя на предыдущих очередях. Мы получили возможность предложить альтернативу, попробовали побороться, но заказчик не увидел достаточного основания менять привычную систему при более привлекательной цене действующего поставщика.

Я считаю такой проигрыш нормальным. Мы понимали, кому уступили и почему. Гораздо опаснее проиграть и объяснить это одной фразой «у конкурента всё схвачено». Иногда конкурент просто сильнее именно в этой точке проекта. Это тоже информация для следующей сделки.

Сильнейший результат проявился позже

В какой-то момент я передал этот проект другому сотруднику. Но работа, сделанная до этого, не исчезла вместе со сменой менеджера. Согласованные решения продолжали использоваться в проектировании, по сформированным направлениям шли дальнейшие закупки и поставки, а новый человек получил не пустой список контактов, а уже созданную систему отношений, технических решений и маршрутов.

Для меня это, пожалуй, самый важный результат всего кейса. Сильная проектная продажа не должна держаться только на личной харизме менеджера. Если после его ухода всё обнуляется, значит, значительная часть сделки жила у него в голове. Если карта участников, проектные решения, документация и рабочие связи продолжают двигать поставки дальше, значит, была создана система.

Именно поэтому я называю сложную сделку проектом. Здесь нельзя указать одну встречу, после которой «мы продали». Продажу сделали десятки связанных действий: ранний вход, карта людей, испытания, инженерная работа, проектирование, бюджет, закупка, работа с генподрядчиком и сопровождение реализации. Ни один из этих элементов не заменяет остальные. Но вместе они создают позицию, которую намного труднее свести к сравнению двух строк прайса.

Час десятый. Учитесь на живых сделках

Можно за два дня рассказать менеджеру практически всю базовую теорию продаж. Объяснить этапы, дать структуру встречи, разобрать возражения, показать карту влияния и научить формулировать следующий шаг.

Через неделю человек возвращается к своему настоящему клиенту — и снова делает почти всё по-старому. Не потому, что тренинг был плохой. Знать и уметь — разные вещи.

Настоящий клиент не произносит реплики из учебного сценария. Участники сделки не появляются в удобной последовательности. Технический специалист уходит в детали, закупка требует цену, руководитель торопится, а человек, которого продавец считал главным, вдруг отправляет его совсем в другое подразделение. Именно поэтому сложным B2B-продажам невозможно научить только в аудитории.

Хорошее обучение помогает команде получить общий язык, разобрать модели и увидеть собственные ошибки со стороны.

Менеджеры начинают одинаково понимать, что такое карта влияния, проектная возможность, следующий шаг, техническое обоснование или работа с проектировщиком. Это полезно. Но знания сами по себе редко меняют устойчивое поведение.

Менеджер вернулся к работе и снова слишком быстро отправил КП. Снова разговаривает только с закупкой. Снова пишет «клиент думает». Снова проводит встречу без ясной цели. Старый способ действий привычнее новой теории. Чтобы поведение изменилось, человеку нужен повторяемый опыт применения.

Для отработки отдельных навыков выдуманные ситуации удобны. Можно специально создать возражение, конфликт или нужную роль. Но для развития проектного мышления намного интереснее настоящая текущая сделка менеджера.

В ней уже есть реальные деньги, люди и конкуренты. Не надо придумывать, почему сложно выйти на нужного человека. Менеджер действительно не может туда выйти. Не нужно создавать искусственную спецификацию конкурента. Она уже существует. Не надо просить участника тренинга представить, что он очень хочет выиграть. Он и так хочет.

Тогда обучение перестаёт быть разговором о том, «как правильно вообще», и становится разговором о том, что именно делать завтра.

Когда человек приносит возможность на разбор, необязательно сначала слушать историю всех звонков за последние полгода. Полезнее восстановить конструкцию.

Что за проект? Где наше применение? Какой потенциал? Какова стадия? Кто проектирует? Кто покупает? Кто будет монтировать? Что известно о конкурентах? Есть ли техническое решение? Что происходит со спецификацией и бюджетом? Обычно уже здесь появляются пробелы.

Менеджер помнит последние разговоры, но не знает подрядчика. Хорошо знает закупку, но ни разу не разговаривал с техническими службами. Говорит о большом проекте, но не может объяснить, где именно там существует его потенциальная поставка. Это не повод ругать. Это и есть учебный материал.

Разбор должен заканчиваться работой

Можно час очень умно обсуждать сделку и закончить фразой: «Ну, в общем, надо лучше проработать клиента». Практической ценности в таком разборе мало.

После разговора у менеджера должны появиться конкретные действия: получить актуальный чертёж, найти подрядчика, проверить бюджет, выйти на эксплуатацию, подготовить расчёт, позвать инженера на встречу. Он выполняет действие, получает новую информацию, возвращается к разбору. Получается нормальный цикл: подумали, сделали, увидели результат, скорректировали. Именно так постепенно развивается самостоятельное мышление.

Полевой день иногда даёт больше аудитории

Есть навыки, которые особенно плохо передаются через презентацию: первый вход, отказ, разговор на проходной, неожиданный вопрос, работа на объекте.

В учебной аудитории человек всё равно знает, что перед ним коллега, который через двадцать минут снова станет нормальным. На настоящей встрече паузу не нажмёшь.

Можно неправильно понять роль собеседника, слишком рано начать презентацию, упустить важную реплику или просто растеряться.

Именно поэтому после настоящего полевого дня появляется очень качественный материал для обучения. Можно обсуждать не гипотетическое поведение, а то, что человек действительно сделал.

Совместный визит полезен, пока менеджер остаётся участником, а не зрителем. Если при первой паузе руководитель забирает разговор и доводит встречу сам, клиент может получить хороший результат, но менеджер почти ничему не научится.

Поэтому роли лучше определить заранее: кто ведёт, какова цель, когда руководитель подключается и какой участок менеджер проходит сам. В начале нормально больше показывать, но постепенно ответственность за разговор должна переходить сотруднику.

Обратную связь лучше начинать с самооценки

После встречи полезно сначала спросить самого менеджера, как он оценивает разговор.

Что получилось? Где было сложно? Что он услышал и что сделал бы иначе? Так человек учится анализировать собственную работу, а не ждать готового приговора.

После этого руководитель добавляет свои наблюдения. Важно отмечать не только ошибки: сильное поведение нужно закреплять так же, как слабое исправлять.

Иногда менеджер и руководитель видят одну встречу по-разному. Это нормально. Руководитель может что-то не услышать или иначе понять мотив клиента. У менеджера может быть дополнительный контекст из прошлых разговоров. Поэтому обратная связь полезнее в форме обсуждения, а не приговора.

Почему ты сделал именно так? Что услышал в ответе? Я увидел ситуацию иначе — как ты это воспринимаешь? Иногда после разговора руководитель останется при своём мнении. Иногда менеджер убедит его. Цель в обоих случаях одна: сделать следующее действие сильнее.

Не исправляйте десять вещей одновременно

После одной встречи легко собрать длинный список замечаний. Если выдать человеку всё сразу, на следующей встрече он будет думать не о клиенте, а о десяти правилах в голове.

Лучше выбрать один-два навыка. Например, меньше рассказывать до понимания задачи, не перебивать инженера, проверять роль человека, чётче фиксировать следующий шаг. Появилась устойчивая привычка — двигаемся дальше. На бумаге это кажется медленнее. В реальности именно так поведение действительно меняется.

Новичку нужны основы: как начать разговор, как провести встречу, как задавать вопросы и не бояться первого отказа. С опытными людьми интереснее работать глубже.

Менеджер может прекрасно общаться с клиентами, но плохо видеть структуру проекта. Сильный инженер умеет подбирать решение, но работает только с техническими специалистами. Полевой продавец проводит много встреч, но плохо приоритизирует территорию. Человек умеет продавать, но слишком поздно входит в проекты. Вот это уже материал для развития.

Не надо второй раз рассказывать человеку определение открытого вопроса, если его проблема вообще в другом. Обучение должно начинаться с диагностики.

Иногда сначала надо обучить компанию

Если весь отдел системно работает плохо, проблема может находиться не только в людях. Есть ли нормальный продукт? Понятная цена? Каталог? Техническая поддержка? Быстрый расчёт? Коммерческие условия? Реальный потенциал на территории?

Для проектных продаж добавляются полевая готовность, допуски, транспорт, работа с объектами, проектировщиками и техническими материалами. Если всего этого нет, тренинг менеджеров мало что исправит.

Человека можно научить великолепно проводить встречу. Потом он вернётся в офис и десять дней не сможет получить цену. Для клиента система продаж всё равно будет плохой.

Это различие я считаю очень важным. Можно анализировать навыки конкретного менеджера: встречи, переговоры, вопросы, работу с проектами. А можно смотреть на систему компании: продукт, рынок, цены, процессы, CRM, техническую поддержку, руководство.

В проектных продажах появляется ещё один слой: объект, проектная документация, проектировщики, подрядчики, допуски, инженерная работа.

Иногда хороший продавец вытягивает слабую систему на личном опыте. Иногда хорошая система помогает среднему менеджеру получать достойный результат. Но для устойчивого роста нужны обе части.

Обучение измеряется изменением поведения

Самый простой критерий развития — не понравился ли людям тренинг. Важно, что они стали делать иначе.

Раньше менеджер сразу отправлял коммерческое предложение — теперь сначала проверяет задачу. Работал только с закупкой — начал строить карту людей. После встречи писал «клиент думает» — теперь понимает следующий проверяемый шаг. Ездил по территории без системы — начал выбирать объекты по потенциалу. Руководитель спрашивал только про деньги — теперь разбирает факты, гипотезы и неизвестное. Вот это изменение. И оно почти всегда происходит не в момент лекции. Оно происходит на настоящей работе.

Тренировочный цикл: подготовка — спарринг — поле — разбор

Между теорией и реальной встречей всегда не хватает безопасного места, где человек может попробовать действие несколько раз. Раньше эту роль в основном выполняла ролевая игра с коллегой или руководителем. Сейчас к ней добавился ИИ, и мне он интересен именно в этой узкой роли — как тренировочный собеседник, а не как автор волшебной фразы.

Перед встречей менеджер сначала сам формулирует цель, карту участников, аргументы и следующий шаг. После этого можно провести короткий спарринг: попросить систему сыграть закупщика, главного инженера или руководителя проекта, задать неудобные вопросы, проверить, где аргументация разваливается и где гипотеза выдана за факт. Затем человек идёт в поле и получает единственную обратную связь, которую нельзя заменить симуляцией, — реакцию настоящего клиента.

После встречи цикл повторяется в обратную сторону. Сначала менеджер сам фиксирует факты и делает выводы. Потом может использовать тренажёр, чтобы оспорить собственную картину и подготовить варианты. А уже после этого обсуждать сложную развилку с руководителем. Тогда разговор начинается не с «что мне делать?», а с «я вижу три варианта, вот факты и риски каждого».

Подготовка → спарринг → поле → саморазбор → разбор с руководителем → следующее действие.

Руководитель при этом остаётся важнее любого тренажёра. Он знает внутренний контекст компании, видел предыдущие встречи, отвечает за коммерческий результат и способен принять решение, которое нельзя получить из одной переписки с ИИ. Технология здесь не заменяет человека, а освобождает повторяемую практику для того, чтобы руководитель тратил время на действительно сложные места.

Если в компании несколько продавцов и у каждого есть реальные сделки, учебного материала уже больше, чем обычно успевает использовать любой тренер: выигранные и потерянные проекты, замены оборудования, сложные подрядчики, удачные входы в проект, ошибки с закупкой, технические возражения, работа с проектировщиками. Лучше разбирать их, пока ситуация ещё жива, а не через полгода, когда половина деталей уже забыта.

Проигрывать не страшно. Страшно не учиться

Если проигрыш автоматически считается виной менеджера, сотрудник быстро учится защищаться. Конкурент демпинговал. Клиент странный. Закупка заранее всё решила. Иногда это действительно правда.

Но если компания умеет спокойно исследовать проигрыш, появляются более полезные ответы: вошли поздно, не нашли одного человека, переоценили поддержку инженера, не защитили комплектность, долго готовили расчёт. Вот это уже знания.

Проигранная сделка стоила компании денег и времени. Хорошо бы хотя бы вернуть часть этой стоимости в виде опыта.

Самая дорогая ошибка — та, которую команда через год повторяет в точно таком же виде.

Выигрыш сам по себе ещё не доказывает идеальность процесса. Можно ошибаться и всё равно победить, потому что конкурент ошибся сильнее. Можно случайно получить сильного союзника. Оказаться единственным поставщиком с нужным наличием.

Поэтому после хорошей сделки тоже полезно понять механизм: что действительно сработало, что можно повторить, где нам повезло. Так постепенно появляется не коллекция красивых историй, а собственная система компании.

Цель обучения — самостоятельность

Главный результат обучения — самостоятельность. В начале менеджеру чаще нужна помощь: подготовиться к встрече, разобрать сложную ситуацию, подключить руководителя.

Потом он сам ведёт переговоры, приносит на разбор собственную оценку и несколько вариантов решения. В какой-то момент становится ясно: большинство ситуаций человек уже способен вести самостоятельно. Для меня это один из лучших результатов обучения.

Не сотрудник, который на каждой встрече вспоминает слова тренера, а сотрудник, который научился думать сам.

Что проверить после десятого часа

1. Какой вывод из этой сделки вы сможете применить повторно?
2. Какое поведение менеджера должно измениться уже в следующем действии?
3. Что менеджер теперь способен решить самостоятельно?

Завершите паспорт сделки: сформулируйте главный риск, следующий шаг и один урок для команды.

Вместо заключения

Закройте эту книгу и откройте одну живую сделку. Не весь портфель и не отчёт по воронке — одну возможность, в которой сейчас есть деньги, люди и неопределённость.

Сначала сформулируйте в одном предложении, что клиент на самом деле пытается сделать. Потом нарисуйте коммерческий контур: откуда возникла потребность, кто формирует техническое решение, где появляется бюджет, кто проводит закупку и кто будет реализовывать. Отметьте людей, которых вы действительно понимаете, и тех, чью роль пока только предполагаете. Отдельно поставьте конкурента не как название компании, а как позицию внутри этой карты.

После этого проверьте четыре вещи: где сейчас находится решение, какой факт подтверждает движение, какой риск способен изменить маршрут и что должно произойти следующим. Если на один из вопросов нет ответа, не придумывайте его. Это и есть ваша ближайшая работа.

Не пытайтесь улучшить сделку сразу во всём. Найдите один пробел, который сильнее остальных влияет на результат, и сделайте следующее осмысленное действие: получить документ, выйти на человека, проверить расчёт, подтвердить бюджет, провести испытание, поговорить с подрядчиком. Потом снова посмотрите на карту.

В этом для меня и состоит практический смысл проектных продаж. Не в том, чтобы контролировать каждый шаг клиента и не в том, чтобы всегда заранее знать правильный ответ. Нужно достаточно хорошо видеть систему, чтобы замечать изменения и принимать следующее решение раньше, чем сделка сама поставит вас перед фактом.

Если после десяти часов у вас осталась не только прочитанная книга, но и одна честно разобранная возможность, значит, книга уже сработала. Дальше всё решит не текст. Дальше начинается ваша следующая встреча.

Благодарности

Эта книга появилась не только благодаря моему опыту. Большая часть того, как я сегодня смотрю на проекты, продажи и работу с людьми, когда-то появилась благодаря людям, встретившимся мне намного раньше.

В первую очередь я хочу поблагодарить мою маму, Елену Васильевну Моргачеву. Именно благодаря ей когда-то произошло знакомство, которое во многом определило мой дальнейший профессиональный путь.

Особая благодарность моему наставнику, а теперь и другу Сергею Владимировичу Юдину. С юности он учил меня смотреть на задачу шире отдельных действий и видеть систему целиком. Мы вместе прошли через реальную работу на объекте, и от него я получил намного больше, чем технические знания. Он учил меня инженерной грамотности, ответственности, переговорам, работе с людьми и управленческому мышлению. Думаю, именно тогда, задолго до появления этой книги, начала формироваться главная её идея: сложная задача почти никогда не существует сама по себе — вокруг неё всегда есть люди, связи, ограничения и последствия.

Спасибо моей супруге, Алине Васильевне Моргачевой, которая была рядом со мной тогда, когда проектные продажи становились серьёзной частью моей жизни. Были длинные поездки, Дальний Восток, новые территории, новые проекты и много неопределённости. Её поддержка позволяла мне пробовать, ошибаться, двигаться дальше и принимать решения, которые не всегда были простыми.

Я благодарен Булату Нофикофу за настоящую школу проектных продаж. За требовательную обратную связь, работу с реальными сделками и ту профессиональную базу, на которой позднее я смог строить уже собственный подход. Очень многое из того, что сегодня кажется мне естественным в работе с проектом, когда-то приходилось осваивать благодаря его вопросам, замечаниям и доверию.

Отдельное спасибо Владиславу Юрьевичу Кушниру. В определённый момент он поверил в меня и доверил мне уже не только продажи, но и управление проектом и людьми. Этот опыт сильно изменил мой взгляд на работу: когда отвечаешь не только за собственный результат, начинаешь иначе понимать ответственность, команду и роль руководителя. Со временем наши профессиональные отношения переросли ещё и в дружбу, что для меня особенно ценно.

И спасибо всем руководителям, коллегам, инженерам, проектировщикам, технологам, энергетикам, подрядчикам и клиентам, с которыми мы в разные годы работали над настоящими проектами. Одни сделки мы выигрывали, другие проигрывали. Иногда правильное решение находилось быстро, иногда приходилось переделывать всё сначала. Именно из этих ситуаций и появилась большая часть того, о чём написана эта книга.

Практический комплект проектного продавца

Эти страницы не требуют последовательного чтения. Их задача — быть рядом с реальной сделкой. Заполняйте только то, что помогает принимать решения. Если информации нет, не заменяйте её предположением: помечайте неизвестное и превращайте его в следующий шаг.

Рабочий лист 1. Паспорт сложной сделки

Рабочий лист 2. Карта влияния

Для типовой сделки достаточно простой карты влияния. Для большого холдинга, инвестиционного проекта или нескольких юридических лиц полезнее строить коммерческий контур: сначала основной маршрут решения, затем второстепенные связи.

При заполнении карты по каждому значимому человеку или функции фиксируйте пять вещей: роль, интерес, влияние, отношение к решению и следующий шаг. Отдельно отмечайте качество знания: факт / гипотеза / неизвестно.

Не стремитесь нарисовать красивую оргсхему. Карта нужна, чтобы увидеть, кого вы не знаете, кто способен изменить решение и через кого оно реально движется.

Рабочий лист 3. Встреча: до и после

Перед встречей

1. Какое изменение в сделке я хочу получить после разговора?
2. С кем я встречаюсь и какую роль этот человек играет именно в этой сделке?
3. Какие факты уже известны, а какие вещи я только предполагаю?
4. Какие технические документы, расчёты или данные надо взять с собой?
5. Какие два-три вопроса действительно способны изменить моё понимание ситуации?
6. Что может быть главным возражением или риском для этого человека?
7. Какой следующий шаг будет соответствовать текущей стадии проекта?

После встречи

1. Что изменилось по сравнению с состоянием сделки до встречи?
2. Какой новый факт появился?
3. Какая гипотеза подтвердилась или оказалась неверной?
4. Появился ли новый участник или новая связь на карте?
5. Что пообещал клиент и что пообещали мы?
6. Какой следующий шаг согласован, кто отвечает и к какой дате?
7. Какая помощь нужна от инженера, руководителя или других функций внутри компании?

Рабочий лист 4. Разбор победы или проигрыша

После закрытия крупной возможности задайте команде одинаковые вопросы независимо от результата.

1. Почему клиент в итоге выбрал именно это решение и этого поставщика?
2. На какой стадии мы вошли в проект и было ли у нас достаточно времени для влияния?
3. Какие участники реально двигали решение, а каких мы увидели слишком поздно?
4. Где находился конкурент и что он сделал сильнее нас?
5. Какую роль сыграли цена, комплектность, сроки, техническое решение и сервис?
6. Где мы опирались на факт, а где приняли гипотезу за реальность?
7. Какой наш шаг дал наибольший эффект?
8. Что было удачей, а что можно воспроизвести как систему?
9. Какую ошибку нельзя повторять в следующей сделке?
10. Какой один урок стоит передать всей команде?

Об авторе

Алексей Моргачев — руководитель и практик проектных, объектных и инженерных B2B-продаж. Работал с промышленными, строительными и энергетическими проектами, проектными институтами, заказчиками, генподрядчиками и подрядчиками.

Прошёл путь от полевой и технической работы с клиентами до управления проектами, развития направлений и команд. В своей практике соединяет инженерную логику, коммерческую экономику, работу на объекте и управление длинным циклом сделки.

Основная идея его подхода проста: в сложной продаже недостаточно хорошо представить товар или провести переговоры. Нужно понимать, как решение проходит через людей, проектирование, деньги, закупку, реализацию и эксплуатацию — и управлять следующим осмысленным шагом.

Пожелание читателю

Пусть у вас будет меньше сделок, которые живут только в CRM и надеждах, и больше проектов, где понятны люди, техника, деньги, сроки и следующий шаг. Сложность сама по себе не мешает продаже: если её разложить на систему, ею можно управлять.

Сайт: http://morgachev-sales.ru/
Канал «Проектные продажи | Моргачев»: https://dzen.ru/sales_engineering