Интеграция сайта с CRM: какие данные передавать из формы, чтобы менеджер мог работать без ручной переписки

Карта данных между формой и CRM

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

Маршрут заявки после отправки

Запись в CRM сама по себе не гарантирует обработку. Нужно определить сущность, в которую попадет обращение, ответственного, очередь при его отсутствии, уведомление и действие при ошибке обмена. В Битрикс24 это может быть лид, сделка или элемент другой сущности — выбор зависит от воронки и правил квалификации, а не от формы сайта.

Проверка по тестовым обращениям

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

Интеграция начинается с карты данных, а не с webhook

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

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

Сущности и дедупликация

В Битрикс24 заявка может стать лидом, сделкой, контактом или записью в другой согласованной сущности. Выбор зависит от процесса продаж; его фиксируют до запуска, чтобы одна и та же заявка не появлялась в разных воронках. Отдельно согласуют правило совпадения по телефону, e-mail или компании и действие при дубле: объединение, уведомление менеджера или создание новой записи с пометкой.

Проверка обмена проходит по всей цепочке

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

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

Частые вопросы

Какие поля передавать в CRM из формы?

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

Нужно ли создавать лид или сделку?

Это зависит от модели продаж в конкретном портале Битрикс24. До настройки описывают, кто квалифицирует обращение, когда оно становится сделкой и какие статусы нужны менеджеру.

Как проверить, что заявка не потерялась?

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

Итог

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

Ответственный и скорость реакции

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

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

Изменения без потери истории

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