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

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

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

Поток обработки обращенийВходящиеписьма и тикетыКатегориятема и цельСрочностьтри сигналаЧерновикпроверка оператораСпорные случаи передаются человеку
Инфографика

Как устроить поток обработки обращений

Сотрудник проверяет поток обращений, разделённый на этапы классификации и подготовки ответа

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

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

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

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

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

Как классифицировать обращения без путаницы

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

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

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

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

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

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

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

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

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

Модельный кейс: компания из сферы логистики, около 200 сотрудников, получает 240 обращений за рабочий день. Для пилота можно пометить как срочные сообщения о недоступности личного кабинета, ошибке оплаты и срыве доставки. После проверки 50 таких сообщений руководитель отдела сравнивает решения модели с ручной разметкой и меняет правила, если доля спорных меток превышает 10%.

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

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

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

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

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

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

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

Как сравнить подходы к обработке обращений

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

Подход Подходящая задача Преимущество Ограничение
Ручная обработка Сложные и редкие обращения Человек видит контекст и отвечает гибко Скорость зависит от загрузки сотрудника
Жёсткие правила Простые маршруты по словам и полям Легко объяснить причину решения Плохо работает с синонимами и неполным текстом
Нейросеть Классификация, извлечение фактов, черновики Обрабатывает разные формулировки Может ошибиться на пограничном примере
Гибридная схема Поток с приоритетами и эскалацией Автоматизация повторяемых этапов при контроле человека Требует набора примеров и регулярной проверки

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

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

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

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

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

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

Условный пример: из 500 обращений за неделю система верно определила категорию в 440 случаях, а 60 отправила на ручную проверку. Это даёт 88% совпадения по классификации, но не доказывает качество черновиков. Для текста нужен отдельный замер, например оценка по пяти критериям: точность, полнота, тон, действие и отсутствие выдуманных сведений.

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

Как начать без длинного проекта

Я бы закладывал на первый рабочий пилот 10 будних дней: 2 дня на сбор примеров, 3 дня на рубрикатор, 3 дня на тестирование и 2 дня на разбор ошибок. За этот срок команда получает измеримый прототип, а не абстрактное обещание автоматизации.

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

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

В дни тестирования я прогоняю минимум 30 новых примеров, которых не было в исходной выборке. Отдельно проверяю 10 пограничных случаев. Если модель уверенно отвечает там, где данных мало, правило меняется: отсутствие подтверждения должно вести к уточняющему вопросу или эскалации.

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

Где проверять сценарии и черновики

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

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

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

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

Я бы начал с одной очереди и 5 категорий, установил 3 уровня срочности и оставил финальную отправку сотруднику. Через 10 рабочих дней сравнил бы ручную разметку с результатами нейросети на 30 новых обращениях.

Если совпадение по категориям приемлемое, следующий шаг, подготовка черновиков, вводится отдельно. Если ошибки сосредоточены в одном типе сообщений, я бы сначала переписал описание категории и добавил 5–10 контрпримеров. Масштабирование на другие отделы имеет смысл после того, как понятны причины ошибок, доля эскалаций и среднее время проверки.

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