WWebpotсайт, заявки, SEO

Заявки

Почему заявки с сайта не приходят

Автор: Webpot

Редакция: сайты, заявки, SEO и РКН-контур

Заявка может потеряться на любом участке: форма, сервер, email, спам, MAX, CRM, менеджер или аналитика. Проверять нужно весь маршрут, а не только кнопку.

Короткий ответ

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

Рабочая форма должна показать пользователю успех, отправить уведомление бизнесу, зафиксировать событие в Метрике и сохранить источник заявки.

Самая опасная ситуация - пользователь видит “спасибо”, а бизнес ничего не получает. Поэтому нужен тест с реальной отправкой и контрольным списком полей.

Почему это важно

Пользователь считает заявку отправленной, а бизнес может ее не увидеть.

Email без SPF/DKIM/DMARC и резервного канала часто ненадежен.

Если событие не фиксируется, реклама и SEO оцениваются вслепую.

Как понять на практике

Спасибо есть, письма нет

Фронтенд может показывать успешное состояние даже при проблемах SMTP, спама или серверной ошибки.

Письмо пришло без контекста

Если нет страницы, услуги, UTM и времени отправки, менеджер хуже понимает, что хотел клиент и откуда он пришел.

Цель Метрики не сработала

Без события `lead_submit` реклама и SEO не смогут корректно оценивать источник заявок.

Внешние ориентиры

Что берем из практики и официальных источников

Редакционный разбор

Как смотреть на проблему глубже

Успешное сообщение не доказывает доставку

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

Письмо без контекста снижает качество продажи

Если менеджер получает только телефон, он вынужден заново спрашивать, что нужно клиенту. В заявку должны попадать страница, услуга, комментарий, UTM, referrer, время и технический статус. Это помогает быстро ответить и связать обращение с рекламой, SEO или статьей.

Доставляемость - часть продукта сайта

Форма может быть красивой, но если письма уходят со случайного отправителя без SPF/DKIM/DMARC, уведомления могут попадать в спам. Для коммерческого сайта доставка заявки не второстепенная настройка, а критический бизнес-процесс.

Примеры из открытой практики

Как применить это к своему сайту

Пользователь видит 'спасибо', а бизнес не получает письмо

SPF/DKIM/DMARC

Паттерн

Доставляемость зависит от домена отправителя, DNS-записей, SMTP и корректного поля From, а не только от frontend-сообщения.

Как выглядит на сайте

Форма показывает успешную отправку, но письмо уходит с технического адреса хостинга, попадает в спам или не отправляется при ошибке сервера.

Что делает Webpot

Проверяем серверный ответ, SMTP, SPF/DKIM/DMARC, папку спама, резервный email/MAX/CRM и событие ошибки в аналитике.

Что сверить по сайту

Участок

Тест заявки

Проверка

Отправить заявку с desktop и mobile, с UTM и без UTM.

Зачем

Так проверяется реальный путь пользователя, а не только наличие формы.

Участок

Каналы

Проверка

Проверить email, спам, MAX, CRM, резервную копию и лог ошибки.

Зачем

Один канал может быть недоступен, поэтому критичные заявки лучше дублировать.

Участок

Поля

Проверка

Сверить наличие страницы, услуги, контакта, комментария, UTM, referrer и времени.

Зачем

Контекст заявки нужен продажам и аналитике.

Участок

События

Проверка

Проверить успешную отправку и ошибку формы в Метрике.

Зачем

Без событий невозможно увидеть потери на техническом участке.

Критерии решения

Как понять, что делать дальше

Критерий

Паспорт заявки

Норма

В заявке есть контакт, услуга, страница, UTM, комментарий, время и канал.

Риск

Менеджер получает только телефон и не понимает, что человек хотел.

Действие

Добавить скрытые поля контекста и единый формат уведомлений.

Критерий

Надежность доставки

Норма

Есть основной канал, резерв, лог ошибки и регулярная тестовая заявка.

Риск

Форма показывает успех, но email/CRM/MAX недоступны или письмо попадает в спам.

Действие

Проверить SMTP, SPF/DKIM/DMARC, MAX/CRM API и fallback.

Критерий

Обработка

Норма

Назначены ответственные, сроки реакции и этапы сделки.

Риск

Технически заявка дошла, но ее никто не обработал вовремя.

Действие

Описать воронку, SLA ответа и контроль просрочек.

Типовая ситуация

пользователь видит спасибо, письмо не приходит

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

Ситуация

После отправки формы сайт показывает успешное сообщение, но письмо попадает в спам, а в Метрике цель не фиксируется.

Как лучше

Проверяют SMTP, спам, резервный канал, событие `lead_submit` и состав полей в уведомлении.

Вывод

Успешное сообщение на сайте еще не означает, что бизнес получил заявку.

Чек-лист

1

Отправить тестовую заявку с сайта.

2

Проверить успешное состояние для пользователя.

3

