CRM
Что должна фиксировать заявка с сайта
Редакция: сайты, заявки, SEO и РКН-контур
Заявка с сайта должна помогать менеджеру быстро ответить клиенту и помогать владельцу понять, какой канал привел обращение. Телефона без контекста уже недостаточно.
Короткий ответ
Минимум заявки: имя или контакт, телефон/email, услуга, страница отправки, время, источник, UTM и комментарий пользователя.
Для контроля нужны технические поля: успешная отправка, ошибка, канал доставки, согласие и резервное уведомление.
Если заявка попадает в CRM, важно фиксировать статус, ответственного и дальнейшую судьбу обращения.
Почему это важно
Контекст заявки ускоряет первый ответ.
Источник и UTM связывают маркетинг с продажами.
Технический статус помогает найти потерянные обращения.
Как понять на практике
Менеджер спрашивает, откуда клиент
Значит, источник и страница не передаются в уведомление или CRM.
Реклама не окупается на бумаге
В заявках нет UTM, поэтому нельзя связать обращение с кампанией и ключом.
Нельзя проверить согласие
Форма не фиксирует, какой текст согласия был показан и на какой странице.
Внешние ориентиры
Что берем из практики и официальных источников
Редакционный разбор
Как смотреть на проблему глубже
Заявка должна быть полезна двум людям
Менеджеру заявка нужна, чтобы быстро понять запрос и ответить клиенту. Владельцу бизнеса заявка нужна, чтобы понять, какой канал работает. Поэтому одного телефона недостаточно. Минимальный полезный набор: контакт, услуга, страница, комментарий, UTM, referrer, время, канал отправки и статус доставки.
Контекст важнее лишних полей формы
Не нужно заставлять пользователя заполнять десять полей ради удобства менеджера. Часть контекста сайт может добавить автоматически: URL страницы, название услуги, источник, UTM, устройство, время. Так форма остается короткой, а заявка становится информативной.
Согласие и версия формы тоже имеют значение
Если сайт часто меняется, полезно фиксировать, с какой страницы и какой формы пришла заявка. Для РКН-контура важно понимать, какой текст согласия был показан пользователю и куда вела ссылка на политику на момент отправки.
Примеры из открытой практики
Как применить это к своему сайту
Директ ведет на страницу, которая не повторяет обещание объявления
Яндекс Директ и МетрикаПаттерн
Рекламная система и Метрика дают данные по кликам и целям, но качество заявки зависит от связки объявление -> первый экран -> форма -> обработка.
Как выглядит на сайте
В объявлении обещан бесплатный РКН-аудит, а на странице первый экран говорит только 'создаем сайты'. Человек не видит своего запроса и уходит до формы.
Что делает Webpot
Мы сверяем ключевую фразу, объявление, H1, CTA, форму, цели Метрики, UTM и доставку заявки, чтобы понять, где рекламный бюджет превращается в потерю.
Цель считается раньше, чем появляется реальная заявка
Яндекс МетрикаПаттерн
Цели и события должны отражать понятные действия: открытие формы, успешную отправку, звонок, мессенджер, ошибку и заявку из инструмента.
Как выглядит на сайте
Отчет показывает конверсии, потому что цель срабатывает при клике по кнопке, но SMTP падает и письмо менеджеру не приходит.
Что делает Webpot
Мы разделяем микроконверсии и лиды, добавляем событие ошибки и проверяем заявку в почте, MAX или CRM, а не только в интерфейсе формы.
Что сверить по сайту
Участок
Контакт
Проверка
Проверить телефон, email или мессенджер и имя, если оно действительно нужно.
Зачем
Менеджеру нужен рабочий способ связи, а не лишняя анкета.
Участок
Источник
Проверка
Передавать страницу, UTM, referrer и канал отправки.
Зачем
Без источника нельзя оценить рекламу, SEO и статьи.
Участок
Смысл
Проверка
Передавать услугу, форму, комментарий и выбранные параметры.
Зачем
Менеджер быстрее отвечает, если понимает, зачем пришел клиент.
Участок
Техника
Проверка
Фиксировать время, статус доставки и ошибку при сбое.
Зачем
Так можно расследовать потерянные заявки.
Критерии решения
Как понять, что делать дальше
Критерий
Паспорт заявки
Норма
В заявке есть контакт, услуга, страница, UTM, комментарий, время и канал.
Риск
Менеджер получает только телефон и не понимает, что человек хотел.
Действие
Добавить скрытые поля контекста и единый формат уведомлений.
Критерий
Надежность доставки
Норма
Есть основной канал, резерв, лог ошибки и регулярная тестовая заявка.
Риск
Форма показывает успех, но email/CRM/MAX недоступны или письмо попадает в спам.
Действие
Проверить SMTP, SPF/DKIM/DMARC, MAX/CRM API и fallback.
Критерий
Обработка
Норма
Назначены ответственные, сроки реакции и этапы сделки.
Риск
Технически заявка дошла, но ее никто не обработал вовремя.
Действие
Описать воронку, SLA ответа и контроль просрочек.
Типовая ситуация
письмо есть, но пользы мало
Типовые ситуации в статье обобщают частые ошибки сайтов и не являются описанием конкретного клиента. Перед публикацией юридически чувствительные формулировки нужно проверять с профильным специалистом.
Ситуация
На почту приходит имя и телефон, но нет страницы, услуги, источника, UTM и времени отправки.
Как лучше
В уведомление добавляют контекст заявки и технический статус доставки, а при росте потока передают эти поля в CRM.
Вывод
Заявка должна быть полезной для продаж и аналитики одновременно.
Чек-лист
Контакт пользователя.
Услуга или тема обращения.
Страница отправки и заголовок страницы.
Источник, UTM и referrer.
Время, канал доставки и статус отправки.
Вопросы для ручного аудита
Какие каналы сейчас принимают заявки и кто за них отвечает?
Нужно исключить точки, где обращение может остаться без реакции.
Какие поля нужны менеджеру для первого ответа?
Короткая форма не должна означать пустую заявку.
Что происходит, если почта, CRM или MAX недоступны?
Нужен резервный маршрут и видимая ошибка.
Как фиксируется источник заявки и качество лида?
CRM и аналитика должны помогать решать, куда вкладывать продвижение.
Ошибка, риск и исправление
Ошибка
В заявку передается только телефон.
Риск
Менеджер не видит услугу, страницу, источник и UTM.
Что исправить
Передавать страницу, форму, услугу, UTM, referrer, время и статус отправки.
Ошибка
Нет резервного канала при ошибке CRM или почты.
Риск
Заявка исчезает, хотя пользователь видит успешное сообщение.
Что исправить
Дублировать критичные заявки в email/MAX и логировать технические ошибки.
Ошибка
Письма уходят с неподтвержденного домена.
Риск
Уведомления попадают в спам или отклоняются почтовыми сервисами.
Что исправить
Настроить SPF, DKIM, DMARC и отправку через доменную почту.
Что проверить за 10 минут
Отправить тестовую заявку
Проверьте, что заявка дошла туда, где ее реально видит ответственный.
Проверить поля
В уведомлении должны быть страница, услуга, контакт, комментарий, UTM, referrer и время.
Проверить ошибку
Отключение CRM, SMTP или API не должно приводить к молчаливой потере обращения.
Проверить резерв
Критичные заявки лучше дублировать в email или MAX до стабильной CRM-интеграции.
Проверить доставляемость
Для email-уведомлений проверьте доменную почту, SPF, DKIM, DMARC и папку спама.
План внедрения
Что сделать по шагам
Срок
За 1 день
Фокус
Тестовый маршрут
Работа
Отправить заявки с разных форм, устройств и UTM, проверить email, MAX, CRM, спам и логи ошибок.
Результат
Видно, где обращение теряется или приходит без полезного контекста.
Срок
За 1 неделю
Фокус
Единый формат заявки
Работа
Согласовать поля, ответственного, резервный канал, статус доставки и событие аналитики.
Результат
Менеджер получает понятную заявку, а владелец видит источник и качество лида.
Срок
За 1 месяц
Фокус
Управление продажами
Работа
Настроить этапы, контроль просрочек, отчеты по каналам и регулярную проверку интеграций.
Результат
Сайт перестает быть отдельной формой и становится частью управляемой воронки.
Definition of Done
Когда задачу можно считать закрытой
Заявка не теряется
Есть основной канал, резервный канал, лог ошибки и регулярный тест маршрута.
Менеджеру хватает контекста
В уведомлении есть контакт, услуга, страница, UTM, комментарий и время.
CRM отражает реальную воронку
Этапы, ответственные и сроки реакции совпадают с процессом продаж.
Данные можно сравнивать
Метрика, email/MAX/CRM и фактические обращения не противоречат друг другу.
Порядок действий
Посмотреть текущее письмо или сделку в CRM.
Сравнить поля с реальными вопросами менеджера.
Добавить недостающие поля в форму/API.
Проверить передачу UTM через несколько страниц.
Сделать тестовые заявки с разных источников.
Что можно проверить автоматически
Поля формы
URL страницы
UTM
Referrer
События аналитики
Что требует ручного разбора
Какие поля нужны продажам
Регламент ответа
Качество статусов
CRM-процесс
Когда нужен ручной разбор
Менеджеры не понимают контекст обращений.
Невозможно оценить рекламу и SEO по заявкам.
Заявки идут в разные каналы без единой структуры.
Нужно подготовить сайт к CRM.
Официальные источники и справки
Статья использует официальные материалы Метрики как основу для связки событий и источников. Состав CRM-полей определяется процессом конкретного бизнеса.
Типичные ошибки
Оставлять в заявке только имя и телефон.
Терять UTM при переходе между страницами.
Не фиксировать страницу отправки.
Не различать успешную отправку и ошибку уведомления.
FAQ
Нужно ли сохранять UTM для SEO?
Для SEO чаще важнее страница и источник, но UTM полезны для рекламы, рассылок и сквозной аналитики.
Можно ли отправлять все поля в письмо?
Можно, но письмо должно оставаться читаемым. Для сложной структуры лучше CRM.
Связанные материалы
Бесплатные инструменты по теме
Эти проверки помогают быстро применить материал к своему сайту и понять, что отдавать в ручной разбор.