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

Пользователь заполнил форму и увидел «Заявка отправлена», но менеджер не получил письмо или карточку в CRM. Для бизнеса это опасный сбой: интерфейс выглядит исправным, реклама продолжает приводить трафик, а обращения теряются или приходят с задержкой.

Такую проблему нельзя надёжно проверить одной отправкой с компьютера владельца. Нужно проследить конкретную тестовую заявку через браузер, сервер, очередь, почту, CRM и назначение ответственному.

Сообщение об успехе подтверждает только тот этап, которого дождался интерфейс. Оно не доказывает, что заявка сохранена, доставлена во все системы и уже видна менеджеру.

Кому это актуально

Сквозная проверка нужна сайтам услуг, интернет-магазинам, личным кабинетам и B2B-порталам, где форма связана с рекламой, расчётом стоимости, заказом или работой отдела продаж. Поводом для диагностики могут быть конкретные симптомы:

• пользователь прислал скриншот подтверждения, но менеджер не видит обращения;
• письмо-подтверждение клиенту пришло, а уведомление менеджеру или вложение — нет;
• карточка в CRM или рабочей системе появляется заметно позже письма;
• заявки приходят только с части форм, устройств или источников трафика;
• письмо есть, а карточка в CRM не создалась — или наоборот;
• в аналитике зафиксирована конверсия, которую нельзя сопоставить с реальным обращением;
• после обновления сайта, почты, CRM, капчи или CDN путь заявки стал нестабильным.

Одна успешная отправка не исключает плавающую ошибку. Сбой может зависеть от мобильного браузера, формата телефона, вложения, антиспама, нагрузки, очереди или ответа внешнего сервиса.

Форма принята — это ещё не доставка заявки

В цепочке обращения есть несколько разных результатов. Браузер может получить успешный ответ от обработчика, сервер — сохранить запись, очередь — принять задание, почтовый сервер — принять письмо, CRM — создать карточку, а система распределения — назначить менеджера. Если проверять только первый результат, остальные сбои остаются невидимыми.

Полезно различать такие статусы:

1. данные отправлены из браузера;
2. запрос принят и проверен сервером;
3. заявка сохранена в устойчивом хранилище;
4. задания на письмо и интеграции поставлены в очередь;
5. письмо передано почтовому серверу, а вложение сформировано;
6. CRM или другая рабочая система приняли данные;
7. карточка попала в нужную воронку и назначена ответственному;
8. менеджер получил уведомление и может открыть обращение.

Подтверждение пользователю и уведомление менеджеру нередко обслуживаются разными операциями. Поэтому копия клиенту может прийти раньше, а карточка в CRM — появиться позже или завершиться ошибкой. Такой порядок сам по себе не указывает на причину, но показывает, почему результат нужно контролировать на каждом этапе.

Зачем нужны correlation_id и visit_id

Для каждой отправки полезен сквозной технический идентификатор, например correlation_id. Один и тот же безопасный маркер записывают рядом с серверной заявкой, заданием очереди, попыткой отправки письма и обращением к CRM. Тогда подрядчик ищет не «примерно ту заявку около полудня», а один маршрут с понятными статусами и временем.

visit_id помогает связать технический маршрут с визитом и событием аналитики. При этом в логи не нужно копировать телефон, email, текст обращения, токены или другие персональные данные: для сопоставления достаточно случайного идентификатора, времени и статуса этапа. Если внешняя система возвращает собственный ID, его можно хранить как ссылку на результат интеграции без публикации содержимого заявки.

Где теряются заявки между формой, почтой и CRM

1. Браузер показал успех раньше времени

Кнопка может выглядеть активной, но запрос не уйдёт из-за ошибки JavaScript, конфликтующей маски телефона, капчи, просроченного CSRF-токена или слишком строгой проверки полей. Бывает и обратная ситуация: запрос ушёл, а интерфейс показывает успех до подтверждения серверного сохранения.

Поэтому проверяют не только надпись на экране, но и сетевой запрос: адрес обработчика, HTTP-статус, структуру ответа и время отправки. Статус HTTP 200 тоже не гарантирует доставку, если обработчик вернул ответ до завершения фоновых операций.

2. Серверный обработчик принял запрос, но не сохранил заявку

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

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

3. Задание задержалось или застряло в очереди

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

Здесь важно сопоставить correlation_id, время постановки, число попыток и итоговый статус. После восстановления нужно проверить накопившиеся задания и защиту от дублей: простое повторное включение очереди иногда создаёт несколько одинаковых писем или карточек.

4. Письмо или вложение не дошли

Сбой может быть в SMTP, DNS-настройках домена, адресе отправителя, лимите хостинга, спам-фильтре, генерации файла или размере вложения. Почтовый сервер может принять сообщение, но это ещё не означает, что оно оказалось во входящих нужного сотрудника.

Для проверки нужны журнал отправки, ответ сервера, точное время, получатель и, если он создаётся, Message-ID. Важная заявка не должна существовать только внутри одного письма: резервная запись на сайте или в CRM позволяет восстановить обращение.

5. CRM или вебхук приняли не всё

Сайт может успешно сохранить заявку, но внешний API вернёт ошибку из-за истёкшего токена, нового обязательного поля, неверного формата телефона, ограничения запросов или изменившейся схемы. В другом сценарии карточка создастся, но попадёт не в ту воронку, останется без ответственного или не получит вложение.

