1. Выберите место, где хранится заявка
Если обращения одновременно живут в почте, личном Telegram менеджера и таблице, общего состояния у них нет. Сначала определите основную систему учёта. Для отдела продаж это часто CRM, но решение зависит от объёма и процесса.
Уведомление в мессенджере удобно для скорости реакции. Оно не должно становиться единственной записью о клиенте. Из уведомления сотрудник должен понимать, где открыть и продолжить работу с обращением.
2. Согласуйте обязательные поля
Не стоит собирать все сведения на первом шаге. Оставьте данные, без которых менеджер не может связаться с человеком или понять запрос. Источник обращения сохраняйте отдельно от текста сообщения.
Для каждого поля определите правила: что делать с пустым телефоном, нестандартным номером или неизвестной услугой. Неполная заявка может нуждаться в ручном разборе, а не в молчаливом удалении.
- Идентификатор обращения.
- Контакт и удобный способ связи.
- Текст задачи или выбранная услуга.
- Источник и рекламные метки, если они доступны.
- Время получения и ответственный.
3. Решите, что считать дублем
Человек может дважды отправить форму или вернуться с новой задачей. Совпадение телефона не всегда означает одинаковое обращение. Правило зависит от бизнеса: обновлять карточку, добавлять новую сделку или передавать на проверку.
Отдельно учитывайте техническую повторную отправку после сбоя. Идентификатор события помогает отличить её от нового обращения. Без такой проверки повторная попытка может создать две сделки.
4. Предусмотрите недоступность сервисов
CRM, почта или внешний API могут временно не отвечать. Для такого случая нужны запись ошибки, уведомление и правило повторной обработки. Сам факт использования n8n не настраивает это автоматически.
В n8n можно назначить отдельный сценарий обработки ошибок и просматривать выполнения. Как именно повторить действие и не создать дубль, нужно продумать в логике проекта. Документация инструмента описывает механизм уведомлений, но бизнес-правила остаются вашей задачей.
5. Пройдите весь путь заявки перед запуском
Отправьте обычное обращение, повторите его, уберите обязательное поле и проверьте ситуацию с недоступной CRM. Затем откройте результат глазами менеджера: хватает ли сведений, понятен ли следующий шаг, виден ли источник.
После запуска сравнивайте число обращений у источника и в системе учёта. Следите за необработанными ошибками и временем до первого действия сотрудника. Доставка события и работа с клиентом являются разными этапами.
- Есть ли запись при каждом новом обращении?
- Что происходит после повторной отправки?
- Кто узнает о сбое?
- Как найти обращение, которое требует ручного разбора?
- Кто отвечает за обновление доступа к сервисам?
Пример из практики
В Minder я связывал CRM, автоматизацию, ИИ и привлечение клиентов для проекта недвижимости в Черногории. Такая работа требует одновременно смотреть на рекламу и дальнейшую обработку обращения. Подробности моей роли собраны в кейсе.
Начать обсуждение можно со списка источников заявок и одной схемы: откуда пришло обращение, куда попало и кто должен его обработать.
Источники и документация
Источники проверены 2026-10-13. Условия сервисов проверяйте перед внедрением.