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