Если заявка появилась в 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 подготовьте названия систем, обезличенный пример заявки, правила назначения менеджеров и допустимую задержку доставки. По этим данным можно выбрать подходящую схему и составить проверяемое задание.