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