Нейросеть сортирует обращения и готовит ответы в 2026
Нейросеть превращает поток писем и заявок в упорядоченную очередь: определяет тему, оценивает срочность, предлагает ответ и передаёт сложные случаи сотруднику.
Почта, формы обратной связи и сообщения из чатов часто собираются в одну длинную очередь. В ней рядом оказываются вопрос о статусе заказа, жалоба на оплату, просьба прислать документ и сообщение о недоступном сервисе. Человеку приходится читать каждое обращение целиком, хотя большая часть запросов повторяет уже известные сценарии.
Нейросеть помогает разложить поток по признакам и подготовить рабочий черновик. Она не принимает решение вслепую: правила маршрутизации, пороги срочности и финальная отправка должны оставаться под контролем сотрудника. Такой подход полезен для поддержки, продаж, административной почты и внутренних сервисных линий.
Как устроена сортировка обращений
Сортировка обычно проходит в 4 шага: извлечение текста, определение темы, оценка срочности и назначение следующего действия. Каждый шаг даёт отдельный результат, который можно проверить до передачи обращения оператору.
Сначала система выделяет текст сообщения, тему письма, дату, адрес отправителя и вложения. Затем она ищет смысловые признаки: «не прошёл платёж», «нужен счёт», «заказ не приехал», «хочу изменить договор». На этом этапе полезно задавать фиксированный набор категорий, например «оплата», «доставка», «документы», «техническая проблема», «жалоба» и «прочее».
После классификации обращению назначается приоритет. Для этого учитываются слова о недоступности услуги, блокировке денег, нарушении срока или угрозе расторжения договора. Четвёртый шаг, маршрутизация, связывает категорию с группой сотрудников, сроком реакции или шаблоном черновика.
В разборе задач для генерации текста я советую разделять распознавание и написание. Когда одна инструкция просит сразу понять смысл, выбрать исполнителя и отправить ответ, ошибку трудно найти. Раздельные поля «категория», «приоритет», «основание» и «следующий шаг» делают проверку прозрачнее.
Какие признаки нужны нейросети
Для устойчивой классификации достаточно начать с 5 групп признаков: тема, намерение, тональность, срочность и наличие подтверждающих данных. Чем яснее словарь категорий, тем меньше обращений попадает в расплывчатую папку «прочее».
Тема отвечает на вопрос, о чём сообщение. Намерение показывает, чего хочет человек: узнать статус, изменить данные, вернуть оплату или получить консультацию. Тональность помогает заметить раздражение, но сама по себе не доказывает приоритет. Нейтральное сообщение о заблокированном платеже может быть срочнее эмоциональной жалобы.
Срочность связывают с последствием задержки. Удобно использовать три уровня: критический, обычный и низкий. Подтверждающие данные включают номер заказа, дату операции, сумму, идентификатор договора или скриншот ошибки. Если данных не хватает, черновик должен запросить их, а не заполнять пропуски догадками.
| Признак | Что извлекает нейросеть | Как проверяет сотрудник |
|---|---|---|
| Тема | Оплата, доставка, документы, техническая проблема | Смотрит на категорию и ключевую фразу |
| Намерение | Вопрос, жалоба, возврат, изменение данных | Сверяет действие с просьбой клиента |
| Срочность | Критический, обычный или низкий уровень | Проверяет последствие задержки |
| Данные | Номер заказа, сумма, дата, файл | Уточняет отсутствующие сведения |
| Тональность | Спокойное, раздражённое или конфликтное сообщение | Не использует эмоцию как единственный критерий |
Практические приёмы промптинга помогают закрепить этот формат. В запросе стоит описать допустимые категории, показать 2 или 3 коротких образца и потребовать ответ в заданной структуре. Свободный текст удобен для чтения, но JSON или таблица удобнее для последующей проверки и передачи результата в рабочую систему.
Как выделять срочные запросы
Срочность лучше считать по последствиям и сроку реакции, используя 3 уровня приоритета и явные правила эскалации. Одного слова «срочно» недостаточно: его могут использовать и для вопроса, который спокойно подождёт до следующего рабочего дня.
Критический уровень подходит для признаков остановки услуги, повторного списания, утечки доступа, угрозы безопасности или пропущенного договорного срока. Обычный уровень получают запросы, где проблема мешает работе, но есть временное решение. Низкий уровень относится к справочным вопросам, предложениям и массовым просьбам о документах.
Я бы зафиксировал для каждой категории срок первой реакции. Например, критические обращения проверяются человеком в течение 15 минут, обычные попадают в очередь текущего дня, низкие обрабатываются в плановом порядке. Это не универсальный норматив, а стартовая настройка, которую нужно сверить с договором и графиком поддержки.
Модельный кейс: компания из сферы логистики, примерно 200 сотрудников, получает 600 сообщений за рабочую неделю. Для неё фраза «машина не приехала к окну разгрузки» может означать обычный запрос, а сочетание «оплата списана дважды» требует отдельной проверки финансовой группой. Нейросеть предлагает приоритет, но оператор смотрит на номер заказа, дату и историю переписки.
Полезная схема контроля выглядит так:
- Система присваивает уровень и указывает 1 или 2 фразы, на которых основан вывод.
- Оператор подтверждает приоритет либо меняет его с указанием причины.
- Руководитель раз в неделю сравнивает автоматическую оценку с решениями людей.
Если доля исправлений по критическому уровню заметно растёт, проблема может быть в словаре признаков, неполных данных или слишком широком определении срочности. Сначала меняют правило, затем проверяют его на архиве из 50–100 обращений.
Как готовить черновик ответа
Хороший черновик состоит из 4 блоков: признание запроса, проверенный факт, следующий шаг и уточнение недостающих данных. Такая структура снижает риск обещаний, которых компания не может выполнить.
Первый блок коротко показывает, что смысл обращения понят. Второй содержит только сведения из сообщения, базы знаний или переданного оператором контекста. Если факта нет, нейросеть должна написать «данных недостаточно», а не придумать дату доставки или сумму возврата.
Третий блок формулирует действие: проверить платёж, передать заявку специалисту, запросить номер договора или открыть инструкцию. Четвёртый задаёт максимум 1–2 уточняющих вопроса. Длинный список вопросов увеличивает число повторных сообщений и раздражает человека.
Модельный кейс: клиент пишет «после обновления не открывается личный кабинет». Черновик может подтвердить проблему, попросить время возникновения ошибки и тип устройства, затем предложить безопасную проверку браузера. Если сообщение содержит признаки блокировки учётной записи, ответ не должен предлагать рискованные действия и отправляется сотруднику.
Для качества черновика я использую двухпроходную проверку. Первый проход оценивает смысл, второй ищет неподтверждённые обещания, лишние персональные данные и несоответствие тону компании. Подробный подход к внедрению таких сценариев описан в материале о нейросетях в рабочих процессах.
В веб-чате SoftChat удобно тестировать разные формулировки и переключать модели в рамках разговора. Ответы приходят потоково через SSE, поэтому длинный черновик можно просматривать по мере генерации, не ожидая полной загрузки. Для рабочих данных я советую заранее убрать номера карт, пароли и лишние персональные сведения.
Когда передавать обращение человеку
Передача оператору нужна минимум в 4 ситуациях: есть финансовый риск, требуется исключение из правила, человек просит юридически значимое действие или нейросеть не уверена в классификации. Автоматизация должна сокращать чтение очереди, а не скрывать спорные случаи.
К сотруднику отправляют сообщения о возвратах, претензиях по договору, угрозах безопасности, конфликте между двумя заявками и повторной жалобе. Ещё один триггер, низкая уверенность классификации. Если система выбирает между «оплатой» и «технической проблемой» почти с одинаковой вероятностью, обращение лучше показать человеку.
Для передачи достаточно сохранить 4 элемента: исходный текст, выбранную категорию, причину приоритета и предложенный ответ. Оператору не нужно заново искать, почему сообщение оказалось в его очереди. После решения человека исправленная категория возвращается в набор примеров для будущей проверки.
| Ситуация | Действие нейросети | Решение человека |
|---|---|---|
| Справочный вопрос | Готовит черновик по базе знаний | Проверяет факт и отправляет |
| Нет номера заказа | Выделяет пропуск | Запрашивает данные |
| Повторное списание | Ставит высокий приоритет | Проверяет операцию и правила возврата |
| Конфликтная жалоба | Суммирует историю | Выбирает тон и дальнейшее действие |
| Низкая уверенность | Показывает 2 возможные категории | Назначает окончательную категорию |
Материал о повседневных задачах с нейросетями пригодится для небольших команд, где один сотрудник совмещает поддержку, документооборот и внутренние запросы. Там разумнее начинать с черновиков, а автоматическую маршрутизацию подключать после накопления проверенных примеров.
Как измерять качество сортировки
Качество нужно оценивать по 5 показателям: точность категории, доля верно найденных срочных обращений, время до первой реакции, доля принятых черновиков и число повторных сообщений. Один показатель не описывает всю работу очереди.
Точность категории показывает, какая доля проверенных классификаций совпала с решением сотрудника. Полнота по срочным обращениям отвечает на другой вопрос: сколько действительно критических сообщений система заметила. Если из 100 срочных обращений обнаружены 92, пропущенные 8 нужно разбирать отдельно, даже при высокой общей точности.
Время до первой реакции измеряют от момента поступления до ответа или передачи сотруднику. Долю принятых черновиков считают среди ответов, которые оператор отправил после минимальной правки. Повторные сообщения помогают найти неясные формулировки и случаи, где ответ не решил задачу.
Модельный кейс: за неделю команда проверила 300 обращений. 240 черновиков приняли после правки, 45 переписали полностью, а 15 не использовали из-за неверной категории. Для анализа этого достаточно, чтобы отдельно посчитать 80 процентов принятых черновиков, долю ошибок классификации и причины полного переписывания. Эти значения иллюстративны, их нельзя выдавать за результат конкретной компании.
Проверку проводят на выборке, где есть разные темы, длина сообщений и уровни срочности. Архив из 20 одинаковых вопросов создаёт ложное ощущение качества. Я бы собрал минимум 50 обращений на каждую крупную категорию, а затем повторил замер после изменения инструкции.
Как начать внедрение без потери контроля
Безопасный старт занимает 4 этапа: собрать архив, описать категории, включить черновики и провести ручное сравнение. Автоматическую отправку сообщений на первом цикле я бы не включал.
На первом этапе достаточно выгрузки за 7–14 дней, если в ней есть обычные, срочные и спорные обращения. Из текста удаляют пароли, платёжные реквизиты и сведения, которые не нужны для классификации. Затем создают таблицу с исходным сообщением, верной категорией, приоритетом и решением оператора.
На втором этапе фиксируют словарь из 5–8 категорий. Слишком подробная схема с 30 папками часто распадается: сотрудники по-разному понимают границы соседних тем. Лучше объединить редкие случаи в «прочее» и каждую неделю пересматривать эту группу.
На третьем этапе нейросеть только сортирует сообщения и создаёт черновики. Сотрудник видит исходный текст, основания решения и предложенный ответ. На четвёртом этапе сравнивают минимум 3 среза: точность категорий, пропущенные срочные обращения и время обработки.
Руководство по проверке результата генерации текста помогает превратить редакторскую оценку в понятную процедуру. Для команды из 2–5 человек достаточно одной общей таблицы ошибок и короткого еженедельного разбора. При большем потоке понадобятся владельцы категорий и журнал изменений инструкций.
Что бы я сделал на вашем месте
Я бы начал с режима «нейросеть предлагает, сотрудник решает» и оставил ручную отправку на первые 2 недели. Сначала проверил бы 100–150 обращений, затем сравнил категории, приоритеты и черновики по отдельности.
Если ошибки сосредоточены в одной теме, я бы уточнил её признаки, добавил 3–5 контрпримеров и повторил проверку. Если проблема связана с неполными данными, изменил бы форму входящего сообщения, а не пытался компенсировать пробелы более длинной инструкцией. Такой порядок даёт измеримый результат и сохраняет человека на всех участках, где цена ошибки высока.