Нейросеть для обработки писем и заявок: классификация в 2026

Стэндфирст: Практическая схема обработки потока обращений, от выделения темы и срочности до проверки черновика ответа человеком.

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

В этой статье я разбираю рабочую механику без привязки к конкретному поставщику. Для ручной работы с текстом можно использовать веб-чат SoftChat: каталог продукта указывает потоковые ответы через SSE и переключение моделей для отдельного разговора. Автоматическую интеграцию с почтой, CRM или мессенджерами я SoftChat не приписываю, поскольку такой функции в доступном каталоге нет.

Что нейросеть делает с потоком обращений

Нейросеть превращает одно обращение в набор из 5–6 структурированных полей и помогает принять 3 первичных решения: куда направить сообщение, насколько оно срочное и нужен ли ответ человека. Такой разбор экономит время на чтении однотипных формулировок, но не отменяет проверку спорных случаев.

Обычно из текста извлекаются:

1. Тема обращения. Например, доставка, возврат, оплата, техническая ошибка или изменение персональных данных.
2. Намерение автора. Клиент сообщает о проблеме, задаёт вопрос, просит действие или присылает уточнение.
3. Срочность. Система ищет срок, указание на остановку работы, финансовый риск, повторное обращение или жалобу.
4. Объект обращения. Это номер заказа, договор, продукт, счёт, дата операции или название услуги.
5. Тональность. Спокойный вопрос, раздражение, претензия и сообщение о возможном ущербе требуют разных формулировок ответа.
6. Следующее действие. Нужен шаблонный ответ, передача специалисту, запрос недостающих данных или ручное расследование.

Поток из 200 писем, где повторяются 6–8 тем, трудно быстро просмотреть без пропусков. Нейросеть в таком сценарии выполняет первичную сортировку, а сотрудник проверяет спорные решения и работает с исключениями. Подробный разбор задач для генерации текста и способов проверки результата приведён в статье о нейросети для генерации текста и проверки результата.

Для стабильного результата нужно заранее определить допустимые категории. Если сегодня «оплата» и «счёт» считаются разными темами, а завтра объединяются, статистика перестаёт быть сопоставимой. Я рекомендую начинать с 5–7 категорий и добавлять новые только после анализа журнала ошибок.

Как проходит первичная обработка сообщения

Рабочая схема состоит из 6 этапов: получение текста, очистка, классификация, извлечение данных, подготовка ответа и контроль. Такая последовательность отделяет технические операции от редакторской проверки и помогает найти место сбоя.

1. Сбор сообщения. Сохраняются текст, тема письма, дата, отправитель, канал и идентификатор обращения. Для CRM полезно передавать ещё статус заявки и ответственного сотрудника.
2. Очистка. Убираются повторяющиеся подписи, длинные цепочки цитат, технические заголовки и дубли вложений. Исходное сообщение лучше сохранять отдельно, чтобы специалист мог свериться с ним.
3. Классификация. Нейросеть выбирает одну основную категорию и, при необходимости, одну дополнительную. Ограничение числа меток снижает хаос в отчётах.
4. Извлечение полей. Номер заказа, дата, сумма, город и требуемое действие возвращаются в заранее заданной структуре, например в JSON.
5. Оценка срочности. Система присваивает уровень приоритета и объясняет его конкретными словами из сообщения, а не общей оценкой «похоже на срочное».
6. Черновик. Ответ строится по фактам обращения, правилам компании и доступным данным. Перед отправкой сотрудник проверяет обещания, суммы, сроки и персональные сведения.

В запросе к нейросети я задаю формат результата заранее. Например: «Верни категорию, приоритет от 1 до 4, извлечённые поля, причину приоритета и черновик ответа до 700 знаков». Такая формулировка полезнее просьбы «разбери письмо», потому что задаёт измеримые поля и предел объёма.

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

Как выделять срочные обращения

Срочность лучше рассчитывать по 4 признакам: сроку, последствиям, повторности и эмоциональной окраске. Одного восклицательного знака недостаточно, зато сочетание «срок сегодня», «оплата списана» и «работа остановлена» уже требует повышенного приоритета.

Я использую шкалу из 4 уровней:

• 1, информационный вопрос. Ответ можно подготовить по обычному регламенту.
• 2, обычная задача. Нужно действие сотрудника, но прямой угрозы сроку или деньгам нет.
• 3, ускоренная обработка. Есть приближающийся дедлайн, повторное обращение или риск задержки услуги.
• 4, критический случай. Указаны остановка работы, возможный финансовый ущерб, утечка данных, блокировка доступа или конфликт с обязательным сроком.

Порог должен быть связан с правилами конкретной команды. Для одного отдела сообщение о задержке на 24 часа относится к уровню 3, для другого такой срок считается обычным. Поэтому в инструкции полезно хранить примеры признаков, исключения и канал эскалации.

Модельный кейс: компания из сферы логистики, около 200 сотрудников, получает 600 обращений в неделю. Для неё сообщение о недоставленной посылке и сообщение о полной остановке склада не должны попадать в одну очередь, даже если в обоих текстах встречается слово «доставка». Разделение строится по последствиям, срокам и объекту проблемы, а не по одной ключевой фразе.

Причину приоритета нужно возвращать отдельным полем. Формулировка «уровень 4, потому что автор сообщает о блокировке доступа и просит восстановить его до 18:00» пригодна для проверки. Ответ «высокая срочность по контексту» не объясняет решение и плохо подходит для аудита.

Как получать полезный черновик ответа

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

