Форма на сайте отправила в CRM имя и телефон. Менеджер открывает карточку и начинает звонок с вопросов: какую услугу смотрел посетитель, откуда пришёл, что уже выбирал. Всё это человек только что указывал на сайте — но до CRM эти данные не доехали. Переписка и уточнения съедают и время менеджера, и лояльность клиента на первом касании.
Это не техническая мелочь, а потеря контекста первого контакта. Рабочая интеграция начинается не с webhook, а с карты данных.
Карта данных между формой и CRM
Интеграцию проектируют от работы менеджера, а не от списка технических полей. Для каждой формы описывают, что именно увидит сотрудник: контакт, запрос, выбранную услугу, страницу отправки, рекламный источник, комментарий и служебные признаки. Рядом фиксируют формат значения, обязательность, место в карточке и правило, по которому поле может измениться.
Обычно в карту входят:
- контактные данные — имя, телефон, e-mail;
- выбранная услуга или товар;
- страница отправки формы;
- кампания и UTM-метки;
- комментарий посетителя;
- согласие на обработку персональных данных;
- вложение, ответственный, статус доставки.
Не всё нужно показывать посетителю: технические данные страницы и источника можно передавать скрыто, если их сбор согласован с правилами сайта. Состав полей утверждают продажи, маркетинг и ответственный за обработку данных — не разработчик в одиночку.
Маршрут заявки после отправки
Запись в CRM сама по себе обработку не гарантирует. Отдельно определяют сущность, в которую попадёт обращение, ответственного, очередь на случай его отсутствия, уведомление и действие при ошибке обмена.
В Битрикс24 заявка может стать лидом, сделкой, контактом или записью в другой согласованной сущности. Выбор зависит от воронки и правил квалификации, а не от формы сайта. Его фиксируют до запуска, чтобы одна и та же заявка не появлялась в разных воронках дважды.
Отдельная тема — дедупликация. Правило совпадения (по телефону, e-mail или компании) и действие при дубле — объединение, уведомление менеджера или новая запись с пометкой — согласуют заранее, а не тогда, когда база уже засорена повторами.
Проверка по тестовым обращениям
Тестируют не одну «идеальную» заявку, а несколько вариантов: с обязательными полями, без необязательного комментария, с разными метками источника и повторным номером телефона. Полезно добавить сценарии с вложением, повторной отправкой и отключённым внешним сервисом.
После отправки сверяют:
- появилась ли запись в CRM и все ли значения на месте;
- кто назначен ответственным, сработала ли очередь;
- пришло ли уведомление;
- попала ли ошибка обмена в журнал и к кому.
Ошибка интеграции не должна молча оставлять посетителя без результата. Права доступа к полям и журнал обмена определяют заранее: сотрудник видит только нужные данные, техподдержка может диагностировать обмен без доступа к лишней информации.
Кто отвечает за запуск
Для каждой формы нужен владелец маршрута — человек, который подтверждает, что карточка содержит данные, с которыми менеджер может сразу начать работу. После запуска маркетинг и продажи выборочно сверяют источник обращения, содержимое карточки и результат обработки.
Основание обработки, текст согласия, сроки хранения и состав персональных данных подтверждает ответственный за данные или юрист. Настройка CRM эту проверку не заменяет.
Итог
Рабочая интеграция описывает путь заявки от формы до ответственного сотрудника и даёт проверить каждое поле. Начинать стоит с карты данных и тестовых обращений, а не с настройки webhook или робота — иначе в CRM будет аккуратно складываться пустое имя с телефоном, а менеджер снова будет переспрашивать то, что сайт уже знал.
Top comments (0)