GPTmag GPTmag
Автоматизация

AI-классификатор заявок в CRM: как собрать процесс на n8n

Практическая схема AI-классификатора входящих заявок: n8n, CRM, уведомления, ручная проверка и контроль качества без опасного автопилота.

Кирилл Пшинник Кирилл Пшинник 16 минут

Входящие заявки редко ломают бизнес из-за одного плохого ответа. Чаще проблема тише: заявки приходят из разных каналов, менеджеры вручную разбирают смысл обращения, часть лидов получает поздний ответ, а руководитель видит хаос уже после факта. Практичный способ навести порядок — поставить между каналами и CRM AI-классификатор: он читает текст заявки, определяет тип обращения, срочность, следующий шаг и передает результат в CRM или в чат менеджера.

Эту схему удобно собирать на n8n, потому что официальная документация n8n описывает платформу как инструмент для workflow automation and integrations: https://docs.n8n.io/. Для российских команд логично подключать CRM через REST API Битрикс24, если компания уже работает в Битрикс24; официальный справочник находится на https://apidocs.bitrix24.ru/. Для быстрых уведомлений можно использовать Telegram Bot API, который сам Telegram описывает как HTTP-based interface: https://core.telegram.org/bots/api.

Важно: это не статья про «заменить отдел продаж нейросетью». Для малого и среднего бизнеса надежнее начать с классификации, подсказок и контрольных точек. AI помогает разложить входящий поток, но ответ клиенту, изменение статуса сделки и обещания по срокам лучше оставлять человеку, пока процесс не проверен на реальных заявках.

Что такое AI-классификатор заявок

AI-классификатор заявок — это связка из формы, мессенджера, почты или сайта, сценария автоматизации, языковой модели и CRM. На вход он получает текст клиента. На выходе отдает структурированное решение: категория заявки, краткое резюме, возможная потребность, уровень срочности, рекомендуемый ответ и действие для менеджера.

Чем он отличается от чат-бота

Чат-бот разговаривает с клиентом напрямую. Классификатор может вообще не писать клиенту. Он работает внутри команды: помогает быстрее понять, что пришло, кому это передать и как не потерять важную деталь.

Это принципиальная разница. Когда бот отвечает клиенту сам, ошибка сразу видна наружу. Когда классификатор ошибается внутри процесса, менеджер может поправить категорию, текст ответа или следующий шаг до отправки. Поэтому такой формат лучше подходит для первого внедрения AI в продажах, сервисе и операционной поддержке.

Какие заявки можно классифицировать

Начинать стоит с текстовых заявок, где клиент уже описал проблему или запрос. Подход хорошо работает для:

  1. заявок с сайта;
  2. входящих писем;
  3. сообщений из Telegram-бота;
  4. обращений из формы обратной связи;
  5. заявок из рекламных квизов;
  6. сервисных обращений после покупки;
  7. запросов на консультацию.

Не стоит начинать с голосовых звонков, конфликтных претензий, юридически значимых обещаний и медицинских или финансовых рекомендаций. Там выше цена ошибки, а значит сначала нужен отдельный регламент, запись решений и жесткое участие человека.

Какой результат должен получить менеджер

Хороший классификатор не просто пишет «горячий лид». Он выдает пакет, с которым можно работать:

  • краткое содержание заявки;
  • тип запроса;
  • продукт или услугу, если это ясно из текста;
  • признаки срочности;
  • недостающие данные;
  • предложенный следующий шаг;
  • черновик ответа;
  • флаг «нужна ручная проверка».

Если система не уверена, она должна честно отправлять заявку на ручной разбор, а не изображать уверенность. Для бизнеса это важнее красивой демонстрации.

Почему n8n подходит для такой автоматизации

n8n удобен как слой между источниками заявок, AI-сервисом и CRM. По данным официальной документации n8n, платформа ориентирована на автоматизацию рабочих процессов и интеграции: n8n Docs. Для задачи классификации это значит, что сценарий можно собрать как цепочку шагов: принять входящие данные, подготовить текст, отправить его в модель, разобрать ответ, записать результат и уведомить человека.

Где в схеме находится AI

AI не должен быть единственным центром процесса. В устойчивой схеме у него ограниченная роль: прочитать текст и вернуть структурированную интерпретацию. Все вокруг модели делает автоматизация:

  • принимает входящий запрос;
  • нормализует поля;
  • проверяет обязательные данные;
  • подставляет системную инструкцию;
  • отправляет запрос к модели;
  • валидирует ответ;
  • записывает результат;
  • ставит задачу менеджеру;
  • логирует ошибку, если что-то пошло не так.

