В B2B проектные продажи редко держатся исключительно на менеджере. Сначала нужно разобраться в запросе, подобрать решение, подключить технических специалистов, получить расчёты и согласовать условия.
При низкой конверсии потенциальных покупателей в клиентов кажется, что проблема заключается в отсутствии сильных менеджеров. На деле слабое место может быть в самом процессе. Разбираем, как low-code CRM помогает выстроить длинные B2B-продажи и управлять ими.
При низкой конверсии потенциальных покупателей в клиентов кажется, что проблема заключается в отсутствии сильных менеджеров. На деле слабое место может быть в самом процессе. Разбираем, как low-code CRM помогает выстроить длинные B2B-продажи и управлять ими.
Содержание:
Что такое проектные продажи в B2B
Чем структура проектных продаж отличается от типовых сделок
Этапы проектных продаж: где теряется контроль
Как понять, что проектные продажи пора автоматизировать
Как автоматизировать проектные продажи в CRM
Кейс ГК «Ревада»: как CRM помогает вести подбор сырья в одном рабочем пространстве
Кейс «Делетрона»: как связали проектные продажи, закупки и входящие документы
Заключение
Чем структура проектных продаж отличается от типовых сделок
Этапы проектных продаж: где теряется контроль
Как понять, что проектные продажи пора автоматизировать
Как автоматизировать проектные продажи в CRM
Кейс ГК «Ревада»: как CRM помогает вести подбор сырья в одном рабочем пространстве
Кейс «Делетрона»: как связали проектные продажи, закупки и входящие документы
Заключение
Что такое проектные продажи в B2B
Проектная продажа — это сделка, где компания продаёт решение под задачу клиента, не типовой товар «с полки». Перед подготовкой КП менеджер уточняет запрос, собирает вводные, подключает кросс-функциональную команду, сводит расчёты воедино и согласует условия. Такой подход встречается в промышленности, строительстве, инжиниринге, поставках сложного оборудования, IT-решений, химического сырья и других B2B-направлениях.
Чем структура проектных продаж отличается от типовых сделок
При типовой продаже клиент выбирает готовый продукт или услугу с понятными характеристиками. Менеджер уточняет условия, проверяет наличие или стандартные параметры, готовит счёт и доводит сделку до оплаты. Процесс в целом предсказуем — понятно, что именно продаётся, кто участвует в процессе и какие шаги нужны до оплаты.
В проектной продаже сначала нужно понять задачу клиента, а потом собрать под неё решение. Такую сделку редко ведёт один менеджер. Поэтому руководителю важно видеть не только этап воронки продаж, но и то, что происходит внутри этапа: кто готовит расчёт, какие данные уже собраны, где задержалось согласование и почему клиент всё ещё ждёт ответа.
Этапы проектных продаж: где теряется контроль
В IT, строительстве, инжиниринге, поставках оборудования или сырья этапы проектных продаж могут называться по-разному. Главный нюанс заключается в том, как выстроена работа и где происходят сбои.
Как понять, что проектные продажи пора автоматизировать
Автоматизация продаж нужна, когда длинные продажи уже нельзя нормально вести только по этапам воронки продаж. Сделка вроде бы находится в работе, но руководителю непонятно, что именно происходит внутри: кто готовит расчёт, на чём задержалось КП, кто ждёт данных и какой следующий шаг должен быть сделан.
КП готовят слишком долго
Менеджер не всегда может подготовить КП сам. Для предложения нужны расчёты, технические данные, состав поставки, сертификаты или оценка объёма работ. Менеджеру приходится напоминать коллегам о расчётах, отслеживать, какие данные уже есть, и самому сводить всё воедино.
Руководитель не видит реальный статус сделки
Воронка показывает общий этап: «КП готовится», «согласование» или «договор». Но по нему не видно, что именно задерживает сделку: расчёт, проверка наличия, правки договора, ответ клиента или задача смежного отдела.
Если эта работа не отражена в одном месте, руководитель узнаёт о проблеме с опозданием. Он спрашивает менеджера, но тот не всегда может сразу ответить: нужно уточнить статус у коллег, проверить переписку, найти актуальные файлы и понять, где остановился процесс. К тому моменту, когда причина задержки становится понятной, компания уже срывает срок ответа или рискует потерять клиента.
История запроса теряется
Часть информации остаётся в CRM, часть — в 1С, часть — в почте, файлах или личных заметках менеджера. Проблемы начинаются, когда сделку нужно передать коллеге или вернуться к запросу через несколько месяцев. Тогда приходится заново собирать контекст: что клиент запрашивал, какие расчёты уже делали, какие условия согласовали, какие документы готовили и на чём остановились.
Как автоматизировать проектные продажи в CRM
Описать реальный путь сделки
Автоматизацию лучше начинать не с новых полей в CRM, а с разбора самого бизнес-процесса. Нужно понять, как сделка проходит от первого запроса клиента до КП, договора и передачи заказа в работу: кто принимает обращение, кто собирает вводные, где нужен расчёт, кто согласует условия и кто отвечает за следующий шаг.
Так видно, где проектная продажа выходит за рамки работы одного менеджера. Например, менеджер ждёт расчёт от технолога, проверку наличия от склада, условия поставки от закупки или правки договора от юриста. Если эти участки не описать, CRM будет показывать этап воронки, а реальная работа по сделке останется в переписке, таблицах и устных договорённостях.
Определить результат каждого этапа
После описания пути сделки нужно понять, чем должен заканчивается каждый этап: расчёт готов, условия согласованы, актуальная версия КП собрана, заказ можно передать в работу. Тогда CRM показывает не формальный этап, а реальное состояние сделки.
Собрать данные в карточке сделки
Карточка сделки должна помогать менеджеру вести запрос. В ней нужны данные, которые влияют на следующий шаг: задача клиента, требования, ограничения по срокам или бюджету, расчёты, актуальная версия КП, согласованные условия, документы и ответственный за ближайшее действие.
Если CRM интегрирована с 1С, ЭДО, учётными базами и другими системами, часть данных подтягивается в карточку автоматически. Менеджеру не нужно отдельно искать их в соседних программах, файлах и переписке. Иначе CRM остаётся витриной: сделка в ней есть, но рабочая информация по-прежнему живёт в других местах.
Обеспечить данные для будущих отчётов и дашбордов
В длинных B2B-продажах руководителю мало видеть сумму сделок, количество лидов и конверсию сделки. Эти показатели показывают общий результат, но не объясняют, почему сделки тормозят.
Полезнее смотреть, сколько времени готовится КП, какие задачи чаще всего просрочены, на каких этапах сделки застревают, где ждут ответ клиента и где есть риск по срокам, данным или документам. Такая аналитика показывает не только продажи, но и работу команды внутри сделки.
На её основе можно менять структуру проектных продаж: убирать лишние согласования, подключать участников раньше, дорабатывать маршруты и интеграции. Тогда развитие проектных продаж опирается не на ощущения менеджеров и руководителя, а на реальные узкие места процесса.
Подробнее о CRM-системе для сложных B2B2-продаж длительного цикла
Узнать подробнее
Кейс ГК «Ревада»: как CRM помогает вести подбор сырья в одном рабочем пространстве
ГК «Ревада» поставляет химическое сырьё для косметической и пищевой промышленности, производителей бытовой химии, промышленного клининга и переработки пластмасс. Обработка клиентского запроса здесь делится на две стадии:
- интерес — когда клиент озвучивает свою потребность, изучает возможные варианты, тестирует образцы, но ещё не принял окончательного решения о покупке;
- проект — когда проходит подготовка к заключению сделки.
Что усложняло работу с запросами
- Менеджеры общались с клиентами по почте, поэтому часть запросов могла теряться в потоке писем. По обращениям, которые уже находились в работе, было сложно быстро понять текущий статус.
- Запросы технологам передавали через пересылку писем. У технологов скапливались разрозненные задачи, а менеджерам приходилось отдельно отслеживать сроки и напоминать о дедлайнах.
- У руководства не было сводной картины по клиентским запросам. Из-за этого было сложнее оценивать спрос и корректировать закупочную политику.
Как CRM изменила процесс
Теперь обращения клиентов фиксируются в одном месте. По каждому запросу технолог получает задачу с вводными, деталями и сроком выполнения. Менеджеру не нужно пересылать письма вручную и отдельно выяснять, кто взял запрос в работу.
Когда клиент готов перейти к покупке, менеджеру не нужно поднимать старую переписку и заново восстанавливать детали запроса: что именно искали, какие варианты подобрали, какие материалы уже передали. Всё это зафиксировано в системе, поэтому можно быстрее готовить КП и вести сделку дальше.
Поскольку клиентские запросы обрабатываются централизованно, руководство видит, в каком направлении движется спрос. Например, в сторону более дешёвых продуктов для масс-маркета или дорогих брендовых ингредиентов.
Что изменилось после внедрения low-code BPMS
- Ускорилась обработка клиентских запросов.
- Упростилось взаимодействие между продажами, закупкой, логистикой и технологической поддержкой.
- Руководство получило основу для более точной корректировки закупочной политики.
Кейс «Делетрона»: как связали проектные продажи, закупки и входящие документы
«Делетрон» занимается сложными инженерными решениями в сфере систем безопасности. Компания состоит из 21 обособленного подразделения и собственного Центра компетенций (Research and Development, R&D). Каждая сделка включает несколько связанных этапов — от подготовки предложения до закупки и документов.
Что усложняло управление сделками
Из-за того, что сотрудники работали в нескольких программах одновременно, сделку было трудно вести как единый процесс. Так, технико-коммерческое предложение в «Делетроне» готовит не один менеджер. В подготовке участвуют несколько специалистов, и каждый отвечает за свой блок расчётов и данных по оборудованию.
После согласования предложения начинается работа с составом заказа. Это один из самых сложных участков работы: по одной заявке могут быть тысячи позиций, часть которых есть в наличии на складе, а остальное требуется согласовать и закупить. Специалисту по закупкам приходилось вручную отслеживать, что уже одобрено или отклонено, чтобы в итоге собрать всё необходимое оборудование для объекта.
При этом процесс редко завершается за один раунд: часть позиций согласовывается, остальные уходят на следующий круг. Параллельно требуется контролировать каждого из согласователей, чтобы никто не нарушал сроки.
Компании требовалось on-premises решение на базе ОС Linux с СУБД PostgreSQL
Как связали продажу со складом и закупками
После встречи с клиентом менеджер запускает подготовку ТКП в системе. Предложение собирает не один человек: в расчётах участвуют специалисты по оборудованию, материалам, проектным, монтажным и пусконаладочным работам. Каждый отвечает за свою часть, а итоговое ТКП формируется на основе этих данных.
После согласования предложения команда переходит к спецификации. В крупных заявках она может содержать сотни позиций, поэтому важно сразу понимать, что есть на складе, а что нужно докупить. Склад проверяет позиции из спецификации и резервирует наличие. Всё, чего не хватает, попадает в список дефицита.
Дальше с дефицитом работает закупщик: подбирает нужную номенклатуру, предлагает аналоги или оформляет заказ поставщику. Так продажа, склад и закупка работают с одной заявкой, а менеджер видит, что происходит с заказом внутри компании: что уже есть в наличии, что ушло в закупку и к чему привязаны сроки.
Как документы связали с заказом
Входящие УПД загружаются в систему через интеграцию с Контур.Диадоком. Ответственный сотрудник получает уведомление и обрабатывает документ в том же процессе, где уже есть сделка, заявка, закупка и связанные позиции.
Формализованные документы автоматически распознаются и связываются с нужным счётом, договором и заявкой. Для остальных связь создаётся вручную за несколько кликов.
Таким образом, всё зафиксировано в системе: для какого проекта закупка, по какой заявке, когда поступили позиции. Это исключает потерю данных и чётко обозначает зоны ответственности.
Заключение
Кейсы «Ревады» и «Делетрона» показывают, зачем в проектных продажах связывать работу разных участников вокруг одного клиентского запроса.
Запрос должен быть виден в системе не как общий этап воронки, а как понятная рабочая картина: что уже сделано, кто отвечает за следующий шаг, каких данных не хватает, какие документы связаны со сделкой и что влияет на срок ответа клиенту.
Тогда участники работают в одной информационной среде и меньше тратят время на ручные уточнения. Сделка не держится на памяти конкретного менеджера или специалиста: данные, задачи, документы и следующий шаг видны в системе. Руководитель понимает, что происходит с запросом, и может раньше заметить риск по срокам.
Клиенту неважно, почему компания долго отвечает на запрос. Ему нужно понять, подходит ли решение и когда можно двигаться дальше. Если ответ приходит слишком поздно, клиент начинает рассматривать другие варианты.
