Начните с значения слова «не приходит»

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

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

Нарисуйте фактический маршрут

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

Для каждого перехода нужны вход, выход и время. Сообщение «Спасибо» доказывает лишь появление сообщения. HTTP-ответ относится к конкретному запросу, а не автоматически ко всей цепочке. Например, статус 202 означает принятие запроса без подтверждения завершённой обработки — это определено в стандарте HTTP Semantics.

Успех метода CRM проверяют по его контракту. В API Битрикс24 метод создания лида возвращает идентификатор созданного объекта, а ошибки описываются отдельно. Это видно в документации crm.lead.add. Другие продукты и методы могут возвращать результат иначе.

Как провести безопасный контрольный тест

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

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

Не запускайте многократную повторную отправку до проверки результата первой. Запрос мог завершиться на стороне CRM, а ответ — не дойти до сайта. Без защиты от дублей повтор создаст вторую запись и затруднит разбор.

Чек-лист поиска участка сбоя

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

Условный пример: сообщение есть, записи нет

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

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

Чего не установить одним тестом

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