Форма заявки на мобильном сайте: что проверить, чтобы не терять обращения

Определите, что нужно для первого разговора

Проверка формы заявки на сайте не заканчивается появлением надписи «Спасибо». Посетитель должен без затруднений заполнить её на телефоне, понять результат отправки и получить ответ по указанному контакту. Сотрудник должен получить обращение вместе с необходимыми данными. Проблема может возникнуть на любом шаге: клавиатура закрыла поле, проверка не приняла вставленный номер, сервер получил заявку, но она не дошла до менеджера.

Начните с обычного сценария клиента. Человек открыл страницу услуги, прочитал условия и хочет обсудить задачу. Какие сведения действительно нужны сотруднику до первого разговора? Если достаточно номера телефона, не стоит заставлять посетителя сразу заполнять реквизиты компании, бюджет и подробный бриф.

Для каждого поля запишите назначение: кто использует значение и какое решение принимает. Имя помогает обратиться к клиенту; выбор услуги направляет запрос нужному специалисту; контакт позволяет ответить. Если назначение неясно, уберите обязательность или перенесите вопрос на следующий этап. Обязательное поле должно быть нужно именно сейчас, а не «когда-нибудь для отчёта».

Не всякая короткая форма удобнее длинной. Для расчёта доставки может понадобиться адрес, а для оценки ремонта — описание неисправности. Объясните, зачем просите эти сведения. Число полей выбирают по задаче; универсальной нормы, которая гарантирует больше заявок, нет.

Разделите первое обращение и подготовку подробного задания. На сайте разработки можно принять ссылку и короткое описание, а требования обсудить позже по структуре технического задания. Форма не должна превращаться в анкету, без которой невозможно задать простой вопрос.

Настройте подписи, клавиатуру и автозаполнение

Подпись поля должна оставаться видимой после ввода. Подсказка внутри пустого поля исчезает, как только человек начинает печатать: вернувшись к заполненной форме, он может забыть, что означало значение. Используйте явные подписи и связывайте их с элементами ввода. Этот подход описан в руководстве W3C по подписям элементов формы.

Для телефона обычно подходит тип поля tel, для электронной почты — email. Атрибут inputmode подсказывает браузеру подходящую виртуальную клавиатуру, но сам не проверяет введённые данные. Это различие поясняет MDN. Выбор клавиатуры и правила допустимого значения нужно проверять отдельно.

Добавьте подходящие значения autocomplete, например name, tel и email. Они сообщают браузеру назначение полей и помогают использовать сохранённые данные. Список значений приведён в справке по автозаполнению. Фактическое поведение всё равно зависит от браузера и настроек пользователя.

Маска номера должна облегчать ввод и сохранять все значащие цифры. Возьмите разрешённые бизнесом форматы: с кодом страны, пробелами и скобками, если они поддерживаются. Согласуйте с разработчиком, как номер приводится к единому формату и проверяется на сервере. Если клиенты могут обращаться из разных стран, одна жёсткая маска требует особенно внимательной проверки.

Проверяйте форму не только на пустых полях. Вставьте данные из заметки, выберите предложение браузера, удалите часть текста и восстановите её. Такой проход обнаруживает ошибки, которые не видны при аккуратном вводе по одному символу.

Объясняйте ошибку и сохраняйте уже заполненное

Сообщение «Некорректные данные» заставляет человека угадывать, что произошло. Укажите поле и способ исправления: «Проверьте адрес почты: в нём нужен символ @». Если есть ограничение длины или формата, покажите его заранее. Не выводите ошибку только красной рамкой: смысл должен быть понятен по тексту.

Не требуйте законченный адрес или номер, пока человек ещё печатает первые символы. Для таких полей проверка после выхода из поля или попытки отправки обычно понятнее, чем предупреждение на каждой букве. После неудачной отправки помогите перейти к первой ошибке; при нескольких проблемах может понадобиться общий список. Руководство W3C по уведомлениям разбирает сообщения рядом с полем и управление фокусом.

Остальные введённые данные сохраняйте в текущей форме. Если неверна одна цифра, посетитель не должен повторно писать комментарий. При этом сохранение ввода на экране и постоянное хранение в браузере — разные решения. Для обычной короткой заявки долговременное сохранение персональных сведений чаще не требуется.

Проверка в браузере даёт быструю обратную связь, но её можно обойти. Сервер должен самостоятельно проверять полученные значения; это отдельно подчёркнуто в MDN о валидации форм. Согласуйте правила двух сторон, чтобы браузер не принимал значение, которое сервер затем отклоняет без понятного объяснения.

Предусмотрите ожидание, повторное нажатие и сбой

После нажатия кнопки человек должен видеть, что отправка началась. Меняйте подпись или показывайте понятное состояние ожидания, сохраняя размер кнопки. На время текущего запроса повторное нажатие обычно блокируют. Не оставляйте интерфейс в таком состоянии навсегда: при ошибке нужен понятный способ продолжить.

Защита кнопки решает только часть задачи. Повторный запрос может возникнуть после перезагрузки или восстановления соединения. Разработчику нужно определить, как сервер узнаёт повтор одной попытки и предотвращает создание дубликата. Способ зависит от обработчика формы и принимающей системы; сравнивать только телефоны нельзя, потому что один клиент может оставить два разных обращения.

Особенно сложен обрыв связи после отправки. Сервер мог принять данные, а браузер не получить подтверждение. В такой ситуации фраза «Заявка не отправлена» может оказаться неверной. Предусмотрите отдельное сообщение о том, что результат пока не удалось подтвердить, и способ проверить его или безопасно повторить попытку.

