Как нейросеть сортирует обращения отдела продаж
Стендфирст: практическая схема разбора заявок, подготовки ответа и передачи лида менеджеру без потери контекста.
Когда в отдел продаж приходит 80, 150 или 300 обращений за день, проблема обычно начинается не с отсутствия менеджеров, а с разнородности входящих данных. Один человек пишет подробное техническое задание, другой оставляет телефон и два слова, третий задаёт вопрос о сроках. Нейросеть помогает привести такие сообщения к единому виду, но решение о контакте, обещании клиенту и передаче заявки остаётся за сотрудником.
В этой статье я разбираю рабочую механику: какие поля извлекать, как задать категории, где поставить ручную проверку и какие показатели считать после запуска. Для подготовки правил полезно свериться с материалом об искусстве формулировки запросов для нейросетей, потому что качество сортировки начинается с точного задания.
Что именно нейросеть делает с обращением
Нейросеть превращает свободный текст в карточку из 5 полей: тема, намерение, срочность, извлечённые контакты и следующий шаг. Такой формат сокращает время первичного чтения, но не отменяет проверку спорных заявок человеком.
Я разделяю обработку входящего сообщения на четыре операции:
- Определение темы. Модель понимает, идёт ли речь о цене, сроках, характеристиках, возврате, партнёрстве или технической проблеме.
- Извлечение сути. Из длинного письма убираются приветствия и повторения, сохраняются продукт, объём, регион, дедлайн и вопрос клиента.
- Оценка приоритета. Приоритет строится по наблюдаемым признакам, например по указанному сроку, готовности к покупке и полноте контактов.
- Подготовка следующего действия. Менеджер получает рекомендацию: уточнить бюджет, отправить расчёт, назначить звонок или передать запрос специалисту.
Для каждого обращения я советую хранить исходный текст рядом со структурированной карточкой. Если классификация окажется неверной, сотрудник увидит, на какой фрагмент сообщения опиралась модель. Это полезнее, чем безымянная метка «высокий приоритет».
| Этап | Что получает менеджер | Контрольный вопрос |
|---|---|---|
| Приём | Исходное сообщение и дату | Не потерялся ли канал обращения? |
| Разбор | Тему, намерение и краткое резюме | Сохранилась ли конкретика клиента? |
| Приоритизация | Срочность и основания оценки | Видны ли факты, а не только балл? |
| Ответ | Черновик с вопросами и следующим шагом | Нет ли неподтверждённых обещаний? |
| Передача | Ответственного и статус | Понятно ли, кто действует дальше? |
В SoftChat в каталоге указаны веб-чат, потоковые ответы через SSE и переключение моделей для разговора. Классификация лидов, CRM-маршрутизация и автоматическая передача заявок в каталоге не заявлены, поэтому такую схему нужно проектировать отдельно, без приписывания её продукту.
Как собрать категории и правила приоритета
Рабочая таксономия обычно начинается с 6–8 основных категорий и второго уровня уточнений. Если сразу создать 25 меток, сотрудники будут по-разному трактовать границы, а статистика быстро потеряет смысл.
Для отдела продаж я бы начал с таких групп:
- новый запрос о покупке;
- повторное обращение по действующему предложению;
- запрос цены или расчёта;
- вопрос о сроках и наличии;
- техническое уточнение перед покупкой;
- претензия или проблема после сделки;
- партнёрское предложение;
- нерелевантное сообщение.
На втором уровне можно добавить тип продукта, регион, размер заказа и стадию переговоров. Сначала достаточно 3–4 уточнений. Их число стоит увеличивать только после просмотра ошибок, а не из желания описать каждую деталь бизнеса.
Приоритет лучше задавать правилами, которые можно объяснить за 30 секунд. Например, высокий приоритет получает обращение с конкретным продуктом, обозначенным сроком и доступным каналом связи. Средний уровень означает наличие интереса без дедлайна или без части данных. Низкий уровень подходит для общих вопросов, рекламы и сообщений без понятного намерения.
Модельный кейс: в потоке из 120 обращений за смену метка «расчёт для объекта до пятницы» должна попасть в категорию расчёта и получить повышенный приоритет, а сообщение «Расскажите о возможностях» требует уточняющего ответа, а не автоматического обещания цены.
Я не советую использовать один показатель вроде длины сообщения. Короткая фраза «Нужна поставка 40 единиц к 12 мая» содержит больше коммерческих сигналов, чем абзац общих рассуждений. Для проверки категорий возьмите 100–200 обезличенных сообщений, разметьте их вручную и сравните результат модели с эталоном.
Как подготовить запрос для извлечения сути
Надёжный запрос состоит из 4 блоков: роль, схема результата, правила неопределённости и примеры. Такая конструкция снижает число свободных трактовок и упрощает последующую проверку.
В роли достаточно написать: «Ты помощник отдела продаж». Затем перечислить поля, которые должны появиться в ответе:
- краткая суть в 1–2 предложениях;
- категория из фиксированного списка;
- срочность, обычная или высокая;
- факты, найденные в тексте;
- отсутствующие данные;
- рекомендуемый следующий шаг;
- черновик ответа клиенту.
Отдельно задайте правило для неизвестных значений: модель должна писать «не указано», а не додумывать бюджет, срок, город или наличие товара. Для контактов полезно разделить найденные данные и предположения. Номер телефона, электронная почта и имя должны копироваться без изменения, а сомнительный фрагмент лучше помечать для проверки.
Модельный кейс: запрос «Нужен расчёт на 40 единиц, доставка до 12 мая, телефон указан в подписи» можно разложить на количество 40, срок 12 мая и контакт из подписи. Если цена в сообщении отсутствует, поле бюджета должно остаться пустым.
Формулировки запросов я проверяю на трёх типах данных: короткое сообщение на 1 строку, письмо на 500–700 слов и переписка с несколькими вопросами. Если правило работает только на аккуратных письмах, оно не готово к реальному потоку. О подходах к черновикам и проверке результата можно прочитать в статье о генерации текста и контроле качества.
В запросе следует зафиксировать запрет на выдуманные сведения. Нейросеть может предложить корректную формулировку, но она не знает фактическую цену, остаток на складе и согласованный срок, если эти данные не переданы ей явно. Черновик ответа должен содержать вопросы к клиенту там, где информации недостаточно.
Как подготовить ответ и передать лид менеджеру
Безопасная передача лида состоит из 2 этапов: сначала модель готовит карточку и черновик, затем сотрудник подтверждает содержание перед отправкой. Такой порядок особенно нужен там, где ошибка меняет цену, срок поставки или юридические условия.
В карточке я оставляю три статуса: «нужна проверка», «готово к контакту» и «закрыто как нерелевантное». Статус не должен быть единственным объяснением. Рядом показываются основания: указан срок, назван продукт, есть контакт, присутствует вопрос о цене или описана проблема после покупки.
Модельный кейс: обращение «Пришлите предложение на 40 единиц до 12 мая, ответьте на этот номер» можно передать менеджеру с черновиком из двух частей. Первая часть подтверждает получение запроса, вторая уточняет город доставки и желаемый способ оплаты. Обещать наличие или окончательную сумму без данных компании нельзя.
Для ответа полезен лимит в 600–800 знаков, если это первый контакт. Длинное письмо на 2 000 знаков часто скрывает главный вопрос, а слишком короткая фраза не объясняет следующий шаг. Я прошу модель выделять один главный вопрос клиента и не добавлять больше двух уточнений за раз.
Если обращение содержит конфликтующие данные, его нужно отправлять в ручную очередь. Например, в тексте указан срок 10 мая, а в приложенной форме стоит 20 мая. Модель может обнаружить расхождение, но менеджер или ответственный сотрудник должен подтвердить, какая дата верна.
Сценарий лучше описывать как процесс, а не как обещание полной автоматизации: входящее сообщение, разбор, контроль, контакт, обновление статуса. Подходы к внедрению нейросетей в регулярные процессы разобраны в материале о рабочих сценариях и продуктивности.
Как измерить качество сортировки
Качество оценивают минимум по 4 показателям: точности категории, полноте извлечения, доле безопасных черновиков и времени до первого действия. Один процент общей «правильности» не показывает, где именно возникает ошибка.
Для классификации используйте две базовые величины. Точность показывает, какая доля сообщений с выбранной меткой действительно относится к этой категории. Полнота показывает, какую долю всех подходящих сообщений модель нашла. Если система редко ставит метку «срочно», точность может быть высокой, а полнота низкой.
Для извлечения данных проверяйте отдельные поля. Телефон может быть найден правильно в 98 из 100 сообщений, а срок поставки только в 72 из 100. Эти результаты нельзя объединять в одну красивую цифру, потому что цена ошибки у контакта и у срока различается.
Тестовую выборку разделите на две части по 50–100 сообщений. На первой корректируйте правила, вторую не меняйте до финальной проверки. Записывайте тип ошибки: неверная категория, пропущенный контакт, выдуманный факт, слишком общий ответ или потерянный дедлайн.
Модельный кейс: если из 100 тестовых обращений 18 получают неверную категорию, сначала ищите пересечение инструкций и примеров. Увеличение объёма текста запроса само по себе не исправит размытые границы между «новой покупкой» и «повторным расчётом».
Период проверки зависит от потока, но для первого вывода обычно достаточно 5 рабочих дней и 200–300 сообщений. После этого можно сравнить долю ручных исправлений, среднее время до назначения ответственного и количество обращений без следующего действия. Эти показатели относятся к процессу компании, а не к обещанным возможностям SoftChat.
Какие риски возникают при работе с обращениями
Для входящего обращения нужны 3 группы мер: минимизация данных, разграничение доступа и журналирование изменений. Это снижает риск раскрытия телефона, почты, адреса и коммерческих условий.
Перед передачей текста в нейросеть уберите сведения, которые не нужны для конкретной задачи. Для классификации часто достаточно содержания запроса, даты и обезличенного идентификатора. Фамилия, полный адрес и реквизиты оплаты могут не требоваться на первом этапе.
152-ФЗ регулирует обработку персональных данных в России, поэтому компании нужно определить цель обработки, состав данных и порядок хранения. Отдельно проверьте основания для передачи текста внешнему сервису, сроки удаления и доступ сотрудников к журналу. Я не советую включать в тестовую выборку реальные паспортные данные, банковские реквизиты и полные договоры.
Вторая зона риска, это выдуманные обещания. Если модель не видит прайс или складской остаток, она может написать убедительный, но неверный ответ. Для защиты задайте разрешённые формулировки: «уточним наличие», «подготовим расчёт», «нужно подтвердить срок». Финальную цену и дату пусть подтверждает сотрудник.
Третья зона риска, потеря контекста при передаче. В карточке должны сохраняться исходное сообщение, краткое резюме, извлечённые факты, неизвестные поля и история исправлений. Если менеджер изменил категорию с «общего вопроса» на «покупку», причина изменения пригодится для следующей настройки.
Как провести пилот за 7 дней
Пилот можно организовать за 7 рабочих дней, если ограничить его одной очередью и 3–5 категориями. Цель пилота, не заменить отдел продаж, а найти повторяемые ошибки до масштабирования.
В первый день зафиксируйте маршрут сообщения от поступления до ответа. Во второй соберите 100–200 обезличенных обращений и вручную разметьте тему, срочность и следующий шаг. На третий день подготовьте инструкцию и 5–10 примеров, включая спорные случаи.
На четвёртый день прогоните тестовую выборку, сравните результат с эталоном и выпишите ошибки. Пятый день посвятите уточнению категорий, запретов и формата карточки. В шестой день дайте результат двум менеджерам, попросите их исправить минимум 30 карточек и отметить причины правок.
В седьмой день сравните исходные и новые показатели: время до первого действия, долю ручных исправлений, число пропущенных контактов и количество черновиков, которые пришлось переписать полностью. Если результат нестабилен, расширять поток рано. Если повторяются две-три ошибки, исправляйте конкретные правила, а не добавляйте общие похвалы модели.
Для повседневных задач полезен принцип постепенного усложнения. Сначала сортируйте сообщения, затем извлекайте поля, после этого добавляйте черновики. Такой порядок помогает понять, какой участок процесса действительно даёт эффект. Базовые примеры бытовой автоматизации собраны в статье о применении нейросетей и чат-ботов в повседневных задачах.
Что я бы сделал на вашем месте
Я бы начал с одной очереди, 6 категорий и 200 обезличенных обращений, а не с попытки обработать весь отдел продаж. В первый цикл оставил бы ручное подтверждение каждого черновика и запретил модели самостоятельно обещать цену, наличие или срок.
Затем я сравнил бы две настройки на одинаковой тестовой выборке, записал ошибки по полям и оставил только те категории, которые менеджеры различают одинаково. Через 5 рабочих дней стало бы понятно, нужна ли более детальная схема или проблема находится в маршруте, форме заявки и правилах ответственности.
SoftChat можно учитывать как веб-интерфейс для общения с нейросетью: в каталоге продукта есть потоковые ответы через SSE и переключение моделей в разговоре. Автоматическую сортировку входящих обращений, CRM-интеграцию и передачу лида от имени продукта я не обещаю, поскольку таких возможностей в каталоге нет. Сам процесс продаж лучше строить вокруг проверяемых данных, прозрачных оснований приоритета и понятного владельца следующего шага.