Внедряю ИИ в клиентский сервис с 2023-го. Пишу про то, что происходит с процессами и людьми после внедрения.
Про границы автоматизации согласен, но у цифры 7% есть обратная сторона: доверяют не тому, кто умнее, а тому, у кого виден выход. В проектах, которые я видел, раскрытие «вы говорите с роботом» конверсию не уронило. Людей пугает не бот, а ситуация, где из него нельзя выйти к человеку.
Поэтому передача оператору для меня часть сценария, а не запасной вариант. Интересно, видел ли кто-то, чтобы «ручной тормоз» в автопокупках реально повышал готовность включать автопилот, а не просто успокаивал?
С записями и речевой аналитикой есть практическая тонкость: полезнее общих оценок разбор по шагам диалога. В голосовых проектах с ассистентами, которые я видел, доля перебиваний по шагам показывала слабое место сценария раньше, чем появлялись жалобы и просьбы позвать оператора.
Для отдела продаж, думаю, подход тот же: искать в записях шаг скрипта, на котором клиента чаще всего что-то сбивает, а не только считать оценки менеджеров.
Самое полезное для меня здесь четвертый этап: человек подключается по уровню риска, а не ко всему подряд. В клиентском сервисе такая же логика передачи оператору: границу лучше задавать по цене ошибки в теме обращения, а не по общей уверенности системы.
Правило трех раундов хорошо ложится на голосовые сценарии: если ассистент после нескольких попыток не справился, разговор лучше передать человеку, а не продолжать цикл. Интересно, как у них выбирался порог: по числу попыток или по типу изменения?
С диагнозом в заголовке не согласен: сам текст как раз про то, что финальное решение остается за человеком. В клиентском сервисе после автоматизации первой линии клиенты стали сразу говорить «оператор», то есть человеку достается то, что автомат не закрыл.
Поэтому смотреть стоит не на долю автоматизации, а на то, где человек вынужден вмешиваться. С голосовыми ассистентами так же: доля перебиваний по шагам диалога быстро показывает слабое место сценария, раньше жалоб и передач оператору.
Градация по цене ошибки здесь самое полезное, и в клиентском сервисе она нужна не меньше. Фразу про то, что одобрение ИИ не заменяет человека на критичных участках, я бы расширил: граница должна идти по цене ошибки для клиента, а не по сложности запроса.
В проектах по автоматизации первой линии, которые я вел, после запуска люди сами стали сразу говорить «оператор». Значит, граница между автоматом и человеком формируется быстро, только у компании она часто остается ненаписанной.
Подключить агента к CRM и почте это половина дела. Вторая половина в том, где он должен остановиться и позвать человека. С 2023 года занимаюсь ИИ в клиентском сервисе, и граница «где нужен человек» определяется не моделью, а сценарием, который приходится прописывать заранее.
После автоматизации первой линии люди стали сразу говорить «оператор», так что доверие к агенту надо зарабатывать. Любопытно, как в Cowork устроена передача задачи человеку, когда агент не уверен.
С диагнозом согласен, добавил бы только одно: готовая система не спасает плохой процесс, она просто быстрее его масштабирует. В моей практике внедрения ИИ в поддержку это видно, когда первую линию автоматизировали, а правила передачи заявки человеку остались размытыми.
После запуска люди стали сразу говорить «оператор», и заявка падала в ту же ручную маршрутизацию, что в вашем антикейсе. Поэтому выбор «свое или готовое» я бы начинал с вопроса, кто и по каким правилам принимает заявку дальше.
Точнее всего здесь зеленые графики у поддержки при том, что клиент не может оплатить. В голосовом канале так же: отчет показывает принятые звонки и время разговора, а человек уже бросил трубку. Метрика доступности отвечает про серверы, а не про то, дошел ли клиент до результата.
Про отложенный режим добавлю из практики голосовых ассистентов: клиенты тяжелее переносят не отказ, а тишину без статуса. Текст на этот случай я бы писал раньше, чем настраивал сам режим.
Письменное подтверждение исполнителя хорошо закрывает вопрос «понял ли». Протокол при этом остается пересказом: в нем то, что показалось важным тому, кто его писал. В проектах, которые я видел, так же руководитель узнавал о разговорах с клиентами, и фильтр пересказчика в отчете не виден.
Поэтому для задач про клиентский сервис я бы привязывал контрольную точку не к протоколу, а к самим разговорам. Вы разбираете сорванные сроки по первоисточнику или по записям на встрече?
Мне близка мысль, что одобрение ИИ не заменяет обязательного человека, а уровень риска решает, кто смотрит. В клиентском сервисе та же логика: чем дороже ошибка, тем раньше разговор должен уйти к оператору. После автоматизации первой линии в проектах, которые я видел, люди стали сразу говорить «оператор», и это нормальный сигнал, а не провал.
Любопытно, как у Anthropic проверяют сам классификатор риска: кто смотрит на его ошибки?