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

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

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

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

Где ИИ действительно помогает во входящем потоке

Хорошая автоматизация начинается не с выбора модели, а с карты входящих каналов. В типовом отделе продаж или поддержки их 4–7: форма на сайте, почта, чат на сайте, мессенджер, звонок после расшифровки, заявка из маркетплейса, комментарий в соцсети. Форматы разные, но задача одна: превратить свободный текст в понятную карточку.

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

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

Чтобы не смешивать создание текстов и операционную логику, удобно разделить работу на два слоя. Первый слой отвечает за классификацию и поля. Второй, за текст ответа. Такой подход уменьшает хаос: если категория определилась неверно, вы чините классификатор; если тон ответа сухой, правите шаблон коммуникации. Для текстовой части пригодятся принципы из статьи про генерацию текста с проверкой результата.

Таксономия: какие категории нужны до подключения CRM

Перед интеграцией я прошу команду выписать реальные типы обращений за 2–4 недели. Не 50 красивых категорий из головы, а то, что уже встречается. Обычно хватает 8–15 верхнеуровневых классов. Если их меньше 5, менеджерам не хватает точности. Если больше 25, модель и люди начинают спорить о пограничных случаях.

Рабочий набор для B2B-сервиса может выглядеть так:

Категория Признаки в сообщении Куда отправлять Первый ответ
Новая продажа «хочу купить», «рассчитать», «нужна демо» Воронка продаж, новый лид Подтвердить запрос, уточнить объём и срок
Повторная покупка Есть номер договора, прошлый заказ, знакомый домен Текущий клиент, ответственный менеджер Признать контекст, запросить детали новой потребности
Поддержка «не работает», «ошибка», «не могу войти» Очередь поддержки Попросить номер аккаунта, описать ближайший шаг
Жалоба «верните деньги», «нарушили срок», резкий тон Старший менеджер Спокойно принять обращение, не обещать компенсацию
Спам или нерелевантно Реклама, массовая рассылка, нет запроса Закрыть или в отдельный список Ответ не отправлять
Партнёрство «интеграция», «совместный проект», «агент» Канал партнёров Запросить профиль компании и формат предложения

Категории должны быть взаимоисключающими на первом уровне. Если сообщение подходит сразу под две группы, добавляйте второе поле, например «эмоциональный риск» или «тип клиента». Не надо превращать одну категорию в контейнер для всего. «Срочная продажа с жалобой» лучше хранить как category=Новая продажа, risk=Жалоба, priority=Высокая.

Контракт данных: что должна вернуть модель

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

{
  "category": "Новая продажа | Поддержка | Жалоба | Партнёрство | Спам",
  "priority": "Низкая | Средняя | Высокая",
  "intent": "короткое описание намерения",
  "entities": {
    "company": "если указана",
    "city": "если указан",
    "product": "если указан",
    "budget": "если указан",
    "deadline": "если указан"
  },
  "missing_fields": ["что нужно уточнить"],
  "crm_comment": "короткая заметка для менеджера",
  "draft_reply": "первичный ответ клиенту",
  "confidence": 0.0
}

Поле confidence я использую как технический предохранитель. Если оценка ниже 0,75, карточка уходит на ручную проверку. Если выше 0,9 и категория безопасная, например запрос прайса, можно готовить автоответ. Порог подбирается на исторических данных: возьмите 100–300 старых обращений, разметьте их руками и сравните результат модели с эталоном.

Модельный кейс: интернет-магазин с 1 200 входящими обращениями в месяц может начать с разметки 200 прошлых сообщений и 6 категорий, а затем каждую неделю добавлять по 30–50 спорных примеров в тестовый набор. Это не доказывает будущую точность, зато быстро показывает, где ломается схема: на возвратах, адресах доставки, промокодах или жалобах.

Пример промпта для сортировки заявки

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

Ты классифицируешь входящие заявки компании. Верни только корректный JSON без пояснений.

Категории:
1. Новая продажа, клиент интересуется покупкой, расчётом, демо или ценой.
2. Поддержка, клиент сообщает о проблеме в уже купленном продукте или услуге.
3. Жалоба, клиент недоволен сроками, качеством, оплатой или требует возврат.
4. Партнёрство, предложение о совместной работе, интеграции, агентской схеме.
5. Спам, реклама или сообщение без полезного запроса.

Правила:
- Если есть риск жалобы, ставь risk="Высокий", даже если категория другая.
- Не обещай скидки, возвраты, сроки и юридические условия.
- Если данных не хватает, добавь их в missing_fields.
- draft_reply пиши на русском, до 500 знаков, спокойно и конкретно.
- Если сообщение похоже на спам, draft_reply оставь пустым.

