Форма на сайте отправлена, клиент ждёт звонка — а звонка нет. Через день выясняется, что заявка ушла в почту менеджера, затерялась в спаме или вообще не дошла до CRM: скрипт отдал ошибку, и никто этого не заметил. Такие истории повторяются из проекта в проект, и почти всегда проблема не в самой CRM, а в стыке между сайтом и системой.
Разберём, как построить интеграцию, которая не теряет заявки — от выбора способа связи до мониторинга после запуска.
Почему заявки теряются на стыке
Типичные причины потерь почти всегда одинаковые:
- сайт отправляет данные, но внешний сервис отвечает ошибкой или таймаутом, а обработки сбоя нет;
- заявка уходит на почту менеджеру, а не в CRM — и тонет в ящике;
- антиспам-капча или фильтр отсекает живых клиентов вместе с ботами;
- менеджер не видит новую сделку: не настроены уведомления или ответственный;
- дубли и «мусорные» карточки размывают воронку, и реальные обращения теряются среди них.
Большинство этих сбоев не видно в интерфейсе: форма показывает «Спасибо», клиент доволен, а заявки нет. Именно поэтому интеграцию нужно проектировать с расчётом на то, что внешний сервис когда-нибудь не ответит.
Три способа связать сайт и CRM
1. Готовый модуль или плагин
У популярных CRM (Битрикс24, amoCRM, RetailCRM и других) есть официальные модули для CMS: WordPress, «1С-Битрикс», Tilda, Webflow. Плюс — быстрый запуск и поддержка со стороны вендора. Минус — ограниченный набор полей и логики: если нужны нестандартные сценарии, придётся дописывать.
2. Прямая интеграция через API
Разработчик связывает бэкенд сайта с REST API CRM: создаёт сделку, контакт, при необходимости — компанию и задачу. Это самый гибкий вариант: можно передавать любые поля, UTM-метки, результаты квиза, файлы. Требует больше работы и грамотной обработки ошибок.
3. Прослойка-интегратор
Между сайтом и CRM ставится промежуточный сервис (Make, n8n, Zapier или собственный микросервис). Он принимает вебхук, валидирует данные, при необходимости обогащает и передаёт в CRM. Такой слой удобен, когда CRM несколько, или когда нужно сначала прогнать заявку через проверку дублей и распределение.
Практическое правило: для типового сайта услуг хватает модуля или прямой интеграции; прослойка нужна там, где есть сложная маршрутизация, несколько филиалов или связка с другими системами.
Что подготовить до интеграции
- Модель данных. Заранее решите, какие поля обязательны: имя, телефон, источник, комментарий, страница обращения.
- UTM-метки и источник. Передавайте их скрытыми полями — иначе аналитика по каналам не сойдётся.
- Согласие на обработку данных. Чекбокс и ссылка на политику — требование закона, а не формальность.
- Антиспам. Настраивайте его так, чтобы он не резал людей: honeypot и ограничение по времени надёжнее, чем агрессивные капчи.
Технические детали, которые решают судьбу заявки
Защита от дублей
Клиент может отправить форму дважды из-за медленной сети или двойного клика. Используйте идемпотентность: уникальный ключ заявки, по которому повторный запрос не создаёт новую сделку.
Очередь и повторные попытки
Если CRM недоступна, запрос не должен просто исчезать. Ставьте его в очередь и повторяйте попытки с нарастающей паузой. Так заявка переживёт кратковременный сбой на стороне CRM.
Логирование
Каждое обращение должно оставлять след: время, данные, ответ API, статус. Без логов вы никогда не узнаете, сколько заявок потеряли месяц назад.
Резервный канал
Хорошая практика — дублировать заявку в почту или Telegram-чат. Если интеграция упадёт, у команды останется шанс увидеть клиента вовремя.
Как проверить интеграцию перед запуском
- Отправьте тестовую заявку и убедитесь, что сделка появилась в CRM с правильными полями.
- Проверьте сценарий с ошибкой: временно отключите доступ к API и посмотрите, сработает ли очередь и резервный канал.
- Отправьте форму дважды подряд — дубля быть не должно.
- Проверьте, что UTM-метки, страница обращения и источник записались корректно.
- Убедитесь, что менеджер получил уведомление и видит задачу в мобильном приложении.
Мониторинг после запуска
Интеграция — не задача «сделал и забыл». Настройте оповещения об ошибках API, ведите счётчик успешных и неуспешных отправок, сверяйте количество заявок на сайте и в CRM раз в неделю. Полезно смотреть на конверсию по каналам: если трафик растёт, а сделок больше не становится, проблема почти наверняка на стыке.
Что настроить в самой CRM
- источники и каналы, чтобы видеть, откуда пришёл клиент;
- воронку с этапами и автоматическим распределением ответственных;
- автозадачи на первый контакт и напоминания, если менеджер молчит;
- правила для дублей и объединения карточек;
- отчёт по скорости реакции — она напрямую влияет на конверсию в сделку.
Частые ошибки
- считать, что «форма работает, раз приходит письмо»;
- не обрабатывать ошибки API и не логировать их;
- передавать минимум данных без источника и страницы обращения;
- запускать интеграцию без тестов на сбои;
- не назначать ответственного за мониторинг.
Коротко о главном
Надёжная интеграция строится на трёх вещах: понятной модели данных, обработке сбоев с повторами и резервным каналом, а также постоянном мониторинге. Сама по себе CRM заявки не спасает — спасает инженерный подход к стыку между сайтом и системой. Если интеграцию спроектировать с расчётом на ошибки, потерь заявок можно избежать почти полностью.

Спасибо за разбор способов интеграции, особенно за мысль про обработку таймаута. Подскажите, если сайт на Tilda и amoCRM, лучше сразу ставить модуль или всё-таки делать прямую интеграцию через API, чтобы не потерять UTM? Боюсь, что модуль может не передать часть полей.
Для Tilda и amoCRM я бы сначала проверил официальный модуль: если хватает полей и UTM передаются, не усложнял бы. Но если есть квиз, файлы или нестандартная логика, прямая интеграция через API надёжнее, при условии журнала ошибок и повторной отправки.
У нас была обратная ситуация: поставили прослойку на n8n, чтобы распределять заявки по филиалам, и сначала потеряли несколько обращений из-за дублей. Помогло то, что добавили валидацию телефона и проверку по существующим контактам перед созданием сделки. В статье верно сказано, что прослойка нужна не всегда, но при сложной маршрутизации без неё тяжело.
Не совсем согласна, что типовому сайту услуг всегда хватает модуля или прямой интеграции. Я работала с проектом, где прямая интеграция без очереди теряла заявки при пиковой нагрузке, и буфер с мониторингом решил проблему. По чек-листу подготовки данных статья полезная.