Так проще отлаживать процесс. Если ломается отправка уведомления, не нужно менять промпт. Если модель путает категории, не нужно переписывать интеграцию с CRM.

Какие источники подключать первыми

Лучший первый источник — тот, где поток заявок уже есть и где боль видна каждый день. Обычно это форма на сайте или входящая почта отдела продаж. Мессенджеры можно подключать позже, потому что там выше ожидание быстрого ответа и больше коротких сообщений без контекста.

Внутри компании стоит выбрать один канал и одну команду. Например, только заявки с сайта на консультацию. Это скучно, зато управляемо: проще сравнить работу до и после, собрать ошибки и доработать правила.

Почему не стоит начинать с полного автопилота

Полный автопилот выглядит привлекательнее: заявка пришла, AI ответил, CRM обновилась, менеджер не нужен. Но для первого внедрения это риск. В реальности в заявках встречаются неполные данные, сарказм, смешанные запросы, старые клиенты, дубли, ошибки в телефоне, нестандартные условия и внутренние договоренности, которых модель не знает.

Поэтому надежный старт — режим ассистента:

  1. AI классифицирует заявку.
  2. AI предлагает черновик ответа.
  3. Менеджер принимает, правит или отклоняет.
  4. Система сохраняет выбранный результат.
  5. Руководитель смотрит, где AI ошибался.

Так появляется база для следующего шага: часть типовых заявок можно постепенно переводить в более автоматический режим.

Архитектура процесса: от формы до CRM

Минимальная схема состоит из нескольких блоков. Ее можно реализовать разными сервисами, но логика почти всегда одинаковая.

Блок приема заявки

Источник отправляет в автоматизацию текст заявки и базовые поля: имя, контакт, канал, страницу, комментарий, метку рекламы или другую доступную информацию. Здесь важно не перегрузить первый сценарий. Если поле не используется для решения, его можно сохранить в CRM, но не обязательно отправлять в модель.

Для формы сайта достаточно передать:

  • имя клиента;
  • телефон или email;
  • текст обращения;
  • источник;
  • страницу заявки;
  • время получения по системе сайта или CRM.

В статье мы не привязываемся к конкретной CMS, потому что у разных сайтов разные формы и плагины. Главное требование: сценарий должен получать понятный JSON или набор полей, который можно превратить в текст для анализа.

Блок подготовки текста

Перед отправкой в AI нужно собрать аккуратный контекст. Не стоит просто бросать в модель все поля подряд. Лучше сформировать короткий рабочий документ:

Канал: форма сайта
Страница: консультация
Текст клиента: ...
Контакт указан: да
Задача: классифицируй заявку для менеджера, не отвечай клиенту напрямую

Так модель получает роль и границы. Она понимает, что не должна обещать скидку, назначать встречу или писать клиенту от имени компании.

Блок классификации

В этом блоке AI должен вернуть не красивый абзац, а структуру. Например:

{
  "category": "sales_consultation",
  "priority": "normal",
  "summary": "Клиент просит консультацию по внедрению AI в обработку заявок.",
  "missing_data": ["бюджет", "срок запуска"],
  "next_step": "Передать менеджеру и запросить детали процесса.",
  "needs_human_review": true
}

Категории лучше задать заранее. Если оставить модель свободной, она начнет придумывать варианты, которые трудно анализировать. Для старта достаточно простого набора:

КатегорияКогда использоватьДействие
sales_consultationКлиент интересуется услугой или продуктомПередать в продажи
support_requestКлиент просит помочь после покупкиПередать в поддержку
partnershipРечь о партнерстве или совместном проектеПередать ответственному
spam_or_irrelevantЗаявка не похожа на рабочий запросОтправить на ручную проверку
unclearНе хватает контекстаУточнить данные

Таблица не обязана быть большой. Чем меньше категорий на первом этапе, тем легче проверять качество.

Блок записи в CRM

Если компания использует Битрикс24, интеграция может опираться на официальный REST API. В документации Битрикс24 есть разделы «Справочник API» и материалы по локальным интеграциям: apidocs.bitrix24.ru. В практическом сценарии это обычно означает: создать лид или сделку, записать исходный текст, добавить резюме AI, поставить категорию и назначить ответственного.

Не нужно сразу менять сложную воронку. На первом этапе достаточно добавить отдельное поле или комментарий:

  • «AI-категория»;
  • «AI-резюме»;
  • «AI-рекомендация»;
  • «Нужна ручная проверка».

Так менеджеры видят помощь, но привычный процесс не ломается.

Блок уведомления

