Интеграция CRM и сайта: что проверить до старта - полный чек-лист

Интеграцию «сделали», а заявки всё равно теряются

Подрядчик отчитался: сайт связан с CRM, вебхук отвечает 200 OK. Через пару недель выясняется другое. Часть заявок приходит без телефона. UTM-метки пустые. Статусы на сайте и в CRM живут разными жизнями. Менеджер узнаёт о лиде из чата, а не из карточки. Передача данных вроде есть - пользы нет.

Интеграция CRM и сайта - это мост между двумя городами: если не проверить дорогу, груз не доедет. API, JSON и автоматическое создание сделок работают только тогда, когда заранее ясны поля, статусы, правила дедупликации и журнал ошибок. Иначе синхронизация CRM и сайта превращается в дорогой способ ускорить хаос.

Ниже - полный чек-лист того, что проверить до старта: зоны внимания, таблица полей, сценарий статусов, типичные ошибки и вопросы для самопроверки. Если параллельно «плывут» процессы в отделе продаж, загляните в материал про автоматизацию процессов.

Хотите быстро понять, готов ли ваш сайт к связке с CRM? Напишите нам, разберём путь заявки за 20-30 минут. Или запросите консультацию по карте данных.

Что проверить до интеграции

Не начинайте с настройки интеграции «как получится». Пройдите зоны внимания ниже, это и есть фундамент рабочей передачи заявок с сайта в CRM.

Поля для передачи

На что обратить внимание. Какие данные реально нужны менеджеру в момент первого контакта, а какие - маркетингу и аналитике. Базовый набор: телефон, email, имя, источник, UTM-метки, текст комментария, согласие на обработку. Плюс служебные: дата/время, URL страницы, ID заявки на сайте.

Пример проблемы. В CRM создалась сделка с именем, а телефон и источник пустые. Менеджер не может перезвонить, маркетинг не понимает канал - лид потерян, бюджет на рекламу сгорел впустую.

Как проверить. Составьте таблицу «поле формы → поле CRM → обязательно / нет». Пройдитесь по каждой форме на сайте (обратный звонок, расчёт, квиз) и убедитесь, что карта совпадает. Без карты полей API-обмен будет угадыванием.

Статусы и сценарии обмена

На что обратить внимание. Не только «заявка ушла в CRM», но и что возвращается обратно. Если есть личный кабинет, заказ или запись - клиент должен видеть актуальный этап. Рабочая цепочка: «Новая» → «В работе» → «КП отправлено» → «Счёт выставлен» → «Оплачен» → «Выполнен».

Пример проблемы. Менеджер уже выставил счёт, а на сайте у клиента статус «Новая». Начинаются звонки «а что с моим заказом?» - поддержка превращается в диспетчерскую.

Как проверить. Опишите сценарии на бумаге: новая заявка, повторный клиент, смена статуса, ошибка передачи. Для каждого - направление (сайт → CRM / CRM → сайт), кто меняет статус, какой SLA на первый ответ. Пока сценарии не зафиксированы, синхронизация останется односторонней «для галочки».

Дубли и дедупликация

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

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

Как проверить. Зафиксируйте ключ поиска дубля: нормализованный телефон и/или email. Регламент: при совпадении - обновить карточку и создать активность/сделку по правилу, а не плодить контакты. Это часть настройки интеграции, а не «потом руками почистим».

Ошибки и журналы

На что обратить внимание. Вебхук может упасть: таймаут CRM, 500 от API, невалидный JSON. Сайт покажет клиенту «спасибо», а в CRM тишина. Без журнала ошибок вы узнаете об этом от разгневанного клиента.

Пример проблемы. За выходные «молча» не ушло несколько заявок. Обнаружили в среду - лиды остыли, рекламный бюджет уже потрачен.

Как проверить. До запуска потребуйте: журнал ошибок (время, код ответа, тело запроса, ID заявки), автоматический retry, алерт ответственному. Назначьте владельца обмена: кто смотрит журнал и чинит сбой. Хорошая разработка интеграций не скрывает падения - она делает их видимыми.

Качество данных

На что обратить внимание. Форматы и валидация. Телефон в одном формате (+7…), email с проверкой, имя без пробелов-заглушек, источник не перезаписывается случайно при каждом визите.