Вебхук — это HTTP-уведомление одной системы другой о событии. Надёжная интеграция фиксирует код и безопасную часть ответа, повторяет временно неудачные операции и не создаёт дубли. Токены и персональные данные нельзя выводить в открытые логи; для диагностики достаточно технического идентификатора, этапа и результата.

6. Аналитика создаёт ложную картину

Цель может сработать при клике или показе сообщения, хотя сервер ещё не сохранил данные. И наоборот, реальная заявка попадёт в CRM, но событие аналитики будет заблокировано браузером.

Поэтому число конверсий и число обращений у менеджеров нельзя автоматически считать одинаковыми. Клиентское событие показывает действие пользователя, серверная запись подтверждает приём, а итоговый статус CRM или почты — доставку. Эти сигналы нужно сопоставлять по одной тестовой отправке.

Какие риски закрывает сквозная проверка

Главный риск — незаметная потеря обращений при внешне исправной форме. Бизнес продолжает платить за рекламу, менеджеры не связываются с потенциальными клиентами, а отчёты подсказывают неверные решения.

Сквозная проверка помогает:

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

Не отключайте капчу, WAF, проверку CSRF и другие механизмы защиты на рабочем сайте ради быстрого теста. Безопаснее воспроизвести проблему контролируемой заявкой и проверить журналы каждого этапа.

Как проследить тестовую заявку по всей цепочке

Владельцу сайта не нужно самостоятельно менять код или настройки сервера. Достаточно подготовить данные, по которым подрядчик сможет найти одну отправку без доступа к чужим обращениям.

1. Выберите конкретную форму и используйте безопасный тестовый маркер вместо данных реального клиента.
2. Запишите дату и время с часовым поясом, URL, устройство, браузер и тип сети.
3. Сохраните скриншот подтверждения и текст ошибки, если она появилась.
4. Уточните ожидаемый маршрут: запись на сайте, письмо, вложение, CRM, задача менеджеру и событие аналитики.
5. Попросите найти запрос, correlation_id, серверную запись и задание очереди.
6. Проверьте ответ SMTP или вебхука, появление карточки, воронку и ответственного.
7. Сопоставьте visit_id с клиентским и серверным событиями аналитики.
8. Повторите контрольную отправку с мобильного устройства и другого подключения после исправления.

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

Что запросить у подрядчика

Результатом диагностики должно быть не только сообщение «починили». Попросите передать:

• схему пути заявки и ответственных систем на каждом этапе;
• подтверждённую точку сбоя и данные, по которым она найдена;
• критерий, по которому заявка считается не просто принятой, а доставленной;
• описание исправления, риска повторения и плана отката;
• результаты контрольных тестов для основных форм и устройств;
• правила хранения заявок, повторной отправки и защиты от дублей;
• мониторинг очереди, ошибок интеграции и задержки доставки;
• регламент проверки форм после релизов.

Если подрядчик не может показать, где сохраняется обращение до письма или CRM, это отдельный риск. Важная заявка не должна исчезать вместе с недоставленным уведомлением.

Как это решает OpenStart

OpenStart начинает с карты сценария: какие формы работают на сайте, где сохраняются данные, какие внешние системы участвуют и в какой момент менеджер должен увидеть результат. Затем команда воспроизводит проблему и сопоставляет браузерный запрос с серверными журналами, очередью, почтой, CRM и аналитикой.

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

OpenStart нужен не в каждом случае. Если сбой стабильно воспроизводится, у текущего подрядчика есть доступ к журналам и он может показать точку потери и контрольный тест, проблему разумно исправить в рамках действующей поддержки. Помощь другой команды полезна, когда причина остаётся неясной, системы обслуживают разные подрядчики или изменения опасно проверять на рабочем проекте.

Цель работы — не просто вернуть действие кнопки, а сделать путь обращения наблюдаемым. Владелец должен понимать, где найти тестовую заявку, кто увидит ошибку и как проверить результат после следующего релиза.

FAQ

Почему пользователь видит «Заявка отправлена», а менеджер ничего не получает?

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

Если клиент получил копию письма, значит форма исправна?

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

Как понять, что это задержка, а не потеря?

У каждого этапа должны быть время, статус и допустимый предел ожидания. Если задание остаётся в очереди, повторяется с ошибкой или не получает конечного статуса, это уже диагностируемый сбой, а не неопределённое «письмо где-то идёт».

Безопасно ли записывать correlation_id и visit_id?

Да, если это случайные технические идентификаторы без телефона, email, текста заявки, токена и других персональных данных. Политику хранения и доступ к журналам всё равно нужно согласовать с требованиями проекта.

Нужно ли переписывать форму целиком?

Обычно нет. Сначала локализуют точку потери: причиной может быть одна проверка, остановленная очередь, ошибка вложения, просроченный токен или неверная маршрутизация. Объём исправления определяют после диагностики текущей цепочки.

Следующий шаг

Если форма сообщает об успехе, а менеджер не видит заявку, зафиксируйте одну тестовую отправку: время, URL, устройство и ожидаемые письмо и карточку. OpenStart может проследить её по всей цепочке, показать подтверждённое место сбоя и подготовить план исправления.