Проверить email, спам и резервный канал уведомления.

4

Проверить передачу URL, услуги, источника и UTM.

5

Проверить событие Метрики `lead_submit`.

Вопросы для ручного аудита

Какие каналы сейчас принимают заявки и кто за них отвечает?

Нужно исключить точки, где обращение может остаться без реакции.

Какие поля нужны менеджеру для первого ответа?

Короткая форма не должна означать пустую заявку.

Что происходит, если почта, CRM или MAX недоступны?

Нужен резервный маршрут и видимая ошибка.

Как фиксируется источник заявки и качество лида?

CRM и аналитика должны помогать решать, куда вкладывать продвижение.

Ошибка, риск и исправление

Ошибка

В заявку передается только телефон.

Риск

Менеджер не видит услугу, страницу, источник и UTM.

Что исправить

Передавать страницу, форму, услугу, UTM, referrer, время и статус отправки.

Ошибка

Нет резервного канала при ошибке CRM или почты.

Риск

Заявка исчезает, хотя пользователь видит успешное сообщение.

Что исправить

Дублировать критичные заявки в email/MAX и логировать технические ошибки.

Ошибка

Письма уходят с неподтвержденного домена.

Риск

Уведомления попадают в спам или отклоняются почтовыми сервисами.

Что исправить

Настроить SPF, DKIM, DMARC и отправку через доменную почту.

Что проверить за 10 минут

1

Отправить тестовую заявку

Проверьте, что заявка дошла туда, где ее реально видит ответственный.

2

Проверить поля

В уведомлении должны быть страница, услуга, контакт, комментарий, UTM, referrer и время.

3

Проверить ошибку

Отключение CRM, SMTP или API не должно приводить к молчаливой потере обращения.

4

Проверить резерв

Критичные заявки лучше дублировать в email или MAX до стабильной CRM-интеграции.

5

Проверить доставляемость

Для email-уведомлений проверьте доменную почту, SPF, DKIM, DMARC и папку спама.

План внедрения

Что сделать по шагам

Срок

За 1 день

Фокус

Тестовый маршрут

Работа

Отправить заявки с разных форм, устройств и UTM, проверить email, MAX, CRM, спам и логи ошибок.

Результат

Видно, где обращение теряется или приходит без полезного контекста.

Срок

За 1 неделю

Фокус

Единый формат заявки

Работа

Согласовать поля, ответственного, резервный канал, статус доставки и событие аналитики.

Результат

Менеджер получает понятную заявку, а владелец видит источник и качество лида.

Срок

За 1 месяц

Фокус

Управление продажами

Работа

Настроить этапы, контроль просрочек, отчеты по каналам и регулярную проверку интеграций.

Результат

Сайт перестает быть отдельной формой и становится частью управляемой воронки.

Definition of Done

Когда задачу можно считать закрытой

Заявка не теряется

Есть основной канал, резервный канал, лог ошибки и регулярный тест маршрута.

Менеджеру хватает контекста

В уведомлении есть контакт, услуга, страница, UTM, комментарий и время.

CRM отражает реальную воронку

Этапы, ответственные и сроки реакции совпадают с процессом продаж.

Данные можно сравнивать

Метрика, email/MAX/CRM и фактические обращения не противоречат друг другу.

Порядок действий

1

Отправить тестовую заявку с desktop и mobile.

2

Проверить, что пользователь видит понятное успешное состояние или ошибку.

3

Проверить входящие, спам, резервный email, MAX или CRM.

4

Проверить, какие поля пришли: контакт, услуга, страница, источник, UTM, время.

5

Проверить событие аналитики и связку с рекламными целями.

Что можно проверить автоматически

Наличие формы

Признаки thank-you

Email/MAX слова

События аналитики

Что требует ручного разбора

Доставляемость

CRM-поля

Регламент обработки

Реальный тест заявки

Когда нужен ручной разбор

Пользователи говорят, что отправляли формы, но заявок нет.

Заявки приходят нерегулярно или попадают в спам.

Нужно подключить резервный канал: MAX, CRM или дополнительный email.

Реклама работает, но невозможно связать заявку с источником.

Официальные источники и справки

Блок про аналитику сверяется с официальной справкой Яндекс Метрики. Доставляемость email, MAX и CRM проверяются техническими тестами в конкретной инфраструктуре сайта.

Типичные ошибки

Считать, что если форма визуально есть, она работает.

Не проверять спам и доставляемость почты.

Не передавать источник заявки менеджеру.

FAQ

Нужна ли CRM сразу?

Не всегда. Сначала можно настроить надежный email + MAX, а CRM подключить при стабильном потоке заявок.

Что должно быть в уведомлении?

Контакт, сайт, услуга, страница отправки, источник, UTM и краткий контекст заявки.

Связанные материалы

Бесплатные инструменты по теме

Эти проверки помогают быстро применить материал к своему сайту и понять, что отдавать в ручной разбор.