Чем проектные продажи отличаются от транзакционных
В транзакционной продаже менеджер проходит воронку за дни: квалифицировал, выставил счёт, получил оплату. В проектных B2B-продажах цикл другой:
- Несколько лиц, принимающих решения — технический директор, финансовый директор, генеральный директор.
- Обязательный этап технического согласования — спецификации, ТЗ, расчёт ROI.
- Многоуровневое согласование договора — юрист, бухгалтер, руководитель.
- Долгий межэтапный простой — сделка может «зависнуть» на 2–4 недели без видимого движения.
Если такую сделку вести в обычной воронке «Продажи», аналитика ломается: конверсии занижены, средний цикл непонятен, менеджеры теряют нить переговоров.
По нашему опыту, оптимальное решение — выделить воронку «Проектные продажи» (или «Стройка», «Производство» — в зависимости от отрасли) как отдельное направление в CRM Битрикс24, с собственными стадиями, карточкой и автоматизацией.
Архитектура воронок для длинных сделок
В типовом проекте для B2B-компании с несколькими каналами продаж настраивается система из нескольких связанных воронок:
flowchart LR
COLD[Холодный поиск B2B] -->|Интерес подтверждён| PROJ[Проектные продажи]
COLD -->|Отказ| REJ[Отказники]
PROJ -->|Выиграна| EXEC[Исполнение обязательств]
PROJ -->|Проиграна| REJ
REJ -->|Реанимация| PROJ
EXEC --> REPEAT[Повторные продажи]
Холодный поиск B2B — первичная квалификация: звонки, выявление потребностей, принятие решения о дальнейшем взаимодействии. Если интерес подтверждён, карточка сделки перемещается в воронку проектных продаж; если нет — уходит в «Отказники» для подогрева.
Проектные продажи — основная воронка длинной сделки. Здесь проходят все ключевые этапы от квалификации до подписания договора.
Исполнение обязательств — отдельная воронка для ведения проекта после победы в сделке. Передача проекта из продаж в операционный отдел — один из ключевых сценариев, который прорабатывается при настройке.
Повторные продажи — для клиентов, с которыми уже завершён хотя бы один проект. Цель: выявление новых потребностей и поддержание регулярного контакта.
Если компания участвует в тендерах, под это направление проектируется изолированный смарт-процесс с выделенными стадиями и специфической ролевой моделью — так тендерная аналитика не смешивается с прямыми продажами.
Стадии воронки проектных продаж
Типовой набор стадий для воронки проектных B2B-продаж в Битрикс24 (до 15 стадий в одной воронке):
| № | Стадия | Ключевые действия |
|---|---|---|
| 1 | Квалификация | Заполнение профиля клиента, определение бюджета и сроков |
| 2 | Выявление потребностей | Встреча / звонок, фиксация требований в карточке |
| 3 | Техническое согласование | Подготовка ТЗ или спецификации, согласование с техническим специалистом клиента |
| 4 | Подготовка КП | Формирование коммерческого предложения по корпоративному шаблону |
| 5 | КП отправлено | Фиксация даты отправки, запуск таймера следующего контакта |
| 6 | КП на рассмотрении | Работа с возражениями, дополнительные встречи |
| 7 | Переговоры по условиям | Обсуждение условий сделки, корректировка КП |
| 8 | Договор на согласовании | Запуск бизнес-процесса согласования |
| 9 | Договор подписан | Фиксация даты подписания, переход в исполнение |
| 10 | Счёт выставлен / Оплата получена | Финальные стадии успешной сделки |
Обязательные поля при переходе между стадиями — один из ключевых инструментов контроля: менеджер не может продвинуть карточку вперёд, не заполнив нужные данные (например, сумму сделки или прикреплённый файл КП).
Карточка сделки: какие поля нужны в проектных продажах
Карточка проектной сделки богаче, чем в розничной воронке. В типовой настройке предусматривается до 50 полей суммарно (при нескольких воронках повторяющиеся поля считаются за одно). Для проектных продаж критичны:
- Контактные данные — несколько контактов на стороне клиента с указанием роли (технический специалист, финансовый директор, ЛПР).
- Бюджет и сроки — оценочный бюджет проекта, плановая дата старта.
- Источник сделки и тип обращения — для аналитики по каналам.
- Ответственный менеджер — с автоматическим назначением по заданным правилам.
- Связанные документы — КП, ТЗ, спецификации, договор (файлы прямо в карточке).
- Причина отказа — обязательное поле при переводе сделки в проигранные.
- Тег сделки — для сохранения аналитики по типам обращений при консолидации нескольких воронок в одну.
Перед тем как определять итоговый список полей, имеет смысл пройти опросный лист для клиента перед внедрением — он помогает собрать требования к карточке без лишних итераций.
Согласование договоров внутри воронки
Один из самых болезненных этапов в проектных продажах — согласование договора. Без автоматизации это цепочка звонков и пересылки файлов по почте, где легко потерять версию или пропустить правки юриста.
В Битрикс24 согласование договора настраивается как бизнес-процесс, запускаемый прямо из карточки сделки. Типовая схема:
- Менеджер прикрепляет файл договора и пакет документов контрагента (карточка, устав, налоговая отчётность, ИНН, протокол об избрании директора).
- Система автоматически формирует название задачи согласования по шаблону (наименование контрагента + тип договора).
- Маршрут согласования определяется по типу документа и организации: например, юрисконсульт → главный бухгалтер → генеральный директор.
- Статус согласования («В работе» / «Согласован» / «Не согласован»), текущий согласующий и лог действий отображаются в карточке автоматически.
- После финального согласования в карточке фиксируется итоговый вариант договора.
Подробнее о том, как устроен этот бизнес-процесс технически, — в статье согласование договоров в Битрикс24.
Автоматизация: роботы и бизнес-процессы
Для проектной воронки автоматизация решает три задачи: снижает нагрузку на менеджера, исключает потери на переходах и даёт руководителю сигналы об отклонениях.
Что настраивается роботами (до 7 роботов на воронку):
- Автоматические уведомления менеджеру при «зависании» сделки на стадии дольше N дней.
- Напоминание о следующем контакте после отправки КП.
- Уведомление руководителю при переводе сделки в «Проигранные».
- Смена ответственного при передаче проекта в отдел исполнения.
Что настраивается бизнес-процессами (до 5 БП на воронку):
- Запуск согласования договора по нажатию кнопки в карточке.
- Автоматическое формирование КП по корпоративному шаблону (Word/PDF) с подтягиванием переменных из карточки сделки.
- Передача данных в смежные системы — например, при интеграции с 1С статусы оплат и отгрузок синхронизируются автоматически.
Аналитика и контроль длинных сделок
Для РОПа в проектных продажах важны не только конверсии, но и активности: сколько встреч провёл менеджер, сколько сделок «зависло» без движения, какова средняя длина цикла по типам клиентов.
Стандартный инструментарий аналитики Битрикс24 позволяет отслеживать:
- Воронку по стадиям — количество и суммы сделок на каждом этапе.
- Скорость движения — среднее время пребывания сделки на стадии.
- Активности менеджеров — звонки, встречи, письма, задачи, привязанные к сделке.
- Plan vs fact — запланированные контакты против фактически выполненных.
Права доступа настраиваются по ролям: менеджер видит только свои сделки, руководитель отдела — весь пайп команды, коммерческий директор — сводную аналитику без возможности редактирования карточек.
Если сделки из разных воронок нужно анализировать в едином отчёте, используется система тегирования: при консолидации нескольких воронок в одну теги сохраняют аналитику по типам обращений.
Как выглядит типовой проект настройки
Настройка воронки проектных продаж в Битрикс24 обычно проходит в два этапа.
Этап 1. Формирование технического задания — бизнес-аналитик проводит интервью с командой продаж, фиксирует сценарии работы в виде таблиц стадий, схем переходов и описания автоматизации. Результат — документ ТЗ, на основе которого ведётся настройка. Стандартная трудоёмкость этапа: около 10 часов (5 ч. на интервью + 5 ч. на документ). Срок — 2–3 недели.
Этап 2. Настройка и автоматизация — на основе ТЗ настраиваются стадии (до 15 на воронку), поля карточки (до 50 полей суммарно), роботы и бизнес-процессы. Отдельно настраиваются права доступа и, при необходимости, интеграции. Типовые сроки — 2–5 недель в зависимости от объёма.
Если фактическая трудоёмкость оказывается меньше запланированной, неиспользованный остаток часов конвертируется в работы по другим задачам. Если больше — часы докупаются по согласованию сторон.
Перед стартом настройки рекомендуем провести аудит текущего состояния портала — это помогает выявить унаследованные проблемы и не переносить их в новую архитектуру.