ИИ в поддержке: когда отвечать клиенту, а когда передавать оператору

Разделите вопросы по цене ошибки

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

Например, вопрос «Где посмотреть статус заказа?» может решаться ссылкой на личный кабинет. Жалоба «Мне списали деньги дважды» требует проверки платежей и доступа к данным; в первом пилоте лучше передать её оператору. Такую карту вопросов утвердите с руководителем поддержки, а не только с разработчиком.

Постройте базу ответов с владельцами

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

В документации Microsoft о knowledge sources для Copilot видно, что качество ответов зависит от подключённых источников. Сам факт подключения документа не делает его актуальным. Проверьте, какие файлы доступны агенту и на что он ссылается в каждом тестовом ответе.

Явно задайте признаки передачи оператору

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

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

Как должен выглядеть переход для клиента

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

Учебный пример: «Я не могу проверить списание по переписке. Передаю вопрос оператору; ваше сообщение и номер заказа уже приложены. Ответим в рабочее время по указанному каналу». Формулировку и срок компания должна подтвердить под собственный регламент.

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

Измеряйте качество, а не только долю автоматизации

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

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

С чего безопасно запустить пилот

Выберите 2–3 категории с проверенными ответами, включите черновики для операторов или ограниченный автоматический ответ, подготовьте кнопку передачи человеку и журнал решений. На первой неделе ежедневно смотрите ошибки. Расширяйте охват только после того, как система показывает источник, признаёт пробел и передаёт сложный случай без потери контекста.

Вопросы, которые стоит задать оператору после пилота

Стало ли меньше повторных объяснений? Видно ли, почему бот передал случай? Приходится ли исправлять неверно определённую тему? Какие обращения агент удерживает слишком долго? Оператор видит последствия автоматизации раньше общей статистики. Его наблюдения нужно собирать системно, а не только после жалобы клиента.

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

Сделайте карту ответственности по категориям

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

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

Проверьте беседу после передачи

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

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

Как разбирать ошибочный автоматический ответ

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

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

Частый вопрос: заменит ли агент первую линию

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

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