Почему заявка с сайта не приходит в Битрикс24: 12 точек проверки

01

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

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

Не начинайте с замены формы или повторной настройки всего портала. Откройте страницу в режиме инкогнито, заполните форму уникальными данными и запишите точное время до минуты, URL страницы, имя, телефон и e-mail. Используйте адрес вида test+дата@вашдомен.ru или заметное имя «Тест 14:35». Такой маркер поможет сопоставить браузерный запрос, запись в журнале сайта и объект в CRM.

Дальше идите по маршруту данных: посетитель → форма → JavaScript → обработчик 1С-Битрикс → очередь или почта, если она участвует → REST API → лид, сделка, контакт или смарт-процесс Битрикс24 → робот и ответственный. На каждом переходе нужен наблюдаемый признак: HTTP-ответ, запись лога, ID созданной сущности или уведомление. Иначе команда будет обсуждать предположения, а не причину.

Важно заранее договориться, какой результат считается корректным. Для отдела продаж это не просто «что-то создано в Битрикс24», а карточка с телефоном, источником, UTM, страницей формы и назначенным менеджером. Для маркетинга — ещё и возможность связать обращение с рекламной кампанией. Это определение станет основой диагностики и приёмки доработки.

03

Точки 1–4: форма, браузер и обработчик на сайте

Первые четыре проверки проводят в браузере и на сервере сайта. Они отвечают на простой вопрос: данные действительно ушли с формы и дошли до обработчика. Внешне рабочая кнопка и всплывающее «Спасибо» ничего не гарантируют: такое сообщение иногда выводится до ответа сервера либо после любого ответа без разбора содержимого.

Точка 1 — валидность полей. Убедитесь, что телефон, согласие на обработку данных, капча и обязательные поля не блокируют отправку. Точка 2 — событие отправки: в инструментах разработчика на вкладке Network после нажатия должна появиться POST-запрос. Если его нет, проблема в JavaScript, вёрстке, обработчике события или конфликте стороннего скрипта.

Точка 3 — ответ обработчика. Код 403 обычно указывает на проверку сессии, CSRF или WAF, 404 — на неверный URL, 500 — на PHP-ошибку. При HTTP 200 посмотрите тело ответа: успешный статус должен быть подтверждён фактическим результатом, а не только текстом для посетителя. Точка 4 — серверный лог: разработчик должен записывать ID запроса, время и безопасный результат обращения к CRM без паролей и полного содержимого персональных данных.

04

Точки 5–8: доступ к Битрикс24, API и структура данных

Если форма отправляется и серверный обработчик запускается, переходите к соединению с CRM. Точка 5 — актуальность способа авторизации. В интеграциях часто остаётся входящий webhook пользователя, который уволился, потерял права или был деактивирован. Для сценария с серверной интеграцией доступ не должен зависеть от личного аккаунта менеджера без контроля владельца и срока действия.

Точка 6 — URL портала и метод REST. Ошибка в домене портала, в пути webhook или в имени метода приводит к тому, что сайт получает неуспешный ответ, но не всегда показывает его пользователю. Разработчик должен сохранять HTTP-код и поле error_description из ответа Битрикс24. Справочник REST-методов и параметров доступен в документации Битрикс24.

Точка 7 — обязательные поля целевой сущности. В воронке могут быть настроены обязательный источник, категория, пользовательское поле или телефон. Если сайт передаёт поле с неверным кодом либо отправляет пустое значение, API отклонит создание. Точка 8 — соответствие сущности бизнес-процессу: форма может создавать лид, сделку, контакт или элемент смарт-процесса. Ищите результат именно в согласованной сущности и в нужной воронке.

05

Точки 9–12: дубли, роботы, UTM и уведомления

Даже успешно созданная запись может быть незаметна для менеджера. Точка 9 — контроль дублей. Битрикс24 способен найти существующий контакт по телефону или e-mail и не создать новый лид. Это не ошибка, если сценарий согласован: важно понимать, кто получит задачу и где появится новое обращение. Проверьте тестом с уникальным телефоном и отдельно тестом с номером действующего клиента.

Точка 10 — автоматизация после создания. Робот может сменить стадию, назначить другого ответственного, перенести сделку в отдельную воронку или закрыть её при неполных данных. Проверьте историю карточки: она покажет, кто и когда изменил объект. Точка 11 — UTM и технические поля. Метки часто теряются не в CRM, а ещё на посадочной странице: редирект, переход между доменами или повторное открытие формы очищают параметры URL.

Точка 12 — уведомление менеджеру и доступы. Карточка может быть создана корректно, но сотрудник не видит её из-за прав, фильтра списка или отсутствия задачи. Это операционный сбой, который с точки зрения бизнеса равен потерянной заявке. Проверяйте сценарий под учётной записью менеджера, а не только администратора портала.

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

06

Как пройти проверку за один рабочий цикл

Маркетологу не нужно самостоятельно читать PHP-код или разбирать все REST-методы. Его задача — организовать воспроизводимый тест, передать разработчику исходные данные и проверить бизнес-результат. Лучше выполнять проверку на рабочем сайте в период, когда тестовая запись не помешает отделу продаж. Перед тестом предупредите менеджеров, что в CRM появятся служебные обращения.

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

Если у сайта есть staging-копия, сначала подтвердите исправление там, но обязательно сделайте финальный тест на боевом контуре. На тестовом домене webhook, настройки CORS, капча и URL страниц нередко отличаются. Сохраняйте результаты в короткой таблице: форма, время, ID заявки, ответственный, UTM, статус уведомления.

1. 1

   Подготовьте маркер. Возьмите уникальные имя, телефон и e-mail, запишите URL, устройство и точное время отправки.

2. 2

   Проверьте браузер. Убедитесь, что кнопка инициирует POST-запрос, а ответ не содержит ошибки или ложного success.

3. 3

   Сверьте сервер. Передайте разработчику время теста для поиска записи в журнале и PHP error_log.

4. 4

   Найдите объект. Ищите по телефону и e-mail во всех согласованных сущностях, категориях и у ответственных.

5. 5

   Проверьте атрибуцию. Отправьте форму по URL с UTM и сверьте метки, страницу и название формы в карточке.

6. 6

   Зафиксируйте приёмку. Сохраните ID теста и подтвердите, что менеджер получил обращение по рабочему правилу.

07

Какие настройки чаще всего маскируют проблему

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

Вторая группа рисков связана с «тихими» ошибками. Обработчик ловит исключение, показывает пользователю благодарность и не отправляет уведомление администрации. Либо API возвращает ошибку, но текст ответа не сохраняется. Для критичных форм нужен понятный режим отказа: посетитель не должен видеть подтверждение, если данные не приняты, а ответственная команда должна получить технический сигнал.

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

08

Минимальный контроль после запуска рекламы и доработок

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

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

Для сложной воронки полезно передавать в карточку технический идентификатор отправки. Тогда специалист сопоставит конкретную форму, запись сайта и результат CRM без поиска по похожим телефонам. В проектах с несколькими лендингами и каналами это резко сокращает время диагностики и помогает не терять источник обращения.

09

Когда достаточно настройки, а когда нужна диагностика

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

Сначала отделите техническую доставку от бизнес-маршрутизации. Убедитесь, что запрос дошёл до сайта, сайт получил понятный ответ от Битрикс24, а созданная карточка оказалась в согласованной сущности с нужными полями. Затем проверьте дубли, роботов, ответственного и уведомления. Такой порядок не даёт тратить время на случайные правки и сохраняет доказательства причины.

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