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