Пример проблемы. Заявка пришла с телефоном из пяти цифр → менеджер не может перезвонить → лид потерян. При потоке в десятки заявок в день даже небольшой процент брака быстро бьёт по выручке.

Как проверить. Прогоните тестовые отправки: пустые обязательные поля, кривой телефон, email без «@», повторная отправка той же формы. Пустые обязательные - не создаём сделку, пишем в журнал. Качество данных важнее «количества полей на всякий случай».

Согласия пользователя (GDPR, 152-ФЗ)

На что обратить внимание. Согласие на обработку персональных данных должно уходить в CRM вместе с заявкой: факт согласия, дата/время, версия текста (или ссылка на политику). Для рассылок - отдельное согласие, если оно собирается.

Пример проблемы. Заявки есть, а в карточке нет отметки о согласии. Юрист или проверка рекламной площадки задают вопросы - и выясняется, что «галочка была на сайте», но в CRM её следа нет.

Как проверить. Поле согласия - обязательное в карте передачи данных. Чекбокс без предзаполнения, ссылка на политику, сохранение факта в CRM. Это не «юридическая формальность в конце», а часть интеграции сайта и CRM с первого дня.

Таблица полей: обязательные vs опциональные

Вопрос «как связать сайт с CRM» почти всегда упирается в одно: что именно едет в JSON. Ниже - рабочая база для передачи данных и сквозной аналитики.

Правило: лучше осмысленный набор полей с валидацией, чем десятки пустых колонок «на вырост». Пустые поля в CRM - это шум, а не данные.

Как работают статусы: пример сценария

Технический специалист думает эндпоинтами. Владелец бизнеса - сценариями. Разберём рабочий контур синхронизации на примере одной заявки.

Новая заявка с сайта

1. Клиент отправляет форму → сайт валидирует телефон, email, согласие.
2. Уходит вебхук / API-запрос (JSON) в CRM.
3. CRM создаёт контакт и сделку, проставляет источник и UTM - автоматическое создание сделок без ручного копирования.
4. Назначается ответственный, создаётся задача, уходит уведомление. SLA первого ответа - например, 15 минут.
5. На сайт (или в письмо) возвращается подтверждение: статус «Новая».

Движение по воронке и обратная синхронизация

Дальше менеджер ведёт сделку. Каждый переход статуса должен быть понятен и системе, и клиенту:

• Новая - заявка принята, ждёт первого контакта.
• В работе - менеджер на связи, идёт квалификация.
• КП отправлено - коммерческое предложение у клиента.
• Счёт выставлен - ожидание оплаты.
• Оплачен - деньги получены, старт исполнения.
• Выполнен - услуга/заказ закрыты.

При смене статуса CRM шлёт вебхук на сайт (или сайт читает API). В личном кабинете обновляется этап, клиенту уходит уведомление. Без обратного потока интеграция решает задачу отдела продаж, но ломает сервис.

Повторный клиент

Система ищет контакт по телефону/email (дедупликация), обновляет карточку, создаёт новую сделку или активность - по регламенту. История прошлых статусов и счетов остаётся. Повторный клиент - не «новый лид с нуля».

Типичные ошибки при интеграции

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

Сначала «подключим», поля потом

Запускают API-обмен «как есть», а карту данных дописывают после жалоб менеджеров. Итог: пустые источники, кривые телефоны, ручное дозаполнение. Сначала поля и валидация - потом вебхук.

Односторонняя связка «ради галочки»

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

Нет владельца ошибок

Когда обмен падает, все смотрят друг на друга: «это сайт», «это CRM», «это хостинг». Назначьте ответственного за журнал ошибок и регламент реакции. Иначе сбой за выходные превращается в «куда делись лиды?».

Игнорируют сквозную аналитику

Передают только имя и телефон. Маркетинг не видит, какая кампания приносит оплату. Интеграция без UTM и источника - ускоренный хаос, а не рост.

Кейс из практики: как сервисная компания перестала терять заявки

Кейс вымышленный, но собран из типичных ситуаций клиентов Rogitel, цифры и логика реалистичны для B2B-услуг.

Компания. Региональный поставщик B2B-услуг, сайт на CMS, CRM «из коробки», формы «Обратный звонок» и «Заявка на расчёт», реклама в Директе и SEO.

