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

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

Я рассматриваю ИИ здесь как слой предварительной обработки. Он не должен самостоятельно обещать скидку, менять договор или подтверждать оплату. Его задача уже на первом проходе выделить тему, риск, ожидаемое действие и подходящий черновик. Такой подход снижает объём механической работы и оставляет сотруднику проверку смысла.

Обработка входящего обращенияЧетыре шага от сообщения до решения сотрудника1ВходящиеПисьмо или сообщениес датой и контекстом2КлассификацияТема, факты, пробелыи уровень приоритета3ЧерновикОтвет до 120 словс понятным следующим шагом4ПроверкаФакты, тон и полномочияподтверждает человек
Инфографика

Что именно автоматизировать в переписке

Схема сортировки входящих обращений по темам и приоритету

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

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

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

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

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

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

Как подготовить входящие данные

Для устойчивой сортировки достаточно начать с 4 полей: идентификатора сообщения, даты, канала и текста обращения. Имя отправителя и адрес можно заменить условным кодом, если они не нужны для анализа.

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

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

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

Модельный кейс: компания из сферы логистики, примерно 200 сотрудников, может разделить входящие на 6 групп и добавить поле «срок реакции». В этом сценарии нейросеть не получает ФИО и номера телефонов, а видит обезличенный текст, дату заявки и код отправления. Такой набор уже достаточен для первичной маршрутизации.

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

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

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

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

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

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

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

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

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

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

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

В инструкции для модели нужно задать роль и границы. Например:

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

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

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

Тип входящего Что извлечь Какой черновик подготовить Что проверить человеку
Вопрос об оплате сумма, дата, номер счёта сообщить известный статус или запросить реквизиты факт оплаты и банковские данные
Жалоба на задержку заказ, обещанный срок, последствия признать проблему и предложить следующий шаг реальный срок и полномочия сотрудника
Технический сбой ошибка, время, затронутая функция попросить 2–3 диагностических факта безопасность и корректность инструкции
Запрос документов тип документа, период, адресат перечислить доступные сведения и срок подготовки наличие документа и право отправки
Партнёрское предложение тема, условия, контактное действие кратко зафиксировать интерес или передать ответственному коммерческие условия и адресат

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

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

Как проверять качество до запуска

Проверка должна идти в 2 контура: сначала на заранее размеченной выборке, затем на живом потоке под контролем сотрудника. Один удачный ответ не доказывает пригодность всей схемы.

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

Я бы фиксировал минимум 6 показателей:

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

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

Модельный кейс: если из 40 тестовых сообщений 8 относятся к техническим сбоям, качество маршрутизации этой группы следует оценивать отдельно, а не смешивать с 20 простыми вопросами о графике работы. Иначе лёгкие примеры создадут слишком благоприятную картину.

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

Как встроить обработку в ежедневную работу

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

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

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

На третьем этапе включите режим предложения. Нейросеть показывает категорию, объяснение приоритета и черновик, а сотрудник нажимает «принять», редактирует или отклоняет результат. Причины отклонения лучше свести к 4–6 вариантам, например «неверная категория», «не хватает данных», «тон ответа», «опасное обещание».

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

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

Где проходит граница автоматизации

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

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

Я советую хранить исходное сообщение рядом с результатом обработки. Тогда сотрудник видит, откуда взялась метка, а редактор может восстановить причину ошибки через неделю. Если результат нельзя объяснить по исходному тексту, доверять ему в автоматическом режиме не стоит.

Заключение: что бы я сделал на вашем месте

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

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

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