Я задаю для черновика такие ограничения:

• не обещать возврат денег, скидку или конкретную дату без подтверждённого правила;
• не придумывать номер заявки, имя специалиста и статус операции;
• повторять суть проблемы одной фразой, без пересказа всей переписки;
• задавать максимум 2 уточняющих вопроса за один ответ;
• отделять известные данные от предположений;
• сохранять нейтральный тон при жалобе и не спорить с автором сообщения.

Гипотетический пример: если в письме сказано «счёт оплачен вчера, но доступ не открылся», черновик должен подтвердить получение сообщения, попросить номер счёта или найти его в переданных полях, сообщить порядок проверки и не утверждать, что платёж уже зачислен. Если номер счёта отсутствует, это должно быть явно видно сотруднику до отправки.

Для проверки черновика я разделяю ошибки на 3 группы. Фактическая ошибка меняет смысл, например неверная сумма. Процессная ошибка нарушает регламент, например обещает возврат без согласования. Редакторская ошибка ухудшает ясность, например оставляет длинную цепочку из 5 вопросов в одном абзаце. Первые две группы блокируют автоматическую отправку, третью можно исправлять по шаблону.

Какой подход выбрать для почты, CRM и мессенджеров

Для потока до 3 категорий обычно хватает правил, а при 5–7 повторяющихся темах полезен гибрид правил и нейросети. Полностью автоматический ответ оправдан только там, где факты проверяются по источнику, а ошибка не создаёт финансового или юридического риска.

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

Как внедрять обработку поэтапно

Для первого запуска достаточно 1 канала, 3 категорий, 1 журнала ошибок и выборки из 100 сообщений. Такой объём позволяет увидеть типовые сбои до расширения процесса на весь отдел.

Я бы выстроил внедрение в 4 шага:

1. Собрать эталонную выборку. Отметить категорию, срочность, обязательные поля и приемлемый ответ для каждого сообщения. В выборке должны быть короткие письма, длинные цепочки, опечатки и повторные обращения.
2. Задать инструкцию. Описать формат ответа, список категорий, правила приоритета и действия при нехватке данных. Отдельно указать, что нельзя выдумывать.
3. Запустить режим черновика. Нейросеть предлагает классификацию и текст, но сотрудник вручную подтверждает отправку. Все исправления сохраняются в журнале.
4. Проверить показатели. Через 100–200 обработанных сообщений сравнить решения системы с разметкой человека, сгруппировать ошибки и изменить инструкцию только по наблюдаемым причинам.

Модельный кейс: интернет-магазин с 8 категориями обращений сначала оставляет автоматическую сортировку только для вопросов о статусе заказа, возврате и оплате. Сообщения о персональных данных, конфликте или возможном списании денег направляются сотруднику без готового обещания. После проверки 200 сообщений команда может решить, какие дополнительные категории безопасно включить.

Материал о внедрении нейросетей в рабочие процессы помогает связать такой эксперимент с существующими регламентами, ролями и точками контроля. Это особенно полезно, когда письма распределяются между несколькими отделами и у каждого отдела свои сроки ответа.

Как измерять качество классификации и черновиков

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

Для выборки из 100 сообщений можно считать так:

• Точность категории: сколько решений совпало с разметкой человека из всех проверенных.
• Полнота срочных случаев: сколько действительно срочных обращений система нашла из общего числа срочных сообщений в выборке.
• Доля пригодных черновиков: сколько текстов сотрудник отправил после небольшой правки, без переписывания с нуля.
• Время первичной обработки: средний интервал от поступления сообщения до назначения категории и ответственного.

Если система правильно сортирует 92 из 100 писем, это ещё не означает хорошее качество. При пропуске 4 из 5 критических сообщений показатель для службы поддержки остаётся неприемлемым. Поэтому срочность нужно проверять отдельно, с особым вниманием к категории 4.

Журнал ошибок полезно вести в 5 колонках: исходный текст, решение системы, правильное решение, причина ошибки и изменение инструкции. Через 2–3 недели такой журнал показывает, проблема связана с неполными данными, пересекающимися категориями, плохим примером или слишком широким заданием.

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

Какие ошибки чаще всего мешают запуску

Пять ошибок встречаются особенно часто: слишком широкие категории, отсутствие эталонной выборки, автоматическая отправка без проверки, смешение каналов и отсутствие правила для неизвестных случаев.

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

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

Третья ошибка связана с копированием всей переписки в каждый запрос. В цепочке из 20 сообщений могут повторяться подписи, старые цены и уже закрытые вопросы. Лучше передавать актуальное сообщение, краткую историю и нужные поля, сохраняя полный архив в исходной системе.

Четвёртая ошибка, отсутствие ответа для неизвестной категории, заставляет систему угадывать. В инструкции должен быть явный вариант «нужна ручная проверка», а для него должны существовать срок и ответственный.

Что бы я сделал на вашем месте

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

Веб-чат SoftChat можно использовать как среду для работы с текстом и переключения моделей в разговоре, поскольку эти возможности указаны в каталоге продукта. Для автоматического чтения почты, записи результатов в CRM или самостоятельной отправки ответа понадобится отдельное решение, и при планировании его нельзя подменять предположением о возможностях чата.

Мой критерий готовности простой: сотрудник понимает, почему обращение попало в конкретную категорию, видит все неподтверждённые данные и может отменить предложение до отправки. Если эти 3 условия соблюдены, процесс можно расширять с 1 канала до нескольких, сохраняя журнал ошибок и регулярную проверку выборки.