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