Как построить ИИ-агента в n8n для разбора B2B-заявок, записи в CRM, черновиков ответов и контроля ошибок.
Входящая B2B-заявка редко приходит в удобной форме. Один человек пишет «нужно обучить отдел продаж работе с ИИ», другой прикладывает техническое задание, третий просит прислать КП и не называет ни компанию, ни сроки. Письма попадают в почту, формы — на сайт, часть обращений дублируется в мессенджере. Дальше менеджер читает поток, переносит данные в CRM, назначает ответственного и готовит первый ответ.
Это хорошая задача для ИИ-агента, если понимать границы его работы. БЯМ здесь похожа на стажёра с красным дипломом. Она быстро читает свободный текст, выделяет смысл и готовит черновик. Полномочия на изменение сделки, обещание цены, отправку письма и передачу персональных данных остаются у процесса и у человека.
Рабочая цель такой системы проста. Каждая заявка должна попасть в CRM один раз, с понятным источником, корректным маршрутом, заполненными обязательными полями и черновиком ответа для проверки. Руководитель при этом видит, где агент ошибается, а команда постепенно делает промт и правила точнее.
Базовую механику ИИ-агентов в n8n стоит сначала разобрать в отдельном материале про агентов и n8n. Здесь важнее следующий уровень — как собрать управляемый процесс для входящих B2B-заявок и не получить быстро работающий бардак, который ещё и общается с клиентами.
Где заканчивается обычная автоматизация
Обычная автоматизация действует по жёсткому правилу. Если в форме выбран продукт «корпоративное обучение», заявка создаётся в воронке обучения. Если указан город, поле города копируется в CRM. Если заполнен телефон, система проверяет формат номера. Для таких действий языковая модель не нужна.
ИИ появляется в точке, где нужно понять смысл свободного текста. Например, посетитель написал «у нас пять региональных подразделений, хотим научить руководителей собирать отчёты и не возить данные по почте». В сообщении может не быть слов «Excel», «Power Query» или «корпоративное обучение». Модель всё равно способна предположить тему, выделить признаки запроса и направить карточку в очередь нужной команды.
У этой разницы есть практическое следствие. Внешние действия должны оставаться детерминированными. Модель предлагает категорию и объяснение, а n8n проверяет допустимость значения, выбирает воронку, создаёт карточку и ставит задачу по заранее утверждённым правилам.
Такой подход защищает процесс от двух ошибок. Первая связана с тем, что модель вернула красивый текст вместо нужной структуры. Вторая возникает, когда модель верно поняла обращение, но придумала неподходящее действие. Например, указала высокий приоритет, потому что заметила слово «срочно», хотя для компании это слово не является правилом эскалации.
ИИ-агент нужен там, где сотрудник читает текст и принимает типовое решение. CRM, дедупликация, обязательные поля, статусы и отправка письма остаются обычной автоматизацией. Именно сочетание двух типов логики делает систему полезной в работе, а не только на демонстрации.
Схема обработки заявки
Для первого запуска достаточно следующей цепочки.
Форма или почта → n8n → нормализация → классификация → CRM → черновик ответа → человеческое подтверждение
Форма сайта передаёт данные в webhook. Почта поступает через почтовый триггер. На этом этапе n8n сохраняет исходный текст, источник, время поступления и технический идентификатор. Исходник нужен для разборов ошибок. Если сохранять только результат модели, через неделю уже будет непонятно, почему заявка ушла именно в эту очередь.
После приёма полезно нормализовать входные данные. Email приводится к нижнему регистру, телефон — к единому формату, пустые поля отмечаются отдельно, а тема письма и текст соединяются в одно поле для анализа. Вложения на старте лучше не отдавать модели автоматически. Сначала достаточно названия файла, типа и признака наличия вложения. Содержание документа добавляют в процесс после отдельной проверки рисков и качества извлечения текста.
Дальше работает классификатор. Он получает нормализованную заявку и возвращает строго ограниченный набор полей. Например, тип обращения, направление, приоритет обработки, краткое резюме, список недостающих сведений и уровень уверенности. Результат проходит проверку схемы. Если значение не входит в разрешённый список либо уверенность ниже установленного порога, карточка уходит в очередь ручного разбора.
После этого n8n создаёт лид или сделку в CRM. В карточку нужно записывать исходный текст, технический идентификатор заявки, результат классификации, версию промта и статус проверки. Версия промта особенно важна. Она позволяет увидеть, какое изменение улучшило маршрутизацию, а какое добавило новые ошибки.
Затем отдельный шаг готовит черновик ответа. Он не должен сам отправлять письмо. Для входящих B2B-заявок обычно безопаснее создать задачу менеджеру, приложить черновик и дождаться подтверждения. В n8n есть штатный механизм Human in the Loop, который может приостановить процесс до одобрения или отклонения конкретного действия модели. Его можно настроить для чувствительных операций, включая отправку сообщения или изменение записи. Документация n8n по человеческому подтверждению описывает этот сценарий.
Сначала договоритесь о полях CRM
До настройки модели нужно определить, какое решение она вообще имеет право предлагать. Обычно этой работы избегают, потому что она кажется скучной. На деле она определяет качество всей автоматизации.
| Поле | Что хранит | Кто определяет |
|---|---|---|
| Источник | Форма, email, партнёр, мероприятие | n8n |
| Направление | Обучение, консалтинг, поддержка, другое | Модель и правила |
| Очередь | Конкретная группа обработки | Правила n8n |
| Полнота данных | Достаточно сведений или нужен уточняющий контакт | Модель |
| Статус проверки | Черновик, на проверке, подтверждено, отклонено | Человек и n8n |
Список направлений должен совпадать с тем, как команда реально работает в CRM. Если в воронке есть только «обучение» и «прочее», модель не должна возвращать десять тонких тематических категорий. Полезнее сохранить пояснение в отдельном поле, а статус и маршрут оставить простыми.
Отдельно определите признак дубля. Он может строиться на сочетании email, телефона, домена компании, текста и короткого временного окна. Полного совпадения текста ждать не стоит. Один и тот же человек может сначала оставить форму, а потом через десять минут написать письмо с тем же вопросом.
Дедупликация не должна зависеть от решения БЯМ. Она строится на технических правилах и поиске в CRM. Если найден вероятный дубль, n8n не создаёт новую сделку. Он добавляет заметку к существующей карточке и отправляет её на проверку. Это защищает воронку от двойных задач и от двух писем одному человеку.
Классификатору нужна схема, а не свобода
Свободный текст ответа модели плохо подходит для CRM. Фраза «похоже, это крупный интересный клиент» может быть понятна человеку, но не годится для маршрутизации. Нужен структурированный результат, где каждое поле ограничено.
| Поле | Допустимый результат |
|---|---|
request_type | training, consulting, support, other |
route | sales_team, operations_team, manual_review |
priority | normal, high, manual_review |
summary | Краткое нейтральное резюме до установленной длины |
missing_data | Перечень недостающих сведений |
confidence | Число от 0 до 1 |
После модели должен стоять отдельный валидатор. Он проверяет наличие всех полей, допустимость категории, длину резюме и логическую связность результата. Заявка с request_type, равным training, не должна одновременно получать маршрут operations_team, если такого исключения нет в таблице правил.
Полезно также проверять факты, которые модель могла извлечь из текста. Если она указала название компании, это значение должно присутствовать во входных данных. Если модель дописала предполагаемый бюджет, срок или количество участников, такое поле лучше отбросить. Модель может предполагать, но CRM должна хранить наблюдаемое.
Структурированный вывод уменьшает число технических ошибок, но не отменяет ошибок смысловых. Модель может корректно вернуть JSON и неверно понять запрос. Поэтому проверка схемы нужна вместе с журналом решений и человеческой обратной связью.
Системный промт для маршрутизации
Системный промт — это рабочая инструкция агента. Его не нужно превращать в энциклопедию компании. Модель должна получить ровно те правила, которые влияют на классификацию конкретной заявки.
Хороший промт начинается с роли и границ ответственности. Затем описывает категории, признаки, исключения, формат результата и правила эскалации. В конце полезно добавить несколько анонимизированных примеров, которые показывают похожие на практике обращения.
Ниже шаблон для учебного сценария. Перед запуском его нужно адаптировать к собственной воронке и терминологии CRM.
Роль Ты классифицируешь первичные B2B-заявки для команды корпоративного обучения. Задача Прочитай текст заявки и верни структурированный результат. Не придумывай факты, которых нет в тексте. Не назначай цену, сроки, состав программы и обязательства перед клиентом. Категории training используется для запроса на обучение команды. consulting используется для запроса на настройку процесса или экспертную консультацию. support используется для вопроса по уже действующему проекту. other используется для обращений вне этих категорий. Маршрутизация sales_team выбирай для новых запросов на обучение и консультацию. operations_team выбирай для действующего проекта, если в тексте есть его признаки. manual_review выбирай при нехватке данных, противоречии в тексте или низкой уверенности. Проверка Если в заявке нет контакта, компании или сути задачи, укажи это в missing_data. Если запрос касается договора, цены, гарантий, права или безопасности, выбери manual_review. Не используй сведения из предыдущих заявок и внешние знания. Формат Верни request_type, route, priority, summary, missing_data, confidence и reason. reason содержит короткое объяснение решения только по словам из заявки.
Фраза «не придумывай факты» здесь сама по себе не решает проблему. Она работает вместе с ограниченным форматом и проверкой результата. Важнее другое правило. Каждое значение в CRM должно быть либо получено из заявки, либо рассчитано детерминированным правилом.
Промт нужно тестировать на наборе исторических заявок с известным правильным маршрутом. В набор должны попасть обычные обращения, неполные формы, дубли, смешанные темы, сообщения с эмоциями и запросы, которые должны уйти на ручной разбор. Чем ближе тесты к реальному входящему потоку, тем быстрее обнаружатся ловушки.
Учебный пример хорошо показывает, почему промт дорабатывается итерациями. Допустим, агент распределяет обращения между коммерческой и операционной командами. Фраза «не могу войти в почту с телефона, срочно нужна помощь» попадает к коммерческой группе, потому что модель цепляется за слово «срочно». После проверки команда добавляет правило. Вопросы доступа и поддержки действующего проекта должны идти в операционную очередь, а при отсутствии сведений о проекте — на ручной разбор. Затем этот случай включают в тестовый набор.
Так формируется обратная связь. Ошибка не исправляется общим требованием «будь внимательнее». В промт добавляется конкретное правило, пример или уточнение категории. В статье о рабочих промптах подробно разобрана сама логика постановки задачи модели.
Черновик ответа отделяют от отправки
Черновик первого ответа полезен по двум причинам. Он сокращает время реакции и показывает менеджеру, как модель поняла обращение. Если черновик выглядит странно, ошибку можно заметить до отправки и одновременно увидеть, где сбился классификатор.
В системном промте для черновика нужно зафиксировать несколько ограничений. Модель подтверждает получение заявки, кратко отражает её суть, задаёт только нужные уточняющие вопросы и не обещает цену, сроки, доступность эксперта или юридические условия. Если в заявке не хватает данных, черновик просит их сообщить, а не делает предположения.
Черновик лучше строить по данным, которые уже прошли проверку. В него передают только исходный текст, подтверждённые поля карточки и разрешённые фрагменты справочной информации. Не стоит подмешивать в контекст всю CRM, переписку других клиентов или старые коммерческие предложения. Чем шире и грязнее контекст, тем труднее объяснить источник каждого утверждения.
Галлюцинации у БЯМ остаются свойством технологии. Поэтому полезно давать модели только проверяемые исходные данные и требовать, чтобы она опиралась на них. Этот принцип подробнее разобран в статье о выдуманных фактах нейросетей.
Человеческое подтверждение можно устроить двумя способами. В простом варианте менеджер получает задачу в CRM и вручную отправляет отредактированный ответ. В более связанном варианте n8n отправляет карточку на согласование, ждёт одобрения, отклонения или комментария и только потом выполняет разрешённое действие. Для первых итераций я бы оставил отправку полностью у менеджера. Модель ещё не заслужила автономность только потому, что несколько раз написала приличный текст.
Ошибки нужно разбирать по типам
Ошибка модели и ошибка процесса требуют разного лечения. Если CRM временно не отвечает, бессмысленно менять системный промт. Если модель не отличает запрос на обучение от действующего проекта, повторная отправка в CRM тоже ничего не исправит.
- Ошибки приёма. Не пришёл webhook, письмо не удалось прочитать, вложение имеет неподдерживаемый формат.
- Ошибки данных. Отсутствует контакт, не прошла проверка телефона, модель вернула неполную структуру.
- Ошибки решения. Неверная категория, плохой приоритет, неправильный маршрут или неудачный черновик.
- Ошибки действия. Не создалась сделка, не поставилась задача, отправка ответа остановлена подтверждением или техническим сбоем.
Для первых и четвёртых ошибок нужны повторные попытки, лимиты и уведомления. Для второй группы нужна очередь ручного разбора. Для третьей — метки обратной связи и доработка промта. Все ошибки нельзя лечить одной кнопкой Retry.
Каждой заявке нужен стабильный идентификатор. Он передаётся через весь workflow и записывается в CRM. При повторном запуске n8n сначала проверяет, нет ли уже карточки с таким идентификатором. Это простое правило предотвращает ситуацию, когда после сбоя в CRM появляется три одинаковые сделки.
Отдельный workflow ошибок должен отправлять команде понятное сообщение. В нём достаточно указать идентификатор заявки, шаг сбоя, техническую причину и ссылку на карточку. Сам исходный текст обращения в алёрте лучше не дублировать без необходимости.
Историю выполнений нужно регулярно просматривать. n8n позволяет повторно запускать неуспешные выполнения, включая вариант с сохранёнными данными и текущей версией workflow. Документация по executions описывает этот механизм. Однако повтор разрешён только для идемпотентных шагов. Создание сделки без защиты от дублей к таким шагам не относится.
Данные заявок в журналах требуют отдельного решения владельца процесса. Доступ к выполнениям, состав сохраняемых полей, срок хранения, права на просмотр и порядок работы с вложениями должны быть согласованы с ИБ и юристами компании. Развёртывание n8n само по себе не является таким согласованием. В актуальной документации n8n есть настройки редактирования данных выполнений и аудит их раскрытия, но доступность части возможностей зависит от редакции продукта. Документация по защите execution data.
Обратная связь превращает агента в рабочий инструмент
Менеджер не должен только нажимать «одобрить» или «отклонить». Для каждого вмешательства полезно выбрать причину. Например, неверная категория, неверная очередь, неполные данные, неудачный тон письма или техническая ошибка CRM.
Эти метки дают материал для еженедельного разбора. Руководитель берёт отклонённые заявки, группирует их и отвечает на три вопроса. Какое правило не было описано, какая категория пересекается с другой и нужен ли новый детерминированный фильтр до модели.
В большинстве процессов модель не должна учиться на каждой единичной ошибке сразу. Сначала стоит собрать повторяющийся паттерн. Одна странная заявка может быть исключением, а пять похожих исправлений показывают недостающую инструкцию. После правки промта нужно повторно прогнать тестовый набор и сравнить результаты с предыдущей версией.
| Метрика | Что показывает |
|---|---|
| Доля заявок с корректным первым маршрутом | Точность классификации до вмешательства человека |
| Доля ручного разбора | Насколько часто система честно передаёт сложный случай человеку |
| Доля дублей | Качество технической защиты CRM |
| Время от поступления до первого подтверждённого действия | Скорость обработки входящего потока |
Не стоит подменять качество одной цифрой уверенности модели. Значение confidence показывает внутреннюю оценку конкретного ответа, но не гарантирует правильность. Для руководителя важнее доля случаев, которые менеджеры реально исправили после первого решения агента.
Качественный контур обратной связи делает видимым дрейф процесса. Появилась новая услуга, изменились названия отделов, в заявках стали чаще упоминать другой продукт или добавился канал лидогенерации. Без обновления правил модель будет продолжать отвечать по старой картине мира.
Как запускать без лишнего риска
Начните с теневого режима. Агент получает реальные входящие заявки, строит классификацию и черновик, но не создаёт карточки и ничего не отправляет наружу. Менеджер параллельно работает привычным способом, а команда сравнивает решения.
Когда маршрутизация стала понятной, можно включить создание черновика в CRM. Следующий этап — автоматическое заполнение только безопасных полей, например источника, исходного текста, технического идентификатора и предложенной категории. Изменение воронки, назначение ответственного и отправка ответа всё ещё требуют подтверждения.
Автономные действия появляются последними. Их стоит давать только для узких и хорошо измеряемых случаев. Например, система может поставить внутреннюю задачу в заранее выбранную очередь, если заявка полностью заполнена, категория однозначна и такой сценарий давно не требует ручной коррекции.
У каждого действия должен быть владелец. Руководитель продаж отвечает за маршруты и качество обработки. Операционный владелец отвечает за карточку процесса, статусы и исключения. Технический владелец отвечает за workflow, доступы, мониторинг и восстановление после сбоев. Без этого агент быстро становится ничейным набором кубиков в n8n.
Когда ИИ-агент лучше не подключать
Если форма уже заставляет посетителя выбрать продукт, город, формат и тему обращения, а маршрутизация зависит только от выбранных полей, достаточно обычной автоматизации. Она дешевле в сопровождении и проще в проверке.
Если ошибка в обработке ведёт к финансовому обязательству, юридическому выводу, передаче чувствительных данных или изменению критичной записи, первый шаг должен оставаться у человека. ИИ может подготовить сводку и черновик, но решение должно проходить утверждённый маршрут согласования.
Если у компании нет владельца процесса и критериев правильного ответа, начинать с агента рано. Сначала нужно договориться, как команда различает заявки и куда они должны идти. ИИ не создаёт порядок из отсутствующих правил. Он только быстрее воспроизводит тот порядок, который в него заложили.
Корпоративное обучение по n8n и ИИ-агентам
Для команды, которая хочет собрать такой workflow на своих процессах, подойдёт корпоративное обучение автоматизации и ИИ-агентам на n8n. На практикуме можно разобрать входящие каналы, схему CRM, системный промт, обработку ошибок и безопасный запуск с человеческим подтверждением.