Собираю связку n8n и ИИ-агентов для клиентов, у которых заявки идут из нескольких каналов сразу: форма на сайте, заказ в интернет-магазине, сообщения в Telegram. Задача обычно одна: заявка должна долетать до нужного менеджера с уже готовой классификацией, а не лежать в общей куче до тех пор, пока кто-то не откроет почту. На бумаге схема простая: вебхук, обработка, запись в CRM. На практике часть узлов в такой цепочке окупается уже на первой неделе, а часть на объёме начинает сыпать дублями и зависшими заявками. Ниже разбираю рабочий сценарий целиком и показываю, где автоматизация в n8n экономит время, а где дешевле написать код руками.
Зачем связывать n8n и ИИ-агентов для обработки заявок
Ручная сортировка заявок это узкое место почти в любой компании, где заявки идут не из одного источника. Менеджер открывает почту, потом CRM, потом Telegram-чат, и в каждом канале свой формат: где-то просто текст, где-то JSON с заказом, где-то голосовое сообщение. ИИ-агент внутри сценария берёт на себя рутину: читает текст заявки, определяет тему и приоритет, при необходимости сразу готовит черновик ответа. n8n в этой связке работает диспетчером, принимает данные из разных источников, прогоняет их через агента по одной и той же логике и раскладывает результат туда, где с ним будут работать люди.
По моей практике самый заметный эффект дают не сложные сценарии с десятками узлов, а простые: одна точка входа, один вызов ИИ-агента для классификации, запись в CRM и уведомление ответственному. Чем больше веток и условий добавляется сверху, тем выше шанс, что сценарий развалится именно в тот момент, когда заявок стало много и разбираться в логах некогда.
Собираю сценарий: от вебхука заявки до записи в CRM
Разберу сценарий на примере заявки с сайта на Tilda и заказа из WooCommerce, у обоих источников есть встроенная отправка данных на внешний адрес, и это сильно упрощает первый узел.
Триггер: вебхук с сайта или из заказа
У форм на Tilda есть интеграция с отправкой данных на вебхук, у WooCommerce, вебхуки на события заказа через встроенный REST API. В n8n оба случая начинаются с ноды Webhook: она принимает POST-запрос и отдаёт сценарию JSON с данными заявки. Здесь же ставлю первую проверку: есть ли обязательные поля (имя, телефон или email), и сразу отсекаю пустые или тестовые запросы, чтобы не гонять их через ИИ-агента впустую.
ИИ-агент классифицирует и готовит ответ
Дальше нода HTTP Request дёргает Claude API с промптом: описание заявки плюс список тем и приоритетов, которые нужно вернуть в структурированном виде. Агент определяет, к какому отделу относится заявка, насколько она срочная, и формирует короткий черновик ответа менеджеру. Важно жёстко задать формат ответа, фиксированный JSON с заранее оговорёнными полями, иначе узлы, которые разбирают этот ответ дальше по цепочке, будут падать на каждой второй заявке, где модель чуть отступила от формата.
Запись результата и уведомление
Результат классификации записываю в CRM, у меня это обычно Bitrix24 или amoCRM, в зависимости от того, что уже использует клиент, и параллельно отправляю уведомление ответственному менеджеру в Telegram через нативную ноду Telegram. Контакты и историю заявок принципиально храню в CRM на серверах в России, а не в Google Таблицах: если в заявке есть телефон или email, это персональные данные, и хранить их в зарубежном облаке лишний юридический риск.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Где автоматизация в n8n реально экономит
Из практики видно, какие узлы окупаются быстрее всего:
- Классификация и приоритизация заявок: раньше это делал человек глазами, теперь агент раскладывает заявки по темам за секунды, и менеджер сразу видит, что горит, а что может подождать.
- Объединение каналов в один сценарий: вместо трёх отдельных интеграций (сайт, магазин, Telegram) один сценарий с несколькими триггерами и общей логикой обработки.
- Черновик ответа: агент не отвечает клиенту сам, но готовит текст, который менеджер за пару секунд проверяет и отправляет, а не пишет с нуля.
- Уведомления в реальном времени: вместо того чтобы проверять почту, менеджер получает сообщение в Telegram с уже готовой сводкой по заявке.
По моей практике заявки, которые раньше час висели в общем ящике, теперь долетают до нужного человека за пару минут, просто потому что между поступлением заявки и уведомлением менеджеру больше нет ручного шага.
Что ломается, когда заявок становится много
Пока заявок десяток в день, сценарий работает без сюрпризов. Проблемы всплывают на объёме, и вот какие я встречал чаще всего.
Вебхук ждёт ответ от ИИ-агента и не успевает
Если нода Webhook настроена ждать, пока весь сценарий, включая вызов Claude API, отработает, и только потом отвечать вызывающей стороне, то при задержке ответа от модели сайт или магазин, отправивший заявку, может не дождаться ответа и отправить её повторно. На выходе дубли заявок в CRM. Решение простое: отвечать вебхуку сразу, в режиме немедленного ответа, а обработку через ИИ-агента запускать уже после этого, асинхронно.
Лимиты и ошибки API под нагрузкой
В пиковые часы запросы к Claude API иногда упираются в ограничения по частоте запросов, и нода HTTP Request просто падает с ошибкой. Без настроенных повторных попыток с паузой между ними такая заявка вылетает из сценария молча, если не подключён отдельный workflow для обработки ошибок.
История выполнений раздувает базу
n8n хранит данные по каждому запуску сценария, и на потоке в сотни заявок в день эта история быстро разрастается, замедляя интерфейс и сам сервер. Нужно заранее настроить автоматическую очистку старых выполнений, иначе через пару месяцев открывать список запусков станет неприятно.
Один сбойный узел останавливает всю цепочку
Если в заявке пришло что-то нестандартное, например телефон в неожиданном формате, и это ломает один из узлов, по умолчанию сценарий на этом останавливается. Без включённой опции продолжения при ошибке или отдельного обработчика ошибок заявка просто теряется, и никто об этом не узнает, пока клиент не напишет второй раз.
Какие узлы дешевле переписать обычным кодом
n8n отлично справляется, пока логика укладывается в цепочку из вебхука, пары условий и вызова внешнего API. Когда сценарий обрастает вложенными IF-нодами, циклами и кастомной обработкой ошибок, визуальный редактор начинает мешать, а не помогать: каждое изменение приходится тестировать вручную, кликая по узлам.
Небольшую логику, дедупликацию заявок по телефону, нормализацию номера, сборку сообщения для CRM, оставляю прямо в n8n через ноду Code на JavaScript в режиме Run Once for All Items:
const seen = new Set();
return $input.all().filter(item => {
const phone = (item.json.phone || '').replace(/\D/g, '');
if (!phone || seen.has(phone)) return false;
seen.add(phone);
return true;
});А вот что обычно выгоднее переписать обычным кодом, а не собирать в n8n:
| Задача | Что выгоднее |
|---|---|
| Приём одного вебхука и запись в свою базу без ветвления | Компактный обработчик на хостинге сайта вместо отдельного сценария и сервера под n8n |
| Парсинг большого объёма страниц или файлов перед отправкой в CRM | Скрипт на Python: меньше узлов, проще логировать и перезапускать частями |
| Сложная цепочка условий с десятками веток | Обычный код с тестами вместо визуального сценария, который сложно ревьюить |
| Классификация заявки, разбор ответа модели, короткие трансформации | Остаётся в n8n, здесь визуальный сценарий нагляднее кода |
Граница простая: пока в сценарии одна точка входа, пара условий и вызов ИИ-агента, n8n экономит время на сборке и правках. Как только логика превращается в десятки узлов с попытками эмулировать циклы и обработку ошибок, которые в обычном коде решаются в три строки, дешевле вынести этот кусок в отдельный скрипт и вызывать его из сценария по HTTP.
Сколько стоит собрать такую автоматизацию
Цена зависит от того, что уже есть у клиента и сколько источников заявок нужно свести в один сценарий.
Базовую автоматизацию в n8n, вебхук, пара условий, запись в CRM и уведомление, собираю от 25 000 ₽. Если нужен полноценный ИИ-агент с классификацией через Claude API и, при необходимости, базой знаний для подготовки ответов, это уже AI-интеграция, и цена стартует от 50 000 ₽. Отдельный скрипт на Python для парсинга или обработки данных, который дешевле держать вне n8n, оцениваю от 20 000 ₽. Дальнейшее сопровождение сценария, от 15 000 ₽ в месяц, разовая доработка или консультация по уже собранной автоматизации, от 3 000 ₽ за час работы.
n8n регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.
Частые вопросы
Нужен ли отдельный сервер для n8n
Для self-hosted n8n нужен отдельный сервер (VPS), который придётся настраивать, обновлять и оплачивать ежемесячно, на обычном хостинге сайта такой сценарий не запустить. Если поток заявок небольшой и не хочется заниматься администрированием, проще начать с облачной версии n8n без своего сервера, а про свой VPS думать, когда сценариев станет много и захочется полного контроля над инфраструктурой.
Можно ли использовать n8n без ИИ-агента, просто для автоматизации заявок
Да, и часто это разумный первый шаг. Сценарий «вебхук, условие, запись в CRM, уведомление» прекрасно работает и без вызова языковой модели, если заявки не нужно классифицировать по смыслу, а достаточно разложить по простым правилам, например по типу товара или региону. ИИ-агента добавляю, когда правилами уже не обойтись: заявки текстовые, разнородные, и нужно понимать их содержание, а не просто сверять поля.
Что делать, если n8n тормозит на большом потоке заявок
Сначала проверяю три вещи: не ждёт ли вебхук синхронного ответа от ИИ-агента, настроена ли автоматическая очистка истории выполнений и стоят ли повторные попытки на вызовах к внешним API. В большинстве случаев эти три настройки снимают тормоза без переезда на более сложную инфраструктуру. Если поток заявок продолжает расти, следующий шаг, режим очереди с отдельными обработчиками, но это уже дополнительная инфраструктура, которую нужно осознанно разворачивать и содержать.
Можно ли хранить заявки клиентов в Google Таблицах, чтобы не платить за CRM
Если в заявке есть телефон, email или другие персональные данные, по закону они должны храниться на серверах в России, а не в зарубежном облачном сервисе. Для рабочего сценария использую CRM или базу данных на сервере в РФ, это и безопаснее с юридической точки зрения, и удобнее для дальнейшей автоматизации, чем таблица, из которой данные потом придётся куда-то переносить.