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

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

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

.title{font:700 28px Inter,Manrope,system-RU,sans-serif;fill:#172033}.label{font:600 22px Inter,Manrope,system-RU,sans-serif;fill:#172033}.small{font:400 18px Inter,Manrope,system-RU,sans-serif;fill:#526078}.arrow{stroke:#6b7cff;stroke-width:5;fill:none;marker-end:url(#m)}Первичная обработка обращенийВходящиепочта, сайт, чатытекст и вложенияПолятема и контактыномер и срокдо 6 значенийПриоритет3 уровняпорог 0,8проверка спорныхДальшеотделчерновикконтроль человекаАвтоматизируем повторяемые шаги, решения с последствиями оставляем сотруднику
Инфографика

Что автоматизировать в первую очередь

Схема первичной обработки входящих сообщений из разных каналов

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

Из письма или сообщения нейросеть может выделить тему, имя отправителя, контакт, номер заказа или заявки, желаемый срок и суть проблемы. Если какого-то поля нет, результат должен содержать значение «не найдено», а не догадку. Это простое правило уменьшает число ложных данных в карточке обращения.

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

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

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

Как устроить разбор входящих сообщений

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

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

Практичный шаблон выглядит так:

Проанализируй обращение и верни результат в 6 полях:
1. тема;
2. краткая суть до 30 слов;
3. найденные контакты и номера;
4. приоритет: высокий, обычный или низкий;
5. рекомендуемый отдел;
6. чего не хватает для ответа.
Не придумывай значения. Если данных нет, напиши «не найдено».

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

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

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

Как определять срочность без хаоса

Для первичного отбора достаточно 3 уровней срочности, например «высокий», «обычный» и «низкий», с целевым ответом в 15 минут, 4 часа и 1 рабочий день соответственно. Эти значения нужно адаптировать под договорённости компании, а не выдавать за универсальный стандарт.

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

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

Граница уверенности помогает передать сомнительные случаи человеку. Например, при оценке ниже 0,8 результат можно отправлять в очередь проверки, а при оценке 0,8 и выше разрешать автоматическую маршрутизацию без немедленной отправки ответа. Сам показатель уверенности не является доказательством правильности, поэтому его нужно сопоставлять с выборочной проверкой.

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

Как маршрутизировать обращения по отделам

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

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

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

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

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

Как готовить черновик ответа

Черновик лучше формировать в 2 этапа: сначала извлечь факты, затем составить текст по утверждённому шаблону. Между этими шагами сотрудник должен иметь возможность исправить категорию, приоритет и недостающие данные.

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

Хороший черновик содержит 4 части:

  1. обращение по имени, если имя подтверждено;
  2. краткое повторение сути вопроса;
  3. конкретный следующий шаг или запрос недостающего поля;
  4. нейтральный срок следующего ответа.

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

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

Формулировки запросов сильно влияют на результат. В статье «Искусство промптинга: как правильно формулировать запросы для нейросетей» подробно разобраны ограничения, формат и проверка ответа. Для почты особенно полезны запреты на выдумывание данных и требование явно показывать пропущенные поля.

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

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

Подход Подходящая задача Плюсы Ограничение
Ручная обработка До 30 обращений в день или нестандартные запросы Полный контроль, легко менять правила Время сотрудника уходит на чтение и копирование
Предварительный разбор нейросетью От 30 до 300 сообщений в день Поля, приоритет и категория появляются до ответа оператора Нужна выборочная проверка и настройка порогов
Автоматическая маршрутизация Повторяющиеся обращения с низкой ценой ошибки Сообщение быстрее попадает в нужную очередь Ошибка классификации может задержать клиента

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

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

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

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

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

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

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

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

Раз в неделю полезно собирать 10–20 спорных обращений и обновлять правила на их основе. Не следует менять шаблон после одной неудачи, если она вызвана редким исключением. Сначала нужно проверить частотность, влияние на клиента и возможность добавить явное условие.

Как запустить пилот без перестройки всей системы

Для пилота я бы заложил 7 рабочих дней и одну категорию обращений, например вопросы о статусе заказа. В первые 2 дня команда собирает 50–100 сообщений и размечает правильный отдел, приоритет и обязательные поля.

На 3-й день формируется шаблон результата. На 4-й и 5-й дни нейросеть обрабатывает новые сообщения, но ничего не отправляет клиентам автоматически. Оператор сравнивает вывод с эталонной разметкой, фиксирует ошибки и меняет правила только после повторной проверки.

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

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

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