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