Почему заявки с сайта не появляются в Битрикс24: пошаговая проверка

01

Сначала зафиксируйте, на каком участке исчезают заявки с сайта

Проблему нельзя корректно описать фразой «форма не работает». Заявка проходит несколько независимых участков: посетитель заполняет поля, браузер отправляет запрос, сайт проверяет данные и запускает обработчик, затем выполняется запрос в Битрикс24. CRM создаёт лид, сделку или контакт либо возвращает ошибку. Сообщение об успехе может появиться ещё до ответа CRM — например, когда фронтенд считает успешной только отправку AJAX-запроса на сайт.

Для проверки создайте контрольную заявку. Используйте номер телефона, которого нет в CRM, например +79990001234, и добавьте в комментарий метку «TEST-2025-03-08-1430». Запишите URL страницы, время с точностью до минуты, браузер, UTM-параметры и выбранные значения формы. По этой метке удобно искать запись в журнале сайта, ленте CRM и системных логах.

Дальше двигайтесь только по фактам. Если браузер не отправил запрос, Битрикс24 проверять рано. Если сайт получил запрос, но не вызвал API, причина в обработчике. Если API вернул ID, а менеджер не видит обращение, нужно искать сущность в правильной воронке, учитывать права и сценарий обработки дублей. Такой маршрут сокращает диагностику с нескольких дней переписки до последовательности из пяти проверок.

03

Проверьте форму в браузере, а не только её внешний вид

Откройте страницу в режиме инкогнито, заполните контрольные данные и в инструментах разработчика перейдите на вкладку Network. После нажатия кнопки должен появиться запрос к обработчику формы: обычно это URL вида /ajax/form.php, /local/ajax/feedback.php или адрес стороннего сервиса. Проверьте метод POST, код ответа и фактически переданные поля. Обязательное поле может иметь другое имя, маска телефона способна очищать значение, а JavaScript — отменить submit при ошибке в консоли.

Код 200 ещё не означает успех. Откройте Response: там должна быть понятная структура, например success:true и crm_id. Если обработчик возвращает HTML страницы, пустой ответ или success:true без идентификатора, разработчик мог скрыть исключение. Ошибки 403 часто связаны с CSRF-защитой или сессией, 404 — с неверным URL после переноса сайта, 500 — с PHP-ошибкой, отсутствующим модулем или недоступным внешним запросом.

Маркетологу важно проверить, что в запрос попадают источник и страница. Для рекламы это utm_source, utm_medium, utm_campaign, а также URL посадочной страницы и referrer. Не передавайте их только в скрытых полях без проверки: скрипт инициализации может не отработать на мобильной версии или в форме в попапе.

04

Разделите ошибки сайта, API и настроек CRM

После браузера проверьте серверную часть. В типовой интеграции сайт вызывает входящий вебхук или REST API методом crm.lead.add, crm.deal.add либо создаёт контакт и сделку последовательными запросами. Адрес вебхука, токены и секреты не должны быть доступны в JavaScript-коде страницы: их хранят на сервере или в настройках модуля. Если токен попал в публичный код, его нужно отозвать и выпустить новый.

В журнале обработчика должны быть время запроса, техническая метка заявки, HTTP-код, тело ответа без персональных данных и ID сущности при успехе. Логировать полный телефон, e-mail и токен небезопасно. Достаточно маскировать значения и связывать запись с внутренним request_id. Если логов нет, задача разработчику — сначала добавить наблюдаемость, а не «попробовать поменять вебхук».

Уточните, какой метод и сущность заложены в сценарии. Компания может ждать лид, тогда как интеграция создаёт сделку в другой воронке. В CRM с отключёнными лидами это нормальная архитектура, но её нужно зафиксировать в требованиях. Список методов и форматов ответов опубликован в документации REST API Битрикс24.

05

Сверьте поля формы с полями лида или сделки

Даже рабочий API-вызов может не создать запись из-за обязательного поля или передать данные не туда. В форме поле часто называется phone, а CRM ожидает массив многозначного поля PHONE со значением и типом. Пользовательское поле Битрикс24 передают его системным кодом, например UF_CRM_123456789, а не подписью «Город» или «Источник». Коды полей нужно получить из CRM и приложить к задаче, иначе они меняются только через догадки.

