Автоматизация работает без ошибок, но заявки не доходят до CRM
Как обнаружить тихий сбой интеграции: сверить исходные обращения с CRM, контролировать возраст очереди и восстанавливать только действительно пропущенные записи.
Сценарий завершён успешно, аварийных уведомлений нет, а менеджер не видит обращения с сайта. При разборе оказывается, что новый вариант поля не прошёл фильтр: ни одной ошибки исполнения не возникло, поток просто ушёл в пустую ветку. Технический успех не подтвердил получение заявки отделом продаж.
Надёжность автоматизации полезно проверять по движению бизнес-объекта. Ниже — предлагаемая схема для передачи обращений в CRM: исходный журнал, состояния обработки, сверка получателя и выборочное восстановление. Это описание архитектуры, а не настроенный мониторинг конкретной инфраструктуры.
Для каждого обращения определите последовательность: принято источником, подготовлено, отправлено, найдено у получателя. Ошибка преобразования и временная недоступность CRM — отдельные состояния. Приём на сайте подтверждается собственной устойчивой записью, а завершение — идентификатором объекта в CRM и необходимыми полями.
Ответ HTTP 200 полезен, но его смысл определяется API. Он может сообщать лишь о принятии задания или сопровождаться прикладным результатом, который нужно разобрать. Если запись создаётся асинхронно, потребуется отдельное подтверждение готовности. Внутренняя отметка «отправлено» не должна подменять эту проверку.
Храните исходный идентификатор, время приёма, версию преобразования и идентификатор записи получателя. По ним можно объяснить судьбу конкретного обращения. Полное содержание формы в уведомлении обычно не требуется: для разбора достаточно разрешённого краткого описания и ссылки на защищённую карточку.
Предположим, сайт принял 40 обращений за рабочий период. В CRM подтверждены 37; ещё 2 отклонены проверкой формата и находятся в очереди исправления, 1 ожидает подтверждения. Учебный баланс сходится: 40 = 37 + 2 + 1. Это не означает, что всё хорошо: возраст ожидающей записи может уже превышать допустимый срок.
Проверка по числу записей — начало, но одинаковые количества могут скрывать замену: одна заявка пропущена, другая задублирована. Поэтому основная сверка работает по устойчивым идентификаторам. Для каждого принятого объекта ищется ровно один ожидаемый результат либо объяснённое исключение. Граница периода учитывает задержку доставки и поздние события.
Состояние хранят на уровне отдельного обращения. Пакет может частично завершиться: девять записей созданы, одна не принята. Общий статус запуска тогда недостаточен. Система должна показать, какая запись требует действия и что уже подтверждено, чтобы не повторять всю пачку.
Тишина ночью может быть нормальной, а в рабочее время после рекламного запуска — поводом посмотреть источник. Один порог «нет заявок час» даёт шум и пропускает другие ситуации. Полезно сочетать календарь, ожидаемый поток и независимый сигнал доступности формы или очереди.
Если сам сборщик событий остановился, он не сообщит о своём отказе. Поэтому состояние источника и регулярное выполнение сверки должны быть видны отдельно от основного сценария. Для малого потока достаточно периодического ручного сравнения реестра формы с CRM. Это лучше, чем сложная сигнализация, которую никто не читает.
В контрольной операции важно отличать проверку соединения от проверки бизнес-пути. Успешное обращение к API показывает доступность сервера, но не гарантирует корректность фильтра и заполнения карточки. Тестовую запись следует явно обозначить и обрабатывать по отдельным правилам, чтобы она не становилась настоящим лидом или письмом клиенту.
В официальном руководстве n8n описан Error Workflow: отдельный процесс с Error Trigger, который назначается основному и запускается при ошибке исполнения. Узел Stop And Error позволяет явно завершить процесс ошибкой, если нарушено выбранное условие. Это подходит, например, для отсутствия обязательного идентификатора в ответе получателя.
В предлагаемой реализации после записи проверяют прикладной результат. Если API отверг объект, состояние фиксируется до передачи в обработчик. Уведомление содержит название процесса, шаг, идентификатор обращения и понятную причину. Не нужно пересылать весь запрос с контактами и токенами в общий чат.
Error Workflow не заменяет сверку бизнес-результата. Если ветка законно закончилась без данных или запуск вообще не произошёл, исключения может не быть. Здесь нужна отдельная проверка исходных обращений и подтверждений. Именно она обнаруживает сценарий, с которого началась статья.
Назначьте владельца и способ подтверждения, что сигнал принят в работу. Повторяющиеся сообщения об одной причине можно объединять, сохраняя число затронутых объектов. Уведомление о восстановлении отправляется после подтверждения результата, а не сразу после перезапуска сценария.
Возраст очереди часто важнее общего количества: пять записей, ожидающих со вчерашнего дня, могут требовать более срочного вмешательства, чем сто только что принятых. Порог зависит от обещанного срока обработки и расписания команды. Для разных типов данных он может различаться.
Восстанавливайте только то, чего действительно нет #
Перед повтором проверьте получателя по исходному ключу. Запись могла создаться, а подтверждение потеряться. В этом случае нужно восстановить связь и статус, а не создавать ещё одну карточку. Если используемый API поддерживает ключ идемпотентности, применяйте его по документации; иначе защиту от повторов строят в интеграции с учётом конкурентных попыток.
Для записи, которой действительно нет, повтор выполняется с сохранённым исходником и зафиксированной версией преобразования. Если правила с момента сбоя изменились, решите, нужна старая или новая логика. Новая версия может исправить ошибку, но также по-другому интерпретировать прежние данные. Решение должно быть видно в истории восстановления.
Подробно проблема повторного действия разобрана в статье почему ИИ-агент не должен выполнять действие дважды . Здесь тот же принцип применяется к восстановлению пропущенных обращений: сначала установить фактическое состояние, затем выбирать действие.
Пропустите через тестовый процесс корректное обращение, неизвестный вариант поля, частичный отказ и потерю ответа после создания карточки. Затем остановите источник и убедитесь, что независимая проверка замечает отсутствие работы. В приёмке должно быть видно не только сообщение об ошибке, но и объяснение судьбы каждого объекта.
После исправления сверьте исходные ключи ещё раз: пропущенные записи появились, дубли не добавились, возраст очереди сократился, штатная обработка новых обращений продолжается. Только такой результат закрывает инцидент. Зелёный статус последнего запуска подтверждает гораздо меньше.
NetLabCS поможет разобрать журнал обращений, подтверждение записи в CRM и порядок восстановления в рамках автоматизации бизнес-процессов . Опишите пример пропавшей заявки : где она появилась, через какие системы проходит и какой результат считается завершённым. На этой основе определим точки сверки и ответственных за исключения.
