Клиент заполнил форму. Нажал «Отправить». Сайт показал: «Спасибо! Ваша заявка принята». Кажется, всё произошло как надо.
Но сообщение на экране подтверждает только один этап сценария. Оно ещё не доказывает, что обращение появилось в CRM, сохранило источник, получило ответственного менеджера и вообще было кем-то замечено.
Между кнопкой на сайте и менеджером находится целая цепочка. Ошибка на любом её участке может привести к неприятной ситуации: посетитель уверен, что связался с компанией, маркетолог видит конверсию, а отдел продаж о клиенте ничего не знает.
«Спасибо» ещё не означает, что заявка дошла
Условно путь обращения можно представить так:
Параллельно существует ещё одна цепочка: источник посетителя → рекламная кампания → страница → форма → аналитическое событие → заявка в CRM.
В исправной системе эти цепочки должны сходиться в одной точке.
Если, например, рекламная аналитика показывает 25 заявок, на сайте сохранилось 23, в CRM оказалось 21, а менеджеры обработали 18, проблема уже не в количестве трафика. Сначала нужно выяснить, где исчезли остальные обращения.
Заявка – это не одна кнопка, а последовательность связанных этапов.
У одной заявки должно быть несколько подтверждений
Полезно разделять несколько состояний, которые обычно ошибочно называют одним словом «заявка».
Посетитель нажал кнопку.
Данные прошли проверку, а сервер действительно получил запрос.
Обращение записано на стороне сайта или в другой контролируемой системе.
Сайт отправил данные дальше – в CRM, почту или другой сервис.
CRM успешно создала или обновила запись.
У обращения появился сотрудник, который должен его обработать.
Менеджер получил уведомление или увидел новую задачу.
Аналитика зарегистрировала нужное действие и сохранила источник.
Где может исчезнуть заявка ещё до CRM
1. Форма выглядит исправной, но данные не прошли проверку
Пользователь мог неправильно заполнить телефон, пропустить обязательное поле, вставить значение в неожиданном формате или столкнуться с ошибкой сценария на странице.
Хорошая форма должна ясно показать, что отправка не состоялась. Плохой вариант – очистить поля, закрыть окно или показать неочевидную ошибку, после которой посетитель решит, что всё отправлено.
Это уже пересекается с проверкой пользовательского сценария формы, но в этой статье мы идём дальше – за пределы интерфейса.
2. Сервер получил запрос, но дальше ничего не произошло
Следующий этап скрыт от пользователя. Браузер передал данные серверу, а сервер должен проверить их, выполнить необходимые действия и передать заявку дальше.
Именно здесь возможны ошибки, которые посетитель никогда не увидит: сбой обработчика, изменение настроек после обновления сайта, проблема с базой данных, истёкший ключ API или недоступность стороннего сервиса.
Для важной формы полезно иметь собственную точку контроля – запись о принятой заявке, журнал отправок или другой механизм, позволяющий ответить на простой вопрос: получал ли сайт эту конкретную заявку?
3. Почта – слабое место, если она единственный канал
На небольших сайтах форма часто работает по простейшей схеме: форма → письмо → почтовый ящик.
Письмо может попасть в спам, быть отклонено почтовым сервером, задержаться, уйти на старый адрес или попасть в ящик сотрудника, который уже не занимается заявками.
Поэтому для бизнеса, где одна заявка имеет ощутимую стоимость, почту разумнее рассматривать как канал уведомления, а не как единственное место хранения обращений.
Сайт всё передал правильно – а клиент всё равно потерялся
Наличие CRM само по себе проблему не решает. Сайт может исправно передать данные, но CRM отвергнет запись из-за обязательного поля, неподходящего значения, правила проверки дублей, ограничения доступа или ошибки автоматизации.
Передать данные в CRM и получить корректно созданную заявку – не одно и то же.
Заявка есть в CRM, но менеджер о ней не знает
Допустим, запись создана. Следующий вопрос – кто за неё отвечает?
Если CRM не назначила менеджера, обращение может лежать в общей очереди. Если ответственный назначен, но уведомление не сработало, результат будет почти тем же.
Один клиент может внезапно превратиться в две заявки
Есть и обратная проблема – обращения не теряются, а дублируются. Сайт передал данные, CRM создала запись, но подтверждение ответа потерялось. Интеграция решила, что произошла ошибка, и отправила данные ещё раз.
Поэтому у заявки полезно иметь собственный уникальный номер. Повторная попытка доставки не должна автоматически создавать второго клиента.
Вместо «где-то вчера была заявка от Ивана» появляется нормальная цепочка: TEST-031026-01 принят сайтом → передан → создан в CRM → назначен менеджеру.
Аналитика может показывать заявку, которой нет
Отдельная ошибка – считать конверсией само нажатие на кнопку.
Пользователь нажал «Отправить». Сработал Google Tag Manager. В Google Analytics 4 ушло событие. После этого сервер мог вернуть ошибку.
В результате аналитика записала конверсию, которой для бизнеса фактически не существует.
| Событие | Что оно действительно означает |
|---|---|
| Клик по кнопке | Пользователь попытался отправить форму. |
| Успешная отправка | Сайт подтвердил приём корректных данных. |
| Заявка в CRM | Интеграция завершилась созданием или обновлением записи. |
| Квалифицированная заявка | Это уже следующий этап работы отдела продаж. |
Для GA4 событие generate_lead логичнее привязывать к подтверждённому успешному формированию обращения, а не просто к нажатию кнопки.
Иллюстрация принципа: цифры 20 и 17 условные и показывают возможное расхождение между аналитикой и CRM, а не статистику конкретного проекта.
Если нужно проверить не только заявки, но и саму систему измерения, полезно отдельно разобрать настройку GA4 и Google Tag Manager.
Источник клиента должен доехать вместе с заявкой
Если сайт получает трафик из нескольких каналов, недостаточно сохранить только имя и телефон.
Для анализа обычно важно понимать, откуда пришёл клиент, с какой страницы он отправил форму и какая именно форма сработала.
При этом содержимое формы нельзя бездумно отправлять в обычную веб-аналитику. Телефон и адрес электронной почты клиента не должны становиться обычными параметрами событий или UTM-метками.
Источники и технические идентификаторы – да. Персональные данные клиента в параметрах аналитики – нет.
Контрольная заявка: как пройти весь путь за 15 минут
Открыть форму и отправить сообщение «Тест» недостаточно. Лучше создать контрольную заявку, которую невозможно спутать с реальным обращением.
Например: TEST-031026-01.
- Открываем сайт из известного источника или добавляем тестовые UTM-метки.
- Заполняем форму реальными по формату, но тестовыми данными.
- Нажимаем «Отправить» только один раз.
- Проверяем корректное подтверждение на сайте.
- Находим заявку в журнале формы или на стороне сайта.
- Проверяем, что она передана дальше.
- Находим ту же заявку в CRM и сверяем поля и источник.
- Проверяем назначенного ответственного и фактическое уведомление менеджера.
- Проверяем событие в аналитике и время прохождения этапов.
Проверяем участок передачи и ответ принимающей системы.
Проверяем правила распределения заявок.
Проверяем канал оповещения.
Аналитика срабатывает слишком рано.
Одна тестовая заявка не доказывает, что система надёжна
Мы отправили тест. Всё прошло. Значит ли это, что за последний месяц не потеряно ни одного клиента? Нет.
Некоторые ошибки возникают только периодически: внешний сервис был недоступен несколько минут, закончились ресурсы почтового ящика, API временно вернул ошибку, изменилась маршрутизация или конкретное значение поля вызвало отказ CRM.
Поэтому после контрольного теста имеет смысл сделать сверку за период.
Для сайта с небольшим количеством обращений можно проверить каждую заявку. При большом потоке нужен автоматизированный контроль, но принцип остаётся тем же: цифры на разных этапах должны объяснимо сходиться.
Особенно внимательно проверяем сайт после обновлений
Форма могла исправно работать год, а потом перестать. Причиной может стать не сама форма, а изменение вокруг неё: обновление WordPress или плагина, новая версия шаблона, смена CRM, изменение обязательных полей, новый антиспам, перенос сайта, замена SMTP, новая логика GTM, изменение API или установка стороннего скрипта.
Поэтому формы стоит включать в проверку сайта после запуска и значимых изменений.
Но задача здесь уже другая: не убедиться, что кнопка нажимается, а провести контрольную заявку до конечной системы.
Что мы считаем нормально настроенной системой заявок
Надёжность определяется не количеством подключённых сервисов. Можно установить CRM, уведомления в мессенджер, почту, GA4, GTM и ещё несколько систем – и всё равно не знать, куда исчез клиент.
Гораздо важнее возможность быстро ответить по конкретному обращению:
- Когда сайт его принял?
- Куда передал?
- Что ответила принимающая система?
- Под каким номером обращение записано?
- Кто назначен ответственным?
- Получил ли он уведомление?
- Какой источник сохранён?
- Какое событие увидела аналитика?
Если ответы можно получить быстро – цепочка контролируема.
Что контролировать постоянно
Для небольшого сайта необязательно строить сложную систему наблюдения. Но хотя бы для ключевых форм стоит знать количество принятых обращений, ошибки передачи, обращения без ответственного и расхождения с CRM.
Чем дороже потенциальный клиент, тем менее разумно узнавать о поломке формы от самого клиента через неделю: «Я вам оставлял заявку, почему никто не позвонил?»
Особенно это касается рекламы. Компания может продолжать оплачивать переходы и видеть «конверсии», пока реальные обращения перестали попадать менеджерам.
В таком случае техническая ошибка превращается уже в прямые расходы.
Форма – это не кнопка, а бизнес-процесс
При разработке сайта форму часто воспринимают как небольшой элемент страницы: несколько полей, кнопка и сообщение об успешной отправке.
Для бизнеса это неправильная модель.
Форма – только вход в процесс. После неё должны сработать сервер, хранение данных, интеграция, CRM, распределение, уведомление и аналитика. Причём желательно так, чтобы каждый важный этап можно было проверить.
Поэтому при создании или переработке сайта эту цепочку лучше закладывать сразу, а не добавлять контроль уже после первой потерянной заявки.
Частые вопросы о потерянных заявках
Почему заявка с сайта не приходит на почту?
Причина может находиться как на стороне формы, так и после неё: обработчик не отправил сообщение, почтовый сервер отклонил его, письмо попало в спам, изменился адрес получателя или возникла ошибка SMTP. Сначала стоит определить, принял ли сайт саму заявку. Если запись есть, проверять нужно уже участок доставки уведомления.
Почему заявка есть на сайте, но её нет в CRM?
Это указывает на проблему между сайтом и CRM: ошибка API, недоступность принимающей системы, неверные данные, обязательное поле, правило дублей, истёкший ключ доступа или другая ошибка интеграции. Важен журнал передачи и ответ CRM, а не только факт отправки запроса.
Может ли CRM сама отклонить заявку?
Да. CRM может не создать запись из-за правил дублей, обязательных полей, ограничений или внутренних сценариев. Поэтому успешная работа формы ещё не доказывает успешное создание заявки.
Нужно ли хранить заявки на самом сайте?
Не всегда именно в WordPress или CMS. Но для важных обращений полезна независимая контрольная точка, позволяющая установить, что сайт действительно принял заявку и попытался передать её дальше. Конкретный способ зависит от архитектуры сайта и требований к защите персональных данных.
Когда фиксировать generate_lead в GA4?
Когда система получила подтверждение успешного формирования заявки, а не просто при нажатии на кнопку. Иначе аналитика может учитывать попытки, которые фактически не стали обращениями.
Нужно ли передавать телефон и адрес электронной почты клиента в GA4?
Нет. Такие данные не следует отправлять в Google Analytics 4 как обычные параметры событий, адреса страниц или UTM-метки. Для связи аналитики с внутренними системами используются допустимые технические идентификаторы и корректно спроектированная схема измерения.
Как понять, теряются ли реальные заявки?
Провести контрольную заявку недостаточно. Нужно дополнительно сверить за выбранный период количество обращений, принятых сайтом, с записями CRM и дальнейшей обработкой. Если числа расходятся, каждое расхождение должно иметь объяснение.
Как часто проверять формы?
Минимум после изменений сайта, формы, CRM, почты, антиспама, аналитики или интеграций. Для сайтов, где заявки напрямую влияют на продажи, разумно дополнительно контролировать цепочку регулярно, а критические ошибки отслеживать автоматически.
Путь заявки лучше закладывать в сайт, а не восстанавливать после потерь
При разработке или переработке сайта можно сразу предусмотреть форму, сохранение обращения, передачу в CRM, назначение ответственного и корректную аналитику. Тогда каждый важный участок цепочки можно проверить.
| Пользовательский путьПроверка юзабилити сайта → | Общая проверкаЧек-лист проверки сайта → | Ещё материалыНюансы создания сайтов → |