Если посетитель отправил форму, а менеджер не видит обращения, сначала найдите последний подтверждённый этап. Проблема может возникнуть до сетевого запроса, при приёме данных, в обработке CRM или только в отчёте аналитики. Сообщение «отправлено» и событие цели не доказывают весь путь.
Ниже — порядок диагностики для владельца сайта и технического исполнителя. Он не описывает инцидент клиента CoreWeb. Проверки проводятся на синтетическом обращении в согласованном окружении, без публикации клиентских данных и секретов.
Определите, что именно пропало
Уточните симптом: форма не реагирует, показывает ошибку, показывает успех без записи в CRM, запись есть без уведомления или обращение есть, но цель не засчиталась. Это разные начальные условия.
Зафиксируйте страницу и язык, время с часовым поясом, устройство, действие и видимый результат. Для повторяемой проверки используйте безопасный идентификатор теста, который можно сопоставить с серверной записью. Не помещайте телефон, почту или текст обращения в название события, URL или UTM-метку.
Заранее согласуйте место приёма и ответственного за тест. Если доступ к серверу или CRM отсутствует, это ограничение проверки, а не доказательство отсутствия записи. Попросите владельца нужной системы подтвердить конкретный этап.
Дерево диагностики
Идите по цепочке, сохраняя доказательство каждого перехода. «Не видно» нужно уточнять: запись отсутствует, ещё обрабатывается, скрыта фильтром или у проверяющего нет нужного доступа.
Нажатие кнопки
├─ Запрос не появился → интерфейс и проверка полей
└─ Запрос появился
├─ Сервер не подтвердил приём → сеть, ответ, контракт
└─ Приём подтверждён
├─ Итоговой записи нет → очередь и обработка
└─ Запись есть
├─ Менеджер не видит → права и маршрутизация
└─ Нет цели → отдельно проверить аналитику
При потерянном ответе не делайте вывод «сервер ничего не получил». Результат может быть неизвестным: операция успела выполниться, но подтверждение не дошло обратно. Перед повтором нужна сверка и согласованный способ избежать дубликата.
1. Кнопка и проверка полей
Проверьте, доступна ли кнопка, понятны ли обязательные поля и видна ли ошибка рядом с нужным полем. Повторите обычный ввод и отправку с клавиатуры. Сообщение об ошибке за пределами экрана может выглядеть для посетителя как отсутствие реакции.
Технический исполнитель проверяет, появляется ли сетевой запрос после действия, и рассматривает ошибки JavaScript. Если запроса нет, начинать с настроек CRM рано: сначала нужно выяснить, почему отправка не началась. Возможные области проверки — обработчик формы, условия блокировки, формат поля и состояние интерфейса после предыдущей попытки.
Сравните правила проверки в браузере и на сервере на тех же синтетических данных. Браузерная проверка помогает человеку исправить ввод, но не заменяет проверку принимающей стороны. Не отключайте защиту формы в production ради успешного теста; причину отказа разбирают в разрешённом окружении.
2. Запрос и ответ сервера
Если запрос появился, сохраните его время, адрес без секретных параметров, HTTP-статус и безопасное описание ответа. Проверьте, что запрос идёт в нужное окружение и обрабатывается ожидаемым методом. Токены, cookies и содержимое формы не должны попадать в публичный отчёт.
Сам факт завершения сетевого вызова не равен успеху приложения. Например, fetch() не отклоняет обещание только из-за HTTP-ответа 404 или 500: код должен проверить статус. Затем нужно проверить и согласованный смысл ответа, а не считать любой JSON подтверждением. MDN о проверке ответа Fetch.
Уточните контракт: какие поля подтверждают приём, как обозначается отказ и что делать при неожиданном формате. Если приложение показало успех на неизвестном ответе, проблема может быть в интерпретации результата, даже когда сеть работает.
3. Приём данных и последующая обработка
Между сайтом и CRM может находиться сервис приёма или очередь. Уточните, что именно он подтверждает: сохранение задания, создание конечной записи или только получение запроса. Например, HTTP 202 означает принятие к обработке, которая ещё не завершена; он не гарантирует конечный результат. MDN о статусе 202.
Проследите тестовый идентификатор от принятого задания до результата. Проверьте статус обработки, причину отказа и наличие повторных попыток. Если данные приняты, но обработчик остановлен или не может обратиться к CRM, исправление текста кнопки не устранит сбой.
Разделяйте временную ошибку и неподходящие данные. Повтор неизменённого запроса с неверным обязательным полем может снова закончиться отказом. Для восстановления нужны условия повтора, предел попыток и ответственный за ручной разбор. Этот состав входит в план интеграции.
4. Запись существует, но менеджер её не видит
Проверьте нужную рабочую область, тип записи, этап, назначенного сотрудника и фильтры списка. Уточните, не было ли объединения с существующим контактом и куда попали дополнительные поля. Поиск только по последним записям может не найти результат обновления старой карточки.
Отдельно проверьте уведомление. Письмо, сообщение в мессенджере и запись в CRM — разные результаты; отказ уведомления не доказывает потерю обращения. И наоборот, уведомление без корректной записи не закрывает задачу интеграции.
Проверку завершает роль, которая будет обрабатывать реальные обращения: она находит тест, видит согласованные поля и может выполнить следующий шаг. Наличие записи под администратором не подтверждает доступность процесса менеджеру.
5. Обращение получено, но аналитика расходится
После подтверждения рабочего пути отдельно проверьте измерение. Какое действие означает цель: нажатие, начало ввода, подтверждённый приём или дальнейшую обработку? Эти события нельзя сравнивать как одинаковые заявки.
Сверьте ресурс и счётчик, период, часовой пояс, фильтры и момент обновления отчёта. Проверьте, вызывается ли событие в нужном состоянии и не повторяется ли при повторном нажатии или переходе. Учитывайте условия загрузки аналитики и блокировки в браузере. Отсутствие события не должно ломать сам приём обращения.
Сравнивайте одинаковые единицы: события, визиты с действием и уникальные обращения — разные числа. Правила расчёта разобраны в термине «Конверсия». Задержка отчёта, отсутствие доступа и нулевое значение требуют разных выводов. Внутренние проверки должны быть отделены от реальных обращений по согласованной методике учёта.
Протокол проверки одной заявки
Чтобы пройти этот путь на своём проекте, выполните практику проверки заявки: подготовьте тестовую метку, согласуйте получателя и заполните результаты до обработки. В уроке есть учебный разбор ситуации, когда запись видна администратору, но недоступна менеджеру.
Заполните таблицу для одного теста. Состояния: подтверждено, ошибка, ожидает обработки или не проверено. У каждого неизвестного должен появиться следующий шаг, а не предположение.
| Этап | Доказательство | Кто подтверждает |
|---|---|---|
| Интерфейс | Действие, проверка полей, видимое состояние без личных данных | Проверяющий сайт |
| Сетевой запрос | Время и безопасные сведения о запросе и ответе | Разработчик интерфейса или сервера |
| Приём | Идентификатор и подтверждённое состояние по контракту | Ответственный за сервис приёма |
| Обработка | Статус задания, результат или причина отказа | Ответственный за обработчик |
| Работа в CRM | Нужная запись, поля, назначение и доступ | Ответственный за CRM и обработку обращений |
| Аналитика | Определение события, тестовый режим, период и результат сверки | Ответственный за измерение |
Не прикладывайте полный сетевой архив или журнал без проверки содержимого: там могут быть доступы и данные формы. Для общей задачи достаточно очищенного описания и ссылки на доказательство в разрешённом рабочем пространстве.
Что считать исправлением
Повторите исходный сценарий после изменения и подтвердите всю цепочку. Затем проверьте связанные ошибки: неверные данные, временный отказ и повтор после неопределённого ответа. Набор и условия включите в критерии приёмки.
Результат — не только исчезнувшая ошибка. Нужны корректная запись, доступный следующий шаг обработки, понятное поведение формы и согласованное измерение. Опишите, кто будет замечать сбои после запуска и как выполняется контрольная проверка.
При разработке сайта под ключ этот путь стоит согласовать заранее вместе с интеграциями и аналитикой. Для первого обсуждения достаточно симптома, времени и последнего подтверждённого этапа; закрытые журналы и доступы в публичную форму не отправляйте.
Если в цепочке используется webhook, отдельно проверьте событие, попытку доставки, повтор и результат у получателя.
Для измерения цепочки составьте карточку события и цели, а для источников — словарь UTM-меток. Условие успеха и модель атрибуции должны быть понятны до сравнения отчётов.