Квалификацию лидов чаще всего хочется отдать машине. Заявок много, большая часть пустая, а разбирать каждую вручную некому. Участник сообщества n8n под ником Jayaprakash_R1 опубликовал в разделе «Built with n8n» воркфлоу, где эту работу делает ИИ-агент. Агент принимает заявку, дополняет её данными, оценивает и сам решает, кому сразу писать письмо, а кого отложить.
Мы разобрали схему по описанию автора. Архитектура собрана грамотно, но в публикации нет ни одной цифры: ни о том, как часто агент ошибается, ни о том, сколько стоит один обработанный лид. Ниже разбираем путь заявки, место, где ИИ заменяет аналитика, и вопросы, которые стоит задать себе до того, как повторять такую автоматизацию обработки лидов у себя.
Почему этот разбор на сайте о производстве контента. Канал эксперта или небольшой компании в итоге приводит заявки. Логика их обработки та же, что в контент-конвейере: приём, обогащение, оценка моделью, развилка. Отличается цена ошибки.
Точка старта: зачем автоматизировать разбор входящих заявок
Автор называет свою аудиторию прямо: B2B SaaS, агентства и рекрутеры. У всех троих заявки приходят потоком, а ценность каждой неочевидна, пока кто-то не посмотрит, что за компания стоит за адресом почты и есть ли у неё бюджет.
Откуда приходят лиды, в описании не сказано. Точка входа одна, это вебхук: адрес, на который форма сайта или другая система отправляет заявку. Есть и намёк на условия задачи. Автор отдельно упоминает логику задержки выполнения «для обработки лидов пачками», значит заявки у него приходят не только по одной.
Чего в исходных условиях нет: объёма в день, бюджета на сервисы, того, как квалификацию делали раньше и сколько времени она занимала. Разбор строится на тексте поста. К нему приложено видео-прохождение на Google Drive, но выводы ниже сделаны по описанию. На момент разбора у публикации 25 просмотров и ни одного ответа, то есть никто из сообщества схему пока не проверял и не комментировал.
Как устроена квалификация лидов в этом воркфлоу
Автор описывает схему как сквозную и автономную: от входящей заявки до записи в CRM и первого письма без участия человека. Путь заявки по его описанию выглядит так.
| Этап | Узлы | Что происходит |
|---|---|---|
| Приём | Webhook | заявка принимается, при пачке включается задержка выполнения |
| Обогащение | Apollo.io | профиль лида дополняется данными через API в реальном времени |
| Оценка | AI Agent | модель оценивает намерение, соответствие бюджету и вероятность конверсии |
| Запись | HubSpot, Airtable | в HubSpot запись создаётся или обновляется, в Airtable пишется журнал |
| Развилка | Switch | лид уходит в одну из трёх веток: горячий, тёплый, холодный |
| Действие | AI Agent с Google Gemini, Gmail, Telegram | письмо, быстрый follow-up или уведомление с отложенной цепочкой |
| Сбой | Error Trigger, Telegram | при ошибке выполнения приходит оповещение |
Два решения здесь стоит отметить отдельно.
Первое: в HubSpot автор делает upsert. Если контакт уже есть, запись обновляется, если нет, создаётся. Повторная заявка от того же человека не плодит дубли. Без этого через месяц CRM превращается в свалку.
Второе: параллельный журнал в Airtable. Автор называет его audit log, журналом проверки. На наш взгляд, это самая ценная деталь схемы. CRM нужна отделу продаж, а журнал нужен тому, кто хочет потом понять, почему агент решил именно так. Без такого следа автономная оценка превращается в чёрный ящик.
Про задержку при пачке заявок автор не объясняет, зачем она. На практике это, скорее всего, защита от лимитов внешних API: Apollo.io и языковая модель вызываются на каждый лид, и сотня заявок разом может в лимиты упереться. Это наше предположение, в посте его нет.
ИИ-агент в n8n: что он оценивает и чего мы не знаем
Работу аналитика здесь делает один узел. Автор называет его AI Qualification Engine и перечисляет три критерия оценки:
- намерение лида, то есть насколько он готов к разговору;
- соответствие бюджету;
- вероятность конверсии.
Создание ИИ-агента в n8n в этой схеме сводится к узлу AI Agent и подключённой к нему модели. В списке узлов они указаны раздельно: AI Agent и Google Gemini Chat Model. В n8n модель подключается к агенту отдельным узлом, поэтому её можно заменить, не перестраивая остальной воркфлоу.
Дальше начинаются пробелы. Gemini в описании прямо упомянут только у второго агента, который работает с горячими лидами. Какой моделью оценивает первый агент, автор не пишет. У поста стоит тег openai, но в списке узлов OpenAI нет. Возможно, первый агент работает на модели OpenAI, возможно, тег остался от другой версии. Из материала это не следует.
Важнее другое: в посте нет промпта, шкалы и порогов. Мы не знаем, во что агент переводит «намерение» и «соответствие бюджету», балл это, категория или текст. Непонятно, где проходит граница между горячим и тёплым лидом. Неизвестно и то, откуда агент берёт сведения о бюджете. Логично предположить, что из данных Apollo.io о компании, но какие поля туда приходят, автор не уточняет.
Для читателя из этого следует практичная вещь. Повторить схему по описанию можно, повторить качество оценки нельзя. Всё качество квалификации живёт в промпте и порогах, а их как раз не показали.
Горячие, тёплые, холодные: маршрутизация после оценки
После оценки узел Switch разводит лиды по трём веткам.
Горячие
Горячий лид уходит ко второму ИИ-агенту на Google Gemini, затем ему отправляется персонализированное письмо через Gmail. Судя по описанию, письмо пишет модель и уходит оно без просмотра человеком.
Тёплые
Тёплым автор обещает «немедленный персонализированный follow-up». Каким каналом он отправляется и кто его пишет, в посте не сказано.
Холодные
Холодные лиды запускают уведомление в Telegram и попадают в отложенную цепочку касаний (drip). Судя по тому, что уведомление стоит именно здесь, человек узнаёт о холодном лиде, а горячий обрабатывается без него.
Здесь у нас с автором расходится логика. Самый дорогой лид в схеме тот, на котором ошибка обходится дороже всего, а письмо ему пишет и отправляет машина. Холодный лид, ошибка на котором почти ничего не стоит, попадает к человеку на глаза. Мы бы сделали наоборот: автоматика сортирует и готовит черновик, а горячему лиду письмо уходит после одного нажатия кнопки.
На том же форуме рядом с этим постом лежит другой подход. Это бесплатный воркфлоу из трёх узлов: вебхук, оценка моделью GPT, отправка в Slack, а между оценкой и действием стоит одобрение человеком. Он проще и медленнее, зато ошибку модели ловят до того, как она дошла до клиента. У нас в заводе принцип тот же: публикация на сайте идёт только после одобрения владельца в превью.
Что получилось
Результат по описанию автора выглядит так: заявка проходит путь от вебхука до CRM и первого контакта без участия человека, ошибки выполнения отслеживаются, решения агента записываются в журнал.
Измеренного результата в посте нет. Таблица «до и после» здесь превращается в список того, о чём автор промолчал.
| Вопрос | Что в материале |
|---|---|
| Сколько лидов в день обрабатывает схема | не указано |
| Сколько времени уходит на один лид | не указано |
| Какая доля оценок совпадает с мнением менеджера | не указано |
| Сколько стоит один лид в API-вызовах | не указано |
| Сколько писем ушло без правки и с каким ответом | не указано |
Для публикации в разделе «Built with n8n» это обычная ситуация: там чаще показывают схему, чем отчитываются цифрами. Но для того, кто решает, внедрять ли такое у себя, именно эти пять строк и важны. Без них разбор говорит, как схема устроена, и ничего не говорит о том, окупается ли она.
Что оказалось сложнее, чем выглядит на схеме
Мы не запускали этот воркфлоу. Сложности ниже вытекают из самой архитектуры, это не отчёт о поломках.
Ошибка оценки не считается ошибкой. Error Trigger срабатывает, когда падает выполнение: не ответил API, сломался узел. Если же модель уверенно назвала холодного лида горячим, воркфлоу отработал успешно, и оповещения не будет. Такой промах найдёт только тот, кто регулярно читает журнал в Airtable. Журнал в схеме есть, а того, кто его читает, в ней нет.
Цена складывается из нескольких счетов. Каждый лид проходит минимум через вызов Apollo.io, вызов модели-оценщика и запись в HubSpot. Горячий лид добавляет к этому второй вызов Gemini и письмо. Цен автор не называет, и мы их не приводим: тарифы всех этих сервисов меняются. До запуска стоит умножить стоимость одного прохода на свой месячный поток заявок.
Персональные данные уходят наружу. Имя, почта и компания лида попадают как минимум к двум внешним сервисам: к поставщику данных и к поставщику модели. Для компании, которая работает с персональными данными по правилам своей страны, это отдельный вопрос, и решать его нужно до запуска.
Две системы учёта расходятся. HubSpot и Airtable обновляются из одного воркфлоу. Но если менеджер поправит запись в CRM руками, журнал об этом не узнает. Для аудита решений агента это не страшно, для любой сводной отчётности уже неприятно.
Набор сервисов не универсален. Apollo.io, HubSpot, Gmail и Gemini подобраны под рынок автора. Тем, кто работает в другой среде, придётся проверить доступность каждого сервиса и, возможно, менять половину узлов. Схема при этом сохранится, а качество обогащения данными будет уже другим.
Кому подойдёт такая схема
Такая автономная квалификация оправдана там, где заявок много, каждая по отдельности стоит недорого, а скорость первого ответа влияет на результат. Под такие условия как раз попадают SaaS, агентства и рекрутинг, которых называет автор. Эксперту с каналом и десятком заявок в неделю полная автономия скорее навредит: заявки проще прочитать самому, а цена одной ошибки слишком высока.
Что из разбора можно забрать к себе:
- Журнал решений рядом с CRM. Даже если всё остальное делается руками, запись «что оценила модель и почему» окупается при первом же споре о потерянном клиенте.
- Upsert вместо создания. Обновление существующей записи вместо новой убирает дубли с первого дня.
- Человек на самой дорогой ветке. Если что-то и оставлять на ручное одобрение, то письмо горячему лиду, а не уведомление о холодном.
- Промпт и пороги до архитектуры. Сначала проверьте на сотне старых заявок, совпадает ли оценка модели с мнением менеджера. Узлы собираются за вечер, а качество оценки упирается в критерии.
- Подсчёт до запуска. Сложите стоимость всех вызовов на один лид и умножьте на месячный поток. Автор этой цифры не дал, её придётся получить самим.
Похожие разборы автоматизаций, где модель принимает решение вместо человека, мы продолжаем в Telegram-канале Content 365.
Источник: Autonomous Lead Qualification & CRM Enrichment - Built with n8n - n8n Community