Боль. «Интеграцию делали год назад». На деле часть заявок уходила на email, UTM не сохранялись, при повторной заявке создавался новый контакт. За неделю находили «потеряшки» - ощутимая доля входящего потока. Статусы клиент узнавал только по телефону.

Что сделали.

1. Собрали карту полей: телефон, email, имя, источник, UTM-метки, комментарий, согласие, URL страницы.
2. Включили валидацию и нормализацию телефона; пустые обязательные поля блокируют отправку «мёртвых» лидов.
3. Настроили дедупликацию по телефону и автоматическое создание задач с понятным SLA.
4. Вернули статусы из CRM на сайт: «Новая» → «В работе» → «КП отправлено» → «Счёт выставлен» → «Оплачен» → «Выполнен».
5. Подключили журнал ошибок, retry и алерт ответственному.

Результат. Доля потерянных заявок резко упала, время до первого контакта стало измеряемым, маркетинг впервые увидел оплату в разрезе кампаний, звонков «какой статус?» стало заметно меньше.

Если у вас похожая картина, посмотрите направление разработка интеграций ; если нужен сайт или кабинет в одном контуре - разработка сайтов и web-разработка; если параллельно нужен порядок в процессах - раздел автоматизация процессов и статья про признаки, что пора автоматизировать.

Краткий чек-лист перед стартом

• Есть таблица полей: сайт → CRM (обязательные отмечены).
• Описаны валидация телефона/email и согласие на обработку ПДн.
• Зафиксированы статусы и направление синхронизации (туда / обратно).
• Прописаны правила дедупликации по телефону/email.
• Есть журнал ошибок, retry и владелец обмена.
• UTM и источник сохраняются для сквозной аналитики.
• Описаны сценарии: новая заявка, повторный клиент, смена статуса.

Чек-лист для самопроверки

Ответьте «Да» или «Нет». Каждое «Нет» - риск потерять заявку или испортить аналитику.

1. Все заявки с сайта попадают в CRM автоматически, без копирования из почты?
2. В карточке всегда есть телефон в едином формате и понятный источник?
3. UTM-метки сохраняются и доживают до сделки/оплаты?
4. При повторной заявке не создаётся дубль контакта?
5. У новой сделки сразу есть ответственный и задача?
6. Статусы из CRM возвращаются на сайт или клиенту в уведомлениях?
7. Есть журнал ошибок обмена, и кто-то на него смотрит?
8. Согласие на обработку ПДн сохраняется в CRM вместе с заявкой?
9. Понятен SLA первого ответа и он реально соблюдается?
10. Вы можете за 5 минут ответить, какой канал принёс оплату за прошлый месяц?

Если набрали несколько «Нет» - интеграция ещё не «готова», даже если эндпоинт отвечает 200 OK. Имеет смысл пройти карту данных до новых доработок.

Часто задаваемые вопросы (FAQ)

Сколько времени занимает настройка интеграции сайта и CRM?

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

Что лучше: готовый модуль, вебхук или свой API-обмен?

Готовый коннектор ускоряет старт, если хватает полей «из коробки». Вебхук удобен для событий «заявка создана / статус изменён». Свой API-обмен нужен, когда логика сложнее: несколько форм, разные воронки, кастомная дедупликация. Выбор - от сценария, а не от моды.

Нужно ли менять CRM, чтобы связать её с сайтом?

Чаще нет. Если у CRM есть API и нормальные поля воронки, достаточно донастроить карту данных и регламент. Менять систему имеет смысл, когда она принципиально не тянет статусы, роли или лимиты обмена.

Как понять, что интеграция реально работает?

Сверьте за тестовую неделю: число отправленных форм ≈ числу сделок в CRM (минус известные отказы валидации). Проверьте дубли, заполненность UTM, скорость создания задачи и обратные статусы. Если цифры сходятся - мост держит нагрузку.

Заключение: сначала правила, потом код

Интеграция CRM и сайта окупается не красивым JSON, а тем, что заявка не теряется, менеджер звонит вовремя, статус понятен клиенту, а маркетинг видит деньги, а не только клики. Мост между «двумя городами» строят с чертежа: поля, валидация, дедупликация, статусы, журнал ошибок, согласия, SLA.

Пройдите зоны внимания до разработки. Опишите сценарии. Назначьте владельца обмена. И только потом подключайте API. Так вы сэкономите недели переделок и десятки остывших лидов.

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