Форма пишет «Заявка отправлена», но в CRM пусто: как найти место потери

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

Начните с номера операции, а не с почтового ящика

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

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

Пять границ, на которых теряется обращение

Код 200 означает успешную обработку HTTP-запроса в принятой приложением модели, но сам по себе не доказывает создание заявки. Иногда обработчик возвращает 200 с текстом ошибки. Иногда интерфейс показывает успех сразу после начала запроса. Эти случаи требуют исправления контракта между формой и сервером, а не настройки почты.

Как должно вести себя исправленное приложение

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

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

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

Проверка исправления: три отказа вместо одного успешного клика

1. На стенде отключите доступ к CRM. Обращение должно сохраниться локально, попасть в очередь и появиться в CRM после восстановления связи.
2. Имитируйте сбой почтовой отправки. Заявка должна остаться доступной, повторяется только уведомление.
3. Имитируйте отказ базы. Ложного успеха быть не должно; введённые поля остаются доступными для исправления или повторной попытки.

Эти проверки проводятся в контролируемой среде: отключать рабочую CRM в разгар продаж ради теста не нужно. Для приёмки сохраните номера тестовых операций и ожидаемый результат каждого сценария. Не ограничивайтесь записью экрана с успешной анимацией.

Что покажет встроенная сверка

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

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