Потерю заявок между сайтом и CRM нужно искать по последовательности подтверждённых событий. Отделите отправку браузером, принятие сервером, сохранение в очереди и создание записи в CRM. Для одного обращения соберите идентификатор и время каждого шага: это позволит найти участок разрыва без случайного изменения нескольких систем.
Зафиксируйте воспроизводимый пример
Укажите страницу, форму, устройство, время и введённые тестовые значения. Используйте условные контактные данные, предназначенные для проверки. Сохраните наблюдение пользователя: появилась ошибка, успешное сообщение или страница не изменилась. Не начинайте с предположения, что виновата CRM.
Проверьте, действительно ли запись отсутствует. Она может находиться в другой воронке, быть связанной с существующим контактом или не отображаться из-за прав. Поиск только по имени ненадёжен. Лучше использовать технический идентификатор или специально выбранное тестовое значение, которое проходит весь путь.
Разделите участки доставки
В браузере выясните, отправлен ли запрос и какой ответ получен. На сервере сайта — принят ли запрос, прошла ли проверка и сохранено ли обращение. В очереди — есть ли событие и состояние обработки. На стороне CRM — принят ли запрос, создан ли объект и куда он направлен.
Конкретные журналы зависят от архитектуры. Если их нет, зафиксируйте недостаток наблюдаемости и добавьте минимальный контроль. В журнал не нужно без необходимости сохранять полный текст и персональные сведения; для диагностики часто достаточно идентификатора, времени, статуса и безопасного описания ошибки.
Разберите условный ложный успех
Сайт показал сообщение «Заявка отправлена», потому что обработчик вернул успешный ответ сразу после получения формы. Затем передача в CRM завершилась ошибкой, а повтор не был предусмотрен. Для посетителя процесс успешен, для отдела продаж обращения не существует.
Проверка показывает, что проблема находится между подтверждением сайта и фактическим созданием записи. Исправление зависит от выбранной архитектуры: надёжное сохранение до ответа, контролируемая очередь или другой согласованный механизм. Важно связать сообщение пользователю с реальным состоянием и обеспечить наблюдение за дальнейшей доставкой. Это проектное требование, а не готовое свойство любой интеграции.
Восстановите очередь без дублей
После устранения причины определите период сбоя и состав недоставленных обращений. Сверяйте их по идентификаторам с уже созданными записями. Повторная отправка всей выгрузки без такой сверки может создать дубли, даже если исходная ошибка исправлена.
Отдельно назначьте владельца общения с клиентами, которые ждали ответа. Техническое восстановление доставки не заменяет обработку накопившейся очереди. Укажите, какие обращения требуют первоочередного внимания и как фиксируется результат. Для специфического подключения amoCRM полезен порядок диагностики заявок с сайта.
Подтвердите исправление на нескольких ветках
Повторите исходный тест, затем проверьте другую форму, мобильное устройство, повторную отправку и временную недоступность получателя. Сохраните подтверждение каждого участка цепи. Исправление одной причины не доказывает работоспособность всех источников сайта.
Критерии завершения: причина воспроизводилась; новая заявка проходит; период сбоя сверён; накопленные события обработаны; повторы не создают лишнего эффекта; ответственный видит будущий отказ. Для сопоставления с веб-аналитикой учитывайте разницу между событием цели и записью CRM, описанную в статье о расхождении Метрики и CRM. Сохраняйте карту доставки рядом с документацией интеграции, чтобы следующий разбор начинался с доказательств.
Применить в вашей компании
Обсудим вашу задачу?
Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.