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

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

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

Маршрут обращения в поддержкеПроверка фактов важнее скорости ответаВопросТема и контекстПроверкаИсточник и рискОтвет ИИЧерновик и уточнениеЧеловекРешениеСпор о деньгах, претензия или конфликт источников всегда требуют проверки специалиста
Инфографика

Какие вопросы можно передать ИИ

Оператор поддержки сортирует типовые обращения с помощью нейросети

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

К первой группе относятся вопросы «Где мой заказ?», «Какие способы оплаты доступны?» и «Сколько длится доставка?». Ко второй относятся просьбы найти раздел личного кабинета, объяснить порядок оформления возврата или подсказать, куда отправить документы. Инструктивные обращения можно разложить на последовательность из 3–6 действий, если каждый шаг описан в базе знаний.

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

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

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

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

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

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

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

У каждой статьи базы знаний нужен срок пересмотра. Для тарифов, условий доставки и возвратов я бы поставил проверку раз в 14 или 30 дней, для стабильных инструкций по интерфейсу, раз в квартал. Дата сама по себе не делает сведения верными, поэтому нужна ответственная роль, которая подтверждает изменение.

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

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

Как измерить экономию времени операторов

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

Метрика Как считать Что считать здоровым сигналом
Корректность Доля ответов без фактической ошибки в выборке из 100 обращений Показатель растёт после каждой правки базы знаний
Время до первого ответа Интервал от сообщения клиента до первого содержательного ответа Интервал сокращается без роста жалоб
Передача оператору Доля диалогов, где понадобился сотрудник Передача происходит по правилам, а не случайно
Повторное обращение Число повторных вопросов по той же проблеме за 7 дней Доля снижается после уточнения инструкций
Оценка клиента Средняя оценка после закрытия обращения Оценка не падает при росте скорости

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

Модельный кейс: компания из сферы логистики, около 200 сотрудников, анализирует 300 обращений за месяц. Если 180 вопросов относятся к статусам и правилам доставки, команда может сначала проверить на них два варианта инструкции, а затем сравнить 100 ответов до изменений и 100 после. Здесь нельзя заранее заявлять экономию в процентах. Результат зависит от полноты статусов, качества данных и дисциплины операторов.

Расчёт времени выглядит так: число обращений умножается на среднее время ручной обработки, затем из результата вычитается время проверки ответа ИИ. Если 120 обращений требуют по 4 минуты на повторяющийся ответ, общий объём равен 480 минутам, или 8 часам. При проверке каждого черновика в течение 1 минуты экономия составит 360 минут, если все 120 ответов действительно подходят для такого сценария. Это расчёт модели, а не обещание для любой службы поддержки.

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

В каких случаях нужен человек

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

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

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

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

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

Для обучения новых операторов полезен подход, описанный в материале о применении нейросетей в образовании: ИИ помогает разбирать примеры и задавать вопросы, но не заменяет проверку наставника. В поддержке это означает разбор 10–20 диалогов с объяснением каждой передачи специалисту.

Как использовать SoftChat в сценарии поддержки

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

Для текстовой поддержки рабочей остаётся вкладка «Текст». Вкладка «Графика» пригодится для визуальных материалов, если службе нужно объяснить процесс схемой. Вкладка «Видео» отмечена как «Скоро», а «Код», «Аудио» и «Презентации» находятся в разработке, поэтому строить текущий сценарий поддержки на этих режимах не следует.

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

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

Как провести пилот за 14 дней

Пилот можно провести за 14 дней, если ограничить его одной очередью и 2–3 повторяющимися темами. Целью должна быть проверка гипотезы, а не попытка сразу охватить все обращения.

В первые 2 дня я выбираю темы и собираю 100–200 обращений для разметки. На 3–5-й день редактор проверяет правила, убирает устаревшие документы и формирует карточки базы знаний. В период с 6-го по 8-й день команда готовит инструкции для нейросети и список ситуаций, требующих оператора.

С 9-го по 11-й день ответы проверяются в теневом режиме: клиент получает обычную поддержку, а нейросеть готовит параллельный черновик. Проверяющий не оценивает стиль отдельно от фактов, а ставит отметки по четырём категориям ошибок. На 12–14-й день сравниваются время ответа, повторные вопросы, доля передачи оператору и оценка клиентов.

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

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

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

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

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