Содержание 6 разделов ↘
Часто форму заявки пытаются улучшить одним способом — сокращают количество полей. Было семь — оставить три. Было три — оставить телефон. Иногда это действительно помогает. Но заполнение может оставаться неудобным и после сокращения, а качество заявок — ухудшиться.
Причина в том, что форма — не самостоятельный элемент. Пользователь сначала должен понять, зачем оставлять данные. Затем заполнить поля без ошибок. После отправки сайт должен подтвердить успех, аналитика — зафиксировать правильное событие, а сообщение с заявкой — попасть к ответственному сотруднику со всеми необходимыми данными.
Форма начинается с обещания
«Оставьте заявку» сообщает только действие пользователя. Что произойдёт потом — непонятно. Ему позвонят? Пришлют расчёт? Назначат встречу? Откроют доступ? Отправят файл?
Чем выше цена решения и чем больше данных просит компания, тем важнее объяснить следующий шаг. Формулировка должна совпадать с реальным процессом. Если после отправки заявки менеджер только уточнит вводные, не нужно обещать «готовый расчёт за 15 минут».
Первый вопрос к форме: может ли человек заранее понять, что он получит после отправки и что потребуется от него дальше?
Каждое поле должно помогать следующему шагу
Количество полей важно, но правильнее спрашивать не «сколько», а «зачем». Имя может помочь нормальному первому контакту. Сайт компании — подготовиться к разговору. Регион — сразу направить заявку нужной команде. А большое обязательное поле «Расскажите подробно о проекте» может только переносить работу менеджера на пользователя.
Полезный тест простой: что команда делает с ответом сразу после получения заявки? Если никто не использует поле для маршрутизации, подготовки или квалификации, его стоит поставить под вопрос.
Особенно осторожно нужно запрашивать бюджет. В некоторых B2B-проектах он помогает понять масштаб задачи. В других человек ещё не знает бюджет и пришёл именно за оценкой. Тогда обязательный выбор из диапазонов вынуждает его угадывать и создаёт плохие данные.
Если часть вопросов нужна только некоторым пользователям, не обязательно показывать их всем. Условная логика может открыть дополнительные поля после выбора типа задачи или продукта. Но многошаговая форма полезна не сама по себе: пять экранов по одному полю могут раздражать сильнее одной короткой формы, если человек не понимает объём и не может вернуться назад.
Ещё один вариант — перенести часть квалификации после отправки. Например, на первом шаге собрать контакт и краткую задачу, а подробности уточнить на следующем экране или в разговоре. Решение зависит от того, насколько эти сведения нужны до первого контакта и сколько потенциальных заявок бизнес готов обрабатывать вручную.
Placeholder внутри поля удобен как пример формата, но плохо работает как единственная подпись. После ввода текст исчезает, и пользователь должен помнить, что именно ожидалось. Это становится особенно заметно в длинной форме или при исправлении ошибок.
Отдельный label помогает и обычному чтению, и доступности. Для телефона, почты, имени и адресных данных стоит использовать корректные типы полей и автозаполнение браузера. На мобильном это уменьшает ручной ввод и помогает открыть подходящую клавиатуру.
Ошибка должна объяснять, что исправить
«Некорректное значение» описывает состояние программы, а не действие пользователя. Лучше написать конкретно: «Укажите телефон с кодом страны», «Введите адрес в формате name@example.ru», «Выберите способ связи».
Сообщение нужно показывать рядом с проблемным полем, а введённые данные сохранять. После одной ошибки человек не должен снова заполнять всё с начала или искать красную рамку выше экрана.
Маска ввода тоже может мешать. Например, пользователь вставляет номер из буфера вместе с +7, а маска ожидает цифры без кода и создаёт ошибку. Перед запуском форму полезно пройти не только клавиатурой, но и вставкой, автозаполнением и мобильной клавиатурой.
Десктопный макет не показывает, как клавиатура перекрывает кнопку, как ведёт себя автозаполнение и куда попадает экран после ошибки. Поэтому мобильная проверка — отдельный сценарий, а не уменьшенное окно браузера.
Полезно пройти форму и без мыши: клавишей Tab, Enter и стандартными средствами браузера. Фокус должен идти в понятном порядке, кнопка — активироваться с клавиатуры, а сообщение об ошибке — быть связано с нужным полем. Это не отдельная «версия для доступности», а проверка того, насколько форма вообще предсказуема.
- в каждое поле удобно попасть пальцем;
- открывается подходящая клавиатура;
- автозаполнение не ломает формат;
- ошибка видна без прокрутки наугад;
- после ошибки данные сохраняются;
- кнопка не уходит под клавиатуру;
- текст согласия можно прочитать без увеличения.
Клик по кнопке ещё не означает успешную заявку
Пользователь может нажать «Отправить», но данные не пройти валидацию. Сервер может вернуть ошибку. Интеграция может не создать запись. Поэтому в интерфейсе и аналитике стоит различать попытку отправки и подтверждённый успех.
После успешной отправки человек должен получить явный итог: данные приняты и что произойдёт дальше. Если компания не гарантирует конкретный срок ответа, лучше не обещать его ради красивого экрана.
Отдельно нужно продумать повторный клик. Если кнопка остаётся активной во время запроса, пользователь может создать два или три одинаковых обращения. На стороне интерфейса кнопку обычно блокируют на время отправки, а на стороне системы обработки всё равно проверяют дубли.
Нужен и сценарий технической ошибки. Сообщение «Что-то пошло не так» без альтернативы оставляет человека в тупике. Если бизнес принимает обращения по телефону, почте или мессенджеру, при сбое можно показать резервный способ связи. Но не стоит выводить его как постоянный второй CTA прямо рядом с формой, если задача страницы — одна: альтернативный путь особенно полезен именно в состоянии ошибки.
Аналитика должна считать успешную отправку, а не намерение
Это место часто искажает CPL. Если цель срабатывает по клику на кнопку, в отчёт попадают попытки, которые не стали заявками. В актуальной документации Яндекс Метрики есть важное ограничение: стандартная цель отправки формы по умолчанию может засчитать даже неуспешную попытку, когда данные не прошли валидацию.
Поэтому после настройки цели форму нужно протестировать: отправить корректные данные, попробовать отправку с ошибкой, сделать повторный клик и убедиться, что в аналитике появляется именно тот бизнес-факт, который команда называет заявкой.
Если для формы используется собственная JavaScript-логика, надёжнее отправлять аналитическое событие после подтверждённого ответа системы, а не просто слушать нажатие кнопки. Название события тоже должно отражать смысл: например, успешная заявка, а не абстрактный submit.
Сайт может показать «Спасибо», а заявка при этом потеряться. Поэтому финальная проверка проходит весь путь до человека, который будет её обрабатывать.
- Откройте страницу так же, как реальный пользователь, включая рекламные параметры при необходимости.
- Отправьте заявку с мобильного и с компьютера.
- Проверьте успешное состояние на сайте.
- Убедитесь, что аналитика зафиксировала подтверждённую отправку заявки.
- Найдите обращение в CRM, почте или другой рабочей системе.
- Сверьте контакт, комментарий, страницу, источник и нужные служебные поля.
- Повторите отправку и проверьте правила дублей и назначения ответственного.
Рост числа отправленных заявок ещё не означает улучшение формы
После сокращения полей доля завершённых отправок может вырасти. Но если менеджерам приходится тратить больше времени на заведомо неподходящие обращения, бизнес не обязательно выиграл.
Поэтому изменение формы стоит оценивать как минимум по двум уровням: успешная отправка и качество обращений дальше. Для e-commerce или простых продуктов финальным показателем может быть заказ. Для B2B — квалификация, встреча или сделка, в зависимости от длины цикла.
Количество полей остаётся важным параметром. Просто оно не должно заслонять весь путь. Хорошая форма — та, где человеку понятен следующий шаг, ввод не мешает, ошибки объясняются, а успешная заявка без потерь доходит до команды.