Входящее сообщение:
{{message}}

Я отдельно прописываю запреты. Не «будь аккуратен», а конкретно: не обещать возврат, не называть цену без прайса, не подтверждать наличие товара, если этого нет в данных. Чем дороже ошибка, тем жёстче правило.

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

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

Как связать ИИ-классификацию с CRM

Интеграция обычно строится вокруг события «новая заявка». Источник отправляет текст и служебные поля в промежуточный обработчик. Обработчик вызывает модель, проверяет JSON, применяет бизнес-правила и создаёт или обновляет карточку в CRM.

Типовой поток выглядит так:

  1. Сайт, почта или чат передаёт сообщение в обработчик.
  2. Обработчик нормализует текст: убирает подписи писем, склеивает несколько сообщений, добавляет канал и время.
  3. Нейросеть возвращает категорию, поля, приоритет, черновик ответа.
  4. Правила проверяют результат: допустимая категория, заполненные обязательные поля, порог уверенности.
  5. CRM получает лид, задачу, комментарий и ответственного.
  6. Клиенту отправляется автоответ или менеджер видит черновик в карточке.

Псевдокод без привязки к конкретной CRM:

onNewRequest(request):
  normalized = normalize(request.text, request.channel, request.created_at)
  ai_result = classify(normalized)

  if not validJson(ai_result):
    createTask(queue="Ручная проверка", reason="Некорректный JSON")
    return

  if ai_result.confidence < 0.75 or ai_result.risk == "Высокий":
    crm.createLead(category=ai_result.category, comment=ai_result.crm_comment)
    crm.createTask(queue="Менеджер", priority="Высокая")
    return

  lead = crm.createOrUpdateLead(fields=ai_result.entities, category=ai_result.category)
  crm.addComment(lead.id, ai_result.crm_comment)

  if safeToAutoReply(ai_result.category):
    sendReply(request.contact, ai_result.draft_reply)
  else:
    crm.createTask(queue="Менеджер", draft=ai_result.draft_reply)

Самая ценная часть здесь не вызов модели, а проверки вокруг неё. JSON может быть пустым. Категория может не попасть в справочник. Клиент может прислать паспортные данные, ругань, коммерческую тайну или вопрос вне компетенции компании. Поэтому интеграция должна уметь останавливать автоматический ответ и отправлять заявку человеку.

Метрики качества: чем проверять настройку

Я смотрю на 5 показателей. Доля правильных категорий, доля заявок без ручной пересортировки, время до первого ответа, доля автоответов без жалоб, количество заявок в ручной проверке. Для старта нормальна ручная проверка 30–50% потока. Через несколько итераций её можно снижать, если тестовый набор показывает стабильность.

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

Условный пример: компания из сферы онлайн-образования, ~40 сотрудников, может разделить 900 обращений в месяц на 7 категорий и оставить автоматическую отправку только для двух безопасных типов, «получить программу курса» и «уточнить дату старта». Для остальных категорий нейросеть готовит карточку и черновик, но кнопку отправки нажимает координатор. Такая схема уменьшает ручную сортировку, не снимая контроль с чувствительных тем.

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

Как обучать команду работать с системой

Автоматизация входящих заявок ломается, когда менеджеры не понимают, почему карточка попала в нужную очередь. Поэтому я добавляю в CRM короткое объяснение: «категория выбрана из-за слов “не могу войти” и “ошибка оплаты”». Это не полноценное рассуждение модели, а рабочая подсказка для человека.

Нужен журнал исправлений. Если менеджер меняет категорию, новое значение уходит в таблицу разметки. Раз в неделю владелец процесса смотрит 20–50 исправленных заявок и решает, что менять: категории, промпт, правила, пороги или справочник CRM. Без такого цикла система застывает через месяц и начинает раздражать команду.

Для обучения сотрудников лучше давать не лекцию про ИИ, а 10–15 реальных карточек без персональных данных. Пусть люди сравнят старый процесс и новый: где модель угадала, где ошиблась, где черновик ответа можно отправить почти без правки. Похожий принцип работает в самообучении: нейросеть полезнее как тренажёр мышления, чем как источник готовых ответов. Эту идею я раскрывал в статье про ИИ для саморазвития и обучения.

Что бы я сделал на вашем месте

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

Через 2 недели уже видно, есть ли эффект. Если менеджеры правят почти каждую карточку, проблема не в «слабой нейросети», а в категориях, данных или правилах. Если правок мало, можно открыть автоответы для безопасных категорий. Дальше добавляйте каналы по одному. Так процесс остаётся управляемым, а команда видит пользу на конкретных заявках, а не в презентации про автоматизацию.