Как разгрузить поддержку с помощью нейросети
Нейросеть в поддержке полезна там, где повторяемые вопросы получают предсказуемые ответы, а сложные обращения вовремя переходят к оператору.
Я разбираю поддержку как очередь задач, а не как набор разрозненных диалогов. Сначала отделяю вопросы о доставке, оплате и настройках от конфликтных или нестандартных обращений. Затем собираю карту намерений, задаю правила ответа и проверяю результат на отложенной выборке. Такой порядок помогает сохранить тональность бренда и не превращать автоматизацию в бесконтрольную рассылку шаблонов.
Разберите очередь до настройки ответов
Начинать нужно со 100–200 последних диалогов: по такой выборке я вижу повторяемые формулировки, причины обращений и места, где оператор тратит время впустую.
Я выгружаю обращения за 2–4 недели и для каждого фиксирую пять полей: тему, цель клиента, использованный ответ, итог и необходимость передачи специалисту. Текст вопроса сам по себе мало что говорит. Фразы «не пришёл заказ» и «где моя посылка» могут относиться к одной теме, а одинаковое слово «оплата» встречается и в вопросе о сроке возврата, и в сообщении о двойном списании.
Дальше я делю очередь на четыре группы:
- Повторяемые вопросы с коротким ответом. Например, сроки доставки, перечень документов, порядок смены пароля.
- Запросы, где нужно получить данные из системы. Нейросеть может объяснить следующий шаг, но не должна придумывать статус заказа или сумму возврата.
- Ситуации с риском конфликта. Сюда попадают претензии, повторное обращение после неудачного ответа и сообщения с юридическими формулировками.
- Сложные технические случаи. Для них нужен оператор, журнал действий и понятная причина эскалации.
Условный пример: интернет-магазин разбирает 120 обращений и обнаруживает 36 вопросов о доставке, 24 запроса о возврате, 18 сообщений о входе в аккаунт и 42 нестандартных случая. В такой картине FAQ стоит собирать для первых трёх тем, а последние обращения использовать как тест на границы автоматизации.
Полезно сразу посчитать долю повторов, среднее время ответа и процент переводов на второй уровень. Если оператор вручную просматривает 80 диалогов в смену, а 50 из них повторяют уже известную инструкцию, узкое место находится в поиске и формулировке ответа, а не в нехватке новых сотрудников. Методика внедрения рабочих сценариев подробнее разобрана в статье как внедрить нейросети в рабочие процессы.
Соберите FAQ как карту намерений
Рабочий FAQ состоит минимум из 20–30 намерений, а каждое намерение получает отдельные условия ответа, источник данных и правило передачи оператору.
Я не складываю вопросы в один длинный документ. Для каждой темы создаю карточку со следующими полями:
- название намерения, например «условия возврата»;
- варианты формулировок клиента, включая короткие и эмоциональные сообщения;
- точный ответ, разбитый на 2–5 предложений;
- ссылка на действующий внутренний источник;
- дата последней проверки;
- условие, при котором разговор переходит человеку.
У ответа должен быть владелец. Если правила доставки меняются раз в месяц, карточку проверяют перед каждым обновлением тарифов. Если инструкция не менялась 180 дней, это ещё не доказывает её актуальность, поэтому я сверяю текст с действующим регламентом, а не с датой публикации.
Для примера: из 100 диалогов 18 содержат вопрос «Как вернуть товар?», но в 6 случаях клиент уточняет повреждение упаковки, срок покупки или отсутствие чека. Значит, одной универсальной фразы мало. В карточке нужны базовый ответ и три развилки, иначе нейросеть будет уверенно выдавать инструкцию, которая подходит лишь части обращений.
Формулировку запроса я строю по схеме «роль, задача, источник, ограничения, формат». Например: «Ты помощник службы поддержки. Ответь на вопрос о возврате по правилам из блока ниже. Не называй срок, если его нет в источнике. Если клиент сообщает о повреждении, передай обращение оператору. Ответ дай в четырёх предложениях». Такой подход связан с качеством промпта, а примеры структуры есть в материале как правильно формулировать запросы для нейросетей.
Тональность лучше описывать наблюдаемыми признаками. «Будь дружелюбным» слишком расплывчато. Рабочее правило выглядит конкретнее: обращаться на «вы», не использовать восклицательные знаки в претензиях, начинать с признания проблемы, давать один следующий шаг и не обещать срок без подтверждения. Я сохраняю 5–7 хороших ответов операторов как примеры ритма, длины и допустимых формулировок, но не копирую их механически.
Настройте маршрутизацию сложных запросов
Маршрутизацию я свожу к 4 решениям: ответить по FAQ, запросить уточнение, передать специалисту или пометить обращение как срочное.
Первое решение подходит, когда намерение распознано, источник ответа актуален, а вопрос не требует персональных данных. Второе нужно, если клиент написал «не работает» без названия функции, даты и описания ошибки. Вместо длинной догадки система задаёт один конкретный вопрос, например просит указать устройство или номер обращения.
Третье решение срабатывает при конфликте, финансовом споре, подозрении на ошибку в данных или повторном обращении. Четвёртое применяют для ограниченного набора сигналов, например недоступности важной функции у большого числа пользователей. Список срочных признаков должен быть коротким. Если срочным считать каждое эмоциональное сообщение, очередь операторов быстро заполнится.
Я задаю правила в виде таблицы:
| Сигнал | Действие | Что получает оператор |
|---|---|---|
| Намерение совпало с FAQ, риск низкий | Отправить ответ | Тема и текст обращения |
| Не хватает одного факта | Задать уточняющий вопрос | Уже собранные сведения |
| Финансовый спор или повторная жалоба | Передать специалисту | История диалога и причина передачи |
| Признак массового сбоя | Пометить срочно | Время, функция и число похожих обращений |
Не стоит скрывать от оператора факт участия нейросети. В карточке передачи я оставляю исходный вопрос, предложенный ответ, сработавшее правило и уровень уверенности, если такая оценка доступна. Человек должен понимать, почему диалог оказался у него, иначе проверка превращается в повторное чтение всей переписки.
Для маршрутизации полезно установить лимит повторных уточнений. Мой рабочий предел составляет 2 попытки. После второй неудачи обращение уходит оператору с пометкой «не удалось классифицировать», а клиент не получает третий круг одинаковых вопросов.
Проверьте качество и тональность на выборке
Контроль качества начинается с 5 показателей: точность фактов, полнота ответа, соответствие тону, правильность маршрута и время до первого сообщения.
Я формирую тестовый набор из 50 обычных FAQ, 20 пограничных вопросов и 10 сообщений с неполными данными. В каждой проверке ставлю оценку от 0 до 2 по каждому показателю. Ноль означает критическую ошибку, единица требует правки, двойка показывает приемлемый результат. Максимум для 80 диалогов составляет 800 баллов, но средняя сумма не заменяет проверку провалов: один неверный ответ о возврате может быть опаснее десяти неудачных ответов о графике работы.
Отдельно проверяю отрицания, даты и числа. Нейросеть может перепутать «не списывать» и «списать», принять дату оформления за дату доставки или убрать ограничение из длинного регламента. В тестах я меняю порядок слов, добавляю опечатки и сокращаю контекст до одного предложения. Так видно, работает ли сценарий по смыслу или запоминает удачную формулировку.
Тональность проверяю по четырём признакам: обращение на «вы», отсутствие обвинений, ясный следующий шаг и совпадение с лексикой бренда. Слова «вы обязаны» и «сами виноваты» могут разрушить доверие даже при фактически правильной инструкции. Для претензий я задаю отдельный стиль: сначала признать неудобство, затем объяснить доступный вариант, после этого назвать срок или запросить недостающие сведения.
Раз в неделю я беру 30 новых диалогов и сравниваю их с тестовым набором. Если появилась новая формулировка, её добавляю в примеры намерения. Если один и тот же сбой повторился 3 раза, меняю инструкцию или источник, а не маскирую проблему дополнительной вежливой фразой.
Для анализа результатов пригодятся показатели AHT, SLA и CSAT. AHT показывает среднее время обработки, SLA отражает соблюдение обещанного срока, а CSAT помогает увидеть реакцию клиента. Я смотрю их вместе: снижение AHT при падении CSAT означает, что ответы стали быстрее, но менее полезными. Общая логика проверки текстов и черновиков описана в статье нейросеть для генерации текста и проверка результата.
Выберите режим автоматизации по риску
Для поддержки есть 3 режима: черновик для оператора, частичная автоматизация FAQ и полная обработка низкорисковых вопросов.
| Режим | Что делает нейросеть | Контроль человека | Когда применять |
|---|---|---|---|
| Черновик ассистента | Предлагает ответ и выделяет тему | Оператор проверяет каждый текст | Новый FAQ, сложная тональность, дорогая ошибка |
| Частичная автоматизация | Отвечает на утверждённые намерения | Проверяется выборка 10–20% и все эскалации | Повторяемые вопросы с понятным источником |
| Полная обработка | Ведёт типовой диалог по жёстким правилам | Контроль исключений и регулярный аудит | Низкий риск, стабильный регламент, простой следующий шаг |
Я начинаю с черновиков, когда в базе меньше 30 проверенных намерений или регламенты часто меняются. Частичный режим подходит, если ответы прошли тест на 80 диалогах и оператор понимает логику передачи. Полную обработку оставляю для тем, где ошибка исправляется одним понятным действием и не затрагивает деньги, доступ или юридические обязательства.
В веб-чате SoftChat можно переключать модели по ходу разговора, а ответы поступают потоково. Это удобно для редакторской проверки: одну модель можно использовать для черновика, другую для критики формулировок, после чего оператор сравнивает варианты. Саму схему поддержки всё равно задают регламенты, тестовые вопросы и правила эскалации, а не выбор модели.
Если нужен бытовой ориентир, сравните подходы в статье Алиса или нейросеть в браузере: что выбрать. Там полезен сам принцип выбора по задаче, уровню контроля и цене ошибки, его можно перенести на поддержку.
Внедрите процесс за 7 рабочих дней
План на 7 рабочих дней я делю на сбор данных, настройку сценариев, тестирование и ограниченный запуск.
В первый день команда выбирает 100–200 диалогов и фиксирует базовые показатели: AHT, долю повторов, число переводов оператору и CSAT, если он уже собирается. Во второй день обращения раскладываются по намерениям, а для каждой группы назначается владелец источника.
На третий день пишутся 20–30 карточек FAQ. В каждой должны быть ответ, ограничения, дата проверки и условие эскалации. Четвёртый день уходит на тестовый набор из 80 сообщений, включая опечатки, короткие реплики и конфликтные формулировки.
В пятый день оператор проверяет результаты по шкале от 0 до 2. Шестой день нужен для исправления источников, промптов и маршрутов. В седьмой день запускается ограниченная группа намерений, например вопросы о графике, доставке и восстановлении доступа. Финансовые споры и претензии в первый запуск я не включаю.
Для команды полезно заранее определить владельцев: один отвечает за актуальность базы, второй проверяет тональность, третий смотрит метрики. Если один человек совмещает все роли, проверка часто откладывается при первой загрузке. Практика работы с повседневными сценариями и рутинными задачами разобрана в материале как использовать нейросети для повседневных задач.
Мой рабочий порядок
На моём месте я бы начал с 2 этапов: сначала подготовил 20–30 намерений в режиме черновиков, затем открыл клиентам только низкорисковые FAQ после проверки 80 тестовых сообщений.
Дальше я смотрел бы на три сигнала: долю повторных вопросов, число эскалаций после неудачного ответа и изменение CSAT. Если обращений к оператору становится меньше, но растёт число повторных сообщений, сценарий нельзя считать удачным. Нужно проверить полноту инструкции, ясность следующего шага и соответствие ответа реальному регламенту.
Нейросеть хорошо разгружает поддержку там, где у команды есть проверенный источник, ограниченный набор намерений и понятная граница ответственности. Оператор при этом сохраняет контроль над конфликтными, финансовыми и нестандартными случаями. Такой процесс масштабируется через регулярный аудит, а не через безусловное расширение списка автоматических ответов.