Заявки с сайта не попадают в CRM: что проверить по шагам

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

Разбираем по шагам, на каком переходе теряется заявка и как это проверить. Порядок важен: диагностика начинается не с портала, а с сайта.

Четыре перехода между формой и карточкой

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

1. Браузер отправил данные на сервер сайта.
2. Сайт отправил запрос в портал.
3. Портал принял запрос и создал лид.
4. Лид виден там, где его ищут.

Шаг 1. Ушли ли данные с сайта

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

Откройте страницу с формой, включите в браузере инструменты разработчика и заполните её. На вкладке «Сеть» должен появиться запрос к обработчику. Смотрите на код ответа: 200 — хорошо, 500 — ошибка на сервере, 403 — запрос отклонён, ничего — скрипт упал ещё до отправки.

Если запроса нет, проверьте вкладку «Консоль»: обычно там будет ошибка JavaScript. Такое случается после правок вёрстки или обновления шаблона.

Шаг 2. Сайт отправил запрос в портал

Данные дошли до сервера, но дальше не уехали. Причины делятся на две группы: не удалось соединиться или соединение оборвалось.

Что проверять:

• Отвечает ли адрес портала с сервера сайта. Не из браузера, а именно с сервера — это разные сети и разные правила.
• Не переопределён ли адрес портала в /etc/hosts. Случай из практики: сервер был развёрнут автоматизированно, и в hosts осталась запись, отправлявшая домен портала на локальный адрес. С браузера всё работало, с сервера — нет.
• Не истёк ли сертификат и не отключена ли его проверка в коде. Отключать нельзя, а вот обновить цепочку на сервере иногда нужно.
• Таймауты. Если портал отвечает долго, а таймаут в коде короткий, запрос оборвётся на полпути — и лид всё-таки создастся, просто сайт об этом не узнает. Так появляются дубли при повторной отправке.

На сайтах 1С-Битрикс запрос к порталу стоит отправлять через Bitrix\Main\Web\HttpClient, а не через прямой вызов curl: клиент ядра учитывает настройки прокси, таймауты и сертификаты, принятые на сайте.

Шаг 3. Портал принял запрос

Запрос ушёл, но портал его отклонил. Ответ REST при этом содержит причину — и он почти всегда теряется, если его никуда не записывать.

Что обычно приходит в ответе:

• INVALID_CREDENTIALS или NO_AUTH_FOUND — вебхук удалён, пересоздан или скопирован не полностью.
• INSUFFICIENT_SCOPE — у вебхука нет права crm.
• ERROR_METHOD_NOT_FOUND — опечатка в имени метода или метод недоступен на тарифе.
• QUERY_LIMIT_EXCEEDED — превышен лимит обращений. Бывает при всплеске трафика или когда интеграция зациклилась.

Проверить вебхук можно с сервера сайта одним запросом:

curl -s "https://ваш-портал.bitrix24.ru/rest/1/КЛЮЧ/profile/"

Если в ответе пришли данные пользователя — вебхук жив. Если ошибка, её текст и будет причиной.

Проверьте заодно, какими методами пользуется интеграция. Старые методы вроде crm.lead.add из первой версии REST помечены как устаревшие: развитие остановлено, вендор рекомендует перейти на методы REST 3.0. Работать они пока работают, но закладываться на это не стоит.

Шаг 4. Лид создан, но его не видят

Самый обидный вариант: всё сработало, лид в портале есть, а менеджер его не находит.

• Фильтр в списке. Сохранённый фильтр по ответственному или источнику прячет новые заявки. Сбросьте фильтр целиком и посмотрите снова.
• Ответственный. Если в интеграции не указан ASSIGNED_BY_ID, лид достаётся тому, от чьего имени создан вебхук. Часто это администратор, который в CRM не заходит.
• Права доступа. Менеджер видит только свои элементы, а лид назначен другому.
• Склейка дублей. Если включён контроль дублей, повторная заявка с тем же телефоном может прилипнуть к существующему элементу вместо создания нового. Найти связанные элементы по телефону и почте можно методом crm.duplicate.findbycomm.
• Роботы и бизнес-процессы. Робот на стадии мог перевести лид дальше по воронке, сконвертировать в сделку или закрыть как некачественный. Смотрите историю элемента: там видно, кто и когда его трогал.

Что настроить, чтобы заявки не терялись

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

Свой журнал на стороне сайта. Пишите каждую отправку: что ушло, что ответил портал, сколько заняло. Этот журнал закрывает 90% разбирательств — сразу видно, дошло до портала или нет.

Запасной канал. Если портал не ответил, данные заявки должны уйти хотя бы в файл и на почту. Клиент не должен зависеть от доступности портала в момент отправки.

Уведомление о сбое. Молчаливый сбой — худший вид сбоя. Пусть при первой же неудачной отправке приходит сообщение ответственному.

Проверка после каждого обновления. Правки шаблона, смена версии PHP, переезд на другой сервер — три самых частых повода для того, чтобы форма перестала работать. Тестовая заявка занимает минуту.

Если заявки доходят, но без источника

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

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