Как быстро разбирать заявки из почты с помощью нейросети
Стендфирст: практическая схема классификации, приоритизации и передачи обращений без потери контроля со стороны сотрудника.
Поток писем редко ломается из-за сложных вопросов. Основное время съедают повторяющиеся операции: открыть сообщение, определить тему, найти срочность, выбрать ответственного и перенести данные в рабочую систему. Если на одно письмо уходит 40 секунд, разбор 300 обращений занимает около 200 минут чистого времени, без учёта пауз и уточнений.
Нейросеть может подготовить для каждого обращения четыре поля: категорию, приоритет, краткое резюме и рекомендуемый маршрут. Сотруднику останется проверить спорные случаи и выполнить действие, которое нельзя передавать автоматике без правил доступа. Для устойчивого результата нужны понятная схема данных, короткая инструкция и измерение ошибок.
Что именно автоматизировать в потоке заявок
Быстрее всего автоматизируются 4 операции: выделение темы, оценка срочности, извлечение данных и подготовка маршрута. Решение о возврате денег, изменении договора или блокировке учётной записи лучше оставлять сотруднику.
Я начинаю с описания результата, а не с выбора модели. Для каждого письма достаточно зафиксировать:
- Категорию. Например, «оплата», «доставка», «доступ», «претензия» или «прочее».
- Приоритет. Удобна шкала от 1 до 3, где 1 означает обычный запрос, а 3 требует быстрой реакции.
- Краткое резюме. Одно предложение без пересказа всей переписки.
- Следующий шаг. Ответить по шаблону, передать специалисту, запросить данные или отправить на ручную проверку.
Пять или шесть категорий обычно проще контролировать, чем двадцать размытых меток. Если тем больше 10, сотрудники начинают по-разному трактовать границы разделов. Я советую добавить описание каждой категории и по два примера, но не перегружать инструкцию исключениями.
Модельный кейс: для иллюстрации возьмём очередь из 180 писем. Если 120 из них относятся к трём повторяющимся темам, сначала имеет смысл настроить классификацию именно этих 120 обращений, а оставшиеся 60 отправлять на ручную проверку. Такой порядок снижает риск ошибочного маршрута в начале работы.
Как подготовить письмо к обработке
Перед классификацией нужно оставить в тексте письма только данные, которые влияют на решение: тему, содержание, дату, язык, номер заявки и признаки срочности. Вложения, подписи и длинные цепочки переписки лучше обрабатывать отдельно.
Я использую последовательность из пяти шагов:
- удалить повторяющиеся подписи и рекламные блоки;
- отделить последнее сообщение от истории переписки;
- сохранить тему письма и дату получения;
- заменить персональные данные нейтральными метками, если они не нужны для классификации;
- добавить идентификатор обращения, чтобы результат можно было сопоставить с исходным письмом.
Дата и время нужны для оценки очереди. Сообщение с фразой «не работает» без срока и номера заказа нельзя автоматически считать срочным. Если в письме есть срок, сумма или номер документа, эти значения лучше выводить отдельными полями, а не прятать внутри резюме.
Гипотетический пример: письмо «Заказ 4812 не приехал, обещанный срок был 12 мая» должно вернуть категорию «доставка», приоритет 3, номер заказа 4812 и причину срочности «нарушен обещанный срок». В таком формате сотрудник видит основание решения за несколько секунд.
Для изображений и сканов нужен отдельный этап распознавания. Если исходный текст неполный, нейросеть не должна додумывать номер договора или сумму. Безопасная формулировка результата в таком случае: «данных недостаточно, требуется проверка».
Практические приёмы подготовки входа и проверки результата собраны в материале о задачах нейросетей для генерации текста и проверке результата. Он пригодится, если поток содержит разные форматы документов и сообщений.
Как составить инструкцию для классификации
Хорошая инструкция содержит 5 частей: роль, список категорий, правила приоритета, формат ответа и условие для ручной проверки. Чем меньше свободного текста требуется на выходе, тем проще контролировать результат.
Рабочий каркас выглядит так:
Определи категорию обращения из списка: оплата, доставка, доступ, претензия, прочее.
Назначь приоритет от 1 до 3.
Извлеки номер заказа, сумму и дату, если они указаны.
Сформулируй резюме в одном предложении.
Если данных недостаточно или подходят две категории, укажи «ручная проверка».
Верни результат в формате JSON с полями category, priority, summary, next_step.
В основном тексте статьи названия полей можно оставить на русском, если результат проверяют люди. Для дальнейшей передачи в программу удобнее использовать стабильные ключи без пробелов. Допустимые значения нужно перечислить заранее: например, priority может принимать только числа 1, 2 или 3.
Запрос «разбери письмо и реши, что делать» слишком расплывчатый. В нём нет границ категории, критерия срочности и поведения при нехватке данных. Я добавляю запрет на выдумывание фактов и правило «не уверен, отправь на ручную проверку».
В статье об искусстве формулировать запросы для нейросетей подробно разобраны структура инструкции, примеры и контроль неоднозначных ответов. Для потока заявок особенно полезны ограничения по формату и явные условия отказа от догадки.
При смене модели я проверяю три группы писем: простые, пограничные и неполные. В каждой группе достаточно начать с 10–20 сообщений, затем расширить выборку до 50. Такой набор показывает, где проблема находится в инструкции, а где исходное письмо действительно двусмысленно.
Как выбрать маршрут и приоритет
Маршрут лучше строить по 3 уровням: обычная обработка, ускоренная реакция и ручная проверка. Число «3» здесь полезно как ограничение: длинная шкала из 7–10 уровней создаёт видимость точности, но редко меняет действие сотрудника.
Пример правил:
| Условие в письме | Приоритет | Маршрут | Почему |
|---|---|---|---|
| Общий вопрос без срока и финансового риска | 1 | Обычная очередь | Можно обработать по стандартному сценарию |
| Указан заказ, дата или повторное обращение | 2 | Профильный сотрудник | Нужна проверка конкретных данных |
| Нарушен срок, есть угроза претензии или остановки работы | 3 | Ускоренная очередь | Задержка увеличивает операционный риск |
| Не хватает номера, темы или ключевого факта | ручная проверка | Контролёр | Автоматическое решение будет ненадёжным |
Правила должны описывать наблюдаемые признаки, а не эмоциональную окраску. Слова «срочно», «безобразие» и «немедленно» сами по себе не доказывают высокий приоритет. Нужны дата, сумма, срок, повторность обращения или конкретное последствие.
Модельный кейс: в очереди из 240 писем 36 содержат повторное обращение, а 18 указывают на просроченный срок. Эти группы можно направить на ускоренную проверку, но итоговое решение всё равно должно зависеть от текста и внутренних правил компании, а не от одного ключевого слова.
Если письмо подходит сразу к двум категориям, модель должна вернуть обе гипотезы или специальную метку. Принудительный выбор одной категории создаёт скрытые ошибки: статистика выглядит аккуратно, а сотрудник получает неверный маршрут.
Как проверять качество и считать ошибки
Контроль начинается с эталонной выборки минимум из 50 писем, размеченных человеком. Для каждой записи фиксируют правильную категорию, приоритет, извлечённые значения и допустимый маршрут. После этого ответы нейросети сравнивают с эталоном по отдельным полям.
Я разделяю ошибки на четыре типа:
- неверная категория;
- завышенный или заниженный приоритет;
- пропущенное значение;
- выдуманное значение, которого не было в письме.
Последний тип опаснее стилистической ошибки. Если резюме написано неидеально, сотрудник обычно поймёт смысл. Если система добавила несуществующую сумму или дату, это может повлиять на финансовое решение.
Для примера: из 50 проверенных писем 44 получили правильную категорию, 47 не содержали выдуманных значений, а 41 получили верный приоритет. Это три разные метрики, их нельзя сводить к одной общей оценке 88%.
Полезно установить порог ручной проверки. Например, все сообщения с двумя возможными категориями, отсутствующим номером заказа или упоминанием юридической претензии отправляются человеку. Порог можно пересматривать после каждой партии из 50–100 писем.
Хорошая проверка включает и время обработки. Если ручная разметка одного письма занимает 40 секунд, а проверка результата нейросети 15 секунд, экономия на 100 письмах составляет около 42 минут. Это расчёт производительности, а не обещание одинакового эффекта для каждой команды.
Как использовать SoftChat в рабочем сценарии
В веб-чате SoftChat ответы выдаются потоково, а модель можно переключать для каждого диалога. Это позволяет вручную сопоставить форматы классификации на одинаковой подборке писем, не меняя саму структуру задания.
Я бы разделил работу на два диалога: в первом хранить схему категорий и правила приоритета, во втором проверять отдельные обезличенные обращения. Для сравнения достаточно подать 10 писем из одной группы, затем повторить проверку на 10 пограничных сообщениях. Такой подход помогает увидеть разницу между стабильной классификацией и случайным удачным ответом.
SoftChat предоставляет веб-интерфейс чата, а поток заявок из почты, правила передачи и действия в CRM нужно организовать средствами рабочего процесса компании. Не стоит приписывать чату автоматическую доставку писем или изменение карточек клиентов, если такая связка отдельно не настроена.
Для ежедневной работы я сохраняю версию инструкции, дату изменения и набор тестовых писем. Если категорию переименовали 1 июня, результаты до и после этой даты нельзя смешивать в одной статистике. История из 3–4 версий уже помогает понять, после какого изменения выросло число ручных проверок.
Материал о внедрении нейросетей в рабочие процессы полезен для этапа, где разовая проверка превращается в регулярную процедуру. А разбор повседневных задач с нейросетями и чат-ботами помогает отделить подходящие операции от тех, где нужен сотрудник.
Что выбрать для разных объёмов писем
Выбор зависит от объёма, повторяемости и цены ошибки. Для 20 писем в день часто достаточно ручной разметки по короткому шаблону, а для 500 обращений уже требуется формальный формат результата и отдельная очередь исключений.
| Подход | Подходящий объём | Преимущество | Ограничение |
|---|---|---|---|
| Ручной разбор | До 30 писем в день | Контекст сразу у сотрудника | Результат зависит от конкретного человека |
| Правила и шаблоны | 30–150 писем в день | Повторяемость простых сценариев | Плохо работают с двусмысленным текстом |
| Нейросеть с проверкой | От 100 писем в день | Быстрая подготовка полей и резюме | Нужны эталонная выборка и контроль ошибок |
| Комбинированная схема | От 200 писем в день | Простые письма идут быстро, сложные попадают к специалисту | Требуется поддерживать правила маршрутизации |
Для небольшого отдела я выбираю комбинированную схему: нейросеть размечает очевидные обращения, а сотрудник проверяет высокий приоритет и неполные данные. При большом количестве писем добавляются журнал решений, версионирование инструкций и регулярная выборка для контроля.
Что бы я сделал на вашем месте
Я бы начал с одной категории и 50 обезличенных писем, а не со всей очереди. Сначала зафиксировал бы допустимые значения полей, затем проверил категории, приоритет и выдуманные данные по отдельности. Если доля ручной проверки после первой итерации превышает 30%, я бы пересмотрел границы категорий, а не сразу менял модель.
Правило выбора простое: чем выше цена ошибки, тем больше решений остаётся у человека. Для обычного вопроса о статусе заказа допустима автоматическая подготовка маршрута. Для претензии, платежа или изменения договора нейросеть может собрать факты, но финальное действие должен подтвердить ответственный сотрудник.
Так поток из писем превращается в измеримую процедуру: есть вход, 4 поля результата, 3 уровня приоритета, эталонная выборка из 50 сообщений и понятная очередь исключений. Именно такая схема даёт скорость без потери контроля.