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

Определите, где заявка считается принятой

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

Для простого проекта отдельная очередь может быть избыточной. Тогда явно определите, кто хранит неотправленные заявки, кто видит ошибку и как выполняется повтор. Фраза «в случае сбоя повторить вручную» работает только при наличии списка таких обращений и ответственного.

Какие данные передавать

  • Идентификатор обращения: постоянное значение, созданное при первом сохранении на сайте.
  • Время и источник: страница формы и согласованные рекламные метки.
  • Контакт и задача: только поля, необходимые для обработки.
  • Версия формата: помогает заметить изменение структуры формы.
  • Статус доставки: принято, отправляется, записано в CRM или требует проверки.

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

Рабочая последовательность n8n

  1. Webhook принимает событие от сайта.
  2. Проверка формата отклоняет неполные и неподдерживаемые данные.
  3. По идентификатору обращения определяется, выполнялась ли операция раньше.
  4. CRM создаёт или обновляет запись по согласованным правилам.
  5. Система сохраняет идентификатор CRM и результат доставки.
  6. Ответственному приходит уведомление со ссылкой на созданную запись.

В n8n у Webhook есть отдельные тестовый и рабочий адреса. Тестовый используется при прослушивании события в редакторе, рабочий регистрируется при публикации сценария. Для рабочего адреса можно настроить аутентификацию. Подробности описаны в документации Webhook.

Почему простой поиск дубля не всегда достаточен

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

Есть и другой случай: CRM создала сделку, но ответ потерялся. Автоматический повтор без сверки способен создать ещё одну. Сохранение внешнего идентификатора в CRM и проверка состояния перед повторной записью помогают разобрать такую ситуацию. Конкретный механизм зависит от API выбранной CRM.

Ошибки должны становиться видимыми

В настройках n8n можно назначить отдельный сценарий ошибок, начинающийся с Error Trigger. Он запускается при неудачном выполнении связанного сценария и позволяет отправить уведомление. Настройка приведена в официальном руководстве по обработке ошибок.

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

Проверка перед запуском

  • Обычная заявка создаёт одну запись с правильными полями и источником.
  • Повтор того же события возвращает прежний результат без второй сделки.
  • Две одновременные доставки также не создают дубль.
  • Недоступная CRM оставляет заявку в списке ожидающих обработки.
  • Потерянный ответ после создания не приводит к повторной сделке.
  • Пустой контакт и неверная версия формата направляются на проверку.
  • После восстановления сервиса можно сверить обращения сайта с записями CRM.

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

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

Как собрать минимальный сценарий

Ниже логическая схема для проекта, в котором сайт уже сохраняет заявки. Названия полей и конкретный способ обращения к CRM нужно адаптировать к её API. Это не готовый импортируемый workflow.

  1. Получение события. Сервер сайта передаёт идентификатор заявки и необходимые поля в защищённый обработчик. Зафиксируйте формат и версию сообщения.
  2. Проверка данных. Разделите корректное событие и запись, требующую ручного разбора. Не подставляйте выдуманный контакт вместо отсутствующего.
  3. Контроль повтора. Зарезервируйте идентификатор обработки атомарно. Уже завершённое событие возвращает сохранённый результат.
  4. Запись в CRM. Создайте или обновите нужную сущность по согласованному правилу. Сохраните полученный CRM ID рядом с исходной заявкой.
  5. Подтверждение. Отметьте событие как доставленное только после проверки результата. Уведомление менеджеру относится к этому этапу.
  6. Исключения. Временный сбой отправляет событие на ограниченный повтор; ошибка полей — ответственному на исправление.

Какие поля полезны в журнале

Минимальная запись: идентификатор обращения, время получения, текущий этап, номер попытки, идентификатор записи CRM и код причины сбоя. Пример учебной записи: «lead-demo-42; ожидает повтор; попытка 2; внешний сервис недоступен». Телефон, секретный URL интеграции и полный текст обращения в такое уведомление добавлять не требуется.

Не смешивайте технический журнал и коммерческий статус. «Передано в CRM» говорит о доставке данных. «Клиенту ответили» и «Сделка выиграна» появляются позже и должны подтверждаться действиями менеджера.

Отдельный сценарий ошибок в n8n

Создайте workflow с первым узлом Error Trigger, сохраните его и выберите в настройке Error workflow основного процесса. После этого проверьте сбой на тестовом сценарии. Подробный порядок указан в документации n8n. Само наличие уведомления не обеспечивает сохранность заявок: хранение входящих событий и контроль повторов проектируются отдельно.