Формы на сайте перестали отправлять заявки: чек-лист диагностики
Проверяем весь путь обращения — от кнопки и серверной обработки до CRM, почты, уведомления менеджера и цели аналитики.
Форма может показать пользователю сообщение об успешной отправке, но заявка не дойдет до менеджера. Возможен и обратный сценарий: обращение сохранено в CRM, а интерфейс показывает ошибку, из-за чего клиент отправляет данные несколько раз. Поэтому проверять нужно не кнопку, а всю цепочку доставки.
Нарисуйте путь заявки
Обычно цепочка выглядит так:
- Пользователь заполняет поля.
- Браузер валидирует данные и отправляет запрос.
- Сервер принимает и проверяет запрос.
- Обращение сохраняется локально или передается в CRM.
- Почта или мессенджер уведомляет сотрудника.
- Пользователь получает подтверждение.
- Аналитика фиксирует успешную отправку.
Сбой на любом этапе требует отдельной проверки. Если форма отправляет данные сразу в сторонний сервис из браузера, отказ внешнего API может сделать весь процесс непрозрачным.
Проверьте интерфейс формы
Откройте инструменты разработчика и выполните тестовую отправку. Нас интересуют:
- ошибки JavaScript;
- фактический сетевой запрос;
- HTTP-код и ответ сервера;
- заблокированные запросы;
- работа согласия на обработку данных;
- корректность обязательных полей;
- поведение на мобильном устройстве;
- повторная отправка двойным нажатием.
После редизайна кнопка может визуально работать, но обработчик события не подключается. Иногда невидимый слой или виджет перекрывает кнопку только на определенной ширине экрана.
Проверьте серверную обработку
Ответ 200 не всегда означает успех: endpoint способен вернуть HTML ошибки внутри успешного ответа. Проверяем серверные журналы и факт создания записи.
Типовые причины:
- истекший CSRF-токен или nonce;
- превышение ограничения размера запроса;
- ошибка обязательного поля;
- недоступная база данных;
- неверная переменная окружения;
- блокировка защитным модулем;
- лимит внешнего API;
- ошибка после обновления формы или CMS.
В журнале должны оставаться безопасные технические идентификаторы, но не полный набор персональных данных клиента.
Отделите сохранение заявки от уведомления
Если менеджер не получил письмо, сначала проверьте, сохранилась ли заявка. Это две разные подсистемы.
Если запись есть, проверяем:
- очередь отправки;
- настройки SMTP;
- доменные записи SPF, DKIM и DMARC;
- папку спама;
- лимиты почтового сервиса;
- адрес отправителя и получателя;
- возвраты и ошибки доставки.
Полезно иметь резервный канал: например, заявка сохраняется в CRM независимо от того, удалось ли отправить уведомление.
Проверьте передачу в CRM
При интеграции с CRM возможны скрытые ошибки: изменился токен, обязательное поле, формат телефона, идентификатор воронки или лимит API. Форма при этом может продолжать показывать успех.
Надежная интеграция должна иметь:
- журнал исходящих попыток;
- идентификатор заявки;
- ответ внешней системы;
- повторную отправку временных ошибок;
- защиту от дублей;
- уведомление о накопившейся очереди.
Если данные не доходят до внешней системы, используйте порядок диагностики сбоев интеграций и API.
Проверьте антиспам
Антиспам способен блокировать реальных пользователей после изменения правил, IP-адреса или поведения формы. Проверяем CAPTCHA, скрытые поля, rate limit и внешние фильтры.
Нельзя решать проблему полным отключением защиты на длительное время. Лучше определить условие ложной блокировки и ослабить только его.
Проверьте аналитику отдельно
Форма может отправляться, но цель аналитики не срабатывать — или наоборот, цель фиксируется до ответа сервера. Для оценки лидогенерации событие должно отправляться только после подтвержденного успешного приема заявки.
Контрольный тест включает:
- метку источника и UTM;
- идентификатор клиентской сессии;
- событие успешной отправки;
- запись обращения в CRM;
- отсутствие дубля события при повторном рендере.
Контрольная заявка после исправления
Проверяем форму с разных устройств и каналов, но помечаем тестовые обращения. Затем сопоставляем время на каждом этапе: браузер, сервер, CRM, уведомление и аналитика.
После восстановления полезно подключить синтетическую проверку или регулярный ручной тест. Обычный мониторинг HTTP не заметит, что страница открывается, а заявки больше не доходят.
Когда проблема требует срочной реакции
Срочность высокая, если форма — основной канал продаж, невозможно определить период потери заявок, обращения не сохраняются локально или сбой возник после релиза. В первую очередь восстанавливается надежное сохранение данных, затем уведомления и аналитика.
Постоянная поддержка сайта должна учитывать этот сценарий заранее: где хранится заявка, кто получает предупреждение и как быстро проверить полный путь обращения.
Частые вопросы
Почему тестовая заявка приходит, а реальные обращения теряются?
Тест может использовать простой набор данных и привилегированную сеть. Реальные пользователи вводят другие форматы телефонов, прикладывают файлы, работают через мобильные сети и попадают под антиспам. Сравните успешную и потерянную операцию по времени, полям и ответам каждого этапа.
Можно ли отправлять форму только на email?
Можно, но это повышает риск незаметной потери. Надежнее сначала сохранить обращение в базе или CRM, а почту использовать как уведомление. Тогда временная проблема SMTP не уничтожит данные клиента.
Как проверить форму, не создавая ложные лиды?
Используйте согласованный тестовый адрес, специальную метку и фильтр в CRM. Аналитическое событие для таких обращений не должно считаться бизнес-конверсией. После теста проверьте не только интерфейс, но и запись, уведомление и источник.
Нужно ли устанавливать CAPTCHA?
Если форма получает спам, защита нужна, но видимая CAPTCHA — не единственный вариант. Можно сочетать honeypot, ограничение частоты, серверную валидацию и оценку поведения. Любое правило нужно проверять на ложные блокировки реальных клиентов.
