Как нейросеть сортирует обращения поддержки и продаж
Стендфест: практическая схема для сортировки заявок, выделения срочных случаев и подготовки черновиков ответов с контролем человека.
Поддержка и продажи получают похожий поток сообщений: вопросы о доставке, оплате, возврате, характеристиках товара, наличии и статусе заказа. Разница проявляется в цели обращения и цене ошибки. Пропущенный вопрос о сроках редко создаёт кризис, а письмо о двойном списании или остановке поставки требует быстрой реакции.
Я рассматриваю нейросеть здесь как слой предварительной обработки. Она читает текст, присваивает обращению признаки, извлекает факты и предлагает оператору следующий шаг. Решение о возврате денег, изменении договора или обещании клиенту остаётся за сотрудником, особенно когда в сообщении есть конфликтующие данные.
Что именно сортирует нейросеть
Нейросеть может разложить одно обращение минимум по 4 полям: тема, намерение, срочность и рекомендуемый следующий шаг. Такой формат превращает длинный текст в короткую карточку, с которой проще работать оператору.
Для поддержки я обычно задаю фиксированный набор категорий: доставка, оплата, возврат, техническая проблема, претензия и общий вопрос. Для продаж набор будет другим: запрос цены, подбор решения, вопрос о сроках, сравнение условий и готовность к разговору. Категории должны описываться примерами и границами. Формулировка «сложный вопрос» слишком расплывчата, а «неоплата после выставленного счёта» уже пригодна для разметки.
Нейросеть может извлечь из сообщения следующие данные:
- номер заказа или договора;
- название продукта и упомянутую характеристику;
- дату, срок или обещанный клиенту дедлайн;
- канал связи и язык обращения;
- тон сообщения, например нейтральный, раздражённый или конфликтный;
- признак повторного обращения по той же проблеме.
Я прошу возвращать результат в одинаковой структуре. Например: категория, намерение, срочность, найденные сущности, недостающие сведения, рекомендуемый маршрут. Если поле не найдено, модель должна написать «нет данных», а не додумывать номер заказа или дату.
Для контроля полезно хранить исходный текст рядом с классификацией. Оператор тогда видит, на каком фрагменте основана метка. Это снижает риск принять уверенный, но ошибочный вывод за готовое решение.
Связь между формулировкой запроса и результатом подробно разобрана в материале об искусстве промптинга для нейросетей. Для задачи поддержки особенно полезны ограничения на формат, список допустимых категорий и требование цитировать основание для срочности.
Как выделять срочные случаи
Срочность лучше оценивать по 3 сигналам: риск для клиента, ограничение по времени и последствия для бизнеса. Одного раздражённого тона недостаточно, потому что эмоциональное сообщение может описывать обычный вопрос о статусе заказа.
Я использую шкалу от 0 до 6. Нулевой уровень означает справочный запрос без срока, 1 и 2 подходят для обычной очереди, 3 требует проверки в течение рабочего дня, а 4, 5 и 6 отправляются в приоритетный маршрут. Границу нужно согласовать с руководителем поддержки, а не брать из готового шаблона.
Признаки высокого уровня могут выглядеть так:
- Клиент сообщает о списании денег, блокировке доступа или невозможности выполнить обязательство.
- В тексте есть конкретный срок, например «до 17:00 сегодня» или «машина стоит с 8 утра».
- Повторное обращение осталось без решения, а клиент явно ссылается на предыдущий номер заявки.
Модельный кейс: компания из сферы логистики, около 200 сотрудников, может назначить уровень 5 сообщению «груз не прибыл к окну разгрузки 14:00, склад закрывается в 16:00». Здесь есть два времени, операционный риск и понятное требование к маршрутизации. Сам пример не доказывает, что нейросеть распознает ситуацию без ошибок, поэтому такую метку проверяют на размеченной выборке.
Для продаж срочность выглядит иначе. Сообщение «нужна лицензия для 30 пользователей к 1 сентября» содержит объём и дедлайн. Сообщение «расскажите о тарифах» обычно идёт в стандартную очередь. Я отделяю срочность от коммерческого потенциала, поскольку крупный запрос может быть долгосрочным, а небольшой вопрос иногда требует ответа в течение 15 минут.
Полезно возвращать вместе с уровнем короткое основание: «дедлайн сегодня», «упомянута оплата», «повторное обращение». Если основания нет, сотрудник снижает доверие к результату и тратит время на повторное чтение всего сообщения.
Как превратить классификацию в черновик ответа
Хороший черновик состоит из 4 блоков: признание вопроса, подтверждённый факт, следующий шаг и уточнение недостающих данных. Такая последовательность удерживает ответ в рамках имеющейся информации.
Первый блок показывает, что запрос понят. Второй пересказывает только проверяемые сведения из карточки или текста обращения. Третий сообщает действие со сроком, если срок действительно известен. Четвёртый задаёт один или два вопроса, без которых нельзя двигаться дальше.
Модельный кейс: для обращения «оплата списалась дважды, заказ 4815, прошу вернуть сумму» черновик может содержать признание проблемы, ссылку на номер 4815, просьбу приложить выписку и указание, что платёж проверит финансовый специалист. Нельзя обещать возврат до проверки операции, даже если такая фраза кажется клиенту приятнее.
Для продаж шаблон меняется. Нейросеть может кратко пересказать потребность, выделить число пользователей, срок запуска и желаемый результат. Если клиент написал «нужен сервис для отдела из 12 человек», в черновике не следует самостоятельно указывать тариф, которого нет в исходных данных. Лучше задать вопрос о сценарии использования и предложить передать запрос менеджеру.
Я разделяю черновик и отправленное сообщение. Между ними должен быть этап проверки: оператор сверяет имя, номер заказа, сумму, срок и обещание. Пять полей занимают меньше минуты, но именно в них чаще всего скрывается дорогая ошибка. Особенно внимательно проверяются числа с запятой, даты в формате 03.04 и похожие названия продуктов.
Схему внедрения таких сценариев в рабочие процессы можно сопоставить с рекомендациями из статьи о внедрении нейросетей в рабочие процессы. Там полезен сам принцип: сначала описать повторяемую операцию, затем определить точку контроля и лишь после этого расширять область применения.
Как проверить качество до запуска
Для первого теста я бы собрал от 50 до 100 обезличенных обращений, распределённых по реальным категориям. В выборке должны быть обычные вопросы, повторные обращения, короткие сообщения без контекста и спорные случаи.
Сначала человек размечает обращения вручную. Затем нейросеть получает тот же материал без правильных ответов. После сравнения считаются четыре показателя: правильные срочные решения, пропущенные срочные случаи, ложные приоритеты и обращения без уверенной классификации.
Модельный кейс: в выборке из 80 сообщений 16 обращений заранее помечены как срочные, а система выделила 18. Если 14 совпали с ручной разметкой, полнота составила 14 из 16, а точность среди выбранных срочных случаев, 14 из 18. Такой расчёт показывает, где ошибка: два случая пропущены, четыре подняты в приоритет без достаточного основания.
Для поддержки пропущенный срочный случай обычно дороже лишней проверки. Для продаж цена ошибки зависит от процесса: слишком агрессивная приоритизация перегружает менеджеров, а слишком осторожная скрывает потенциальные сделки. Поэтому пороги 4, 5 и 6 по шкале срочности нужно проверять отдельно, а не объединять в одну метрику.
Я рекомендую провести два прохода. На первом проверяется классификация без черновика. На втором добавляется формирование ответа. Если одновременно менять категории, промпт, шаблон и правила маршрутизации, причина ошибки будет неясна.
Данные для теста нужно обезличить: убрать имена, телефоны, адреса, номера карт и лишние сведения о заказе. Полезно установить дату пересмотра правил, например через 14 дней после запуска пилота. За это время накапливаются новые формулировки, опечатки и случаи, которых не было в исходной выборке.
Практические приёмы проверки текстовых черновиков собраны в статье о генерации текста и проверке результата. Для поддержки особенно пригодны ручная выборка, сравнение с источником и запрет на выдуманные сведения.
Как использовать SoftChat без лишних продуктовых обещаний
SoftChat предоставляет веб-чат с потоковой выдачей ответов через SSE и переключением моделей для каждого разговора. Для текстовой работы в веб-версии есть вкладка «Текст», а рядом отображается вкладка «Графика».
Эти возможности описывают интерфейс общения с нейросетью, а не готовую систему классификации заявок, CRM-маршрутизации или автоматической отправки писем. Сортировку обращений, правила срочности и шаблоны черновиков я рассматриваю как отдельный рабочий процесс, который нужно спроектировать под конкретную команду.
Потоковая выдача удобна для длинных инструкций и промежуточной проверки: оператор видит, как формируется ответ, и может заметить уход от задачи. Переключение модели в разговоре является функцией интерфейса SoftChat; при этом качество конкретной классификации всё равно проверяется на своей выборке, а выводы нельзя переносить на все обращения без теста.
Для подготовки запроса я задаю роль, входные поля, допустимые метки, формат результата и правило неопределённости. Например, если в тексте нет номера заказа, ответ должен содержать «нет данных». Если есть два возможных намерения, модель должна вернуть оба варианта с пояснением, а не выбирать один случайно.
Для бытовых операций с нейросетями полезен материал о применении чат-ботов в повседневных задачах. В рабочей поддержке тот же подход требует более строгих полей, журналирования решений и обязательного контроля перед отправкой.
Как посчитать экономию времени
Экономию считают по 3 величинам: число обращений, среднее время первичного разбора и доля сообщений, которые проходят через предварительную обработку. Без этих данных разговор об ускорении остаётся предположением.
Базовая формула выглядит так: количество обращений умножается на среднее время разбора. Затем из результата вычитается время проверки классификации и исправления черновиков. Отдельно считают стоимость пропущенного срочного сообщения, поскольку один такой случай может перечеркнуть экономию за неделю.
Модельный кейс: при потоке 200 обращений в день и ручном разборе по 2 минуты суммарная нагрузка равна 400 минутам. Если предварительная обработка сокращает просмотр карточки до 45 секунд, это 150 минут, а разница составляет 250 минут, или 4 часа 10 минут. Это расчёт сценария, а не обещание результата для каждой команды.
Я бы разделял время оператора на три части: чтение, поиск фактов и написание ответа. Нейросеть может быть полезна на каждом этапе по-разному, но итоговую оценку лучше строить по фактическим замерам за 5 рабочих дней. Если оператор после автоматизации всё равно перечитывает полный диалог и заново заполняет карточку, номинальное ускорение не превращается в экономию.
Для продаж добавляется показатель скорости первого содержательного ответа. Полезно измерять период от входящего сообщения до момента, когда клиент получил релевантный вопрос или предложение следующего шага. Для поддержки важнее доля обращений, которые сразу попали к нужной группе, и число повторных сообщений по той же проблеме.
Что я оставил бы в рабочем регламенте
Я бы закрепил 5 правил: классифицировать по заранее описанным меткам, отделять срочность от коммерческого потенциала, показывать основание для вывода, проверять черновик человеком и пересматривать выборку через 14 дней.
Начинать разумно с одной очереди и двух-трёх категорий, где накоплено достаточно примеров. Затем можно добавить извлечение дат, сумм и номеров заказов, а после отдельной проверки подключить черновики. Такой порядок даёт понятную точку сравнения: видно, что именно улучшилось и на каком этапе появилась ошибка.
На моём месте я бы сначала измерил ручной процесс за 5 рабочих дней, затем разметил 80 обезличенных сообщений и проверил 2 версии инструкции. Если классификация нестабильна, я бы не расширял автоматизацию, а уточнил границы категорий и добавил примеры спорных обращений. В этой задаче аккуратная маршрутизация ценнее красивого, но неподтверждённого ответа.