Заявка с сайта может остаться в почте. Найденная B2B-компания может неделями лежать в таблице, до которой никто не дошёл. Автоматизация лидогенерации помогает провести оба потока через понятные проверки: система получает обращение или сигнал, проверяет данные и исключения, помогает оценить пригодность лида и передаёт его человеку вместе с контекстом. Спорные решения и подтверждение интереса остаются за командой.
Начинать стоит не с выбора сервиса. Сначала определите, что именно должно попасть к продажам, по какому признаку это можно проверить и кто подтвердит приём. Тогда автоматизация решает конкретную проблему: уменьшает потери между появлением потенциального клиента и первым осмысленным действием команды.
Сначала договоритесь, какой лид готов к передаче
Словом «лид» часто называют разные вещи: посетителя сайта, заявку, компанию из каталога, контакт конкретного человека или подтверждённую возможность для разговора с продажами. Если смешать эти состояния, отчёт покажет рост лидов даже тогда, когда команда просто импортировала больше строк.
Для работы достаточно различать несколько шагов:
| Состояние | Что известно | Что делать дальше |
|---|---|---|
| Кандидат | Компания найдена и предварительно похожа на целевую | Проверить данные и исключения. Если выполнены правила исходящего поиска, можно передать её сотруднику для первого касания, сохранив статус кандидата |
| Обращение | Человек заполнил форму или написал в чат | Сохранить запрос, проверить данные и ответить |
| Лид для проверки | Есть данные для оценки, но часть условий не подтверждена | Передать на ручную проверку |
| Квалифицированный лид | Выполнены согласованные критерии передачи | Передать продажам с причиной отбора |
| Принятый лид | Ответственный подтвердил, что получил достаточно контекста и взял следующий шаг | Отслеживать дальнейший результат отдельно |
Названия стадий в CRM могут быть другими. Важнее записать условия перехода между ними. Для первого участка используйте правило из трёх исходов: «передаём, если…», «отправляем на проверку, если…», «не передаём, если…».
Например, для входящей заявки: передаём, если сохранены запрос и способ ответа, назначен ответственный, а явных препятствий для работы нет. Отправляем на проверку, если контакт неполный или найден возможный дубль. Если человек обратился повторно, новое обращение нужно сохранить в существующей записи и проверить, требуется ли действие её владельца. Новую карточку создавать необязательно, но новое событие терять нельзя.
Для исходящего поиска составьте отдельное правило. Совпадение компании с целевым профилем может сделать её кандидатом для первого касания. Оно ещё не подтверждает интерес или потребность в покупке. Если критерии целевой компании пока не сформулированы, сначала разберите ICP и предложение для B2B-клиента. Автоматическая проверка не исправит расплывчатое правило «подходят все компании, которым могут быть полезны наши услуги».
Найдите место, где лиды теряются сейчас
Мало заявок и потерянные заявки требуют разных действий. В первом случае стоит проверять источники спроса и предложение. Во втором нужно выяснить, почему уже появившийся интерес не доходит до сотрудника.
Проследите один реальный путь от начала до конца. Где впервые появляется запись? Кто видит её сейчас? Сколько времени она может ждать? Что происходит, если форма передала неполные данные, контакт уже существует или интеграция не сработала? По исходящему потоку задайте те же вопросы: где найдена компания, кто подтвердил её пригодность, почему контакт попал в работу и что случилось после передачи.
Запишите путь в одну строку: источник → место, где появилась запись → кто должен её увидеть → кто увидел фактически → следующий шаг. Рядом отметьте время переходов, если оно известно. Неизвестное время тоже полезно отметить: возможно, именно на этом участке не хватает учёта. Если запись не дошла до ожидаемого человека или для неё не назначен следующий шаг, вы нашли участок для первой проверки.
Признаки потери можно увидеть без сложной аналитики:
- обращения остаются в общей почте или чате без ответственного;
- одна компания появляется в нескольких таблицах и CRM под разными именами;
- сотрудники не знают, почему запись была отобрана;
- автоматический фильтр отбрасывает спорные записи без очереди для проверки;
- запись помечена как переданная, но никто не подтвердил её получение;
- количество карточек растёт, а число пригодных разговоров не меняется.
Выберите один источник и один участок, где ошибка заметна и результат можно проверить. Перед изменением сохраните исходное состояние: сколько записей приходит, сколько из них требуют ручного разбора, сколько остаются без владельца и сколько из них принимают сотрудники отдела продаж. Это даст точку сравнения после запуска.
Если заявок мало и один сотрудник своевременно обрабатывает их вручную, сложная связка может не окупить настройку и контроль. Для первой проверки выберите один канал, где можно увидеть событие, нужные данные и ответственного. Входящий и исходящий потоки не обязательно объединять сразу.
Соберите схему от события до принятого лида
Схема нужна до настройки интеграций. Для каждого шага укажите действие системы, проверку и человека, который разбирает исключение.
| Шаг | Что фиксировать или проверять |
|---|---|
| Событие | Поступила форма, сообщение, запись из источника или сигнал о компании |
| Источник | Канал, страница или список, время события и способ получения данных |
| Запись | Компания и контакт, если они известны; исходный текст обращения или описание сигнала |
| Проверки | Обязательные поля, совпадения с существующими записями, исключения и право на дальнейшее действие |
| Решение | Подходит, требует проверки, не подходит либо пока рано решать |
| Передача | Ответственный, причина отбора, следующий шаг и подтверждение приёма |
| Контроль | Ошибки интеграции, записи без владельца, дубли и итог проверки человеком |
Минимальный набор полей зависит от процесса. Не собирайте данные только потому, что в CRM есть свободная колонка. Нужны те сведения, без которых следующий сотрудник не поймёт, с кем и зачем связываться. Для входящей заявки это обычно контакт, содержание запроса и источник. Для исходящего кандидата также нужны основание соответствия целевому профилю, происхождение сведений и статус их проверки.
Дубли проверяйте по нескольким признакам. Одинаковый адрес электронной почты может указывать на один контакт, но компания может прийти через другую форму, домен или написание названия. Правила объединения зависят от системы и способа создания записи. Например, HubSpot описывает разные механизмы устранения дублей и отдельно оговаривает поведение компаний, созданных через API. Поэтому проверяйте именно свой маршрут передачи данных, а не только ручное добавление карточки.
Входящий сценарий: заявка не должна исчезнуть между формой и продажами
Представим учебную ситуацию: человек оставил на сайте запрос на демонстрацию продукта. Форма отправляет уведомление в общую почту. Один менеджер видит письмо, другой создаёт карточку вручную, а третьему кажется, что клиенту уже ответили. В результате ни у кого нет надёжного подтверждения, что обращение принято в работу.
Сценарий можно собрать так:
- Система принимает событие. Форма или бот передаёт текст запроса, контакты, время и источник в единое место учёта.
- Система проверяет запись. Есть ли данные для ответа, нет ли уже записи об этом человеке или компании, не возникла ли ошибка передачи.
- Исключение попадает человеку. Если не хватает контакта, найден возможный дубль или не определён ответственный, обращение не исчезает. Оно попадает в очередь с причиной проверки. Повторный запрос существующего контакта сохраняется в его записи.
- Ответственный подтверждает приём. Сотрудник открывает запись, проверяет исходный запрос и отмечает в общем месте учёта своё имя, время принятия и следующий шаг. Пока отметки нет, обращение не считается принятым.
- Команда проверяет результат. Видно не только то, что CRM создала карточку или обновила существующую, но и то, что новое обращение дошло до человека.
Входящий поток может начинаться в форме сайта, чате или форме рекламной платформы. Для простого запроса обычно достаточно формы с несколькими нужными полями. Бот полезен, когда требуется последовательно уточнить конкретный пробел в данных. Подозрительные обращения отделяйте по проверяемым признакам, но просматривайте часть отклонённых записей, чтобы фильтр не скрывал настоящие заявки.
До запуска согласуйте предельное время подтверждения и резервного ответственного. Если отметки нет в согласованный срок, обращение должно попасть на разбор. Проверьте, умеет ли ваша связка вернуть его в очередь и уведомить резервного сотрудника. Если такой функции нет, назначьте ручную проверку очереди и ответственного за неё.
Не считайте отправку формы доказательством успешной передачи. Правило дублей или ошибка интеграции может помешать созданию записи. Salesforce, например, отдельно описывает ситуацию, когда проверка дублей влияет на отправку через Web-to-Lead. Поэтому после настройки пройдите путь тестовой заявки до конечной очереди и проверьте, кто увидит ошибку.
Назначение задач, сроки реакции и движение уже принятой заявки по сделке требуют своих правил. Здесь контрольная точка проще: обращение сохранено, спорные данные не потеряны, ответственный подтвердил приём.
Исходящий сценарий: найденная компания ещё не означает лид
Теперь другой учебный пример. Команда ищет компании для исходящего B2B-поиска. Сервис находит организацию по отрасли и размеру, затем подставляет сайт и возможного руководителя нужной функции. Если сразу записать всё это в «квалифицированные лиды», продажи получат смесь подходящих компаний, устаревших контактов и сигналов без подтверждённой потребности.
Здесь полезен другой маршрут:
- Система находит кандидата. Она сохраняет источник и признак, по которому компания попала в выборку.
- Правила убирают явные несовпадения. Проверяются заранее согласованные отрасль, география, размер, исключённые компании и уже существующая работа команды. До передачи сверяйте компанию с действующими клиентами и открытыми сделками, а контакт с действующими запретами на обращение.
- Данные уточняются только для оставшихся кандидатов. Проверяются сайт, роль контакта и свежесть сведений. Отсутствующее поле не заменяется догадкой.
- Человек смотрит спорные случаи. Например, компания формально подходит по размеру, но её подразделение или продукт не соответствуют целевому сегменту.
- Продажам передают кандидата вместе с понятным основанием отбора. Сотрудник видит, почему компания выбрана, что проверено и чего пока неизвестно.
Сигнал вроде новой вакансии или изменения в компании может помочь выбрать момент для исследования. Сам по себе он не доказывает, что у компании есть бюджет, задача или желание разговаривать. Компания может быть готова к первому исходящему касанию до проявления интереса, если прошла согласованные проверки. В карточке она остаётся кандидатом для контакта. Проявленный интерес и подтверждённую потребность отмечайте отдельно, когда появится соответствующий ответ человека.
Полученный ответ нужно связать с исходной записью и передать на разбор; неоднозначный смысл проверяет человек. Запланированные автоматические касания по этому контакту пересматривают или останавливают по заранее заданному правилу, особенно если человек отказался от дальнейших сообщений.
После отбора начинается отдельная работа с касанием, ответом и встречей. Этот путь подробнее разобран в статье про автоматизацию продаж от поиска компании до встречи.
Квалифицируйте и передавайте с причиной решения
Квалификация отвечает на практический вопрос: достаточно ли сведений, чтобы человек мог сделать следующий осмысленный шаг. Для входящего обращения и исходящего кандидата это разные шаги. Первому нужен ответ на запрос, второму может требоваться проверенное основание для первого касания.
Правила могут быть простыми. Например, «страна не обслуживается» даёт отказ, а «неизвестен размер компании» направляет на проверку. Баллы и ИИ могут помогать расставлять приоритеты, но их вывод нужно объяснять. Высокая оценка не должна скрывать явное исключение или превращать непроверенную догадку в факт. Сначала определите обязательные условия, затем решайте, нужен ли скоринг. Для важных или неоднозначных решений оставьте ручную проверку.
Жёсткое правило проверяет конкретное условие. Скоринг складывает несколько признаков в балл, который помогает расставлять приоритеты, но сам по себе не подтверждает качество лида. ИИ может предложить тему запроса по свободному тексту; человек должен видеть исходный фрагмент и проверять спорные выводы. Если лид подходит, но момент для разговора не наступил, сохраните отдельный статус «вернуться позже» и условие повторной проверки.
У каждой записи должен быть один из понятных маршрутов:
- Передать: критерии для следующего действия выполнены, причина отбора сохранена, есть ответственный и следующий шаг. Для исходящего кандидата передача на первое касание не означает подтверждённого интереса.
- Проверить вручную: данных не хватает, признаки противоречат друг другу или найден возможный дубль с новым событием.
- Не передавать сейчас: найдено явное несовпадение, запрет или отсутствие основания для работы. Причину сохраняют. Если найден дубль, сначала проверьте существующую запись: новое обращение или сигнал нужно добавить к ней и уведомить её владельца, если требуется действие. Дубль карточки не означает, что новое событие можно отбросить.
Карточка передачи должна отвечать на вопросы сотрудника: кто это, откуда запись, что произошло, почему она подходит, что уже проверено, чего не хватает и какое действие ожидается. Система может заполнить часть полей автоматически. Человек подтверждает спорные сведения и принимает лид в работу.
После разговора полезно вернуть в процесс причину результата: критерии были верны, контакт оказался не тем человеком, данные устарели или запрос относился к другой задаче. Такая обратная связь помогает исправлять отбор. Последующее движение принятого лида и правила этапов подробнее описаны в материале об автоматизации воронки продаж.
Выберите минимальную связку и проверьте исключения
Для первого участка достаточно источника события, места хранения записи, правил проверки и человека, который разбирает ошибки. Это может быть форма с CRM, таблица с интеграцией или более сложная связка. Выбор зависит от объёма, числа источников, доступных интеграций и того, кто будет поддерживать процесс. Критерии выбора самой CRM разобраны отдельно в статье как выбрать CRM для B2B-продаж.
Существующей CRM достаточно, если она принимает событие, сохраняет нужные поля, показывает ошибки и позволяет проверить передачу. Готовую интеграцию оценивайте по этим требованиям. Если она не передаёт важные данные или не показывает сбои, может понадобиться собственная связка с назначенным владельцем поддержки. При сбое сохраните исходное событие и ошибку, проверьте, появилась ли запись, и только затем повторяйте передачу без создания дубля.
Стоимость складывается не только из подписок. Учтите подготовку данных, настройку правил, проверку разных исходов и дальнейшее обслуживание. До запуска назначьте человека, который увидит ошибку, сможет остановить сценарий и проверит записи, затронутые сбоем.
Перед обработкой реальных обращений проверьте следующие ситуации:
| Ситуация | Что должно произойти |
|---|---|
| Все данные есть, условия выполнены | Запись доходит до нужного ответственного с контекстом |
| Не хватает обязательного поля | Запись попадает на проверку, причина видна |
| Компания или контакт уже есть | Новое событие сохранено в существующей записи, второй лид незаметно не появляется |
| Ответственного определить не удалось | Возникает заметная ошибка или очередь разбора |
| Назначенный сотрудник не подтвердил приём | Запись остаётся под контролем и доходит до резервного ответственного |
| Одно событие пришло повторно | Не создаётся лишнее действие, содержание события не теряется |
| Интеграция недоступна | Событие не считается успешно переданным, проблема видна владельцу процесса |
| Сценарий включили после накопления старых записей | Заранее известно, будут ли они обработаны и по каким правилам |
Для каждой ситуации создайте отдельную тестовую запись и зафиксируйте ожидаемый итог до запуска теста. Затем проверьте фактическую карточку или очередь, назначенного ответственного и сообщение об ошибке, если оно должно появиться. Отмечайте тест пройденным только тогда, когда итог виден в рабочем месте учёта, а не лишь в окне настройки интеграции.
Тест внутри конструктора не всегда выполняет реальные действия. Например, HubSpot предупреждает об ограничениях тестирования workflow. Поэтому после проверки логики нужен небольшой контролируемый запуск с наблюдением за фактическими записями и назначениями.
Если обрабатываются персональные данные или запускаются сообщения, отдельно проверьте применимые правила для стран, каналов и получателей. Наличие публичного контакта либо технической возможности отправить сообщение само по себе не отвечает на правовой вопрос. Для каждого рынка нужно определить основание обработки и правила коммуникации.
Проверьте результат по лидам, а не по числу карточек
Технически исправная интеграция может создать много записей и не улучшить работу продаж. Смотрите на переходы между согласованными состояниями:
- сколько обращений или кандидатов появилось из каждого источника;
- сколько прошло проверку, сколько потребовало ручного разбора и почему;
- сколько записей передано для первого касания или ответа на запрос;
- сколько передач подтверждено сотрудниками;
- сколько осталось без ответственного или потерялось при ошибке;
- сколько принятых лидов привело к содержательному разговору и следующему шагу.
Сравнивайте входящий и исходящий поток отдельно. У них разное начало: человек с формой уже обратился, а найденная компания может вообще не знать о вас. Общим может быть критерий качества передачи, но одинаковый процент конверсии для этих потоков ожидать нельзя.
До первой настройки сохраните исходные показатели за выбранный период. После запуска возьмите сопоставимый период и проверьте количество записей, причины отклонений, время ожидания передачи и подтверждения приёма, а также действия сотрудников. Если цикл продажи длинный, не делите сделки этого месяца на лиды этого же месяца без связи между конкретными группами записей.
Стоимость квалифицированного лида равна относимым расходам на выбранный поток за сопоставимый период, делённым на число лидов, прошедших согласованные критерии. В расходы включайте инструменты, интеграцию, ручную проверку и сопровождение; учитывайте задержку между получением и квалификацией. Расширять схему стоит после проверки на небольшом потоке, когда записи не теряются, дубли контролируются, а команда успевает принимать подходящие лиды.
Если система стала создавать дубли, терять обращения или передавать непроверенные контакты, сценарий нужно исправить или остановить. Если ошибок мало, но продажам по-прежнему не хватает контекста, пересмотрите критерий передачи. Результат автоматизации можно проверить по подтверждению сотрудника: нужная запись пришла, причина понятна, следующий шаг определён.
Что почитать дальше
- Площадки для поиска B2B-клиентов помогут выбрать источники компаний для исходящего потока.
- Как собрать базу B2B-клиентов подробнее объясняет, какие сведения проверять перед работой с найденными компаниями и контактами.
Использованные источники
- HubSpot: создание форм, создание бота, устранение дублей записей, оценка лидов, назначение владельцев через workflow, создание workflow, тестирование workflow.
- LinkedIn: Lead Gen Forms.
- Salesforce: влияние правил дублей на Web-to-Lead.
- Clay: пользовательские сигналы.
- n8n: приём событий через Webhook.
- Google Analytics: события лидогенерации.
- NIST: профиль рисков генеративного ИИ.
- ICO: правила B2B-маркетинга в Великобритании.
- Европейская комиссия: правовые основания обработки персональных данных в ЕС.