Интеграция сайта с CRM должна передавать не только контакт покупателя, но и смысл обращения: что он выбрал, в какой комплектации и откуда пришёл. Для этого нужно заранее связать поля формы с полями карточки, определить правила повторной отправки и проверить конечную запись глазами менеджера.
Иначе легко получить такую ситуацию: на сайте человек выбирал диван, размер и ткань, а сотрудник получил «Прошу перезвонить». Разговор начинается с повторного сбора того, что покупатель уже указал. Я бы начинал подключение с образца полезной карточки, а не с кнопки «Связать CRM».
Решите, что именно появится в CRM
Контакт в Битрикс24 описывает человека; компанию при необходимости оформляют отдельно. Обращение описывает конкретный интерес: расчёт дивана, вопрос о доставке, заказ другого товара. У одного клиента может быть несколько обращений, и каждое важно сохранить со своими условиями.
В разных CRM такой интерес оформляют лидом, сделкой или другим типом карточки. Выберите вариант под свою воронку и назначьте ответственного. Форма «Задать вопрос» не обязана создавать оплаченный заказ или сразу переводить сделку на стадию продажи.
Сначала покажите будущую карточку менеджеру. Ему должно быть понятно, кому ответить, о каком товаре речь, что уже выбрано и что ещё нужно уточнить. Если для ответа приходится заново искать товар по всему каталогу, список передаваемых данных стоит пересмотреть.
В мебельных проектах мы дорабатывали корзины и письма о заказе, чтобы передавать состав и параметры понятнее. Это полезная основа для постановки задачи. Само по себе такое письмо не подтверждает, что подключение к CRM уже работает.
Составьте карту полей до настройки обмена
Карта полей — простая договорённость: откуда берём значение, куда записываем и что делаем, если его нет. Для первого обсуждения можно собрать такую таблицу.
| Данные на сайте | Что должно быть в карточке | Что проверить |
|---|---|---|
| Имя и способ связи | Контакт, связанный с обращением | Значения не потерялись, неоднозначное совпадение не склеило разных людей |
| Артикул, название и адрес товара | Выбранная модель и ссылка на неё | Можно понять, о чём спрашивал покупатель |
| Размер, ткань и количество | Состав выбора на момент отправки | Сохранились точные варианты, а не только название товара |
| Цена и валюта, если они определены | Подтверждённая сумма или отметка «Нужно уточнить» | Неизвестная цена не превратилась в ноль |
| Страница и полученные UTM-метки | Контекст конкретного обращения | Отсутствующий источник остался неизвестным |
| Идентификатор отправки | Связь карточки с исходной заявкой | Повтор доставки можно отличить от нового обращения |
Не стоит складывать всё в один длинный комментарий, если по этим сведениям потом нужно искать заявки или строить отчёт. Выделите поля для важных параметров. При этом описание нестандартного пожелания лучше сохранить и в исходном виде: краткая сводка может потерять деталь.
Точные названия и типы полей зависят от CRM и её настройки. В Битрикс24, например, предусмотрены поля UTM-меток и идентификатора записи во внешнем источнике. Наличие такого идентификатора ещё не означает, что система сама защитит вашу интеграцию от повторных записей.
Сохраните комплектацию на момент обращения
Представим учебный товар: диван шириной 1800 мм, ткань «Рогожка Demo17», одна штука. Покупатель отправил запрос на расчёт. В карточке нужен именно этот набор, даже если позднее на сайте поменяются ткань по умолчанию, название или ассортимент.
Одной ссылки на товар для этого мало. Ссылка помогает открыть страницу, а отдельный снимок выбранных параметров сохраняет условия обращения. Если у вариантов есть собственные артикулы, используйте их вместе с понятными названиями.
Цена из браузера тоже не должна становиться безусловным основанием для суммы сделки. Перед записью её нужно сверить с доверенным источником — например, серверным каталогом или системой учёта. Для товара с ценой по запросу оставьте явную отметку о необходимости расчёта. Ноль рублей выглядел бы совсем другим предложением.
Источник рекламы храните рядом с конкретным обращением. Если прежний клиент вернулся позже с другой задачей, нельзя автоматически приписывать новый интерес старой кампании. Сохранение меток между страницами и выбор модели атрибуции требуют отдельной настройки сайта; само поле в CRM эту работу не выполняет.
Разделите клиента, новое обращение и технический повтор
Одинаковый адрес почты ещё не делает две заявки одной и той же. Клиент мог вчера выбирать диван, а сегодня спрашивать о другом размере. Если новый интерес молча перезаписал прежний, история выбора потерялась.
Правила повтора проверили на локальной учебной модели. В ней один вымышленный покупатель отправляет два разных обращения. Совпадающий адрес почты связывает их с одним учебным контактом, а у каждого нового обращения свой идентификатор отправки. Технический повтор сохраняет прежний идентификатор. Это условие примера, а не совет автоматически объединять реальных людей по одному полю.
Первая отправка создала контакт и обращение с шириной 1800 мм. Её точный повтор вернул прежнее обращение. Следующая отправка с новым идентификатором и шириной 1600 мм создала второе обращение у того же контакта. У второго обращения не было UTM-меток — источник так и остался незаполненным.
Ещё два примера проверяли ошибки. Изменённая ткань под прежним идентификатором дала конфликт, не переписав первую запись. Отправка без артикула попала в список для разбора и не создала новое обращение. Итого после пяти последовательных отправок — один контакт, два обращения и одна отложенная запись. В обоих обращениях неизвестная цена осталась неизвестной.
Это локальная проверка структуры и правил, а не тест подключения к Битрикс24 или другой рабочей CRM. Записи хранились в памяти. Сеть, права реального портала, параллельная обработка, перезапуск и потеря ответа внешнего сервиса здесь не проверялись. Клиентам ничего не отправлялось.
В рабочем проекте отдельно согласуйте поиск существующего контакта и разбор неоднозначных совпадений. Общая семейная почта или телефон организации могут относиться к разным людям. Встроенный контроль дубликатов CRM имеет собственные условия и не заменяет правила доставки заявок.
Проверьте способ подключения и условия доступа
Перед разработкой выясните, что уже умеет сайт и выбранная CRM: встроенная форма, готовый модуль или собственный обмен через API. Сравнивайте их по нужным полям и проверкам. Установка модуля ещё не подтверждает, что размеры, ткань и источник попали куда надо.
Для предметной проверки условий я взял документацию облачного Битрикс24 в зоне ru. На 29 октября 2026 года для локальных вебхуков и приложений нужна соответствующая подписка Маркетплейса. У встроенных инструментов и коробочной версии условия могут отличаться. Доступность нужной функции проверяют на своём портале; цену и подходящий тариф эта статья не определяет.
Рабочий портал для учебного примера не подключался, платный тариф не активировался. Это позволяет разобрать модель данных без чужих контактов, но не подтверждает совместимость с конкретной настройкой CRM. После выбора способа обмена нужна отдельная тестовая запись уже в ней.
Секрет доступа храните на серверной стороне, а не в открытом коде страницы. Выдавайте интеграции права под согласованные действия. До тестовой записи проверьте роботов, уведомления и рассылки: создание карточки в Битрикс24 может запустить настроенные автоматические действия. Для проверки используйте отдельные учебные данные и исключите отправку сообщений реальным людям.
Принимайте работу по конечной карточке
Попросите показать весь путь одной тестовой отправки: форма на телефоне, сохранённое обращение, ответ обработчика и карточка в CRM. Сверьте контакт, товар, варианты, источник и ответственного. Успешный ответ сайта сам по себе не доказывает, что менеджер получил все сведения.
Затем повторите отправку и создайте новое обращение того же учебного клиента. Убедитесь, что первое действие не размножило карточки, а второе не затёрло старую. Проверьте неполные поля и отсутствие меток. Условия удобно заранее записать в ТЗ на автоматизацию.
Для рабочего обмена нужен и разбор сбоев. Если CRM недоступна, заявка должна оставаться в контролируемой очереди, а ответственный — видеть ошибку. Если неизвестно, прошла ли запись, сначала проверьте её фактическое наличие по связи с исходной отправкой. Слепой повтор способен создать лишнюю карточку. Нагрузку, восстановление после перезапуска и одновременные запросы проверяют отдельно на выбранной реализации.
Назначьте человека, который следит за такими ошибками после запуска. Уведомление в мессенджер может помочь заметить обращение; этот участок разобран в статье о заявках с сайта в Telegram. Оно дополняет проверку CRM, но не заменяет её.
Если хотите связать сайт с обработкой обращений, можно обсудить задачу. Для начала пригодятся пример формы, образец нужной карточки и перечень параметров, которые сейчас теряются.