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