Для быстрых уведомлений удобно отправлять сообщение в рабочий чат. Telegram Bot API официально описан как HTTP-based interface для разработчиков ботов: Telegram Bot API. В таком сообщении не нужен весь сырой текст. Достаточно компактного блока:

Новая заявка: консультация
Кратко: клиент хочет понять, как автоматизировать обработку обращений.
Не хватает: срок, текущая CRM, объем заявок.
Действие: связаться и задать уточняющие вопросы.
CRM: ссылка на карточку

Если команда не использует Telegram для работы, уведомление можно отправлять в другой корпоративный канал. Смысл блока не меняется: быстро показать ответственному, что произошло и куда нажать.

Как написать промпт без лишней магии

Промпт для классификатора должен быть скучным и строгим. Его задача — не вдохновлять модель, а ограничивать поведение.

Что указать в системной инструкции

В системной инструкции стоит зафиксировать:

  • модель работает только как внутренний помощник;
  • модель не пишет клиенту напрямую;
  • модель не обещает цену, срок, скидку или результат;
  • если данных мало, нужно выбрать unclear;
  • если заявка конфликтная или юридически чувствительная, нужна ручная проверка;
  • ответ должен быть в заданной структуре.

Пример:

Ты внутренний помощник отдела продаж. Проанализируй входящую заявку.
Не отвечай клиенту напрямую. Не обещай цены, сроки, скидки или результат.
Верни только структуру: category, priority, summary, missing_data, next_step, needs_human_review.
Если информации мало, выбери category = unclear и needs_human_review = true.

В этом промпте нет попытки сделать модель «лучшим продавцом». Это осознанно. Сначала нужна дисциплина данных, а не креатив.

Какие категории задать

Категории должны соответствовать реальному процессу, а не фантазии о будущем порядке. Если в компании нет отдельного ответственного за партнерства, категория partnership может быть бесполезной. Если все сервисные обращения идут в один общий отдел, нет смысла дробить их на много подтипов.

Хорошая проверка простая: для каждой категории должен быть понятный следующий шаг. Если следующего шага нет, категория лишняя.

Как просить краткое резюме

Резюме должно быть коротким и проверяемым. Не нужно просить модель «оценить потенциал клиента», если в заявке нет данных о бюджете, размере компании или срочности. Лучше просить пересказать только то, что есть в тексте.

Плохой вариант:

Оцени, насколько клиент платежеспособен.

Хороший вариант:

Сделай краткое резюме только на основе текста заявки. Не добавляй предположения.

Так снижается риск, что модель придумает важные детали.

Как обрабатывать неопределенность

Неопределенность — нормальная часть процесса. Если клиент написал «хочу узнать подробнее», система не должна угадывать продукт, бюджет и мотивацию. Она должна пометить заявку как неясную и предложить менеджеру уточнить контекст.

Для этого полезен отдельный флаг needs_human_review. Его стоит включать, если:

  • в тексте нет понятной потребности;
  • заявка похожа на жалобу;
  • клиент упоминает юридические условия;
  • клиент просит нестандартное обещание;
  • модель не может уверенно выбрать категорию;
  • данные клиента противоречат друг другу.

Такой флаг превращает AI из рискованного автопилота в аккуратного сортировщика.

Контроль качества: что проверять до запуска

Перед публикацией процесса в работу нужно проверить не только промпт, но и всю цепочку. Ошибка может быть не в AI, а в форме, CRM, правах доступа или уведомлениях.

Тестовый набор заявок

Соберите небольшой набор реальных или обезличенных заявок из прошлого потока. Важно убрать персональные данные, если они не нужны для проверки. В наборе должны быть разные типы обращений:

  1. понятная заявка на консультацию;
  2. короткое сообщение без контекста;
  3. обращение в поддержку;
  4. спам;
  5. партнерское предложение;
  6. заявка с несколькими темами;
  7. эмоциональная жалоба.

Каждую заявку нужно прогнать через сценарий и сравнить результат с ручной оценкой. Не обязательно добиваться идеала. Достаточно понять, где процесс ошибается системно.

Логи и повторная обработка

В автоматизации обязательно нужен след. Минимум — сохранить исходный текст, ответ модели и итоговое действие. Это помогает ответить на вопросы:

  • почему заявка попала в эту категорию;
  • что именно вернула модель;
  • где сломалась интеграция;
  • кто поправил результат;
  • какие категории чаще вызывают ошибки.

Если сценарий не пишет логи, команда будет спорить на уровне ощущений. С логами можно улучшать процесс предметно.

Человек в контуре

Для первых недель работы человеку лучше оставить финальное решение. Это не делает автоматизацию слабой. Наоборот, так вы быстрее учите процесс реальности бизнеса.