Составьте карту соответствий до исправлений: название поля на странице, имя в POST, поле CRM, формат и правило заполнения. Для списка передаётся идентификатор значения, для даты — ожидаемый формат, для согласия — отдельный факт получения согласия, а не текст чекбокса. Если менеджер видит телефон, но не видит комментарий или рекламный источник, это также дефект интеграции, а не «особенность CRM».

Для UTM зафиксируйте модель хранения. Можно записывать метки в стандартные поля источника и кампании, в пользовательские поля или в комментарий. Последний вариант удобен для чтения, но плохо подходит для отчётов. Для аналитики обычно нужны отдельные поля utm_source, utm_medium, utm_campaign, utm_content, utm_term и URL первой страницы.

Поля формы — это контракт между маркетингом, сайтом и CRM. Подпись поля для посетителя не является техническим идентификатором для API.

06

Проверьте правила дублей, воронки и права сотрудников

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

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

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

1. 1

   Найдите по ID. Откройте сущность по ID из ответа API, а не по общему списку.

2. 2

   Проверьте тип. Убедитесь, что создан лид, сделка, контакт или смарт-процесс, предусмотренный сценарием.

3. 3

   Сверьте воронку. Посмотрите направление, стадию, ответственного и права тестового менеджера.

4. 4

   Откройте историю. Проверьте роботов, триггеры и изменения сразу после создания.

5. 5

   Повторите отправку. Зафиксируйте поведение при существующем телефоне и e-mail.

07

Не теряйте источник обращения вместе с заявкой

Заявка без источника технически попадает в CRM, но становится бесполезной для оценки рекламы. Частая ошибка — UTM существуют в адресной строке, но форма открывается позднее в модальном окне, а скрипт не переносит параметры в запрос. Другая ситуация: посетитель перешёл между страницами, и значения не сохранились в cookie или sessionStorage. Проверяйте не только рекламную посадочную страницу, но и страницу, с которой реально отправляют форму.

Определите момент фиксации. Обычно first-touch сохраняет первый рекламный источник визита, а last-touch — последний источник перед отправкой. Если бизнес использует оба подхода, нельзя записывать их в одно поле: значения будут перетирать друг друга. Укажите в требованиях список полей, приоритеты и срок хранения технических данных с учётом политики обработки персональных данных.

При приёмке откройте созданную CRM-запись и сравните UTM с адресной строкой теста. Проверьте кириллицу, пробелы, спецсимволы и длинные campaign: они не должны обрезаться или попадать в неверное поле. Для регулярного контроля достаточно еженедельного теста формы с отдельной тестовой кампанией.

08

Настройте контроль, чтобы ошибка не вернулась после обновления

Единичное исправление не заменяет контроль. Формы ломаются после обновления шаблона, переноса домена, смены CAPTCHA, установки нового модуля, изменения полей CRM или истечения доступа приложения. Владелец процесса должен знать, кто получает сигнал, если интеграция вернула ошибку, и за какое время её исправляют. Иначе падение обнаружат только по снижению продаж через неделю.

Минимальный контроль — ежедневная проверка количества отправок на сайте и количества созданных сущностей в CRM с допустимым расхождением. Более надёжный вариант — сохранять request_id, CRM ID и статус доставки в журнале, а при нескольких ошибках подряд отправлять уведомление в рабочий канал. Не путайте это с веб-аналитикой: цель в Метрике подтверждает событие интерфейса, но не создание сделки.

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

09

Как принять решение по результатам проверки

Если контрольная заявка не дошла до обработчика, исправлять нужно форму, JavaScript или серверный маршрут. Если обработчик получил данные, но Битрикс24 вернул ошибку, зафиксируйте метод API, описание ошибки и права доступа: это уже задача интеграции. Когда CRM вернула ID, не делайте вывод о «потере» до проверки типа сущности, воронки, истории роботов и правил дублей.

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

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