Как сортировать письма в поддержку с ИИ: темы, срочность и ошибочные категории

Составьте категории по действиям

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

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

Три выхода классификатора

Первый — тема. Второй — очередь ответственных. Третий — причина, по которой письмо требует внимания человека сейчас. Срочность нельзя выводить только из эмоциональных слов. Письмо «СРОЧНО!!!» может быть обычным вопросом, а спокойное сообщение о невозможности войти в рабочий кабинет — критичным для обслуживания. Пропишите проверяемые признаки из процесса.

Примеры условные. Если в вашей компании другие SLA и отделы, схему нужно адаптировать до пилота.

Проверьте почтовую цепочку

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

Технический доступ к почте ограничьте выбранным ящиком и необходимыми правами. Документация Microsoft Graph о сообщениях показывает структуру письма и связанных полей; конкретный способ подключения зависит от вашей почтовой среды.

Критерий приёмки

Разделите тестовые письма на обычные, пограничные и редкие критические. На 50–100 случаях сравните маршрут ИИ с решением сотрудников. Отдельно считайте ошибки направления критических писем: средняя точность может быть высокой из-за множества простых запросов, хотя важная категория провалена. После запуска сохраняйте каждое ручное переназначение как сигнал для пересмотра правил.

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

Пример пограничного письма

«Заказ не пришёл, верните деньги сегодня» относится одновременно к доставке и возврату, а также содержит срочное требование. Система должна сохранить обе темы и направить разговор тому, кто может координировать ответ. Если автоматически разделить письмо на две независимые задачи, клиент рискует получить противоречивые сообщения. Если отправить только в обычную очередь доставки, запрос на возврат может остаться незамеченным. Такие примеры должны быть в приёмочном наборе.

Когда меняется продукт или команда

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

Как выглядит безопасный ручной маршрут

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

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

Как проверить вложение без раскрытия лишнего

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

Такой маршрут уменьшает ненужную обработку данных и предотвращает выводы на основании файла, который система фактически не прочитала.

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