Хороший режим:

  • AI предлагает категорию;
  • менеджер видит подсказку;
  • менеджер меняет категорию, если нужно;
  • руководитель периодически смотрит расхождения;
  • промпт и правила обновляются по фактическим ошибкам.

Так постепенно появляется доверие к системе. Часть категорий можно автоматизировать позже, когда накопится достаточная уверенность внутри команды.

Ограничения доступа

Не отправляйте в AI больше данных, чем нужно для классификации. Если задача — определить тип заявки, модели не всегда нужны паспортные данные, полный адрес или внутренние комментарии менеджера.

Практическое правило: перед отправкой в модель убирайте поля, которые не влияют на решение. Это снижает риск утечки лишней информации и делает запросы понятнее.

Пошаговый план внедрения

Ниже — рабочий план без привязки к конкретному тарифу, CRM-настройке или модели. Он подходит как чек-лист для предпринимателя или руководителя отдела продаж.

Шаг 1. Выберите один поток

Не берите сразу все каналы. Выберите один поток заявок, где есть повторяемость. Например: заявки с формы «получить консультацию». Чем уже первый поток, тем легче понять результат.

На этом этапе нужно описать:

  • откуда приходит заявка;
  • кто ее обрабатывает;
  • какие категории нужны;
  • какие действия бывают после классификации;
  • где должен появиться результат.

Шаг 2. Опишите категории и правила

Сделайте короткий справочник категорий. Для каждой категории укажите признак и действие. Не пишите длинный регламент на старте. Достаточно таблицы, которую понимают менеджеры.

Пример:

КатегорияПризнакСледующий шаг
КонсультацияКлиент просит обсудить внедрение или услугуНазначить менеджера
ПоддержкаКлиент уже купил и просит помочьПередать в поддержку
НеясноНельзя понять потребностьЗадать уточняющий вопрос

Когда категории согласованы, их можно переносить в промпт и поля CRM.

Шаг 3. Соберите сценарий в n8n

Сценарий можно разложить на понятные узлы:

  1. входящий webhook или другой источник;
  2. подготовка текста;
  3. запрос к AI;
  4. проверка структуры ответа;
  5. запись в CRM;
  6. уведомление менеджера;
  7. обработка ошибок.

Если команда уже использует n8n, не усложняйте архитектуру. Важнее сделать сценарий прозрачным: чтобы любой ответственный мог открыть его и понять, что происходит.

Шаг 4. Запустите в ручном режиме

Первый запуск лучше делать без автоматического ответа клиенту. Пусть AI только заполняет поля и отправляет подсказку. Менеджеры должны видеть, что это рекомендация, а не приказ.

В ручном режиме полезно отмечать:

  • где AI был прав;
  • где ошибся;
  • какие формулировки непонятны;
  • какие категории лишние;
  • каких категорий не хватает.

Эти заметки потом превращаются в улучшения промпта и правил.

Шаг 5. Автоматизируйте только безопасные участки

Когда процесс стабилизируется, можно автоматизировать отдельные действия. Например, если заявка явно спамовая, отправлять ее в отдельный список. Если заявка понятная и полная, сразу назначать ответственного. Если заявка неясная, отправлять менеджеру шаблон уточняющего вопроса.

Не нужно переводить все в автопилот одновременно. Надежнее автоматизировать только те участки, где ошибка не приводит к серьезному ущербу.

Как связать это с уже существующими процессами

AI-классификатор не должен жить отдельно от воронки продаж. Он полезен только тогда, когда встроен в привычную работу менеджеров.

Связь с квалификацией лидов

Если у вас уже есть ручная квалификация, AI может стать предварительным фильтром. Он не заменяет решение менеджера, но ускоряет первичный разбор. Подробнее о похожей логике можно почитать в материале про квалификацию лидов AI-агентом.

Ключевой момент: не смешивайте классификацию и оценку ценности клиента. Классификация отвечает на вопрос «что это за обращение». Квалификация отвечает на вопрос «насколько оно подходит компании». Это разные решения.

Связь с входящими заявками

Если у вас уже настроен сценарий обработки входящих заявок, классификатор можно добавить как промежуточный слой. Сначала он заполняет резюме и категорию, затем текущий процесс идет как раньше. Близкий подход описан в статье про AI-агента для входящих заявок в n8n.

Такой путь снижает сопротивление команды. Менеджерам не нужно менять весь интерфейс, они просто получают более чистую карточку.

Связь с контрольными точками

Любая AI-автоматизация должна иметь контрольные точки. Если заявка конфликтная, важная или непонятная, система должна остановиться и попросить человека принять решение. Этот принцип подробно раскрыт в материале про AI-агента с контрольными точками.

