Нейросеть для типовых обращений: закрытие и маршрутизация в 2026
Статья о том, какие сообщения можно закрывать автоматически, какие передавать специалистам и как измерять результат без потери качества.
Однотипные письма и чаты отнимают время по одной причине: в общей очереди смешаны простые вопросы, нестандартные случаи и обращения, где нужен доступ к внутренним данным. Нейросеть помогает разделить этот поток, но ей нельзя отдавать все решения без ограничений. Я обычно начинаю с классификации обращений на 4 группы: готовый ответ, уточнение, передача специалисту и запрет автоматического ответа.
Для примера: если из 100 сообщений 60 содержат вопросы о статусе заказа, документах или правилах возврата, команда может заранее подготовить для них отдельные сценарии. Остальные 40 обращений проходят через дополнительные условия: проверку данных, определение отдела и оценку риска. Подход к таким рабочим задачам разобран в материале как использовать нейросети для повседневных задач.
Что нейросеть может закрывать без участия оператора
Нейросеть может самостоятельно отвечать на обращения с одним понятным намерением и заранее проверяемым результатом. Для старта я выбираю 4 категории: статус, инструкция, справочная информация и типовой документ.
К первой категории относятся вопросы «Где заказ?», «Когда будет начисление?» или «Получен ли мой запрос?». Здесь ответ строится вокруг 1 факта, например статуса, даты или номера операции. Если источник данных обновляется с задержкой, в сообщении нужно прямо указать время последнего обновления, а не создавать видимость точности.
Вторая категория, инструкции, подходит для последовательностей из 3–7 шагов. Примером может быть смена пароля, загрузка файла или настройка уведомлений. Для каждого сценария я задаю условие остановки: если пользователь сообщает об ошибке, результат отличается от ожидаемого или действие затрагивает деньги, обращение уходит человеку.
Справочные вопросы закрываются, когда ответ не зависит от профиля клиента. Рабочие часы, список документов, срок рассмотрения и правила доставки можно описывать автоматически, если эти сведения находятся в актуальной базе. У текста должна быть дата пересмотра, например «редакция от 12 марта 2026 года».
Типовые документы требуют осторожности. Нейросеть может объяснить структуру заявления или перечислить обязательные поля, но не должна подтверждать юридический факт без проверки специалистом. Вопросы о возврате средств, блокировке учётной записи и изменении договора я сразу отношу к маршрутизации.
Для примера: из 100 обращений интернет-магазина 55 могут относиться к статусу доставки и правилам получения, 25 потребуют уточнения номера заказа, а 20 будут связаны с претензиями или возвратом денег. Это не готовый результат конкретной компании, а схема для расчёта пилота.
При подготовке ответов полезно разделять черновик и утверждённый текст. Нейросеть создаёт структуру из 2–4 абзацев, а редактор сверяет факты, ссылки и условия применения. Методика работы с черновиками описана в статье нейросеть для генерации текста и проверка результата.
Какие обращения лучше маршрутизировать специалисту
Маршрутизировать нужно сообщения, где есть риск ошибки, неполные данные или несколько разных намерений. На практике достаточно 5 признаков, чтобы остановить автоматический ответ: деньги, персональные сведения, конфликт, юридические последствия и отсутствие точного источника.
Обращение нельзя закрывать шаблоном, если клиент просит изменить платёжные реквизиты, отменить списание или восстановить доступ после подозрительной активности. Даже при ясном тексте система может не знать, прошёл ли платёж, кто имеет право на изменение и какие ограничения действуют для конкретного аккаунта.
Отдельная группа, сложные сообщения с 2 и более вопросами. Например, клиент одновременно сообщает о задержке доставки, просит заменить товар и требует компенсацию. Нейросеть способна выделить намерения, но итоговый ответ должен формировать сотрудник, который видит полную историю обращения.
Тон сообщения тоже имеет значение. Слова «претензия», «суд», «жалоба», «обман» или «верните деньги» не доказывают нарушение, но служат сигналом для дополнительной проверки. В таком случае автоматический ответ лучше ограничить подтверждением получения запроса и сроком обратной связи.
| Тип обращения | Действие | Условие автоматического ответа | Когда нужен человек |
|---|---|---|---|
| Статус заказа или заявки | Закрыть | Есть номер и актуальный статус | Данные не найдены или расходятся |
| Инструкция из 3–7 шагов | Закрыть или уточнить | Действие не связано с деньгами | Возникает ошибка или нужен доступ к аккаунту |
| Два и более вопроса | Маршрутизировать | Можно выделить отдельные простые части | Есть претензия, компенсация или спор |
| Платёж, возврат, договор | Передать специалисту | Только справочная информация без изменения данных | Всегда при запросе на действие |
| Оскорбление, угроза, жалоба | Передать с приоритетом | Допустимо лишь подтвердить получение | При наличии конфликта или риска эскалации |
Такое разделение снижает соблазн измерять успех одной цифрой. Доля автоматических ответов сама по себе ничего не говорит, если после них пользователи повторно пишут в поддержку.
Как построить маршрутизацию из 4 понятных веток
Рабочая схема состоит из 4 веток: «закрыть», «уточнить», «передать» и «остановить автоматизацию». Эти статусы должны быть понятны оператору, редактору базы знаний и руководителю очереди.
Сначала нейросеть определяет намерение сообщения. Я рекомендую использовать короткий справочник с полями: категория, обязательные данные, разрешённое действие, запрещённое действие и отдел-получатель. Такой формат легче проверять, чем длинное описание на несколько экранов.
Затем система оценивает полноту входных данных. Для вопроса о доставке может понадобиться номер заказа, для технической проблемы, версия приложения и описание ошибки, для возврата, дата покупки и основание запроса. Если обязательного поля нет, правильный результат не «ответить наугад», а задать один конкретный уточняющий вопрос.
Третья ветка отвечает за передачу. В карточке обращения должны сохраниться исходный текст, выделенное намерение, собранные данные и причина эскалации. Оператору не придётся заново читать 8 сообщений, чтобы понять, что уже сообщил клиент.
Четвёртая ветка, остановка автоматизации, нужна для опасных или непредсказуемых сценариев. Её применяют при сбое источника данных, конфликте между двумя правилами и повторном обращении после неудачного ответа. Я бы добавил сюда и сообщения, где уверенность классификации ниже установленного порога, например 80%.
Гипотетический пример: в очереди из 1 000 обращений 620 сообщений относятся к справочным вопросам, 180 требуют уточнения, 150 направляются в профильные отделы, а 50 блокируются для ручной обработки. При повторной проверке 30 ответов из первой группы могут оказаться спорными. Их нужно вернуть в набор для редакции, а не считать безусловным успехом.
Маршрутизация хорошо работает, когда названия категорий не пересекаются. Если «оплата», «возврат» и «ошибка платежа» описывают одну и ту же ситуацию разными словами, классификатор будет колебаться. Я свожу справочник к 10–20 устойчивым темам, а редкие случаи оставляю в ручной очереди.
Как измерить влияние на скорость ответа и нагрузку команды
Результат нужно измерять минимум по 5 показателям: время первого ответа, доля закрытых обращений, доля передач, повторные сообщения и оценка клиента. Один показатель не отражает качество всей цепочки.
Время первого ответа считают от момента поступления сообщения до первой содержательной реакции. Простое уведомление «мы получили запрос» не должно считаться полноценным ответом, если договорный срок требует решения. Для очереди из 200 сообщений полезно смотреть медиану и 90-й процентиль: среднее значение может скрыть длинный хвост задержек.
Доля автоматического закрытия рассчитывается так:
закрытые без оператора обращения / все обращения × 100%.
Если из 500 сообщений 275 получили подтверждённый ответ без передачи, показатель равен 55%. Но рядом нужно проверить долю повторных обращений в течение 24 или 48 часов. Рост повторов означает, что формально закрытые сообщения не решили задачу.
Доля маршрутизации показывает нагрузку на специалистов. Её не следует сводить к нулю: передача сложного случая человеку является правильным результатом. Я бы установил отдельные нормы для разных категорий. Для справочных вопросов допустим высокий уровень автоматизации, для платежей и договоров, минимальный.
Повторное сообщение в течение 48 часов можно считать сигналом недовольства или неполного ответа. Полезно разбирать 20–30 таких цепочек каждую неделю, отмечая причину: ошибка факта, не тот отдел, слишком общий текст, пропущенный вопрос или отсутствие следующего шага.
Условный пример: после 14-дневного пилота доля ответов без оператора выросла с 18% до 46%, но повторные сообщения увеличились с 7% до 13%. Такой результат нельзя объявлять улучшением. Сначала нужно сократить набор автоматических сценариев, исправить 5 наиболее частых ошибок и повторить замер на сопоставимом объёме.
Как подготовить пилот без перестройки всей поддержки
Для первого пилота достаточно 7 дней наблюдения и 14 дней тестирования на ограниченной группе обращений. За это время можно получить исходную линию, сравнить категории и увидеть повторяющиеся ошибки.
Я начинаю с выгрузки 100–300 обезличенных сообщений. В наборе должны быть разные формулировки одного намерения, короткие вопросы, длинные цепочки и примеры с неполными данными. Персональные сведения, номера карт, пароли и токены нужно удалить до передачи текста в любой внешний инструмент.
Затем формирую таблицу правил. В ней фиксирую название категории, образец запроса, допустимый ответ, условие передачи и ответственного сотрудника. Для одного сценария достаточно 5–10 примеров, но редкие исключения нужно хранить отдельно, чтобы они не размывали основной шаблон.
В веб-чате SoftChat можно переключать модель в рамках разговора и получать ответ по мере его формирования. Это удобно для подготовки черновых сценариев и последовательного уточнения требований в одном диалоге. Сам чат не заменяет внутренний регламент: итоговые правила всё равно нужно сверить с источником данных и ответственным специалистом.
Запрос к нейросети я строю из 6 частей: роль, задача, входные данные, разрешённые действия, запреты и формат результата. Например:
Ты классифицируешь обращения службы поддержки. Определи одну категорию из списка: «закрыть», «уточнить», «передать», «остановить». Укажи недостающие данные, причину выбора и короткий черновик ответа. Не обещай возврат денег, не меняй данные клиента и не выдумывай статус заказа.
Такой запрос задаёт границы, но не гарантирует правильность каждого ответа. Я проверяю минимум 50 результатов вручную, отдельно отмечаю ложные закрытия и передаю спорные примеры на повторную разметку. Больше приёмов для точной постановки задачи собрано в статье как правильно формулировать запросы для нейросетей.
Где человек должен оставаться в контуре
Человек должен принимать решения по 4 группам случаев: деньги, доступ, конфликт и неоднозначные данные. Даже высокий процент уверенности нейросети не отменяет этого ограничения.
Оператору нужен короткий пакет для передачи. Я включаю в него тему, исходный вопрос, извлечённые факты, пропущенные поля, рекомендованный отдел и причину остановки. Если клиент уже получил автоматический ответ, его текст тоже нужно показать специалисту, иначе сотрудник может повторить ту же ошибку.
Для контроля качества назначается редактор правил. Он раз в неделю просматривает 20–30 закрытых цепочек и все случаи повторной передачи. В журнале достаточно 5 колонок: дата, категория, ошибка, решение и изменение правила.
Компания из сферы логистики, около 200 сотрудников, может получать 300 обращений в день по доставке, документам и претензиям. Для такой структуры разумно автоматизировать справочные вопросы, а запросы о компенсации передавать в отдельную очередь. Размер команды здесь важнее самого факта использования нейросети: при 2 операторах и при 20 специалистах одинаковое правило даст разную нагрузку.
Автоматизация должна иметь понятный выход. Если ответ не найден за 2 попытки, клиент повторил вопрос или сообщил о вреде от предыдущего действия, цепочка передаётся человеку. Это проще объяснить сотрудникам и легче проверить по журналу.
Какое решение принять на старте
На старте я бы разделил работу на 3 этапа: семь дней измерения, четырнадцать дней ограниченного пилота и еженедельный разбор ошибок. Нейросети стоит отдавать справочные вопросы с ясным ответом, а маршрутизацию использовать для денежных, конфликтных и неполных обращений.
После пилота решение принимают по совокупности показателей. Если время первого ответа снизилось, повторные сообщения не выросли, а спорные случаи стабильно доходят до специалистов, набор сценариев можно расширить. Если автоматические ответы ускорили очередь ценой новых жалоб, безопаснее сократить область применения и обновить правила.
Я бы сохранял в работе даже небольшой ручной контур: 20–30 проверенных цепочек в неделю дают больше пользы, чем отчёт с одной красивой процентной цифрой. Нейросеть должна снимать повторяемую часть работы, а не скрывать сложные обращения внутри общей статистики. Практический план внедрения рабочих сценариев с распределением ролей и этапов есть в материале как внедрить нейросети в рабочие процессы.