ИИ-агент для квалификации лидов: как внедрить без риска для продаж
Практическое руководство по ИИ-агенту для первичной квалификации лидов: архитектура, CRM, промпты, контроль качества и безопасный запуск.
ИИ-агент для квалификации лидов полезен не потому, что он «сам продает», а потому что умеет связать текст клиента с данными и действиями в рабочих системах. В документации OpenAI function calling описан как способ подключать модель к внешним данным и действиям приложения: модель может запросить вызов инструмента, приложение выполняет действие, возвращает результат, а затем модель формирует ответ или следующий шаг (https://developers.openai.com/api/docs/guides/function-calling.md). Для отдела продаж это означает простую вещь: агент не должен жить отдельно от CRM, почты, мессенджеров и регламентов. Он должен работать как слой первичной обработки, который читает входящее обращение, задает недостающие вопросы, собирает структуру лида и передает человеку уже подготовленную карточку.
В этой статье разберем, как спроектировать такого агента без магии и без риска для воронки. Речь не о замене менеджера, а о нормальной автоматизации: быстро понять, кто обратился, что человеку нужно, насколько заявка подходит бизнесу, какие данные не хватает и куда ее передать дальше.
Что такое квалификация лидов с ИИ
Квалификация лида — это не один вопрос «готов купить или нет». В нормальном процессе менеджер проверяет контекст: потребность, срочность, бюджетный диапазон, регион, роль человека, канал обращения, историю контактов, ограничения и следующий шаг. ИИ-агент помогает собрать этот контекст быстрее, но не должен принимать необратимые решения без правил.
Где агент действительно помогает
Самый практичный сценарий — первичная сортировка входящих обращений. Клиент пишет в форму, чат, Telegram, WhatsApp, email или звонит через виджет, а команда получает поток сообщений разного качества. В одном сообщении есть конкретный запрос, в другом — одна фраза «сколько стоит», в третьем — длинное описание проблемы без контактных данных.
Агент может:
- Определить тему обращения.
- Вытащить из текста имя, компанию, телефон, email, город, продукт, задачу и срочность.
- Понять, каких данных не хватает.
- Задать уточняющий вопрос по шаблону.
- Присвоить обращению статус: новый лид, повторный контакт, поддержка, спам, партнерство, вакансия.
- Создать или обновить карточку в CRM.
- Передать менеджеру краткое резюме и рекомендуемый следующий шаг.
Такой агент особенно полезен там, где входящие заявки похожи по структуре, но приходят в свободной форме. Например: агентство, онлайн-школа, B2B-сервис, интегратор, юридическая фирма, клиника, производственная компания, сервис ремонта, франшиза.
Где агенту нельзя давать полную свободу
Ошибкой будет поручить агенту обещать цену, скидку, сроки поставки, юридический вывод или финансовую гарантию, если эти ответы не берутся из проверенной базы. Модель может хорошо сформулировать текст, но бизнес-обязательства должны идти из CRM, прайс-листа, склада, договора, политики компании или ответа ответственного сотрудника.
Хорошая граница такая: агент собирает данные, классифицирует, готовит черновик и запускает безопасные действия. Человек подтверждает нестандартные решения, коммерческие условия, отказ клиенту, возврат денег, договоренности с риском и любые обещания, которые компания потом обязана выполнить.
Архитектура: из чего состоит рабочий агент
Внедрение лучше начинать не с выбора модели, а с карты процесса. Если процесс не описан, агент будет автоматизировать хаос. Если процесс понятен, модель становится одним из узлов в системе.
Входящие каналы
Сначала перечислите каналы, откуда реально приходят лиды. Обычно это сайт, формы, мессенджеры, почта, звонки, реклама и личные сообщения. Для первой версии стоит взять один канал с понятным потоком: например, заявки с сайта или входящие письма на общий адрес.
Не надо сразу подключать все источники. В нескольких каналах разные форматы сообщений, разные ожидания клиента и разные правила ответа. Лучше довести один поток до стабильной работы, а потом масштабировать.
Оркестратор
Оркестратор — это слой, который принимает событие, вызывает модель, отправляет запросы в CRM и решает, что делать дальше. Его можно писать в коде, собирать в low-code или использовать workflow-платформу.
n8n подходит для такого сценария, потому что в документации есть отдельный AI Agent node, а также указано, что к AI Agent node нужно подключить как минимум один tool sub-node (https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.agent/). Это важная мысль: агент ценен не как чат сам по себе, а как узел, который может обращаться к инструментам.
Если команда уже использует n8n, Make, Zapier или собственный backend, не обязательно менять инфраструктуру. Важнее, чтобы оркестратор умел логировать шаги, повторять запросы при сбоях, ограничивать права агента и отправлять спорные случаи человеку.
Модель и инструменты
Модель получает инструкцию, контекст и список доступных инструментов. Инструменты — это не обязательно «умные» функции. Это могут быть простые действия: найти контакт по телефону, создать сделку, добавить заметку, отправить внутреннее уведомление, проверить справочник продуктов.
OpenAI описывает tools как функциональность, которую приложение дает модели; модель может вернуть tool call, а приложение уже выполняет код на своей стороне (https://developers.openai.com/api/docs/guides/function-calling.md). Для бизнеса это удобно: модель не получает прямой доступ ко всей CRM. Она только просит выполнить заранее описанное действие, а приложение проверяет входные данные и права.
CRM и карточка лида
CRM должна оставаться источником правды. Если агент что-то понял из сообщения клиента, это надо записывать в CRM как структурированные поля, заметку или задачу, а не хранить только в переписке с моделью.
В документации amoCRM описаны методы для работы со сделками: получение списка сделок через GET /api/v4/leads, добавление через POST /api/v4/leads, редактирование через PATCH /api/v4/leads (https://www.amocrm.ru/developers/content/crm_platform/leads-api). Это пример того, как агент можно связать с CRM через API: он не «помнит» лид в себе, а передает данные туда, где работает отдел продаж.
Для похожего подхода можно посмотреть материал про интеграцию AI с 1C и amoCRM и статью про AI-автоматизацию входящих заявок.
Какие данные собирать при квалификации
Не стоит заставлять клиента отвечать на длинную анкету. Агент должен извлекать максимум из уже написанного текста и спрашивать только то, что реально влияет на следующий шаг.
Минимальный набор полей
Для первой версии обычно достаточно таких полей:
| Поле | Зачем нужно | Как использовать |
|---|---|---|
| Имя | Персональный ответ | Передать менеджеру и использовать в обращении |
| Контакт | Возможность связаться | Телефон, email или мессенджер |
| Компания или роль | Понимание контекста | B2B, частное лицо, партнер, подрядчик |
| Запрос | Суть потребности | Классификация и подбор сценария |
| Продукт или услуга | Маршрутизация | Передать нужному менеджеру или команде |
| Срочность | Приоритет | Выделить обращения, где нужен быстрый ответ |
| Источник | Аналитика канала | Оценивать качество входящего потока |
| Следующий шаг | Управление процессом | Звонок, письмо, КП, демо, уточнение |
Этот набор можно расширять, но сначала проверьте, какие поля менеджеры действительно заполняют и используют. Если поле не влияет на действие, оно часто превращается в шум.
Признаки качества лида
Качество лида лучше описывать правилами, а не общим словом «горячий». Например:
- Запрос относится к продукту компании.
- Есть контакт для связи.
- Человек описал задачу или проблему.
- Понятно, какой следующий шаг нужен.
- Нет явных признаков спама, вакансии или нерелевантного предложения.
Агент может выставлять не «оценку в баллах», а понятный статус: подходит, нужно уточнение, передать в поддержку, нерелевантно, проверить человеком. Такой статус легче объяснить менеджеру и проще отлаживать.
Как формулировать уточняющие вопросы
Плохой агент сразу задает много вопросов и звучит как анкета. Хороший агент выбирает один следующий вопрос, который сильнее всего помогает продвинуть сделку.
Например, если клиент написал: «Нужна автоматизация заявок с сайта», агент может спросить: «Подскажите, куда сейчас попадают заявки: в CRM, почту, таблицу или мессенджер?» Это конкретный вопрос, который помогает понять интеграцию и не требует от клиента длинного ответа.
Если клиент написал только «сколько стоит», агент не должен выдумывать цену. Он может попросить контекст: «Чтобы сориентировать по формату, напишите, пожалуйста, что хотите автоматизировать и какие каналы заявок есть сейчас». Если в компании есть утвержденный прайс, агент может дать ссылку или диапазон только из проверенного источника, а не из памяти модели.
Как настроить промпт и правила
Промпт для бизнес-агента должен быть похож на регламент, а не на вдохновляющее описание роли. Чем меньше неопределенности, тем легче проверять результат.
Роль агента
Опишите роль коротко: агент первично обрабатывает входящие обращения, извлекает данные, классифицирует лиды, задает уточняющие вопросы и готовит резюме для менеджера. Отдельно пропишите, что агент не обещает цены, сроки, скидки, юридические выводы и нестандартные условия без подтвержденного источника.
В инструкции полезно явно указать тон: нейтральный, вежливый, без давления, без канцелярита. Для предпринимательского блога и B2B-продаж это особенно важно: клиент должен чувствовать, что с ним разговаривают нормально, а не прогоняют через робота.
Схема ответа
Для передачи данных в CRM лучше использовать структурированный формат. В документации OpenAI Structured Outputs описаны как возможность заставить модель возвращать ответы по заданной JSON Schema; там же сказано, что Structured Outputs обеспечивают соответствие схеме и рекомендуются вместо JSON mode, когда это возможно (https://developers.openai.com/api/docs/guides/structured-outputs.md).
Для квалификации лида можно задать схему вроде:
{
"lead_type": "new_lead | support | partnership | spam | unclear",
"need": "short summary",
"missing_fields": ["phone", "company"],
"next_question": "one question for the client",
"manager_summary": "short internal note",
"risk_flags": ["price_request", "legal_question"]
}
Смысл не в красоте JSON, а в управляемости. CRM, таблица или workflow получают предсказуемые поля. Если поле пустое, система знает, что спросить. Если есть risk_flags, заявка уходит человеку.
Правила запретов
В промпте стоит выделить отдельный блок запретов:
- Не выдумывать цены, наличие, сроки и условия.
- Не обещать скидку.
- Не закрывать обращение как нерелевантное без причины.
- Не удалять и не перезаписывать данные клиента.
- Не отправлять внешнее сообщение, если статус не прошел проверку.
- Не использовать персональные данные вне сценария обработки заявки.
Эти запреты лучше дублировать не только в промпте, но и в коде. Если инструмент send_message_to_client отсутствует, агент физически не сможет отправить сообщение. Если инструмент delete_lead не создан, он не удалит карточку. Это надежнее, чем просить модель «быть осторожной».
Сценарий внедрения по шагам
Ниже практический план, который можно пройти без большой разработки. Он подходит для малого и среднего бизнеса, где уже есть CRM или хотя бы понятный список заявок.
Шаг 1. Выберите один поток
Начните с одного типа входящих обращений. Например: заявки с формы «получить консультацию». Не смешивайте на старте продажи, поддержку, вакансии, партнерства и жалобы. Чем чище поток, тем быстрее станет понятно, где агент ошибается.
Соберите несколько десятков реальных сообщений из этого канала. Уберите лишние персональные данные, если используете примеры для настройки. Разметьте руками: тема, статус, нужные поля, хороший следующий вопрос, итоговый маршрут.
Шаг 2. Опишите статусы
Минимальный набор статусов:
new_lead— потенциальная продажа.need_more_info— не хватает данных.existing_client— похоже на текущего клиента.support— вопрос поддержки.partnership— партнерское предложение.spam— мусорное обращение.human_review— нужна проверка человека.
Не пытайтесь сразу создать сложную шкалу. Сначала важна точность маршрутизации: нужные обращения должны попадать нужным людям, а спорные — не теряться.
Шаг 3. Создайте инструменты
Для первой версии достаточно нескольких инструментов:
find_contact— поиск контакта по телефону или email.create_lead— создание сделки или лида.update_lead— обновление полей.add_note— запись резюме в карточку.notify_manager— внутреннее уведомление.request_human_review— постановка задачи на проверку.
Каждый инструмент должен иметь узкие права. Например, update_lead может менять только разрешенные поля, а не всю карточку. notify_manager отправляет сообщение только во внутренний канал. create_lead проверяет обязательные поля и не создает дубль, если контакт уже найден.
Шаг 4. Настройте журнал
Логи нужны не для красоты, а для разбора ошибок. Сохраняйте входное сообщение, результат классификации, вызванные инструменты, итоговый статус и причину передачи человеку. Если клиент получил внешний ответ, храните текст ответа и источник шаблона.
Внутренний журнал помогает отвечать на вопросы: почему агент решил, что это поддержка; почему спросил именно это; почему создал новую сделку; почему не отправил менеджеру. Без журнала отладка быстро превращается в спор мнений.
Шаг 5. Запустите в режиме ассистента
Первый запуск лучше делать без автоматических ответов клиенту. Агент готовит карточку, резюме и черновик вопроса, а менеджер нажимает «отправить» или правит текст. Так команда увидит качество работы без риска испортить коммуникацию.
После нескольких циклов можно разрешить агенту отправлять только безопасные вопросы: например, уточнить канал заявок, попросить контакт, спросить удобное время для связи. Все, что касается цены, договора, претензий и нестандартных условий, оставьте человеку.
Подробнее о похожей логике можно прочитать в статье про AI-агента для заявок без риска и материале про AI-агента с контрольными точками.
Контроль качества и метрики без фантазий
Метрики стоит вводить только те, которые вы реально можете посчитать из CRM и журнала. Не надо обещать себе рост продаж из воздуха. Сначала измеряйте качество процесса.
Что смотреть каждую неделю
Полезные показатели:
- Доля заявок, где агент правильно определил тип обращения.
- Доля заявок, где агент нашел или создал правильную карточку.
- Доля обращений, отправленных на проверку человеку.
- Частые причины ручной проверки.
- Поля, которые клиенты чаще всего не указывают.
- Вопросы агента, после которых клиент отвечает.
- Ошибки маршрутизации.
Эти показатели не требуют публичных отраслевых цифр. Они берутся из вашего процесса и помогают улучшать конкретную систему.
Как проверять качество выборкой
Раз в неделю возьмите случайную выборку обработанных обращений и сравните решение агента с решением опытного менеджера. Важно смотреть не только финальный статус, но и объяснение: что агент счел главным, какие поля заполнил, какой вопрос предложил.
Если ошибка повторяется, не спешите менять модель. Часто причина в плохом регламенте: непонятные статусы, конфликтующие правила, устаревшие шаблоны, дубли в CRM, разные ожидания у менеджеров.
Когда расширять автоматизацию
Расширяйте права агента постепенно. Сначала он читает и резюмирует. Потом создает черновики. Затем записывает заметки в CRM. После этого создает сделки в ограниченном сценарии. Только потом можно разрешать простые внешние ответы.
Если на каком-то этапе растет число ручных исправлений, возвращайтесь к правилам и тестовым примерам. Автоматизация должна снижать нагрузку, а не создавать новый слой контроля ради контроля.
Частые ошибки при внедрении
Агенту дают слишком широкую задачу
Фраза «обрабатывай заявки» звучит понятно человеку, но слишком широка для системы. Для агента нужно разложить задачу на действия: классифицируй, извлеки поля, проверь дубль, создай заметку, предложи следующий вопрос, передай менеджеру.
Нет источника правды
Если цены лежат в одном документе, условия — в другом, менеджеры отвечают по памяти, а CRM заполняется нерегулярно, агент будет только подсвечивать этот беспорядок. Сначала определите, откуда брать проверенную информацию.
Слишком много внешних ответов
Автоматические сообщения клиенту должны появляться после проверки. Иначе можно быстро получить вежливого, но вредного бота: он отвечает гладко, но не всегда по правилам компании.
Нет обработки спорных случаев
У агента должен быть статус human_review. Это не провал автоматизации, а нормальная защита. Если заявка непонятная, конфликтная, юридически чувствительная или связана с деньгами, лучше передать ее человеку.
Не учитывается повторный клиент
Повторные обращения часто важнее новых. Агент должен искать контакт в CRM до создания новой сделки. Иначе появятся дубли, менеджеры потеряют историю, а аналитика станет грязной.
Частые вопросы
Можно ли полностью заменить менеджера по входящим заявкам?
В большинстве компаний разумнее начинать не с замены, а с ассистента для менеджера. Агент берет на себя первичную структуру, поиск данных, резюме и простые уточнения. Решения с коммерческим или репутационным риском остаются у человека.
Нужен ли n8n, чтобы сделать такого агента?
Нет, это не обязательное условие. n8n удобен как workflow-платформа, особенно если команда уже использует визуальные сценарии и интеграции. Но ту же архитектуру можно собрать на собственном backend или в другой системе автоматизации.
Что лучше: один большой промпт или набор инструментов?
Лучше сочетание. Промпт описывает роль, правила и формат результата. Инструменты ограничивают реальные действия: найти контакт, создать сделку, добавить заметку, отправить внутреннее уведомление. Чем важнее действие, тем строже должен быть инструмент.
Как не допустить выдуманных данных в CRM?
Не просите модель заполнять факты, которых нет во входном сообщении или справочнике. В схеме ответа разделяйте поля «извлечено из сообщения», «найдено в CRM» и «нужно уточнить». Если данных нет, агент должен оставлять поле пустым и задавать вопрос.
Что делать с персональными данными?
Собирайте только те данные, которые нужны для обработки заявки, ограничивайте доступы и храните логи в понятном месте. Агент не должен использовать контакты клиента для сторонних задач и не должен отправлять данные в каналы, которые не предусмотрены процессом.
Когда можно включать автоответ клиенту?
Когда агент стабильно классифицирует обращения, корректно заполняет карточки и не путает рискованные сценарии с обычными. Начинайте с коротких безопасных уточнений и оставляйте человеку коммерческие условия, конфликтные ситуации и нестандартные запросы.
Итог
ИИ-агент для квалификации лидов — это не «умный продавец вместо отдела продаж», а аккуратный слой автоматизации между входящим сообщением и CRM. Он читает обращение, выделяет структуру, проверяет недостающие данные, создает или обновляет карточку, готовит резюме и передает человеку то, что требует решения.
Самый надежный путь внедрения: выбрать один поток заявок, описать статусы, подключить узкие инструменты, записывать все шаги в журнал и запускать агента сначала в режиме ассистента. Когда система показывает стабильное качество, можно постепенно добавлять автоматические действия.
Главный принцип простой: модель формулирует и помогает выбирать следующий шаг, но проверенные данные и реальные действия должны идти через инструменты, CRM и правила компании. Тогда автоматизация не подменяет процесс, а делает его быстрее и чище.
Кирилл Пшинник
Сооснователь и CEO «Зерокодера», эксперт Forbes по EdTech и AI, лектор МФТИ и Иннополиса. Главный редактор GPTmag.
Все материалы автора →
Дискуссия
Что вы думаете?
Поделитесь опытом, расскажите, как у вас решается похожая задача, или задайте вопрос — я лично читаю все комментарии и отвечаю.