Вернуться к статьям После запуска нового сайта число заявок может снизиться, хотя все страницы открываются и команда уже отчиталась о релизе. Причина не обязательно в дизайне. Посетитель мог перестать находить нужную услугу, форма могла не передавать данные, цель аналитики могла остаться на старом селекторе, а CRM — создавать обращение без ответственного. Один график заявок не показывает, на каком участке разорвалась цепочка.
Диагностика начинается с определения события, которое считают заявкой. Это может быть отправка формы, звонок, сообщение в мессенджер, запись на консультацию или лид, который дошёл до CRM. Для каждого канала нужен наблюдаемый след: запись в аналитике, уведомление, карточка CRM, журнал интеграции. Тогда проверка идёт по маршруту человека, а не по предположению о том, какой экран ему не понравился.
Соберите контрольную воронку
Разложите путь на шаги: показ или переход на страницу, просмотр предложения, открытие формы, попытка отправки, подтверждение, передача в CRM, назначение ответственного и первый контакт. По каждому шагу фиксируют дату изменения, источник данных и владельца проверки. В разных системах цифры могут отличаться из-за фильтров и задержек, поэтому важнее сначала установить направление потери.
Сравнивать нужно сопоставимые периоды и сегменты. Если после редизайна одновременно выключили рекламную кампанию или изменили форму квалификации, общее падение не говорит о технической причине. Раздельно смотрят органические переходы, рекламу, прямые заходы, мобильные устройства, популярные посадочные и каналы обращения.
Проверьте живой сценарий на каждом устройстве
Не ограничивайтесь отправкой тестовой формы с рабочего компьютера. Пройдите сценарий в мобильном браузере, с медленным соединением, с заблокированными сторонними скриптами и с обязательными полями, которые заполняет реальный посетитель. У формы могут не открываться селекты, не работать маска телефона, перекрываться кнопка согласия или исчезать сообщение об ошибке.
Тестовая заявка должна пройти до конечного получателя. Номер телефона и почта в форме не должны попадать в публичный отчёт или в тело статьи; для проверки используют согласованные служебные данные и затем удаляют тестовые записи по регламенту.
Отделите интерфейсную проблему от потери измерения
Цель веб-аналитики может срабатывать при клике на кнопку, хотя сервер отклонил форму. Обратная ситуация тоже возможна: форма отправилась, но событие не передалось из-за смены HTML-разметки или контейнера тегов. Поэтому событие «успешная отправка» привязывают к подтверждённому результату, а не к нажатию.
Сверьте идентификаторы форм, маршруты интеграции, обработку ошибок, обязательные согласия, защиту от спама и уведомления. Если форма передаёт запрос в CRM через промежуточный сервис, изучите его журнал: там видны ошибки авторизации, изменения полей, тайм-ауты и отклонённые запросы. Скриншот красивой формы не заменяет этот след.
Проверьте CRM и реакцию отдела продаж
Новая заявка может создаваться, но не становиться работой менеджера. После редизайна часто меняются значения источника, поля формы, правила маршрутизации и роботы. Очередь может зависеть от несуществующего значения, карточка — попадать без ответственного, а уведомление — уходить в отключённый чат.
В CRM проверяют: появилась ли сущность, заполнены ли ключевые поля, назначен ли ответственный, сработал ли робот, создана ли задача и есть ли отметка о первом контакте. Для этого не нужны персональные данные реальных клиентов: достаточно согласованной контрольной заявки и протокола её прохождения. Если технически всё проходит, а обращения не обрабатываются, проблема уже в операционном процессе, а не в верстке.
Ошибки в разборе падения
Сразу переписывают первый экран
Изменение интерфейса до измерения может скрыть исходную ошибку и создать новую. Сначала подтвердите прохождение формы, события и CRM, затем работайте с гипотезами о содержании и сценарии.
Считают все обращения одним числом
Звонок, заявка с формы и чат имеют разные технические маршруты. Если сложить их без раздельной проверки, источник сбоя останется неизвестным.
Ориентируются на экран благодарности
Страница «спасибо» может появиться до записи в CRM или вообще после имитации отправки на клиенте. Контрольный сценарий заканчивается только тогда, когда заявка назначена и доступна ответственному сотруднику.
Игнорируют мобильные устройства
На мобильном сайте отличаются размер экрана, клавиатура, автозаполнение, блокировщики и скорость сети. Если основная доля трафика приходит со смартфонов, проверка только на десктопе ничего не доказывает.
Часто задаваемые вопросы
- Сколько ждать данных после релиза?
Технические сценарии проверяют сразу. Для выводов о конверсии нужен период, сопоставимый по трафику и источникам; точная длительность зависит от объёма обращений и сезонности.
- Может ли падение быть связано с CRM, если формы отправляются?
Да. Форма может отправляться, но терять поле, попадать в нерабочую очередь или не получать ответственного. Проверяйте всю цепочку до задачи или контакта менеджера.
- Нужно ли отключать новый сайт на время проверки?
Только если есть подтверждённая критическая потеря обращений и подготовлен безопасный план отката. Во многих случаях можно исправить конкретную форму, маршрут или событие без возврата всего релиза.
- Что передать подрядчику для диагностики?
Ссылку на сценарий, устройство и браузер, время попытки, ожидаемый и фактический результат, а также обезличенные идентификаторы записи или ошибки. Фразы «заявок стало меньше» для технического разбора недостаточно.
- Почему аналитика и CRM показывают разные цифры?
Они измеряют разные события и могут иметь задержку. Разница становится проблемой, когда заранее не определено, какой источник подтверждает факт обращения и как сопоставлять записи.
Итог
Падение заявок после редизайна ищут по цепочке, а не по вкусу к макету. Контрольная воронка, реальные тестовые сценарии и сверка сайта с CRM отделяют ошибку передачи данных от изменения спроса или поведения посетителей.