Автоматизация воронки продаж в B2B: этапы, правила и контроль

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

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

Опишите этапы, которые проходит ваша сделка

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

Сначала договоритесь о трёх понятиях. В разных системах названия могут отличаться, но для работы полезно разделять:

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

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

Для начала опишите свой процесс в таблице. Ниже учебный пример.

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

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

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

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

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

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

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

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

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

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

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

Например, проблема «теряем обращения без ответственного» достаточно конкретна. Её можно проверить до настройки и после неё. Формулировка «нужно автоматизировать продажи» пока не объясняет, что именно менять.

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

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

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

Разберите сценарий от события до результата

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

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

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

Можно настроить такую последовательность:

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

Срок здесь задаёт команда под свои рабочие часы и обещания клиенту. Одного универсального значения для всех B2B-продаж нет.

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

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

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

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

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

Сценарий 2. После предложения должен состояться согласованный следующий шаг

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

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

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

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

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

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

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

Задайте условия запуска, остановки и проверки

Перед настройкой заполните карточку сценария.

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

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

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

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

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

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

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

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

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

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

Определите, где достаточно правил, а где нужен ИИ

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

ИИ можно использовать для подготовки кратких сводок исходных материалов. Например, документация Copilot в Dynamics 365 Sales описывает резюме данных о сделке и документов, а также подготовку к встрече по доступным заметкам и письму. Возможности конкретного инструмента и состав используемых данных нужно проверить отдельно.

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

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

Например, ИИ может предложить: «Клиент согласен продолжить». Сотруднику нужно увидеть, на какой фразе основан вывод и что именно согласовано: ещё одна встреча, обсуждение цены или сама покупка.

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

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

Учтите правила отправки сообщений и отказы получателей

Для автоматических сообщений также учитывайте страну, канал и характер общения. Правила коммерческого сообщения и сообщения по уже оформленному заказу могут различаться. Американские требования CAN-SPAM распространяются и на B2B-письма; британские правила различают корпоративных получателей и некоторые другие категории бизнеса. Публичный адрес сам по себе не даёт универсального разрешения на рассылку.

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

Проверьте сценарий на небольшой группе сделок

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

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

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

До работы с клиентами пройдите тестовые ситуации.

Ситуация	Ожидаемый результат
Все условия выполнены	Происходит нужное действие
Не хватает обязательных данных	Запись попадает на проверку
Клиент ответил до запланированного сообщения	Дальнейшие действия пересматриваются
Сотрудник включил ручной режим	Автоматические действия останавливаются по правилам
Событие пришло повторно	Не возникает лишнего действия
Сделка вернулась на предыдущий этап	Повторяются только разрешённые шаги
Исполнитель недоступен или подключение не работает	Проблема передаётся конкретному сотруднику для разбора

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

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

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

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

Оцените результат по движению сделок

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

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

Для конверсии между этапами берите одну и ту же группу сделок:

Конверсия из этапа А в этап Б = число сделок выбранной группы, достигших Б за срок наблюдения / число сделок этой группы, вошедших в А × 100%.

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

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

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

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

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

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

Решение о дальнейшей работе принимайте по исходной задаче:

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

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

Что почитать дальше

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

Использованные источники

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