Для проверки отключите сеть в согласованной тестовой среде до нажатия и во время ожидания ответа. Затем верните соединение. Посмотрите, можно ли продолжить без потери текста и не возникают ли два обращения. Такие испытания проводите с помеченными тестовыми данными, чтобы не засорять рабочую CRM.

У формы может быть несколько получателей: сервер сайта, CRM и почта. Решите, какой факт разрешает показывать успех. Если сайт надёжно сохранил заявку и поставил её в контролируемую очередь доставки, можно подтвердить приём до появления записи в CRM. Если данные ещё не сохранены и могут потеряться при сбое, подтверждать приём рано. Это условие нужно описать в задании разработчику.

Пройдите форму с открытой клавиатурой

Эмуляция узкого окна помогает проверить вёрстку, но не полностью воспроизводит экранную клавиатуру телефона. На реальном устройстве откройте каждое поле и проследите, видны ли вводимый текст, ошибка и следующее действие. Закреплённая кнопка, баннер или чат не должны перекрывать активное поле.

В модальном окне отдельно проверьте прокрутку: иногда движется страница под формой, а до нижней кнопки добраться нельзя. Закройте и снова откройте окно, поверните телефон, увеличьте текст. Убедитесь, что введённое не пропало из-за перестроения интерфейса. Если смена страницы намеренно сбрасывает форму, такое поведение должно быть ожидаемым для посетителя.

Кнопку и переключатели проверяйте касанием, а не только мышью. В WCAG 2.2 критерий 2.5.8 уровня AA задаёт минимум 24 × 24 CSS-пикселя либо соблюдение предусмотренных исключений, в том числе по расстоянию между целями. Условия перечислены в пояснении W3C. Для основной кнопки заявки на практике обычно выбирают более просторную область; минимальный размер стандарта не гарантирует удобство конкретного макета.

Проверьте переход по полям с внешней клавиатуры и чтение формы экранным диктором. Подписи, обязательность и ошибки должны распознаваться без необходимости смотреть на цвет. Для сообщения об успешной отправке разработчик выбирает доступный способ объявления, чтобы изменение было замечено и без визуального просмотра.

Текст согласия и связанные документы должны читаться на телефоне; ссылка не должна случайно переключать флажок или мешать возврату к форме. Юридическое содержание согласуют отдельно под фактическую обработку данных. Копирование чужого текста не проверяет ни его соответствие процессу, ни удобство интерфейса.

Проверку окружающей страницы можно начать с сервиса проверки адаптивности. Затем пройдите все шаги формы на телефоне: снимок экрана не покажет работу клавиатуры, сохранение текста после ошибки и получение заявки.

Проверьте путь от нажатия до обращения у сотрудника

Сделайте контрольную заявку с явной пометкой «Тест». Найдите её там, где с ней начинает работать сотрудник: в CRM, почте или другой системе. Сверьте контакт, комментарий, выбранную услугу и адрес страницы, с которой отправлено обращение. Проверьте, кто назначен ответственным и может ли он открыть запись.

Если запись есть, но никто не получил уведомление, это отдельная неисправность. Если письмо пришло, а заявка потерялась в CRM, нельзя считать весь маршрут рабочим. Отмечайте результат каждого звена. Для нескольких форм с одинаковым обработчиком полезно проверять разные страницы: скрытые параметры и маршруты доставки у них могут отличаться.

В пользовательской аналитике различайте начало заполнения, отказ из-за ошибки и подтверждённый приём. Нажатие «Отправить» ещё не доказывает получение обращения. Таблица ниже задаёт смысл событий. Их настройка разобрана в статье о целях Яндекс Метрики.

В события передавайте название формы, код поля и тип ошибки, если это действительно нужно для проверки. Телефон, почта и полный комментарий для такого анализа не требуются. Удалите их из адресов страниц, текстов ошибок и диагностических сообщений, которые попадают в аналитику.

Как проверить форму перед выпуском и после правок

Соберите короткую таблицу сценариев с ожидаемым результатом. Название браузера, модель телефона и шаги важнее общей пометки «на мобильном не работает». В каждом случае проверяйте и экран, и результат на стороне получателя. Для проблемного сценария сохраните запись экрана без личных данных.

• Пустая отправка: обязательные поля обозначены, сообщение объясняет дальнейшее действие.
• Корректный ввод вручную и через автозаполнение: данные принимаются одинаково.
• Ошибка в одном поле: остальные значения сохраняются, исправленную форму можно отправить.
• Открытая клавиатура и увеличенный текст: нужное поле и кнопка доступны.
• Медленная сеть и повторное нажатие: состояние понятно, нет лишнего обращения.
• Отказ сервера или неопределённый ответ: посетитель видит дальнейший шаг и не получает ложного подтверждения.
• Успешная отправка: обращение найдено у получателя, поля и ответственный проверены.

После запуска сравнивайте долю подтверждённых отправок среди начавших заполнение для одной формы и сопоставимых условий. Если выросло число ошибок телефона, сначала воспроизведите их с допустимыми форматами. Если в аналитике приём подтверждён, но в CRM обращений меньше, проверьте доставку и правила учёта событий. Изменение доли само по себе не доказывает, что виноваты длина формы или цвет кнопки.

Начните исправления с воспроизводимого препятствия: обрезанного поля, непонятной ошибки, потерянной заявки. После обновления повторите весь маршрут, потому что правка маски или обработчика может затронуть соседние сценарии. Если причина неясна, передайте ШТАБ ИТ адрес формы, устройство и описание шагов. Контрольный пример позволит проверить путь обращения от телефона до сотрудника.