Для классификатора контрольная точка — это не бюрократия, а защита. Она не дает автоматизации тихо увести важную заявку не туда.

Связь с уведомлениями

Если менеджеры работают из чата, полезно отправлять им короткие уведомления. Похожая идея есть в статье про связку Telegram, email и n8n. Важно только не превращать чат в шум. Уведомление должно приходить тогда, когда по нему можно действовать.

Ошибки, которые ломают внедрение

Большинство проблем возникает не из-за того, что AI «плохой», а из-за нечеткого процесса вокруг него.

Слишком много категорий

Если на старте сделать большой справочник, модель и люди начнут путаться. Категории должны быть крупными и привязанными к действиям. Детализацию можно добавить позже.

Нет ручной проверки

Если сразу доверить системе менять статусы и отвечать клиентам, первая серьезная ошибка может испортить отношение команды к автоматизации. Ручная проверка на старте нужна не для красоты, а для накопления доверия.

Промпт просит предположения

Фразы вроде «оцени потенциал», «определи бюджет» или «пойми намерение клиента» опасны, если в заявке нет таких данных. Модель может начать достраивать картину. Лучше просить фиксировать только то, что видно из текста.

CRM получает мусорные поля

Если ответ AI не структурирован, CRM быстро превращается в склад длинных комментариев. Лучше заранее определить поля и формат. Резюме — коротко, категория — из списка, следующий шаг — в одну рабочую фразу.

Нет владельца процесса

У автоматизации должен быть ответственный: кто смотрит ошибки, меняет категории, обновляет промпт и решает, какие действия можно автоматизировать. Без владельца сценарий устаревает и начинает мешать.

Частые вопросы

Можно ли отвечать клиенту автоматически

Можно, но не с первого дня и не для всех типов заявок. Сначала лучше использовать AI для внутренней классификации и черновика ответа. Автоматический ответ стоит включать только для понятных, повторяемых и низкорисковых сценариев.

Нужен ли программист для такого проекта

Для простой версии может хватить специалиста, который умеет работать с n8n, CRM и API. Но если процесс затрагивает персональные данные, сложные права доступа или нестандартную CRM-логику, лучше подключить разработчика или интегратора.

Что делать, если AI ошибся с категорией

Ошибка должна попадать в процесс улучшения. Менеджер меняет категорию, а ответственный смотрит, почему система ошиблась: не хватило категории, промпт был расплывчатым, входящие данные пришли в плохом виде или заявка действительно неоднозначная.

Какие данные нельзя отправлять в модель

Не стоит отправлять лишние персональные, платежные, юридически чувствительные и внутренние данные, если они не нужны для классификации. Перед запуском лучше отдельно описать, какие поля уходят в AI, а какие остаются только в CRM.

Как понять, что пора расширять автоматизацию

Расширять стоит тогда, когда команда видит повторяемые успешные решения. Например, определенная категория стабильно распознается правильно, менеджеры редко правят подсказки, а ошибки понятны и не критичны. До этого лучше держать человека в контуре.

Подойдет ли схема для службы поддержки

Да, если обращения текстовые и у поддержки есть понятные категории. Но для претензий, конфликтов и обещаний клиенту нужна ручная проверка. AI может подготовить резюме и маршрут, а не принимать финальное решение.

Итог

AI-классификатор заявок — один из самых спокойных способов внедрить нейросети в бизнес-процесс. Он не требует сразу менять отдел продаж, не заставляет доверять модели общение с клиентом и дает понятный практический эффект: заявки становятся структурнее, менеджеры быстрее понимают суть обращения, а руководитель получает больше порядка в CRM.

Начинайте с одного канала, короткого списка категорий и ручной проверки. Используйте n8n как слой автоматизации, CRM как систему учета, а рабочий чат как канал уведомлений. AI в этой схеме должен быть не самостоятельным продавцом, а аккуратным помощником, который готовит данные для человека.

Главная мысль простая: автоматизировать нужно не хаос, а уже описанный процесс. Если категории, роли и контрольные точки понятны, AI-классификатор быстро становится полезным инструментом. Если процесса нет, модель только ускорит путаницу.

Кирилл Пшинник

Кирилл Пшинник

Сооснователь и CEO «Зерокодера», эксперт Forbes по EdTech и AI, лектор МФТИ и Иннополиса. Главный редактор GPTmag.

Все материалы автора →

Похожие статьи

Дискуссия

Что вы думаете?

Поделитесь опытом, расскажите, как у вас решается похожая задача, или задайте вопрос — я лично читаю все комментарии и отвечаю.