От веб-формы до продажи: как CRM обрабатывает и маршрутизирует данные
На первый взгляд обработка данных из веб-формы кажется простой задачей: получить данные, создать лид в CRM и передать его менеджеру.
Но когда бизнес получает тысячи обращений в день, использует десятки веб-форм и работает с разными маркетинговыми каналами, такой процесс быстро становится значительно сложнее.
В этой статье мы разберем, как может быть построен процесс обработки данных из Webforms в CRM: от получения JSON-запроса и проверки данных до дедупликации, создания или связывания Lead, маршрутизации и уведомления ответственных сотрудников.
В качестве примера рассмотрим реальный проект B2C-клиента, для которого первоначально каждый запрос из веб-формы автоматически создавал новый лид. Это приводило к большому количеству дублей и усложняло работу отдела продаж.
А узнать больше можно в нашем видео:
От простой веб-формы к сложному CRM-процессу
Основным источником лидов у клиента были веб-формы на лендингах и маркетинговые кампании, в том числе через Meta.
Изначально каждый запрос просто создавал новый Lead в CRM. При небольшом количестве обращений это не было критичной проблемой. Но при тысячах лидов в день количество дублей быстро стало влиять на процесс продаж.
Поэтому задача состояла не только в получении данных из формы. Нужно было определить:
существует ли уже такой Lead;
какую веб-форму отправил пользователь;
от какого партнера или канала пришел запрос;
какой процесс продаж нужно запустить;
кому назначить Lead;
какие уведомления отправить.
Так простой процесс создания лида превратился в полноценную систему обработки данных.
Получение и проверка данных
Процесс начинается с получения JSON-запроса с данными веб-формы.
Сначала система создает запись Social Media Request, где сохраняется полученный JSON. Затем проверяется, что это за форма, откуда она пришла и корректно ли заполнены все необходимые поля.
Если данные не соответствуют ожидаемому формату, срабатывает error handling. Уведомление получает как внутренняя команда, так и команда партнера, если проблема возникла на стороне источника.
Если данные корректны, система создает соответствующую запись WebSubmission.
Именно WebSubmission становится центральной точкой дальнейшей обработки.
Дедупликация: поиск существующего Lead
Одна из ключевых задач системы — не создавать новый Lead каждый раз, когда пользователь отправляет форму.
После создания WebSubmission запускается процесс дедупликации. Система ищет подходящий существующий Lead по полученным данным.
При этом учитываются возможные различия в написании имени и небольшие опечатки.
Если Lead найден, WebSubmission связывается с существующей записью, а необходимые данные обновляются.
Если подходящего Lead нет, только тогда создается новый.
Такой подход позволяет значительно сократить количество дублей и сохранить историю взаимодействия с клиентом в одной записи.
Маршрутизация и дальнейшая обработка
После того как Lead найден или создан, система должна определить, что делать с ним дальше.
В зависимости от условий она может:
продолжить текущий процесс продаж;
перезапустить процесс;
обновить определенные поля;
назначить Lead конкретному пользователю;
передать его команде;
отправить необходимые уведомления.
Здесь и появляется основная сложность проекта.
У клиента десятки веб-форм и множество сценариев их обработки. Одна форма может вести в один процесс, другая — в совершенно другой. Решение также может зависеть от партнера, кампании, команды, офиса и других параметров.
Поэтому со временем первоначальный MVP превратился в достаточно большое дерево бизнес-логики.
Почему такая система разрабатывается месяцами
Основная сложность оказалась не в самой интеграции с веб-формами, а в количестве бизнес-сценариев.
Начав с базовой версии, команда постепенно добавляла новые кейсы, правила и исключения.
В результате система должна была не просто принять данные, а самостоятельно определить дальнейший путь каждого обращения:
Web Form → JSON Request → проверка → WebSubmission → дедупликация → Lead → процесс продаж → маршрутизация → уведомление.
На разработку первой версии и последующие улучшения ушло почти год, и система продолжает развиваться.
Глобальная система уведомлений
Следующим этапом стала разработка глобальной системы уведомлений.
Для компании с тысячами пользователей важно не только правильно назначить Lead, но и вовремя сообщить ответственному сотруднику, что произошло и какое действие от него требуется.
Поэтому система должна учитывать разные параметры — офис, команду, маркетинговую кампанию, Lead, тип события и другие условия — и на их основе определять получателей уведомления.
Отдельное внимание уделили шаблонам писем. Поскольку менеджеры могут получать десятки уведомлений в день, письма должны быть короткими, понятными и визуально структурированными.
Пользователь должен практически сразу увидеть:
что произошло → к какому процессу относится уведомление → что нужно сделать.
При этом клиенту важно иметь возможность самостоятельно менять получателей и шаблоны без постоянного привлечения разработчиков.
Заключение
Этот проект хорошо показывает, как простой запрос — «обрабатывать данные из веб-форм» — может превратиться в масштабное CRM-решение.
В конечном итоге система должна не просто принимать данные, а понимать контекст каждого обращения, находить существующего клиента, предотвращать создание дублей, определять нужный процесс, маршрутизировать Lead и своевременно уведомлять ответственного сотрудника.
Именно поэтому при проектировании интеграций с Webforms важно смотреть не только на то, как получить данные, но и на весь их дальнейший путь внутри CRM — от первого запроса до следующего действия и, в конечном итоге, продажи.
Comments