4 сентября 2026 г.
Когда вашему ИИ-агенту поддержки пора замолчать
Полезный агент поддержки — не тот, что любой ценой держит каждый диалог в автоматическом режиме. А тот, что знает свой предел и передаёт работу человеку, не заставляя клиента начинать всё заново.
Клиент пишет в поддержку: экспорт дважды завершился ошибкой. ИИ объясняет, как устроен экспорт, просит попробовать ещё раз, а когда клиент возвращается, выдаёт тот же ответ. Клиент закрывает чат. В дашборде растёт уровень автоматизации. Руководство поддержки видит, что передач оператору стало меньше. И нигде не записано, что экспорт так и не прошёл. Ценность ИИ-агента поддержки не в том, что он может говорить без остановки. Она в том, чтобы двигать проблему к решению — в том числе понимать, когда пора остановиться.
Уровень автоматизации поощряет упорство, а не здравый смысл
Уровень автоматизации отвечает на узкий вопрос маршрутизации: закончился ли автоматический диалог до того, как подключился человек? Для планирования нагрузки это важно. Но это ничего не говорит о том, сделал ли клиент то, ради чего вообще пришёл.
В реальных внедрениях эта разница стирается. Опрос 150 руководителей клиентского сервиса, который Dialpad провёл в 2026 году, показал: 39% включают в определение «проблема решена» молчание клиента, а 51% считают обращение закрытым без участия человека независимо от того, занимался ли кто-то самой проблемой. Уровень автоматизации отслеживали чаще, чем долю решённых проблем. В выборку вошли руководители из ритейла и здравоохранения, так что это не универсальный ориентир для SaaS. И всё же эти определения — полезное предупреждение: служба поддержки может выстроить подробную систему метрик поверх результата, которого никто никогда не видел.
Более масштабное исследование Ada и NewtonX, в котором участвовали 2 000 потребителей и 500 руководителей крупных компаний, показало: лишь каждый четвёртый потребитель сказал, что его последнее обращение к ИИ-сервису было полностью решено без участия человека. Кроме того, 44% компаний измеряют взаимодействия с ИИ и с людьми вместе. К исследованиям, которые заказывает вендор, стоит относиться с обычной осторожностью, но оба вывода вскрывают одну и ту же проблему атрибуции. Команды видят, что автоматизация касалась обращения, но не знают, что именно решило проблему.
Возьмём три чата о сбое экспорта, которые закрылись без оператора:
1. ИИ находит неверный диапазон дат, клиент исправляет его, и экспорт проходит.
2. ИИ даёт ссылку на статью, которую клиент уже читал, и клиент сдаётся.
3. ИИ обещает связаться с поддержкой, но никакой тикет на самом деле не отправляется.
Решён только первый случай. А дашборд автоматизации засчитывает все три одинаково.
Закончившийся диалог доказывает лишь то, что диалог закончился. Без других сигналов он не доказывает, что клиент добился своего, понял ответ или собирается остаться.
Решению остановиться нужна причина
Выход не в том, чтобы снизить общий порог уверенности. Уверенность бывает плохо откалибрована, а уверенному агенту всё равно может не хватать данных или полномочий, чтобы довести дело до конца. Решение о передаче человеку должно опираться на наблюдаемые состояния сбоя.
Состояние сбоя · Что видит продукт · Верный следующий шаг
Ответу не на что опереться · На текущей странице и в одобренных источниках знаний нужного факта нет · Сказать, чего не хватает, и предложить связаться с человеком
Действие не выполнено · Ожидаемое состояние так и не наступило, хотя лимит повторных попыток исчерпан · Сохранить попытку и передать проблему человеку
Граница полномочий · Запрос требует человеческого суждения, исключения из правил или доступа, которого у ИИ нет · Передать обращение тому, у кого есть полномочия
Явное желание · Клиент просит соединить его с человеком · Передать без споров и без нового круга с ботом
Растущая срочность · Дедлайн, повторное обращение или нарастающее раздражение повышают цену промедления · Предложить человека раньше
Это разные состояния. Нет нужной статьи в справке — проблема знаний. Кнопка, которая раз за разом выдаёт одну и ту же ошибку, — проблема продукта или аккаунта. Исключение при возврате денег — проблема полномочий. Более гладкий текст не решает ни одну из них.
Просьба клиента тоже должна быть решающей. В начале 2026 года Gartner опросила 3 566 клиентов из B2B и B2C и выяснила: 87% считают доступ к человеку обязательным, когда компания использует генеративный ИИ в обслуживании. Заметный путь к человеку — не признание того, что стратегия автоматизации провалилась. Это часть самого сервиса.
От того, как запускается передача, зависит исправление сбоя
Формально многие продукты предлагают поддержку живого человека, но заставляют клиента угадывать волшебную фразу, трижды отказываться от бота или рыскать по меню. На блок-схеме передача есть, а в интерфейсе она не работает.
Три онлайн-эксперимента, опубликованные в журнале Decision Support Systems, изучали четыре способа подключить человека после сбоя чат-бота: пассивный путь, текстовый запрос, кнопку и автоматический запуск. Удовлетворённость тем, как исправили сбой, зависела от способа, а срочность эти различия усиливала. Одной аннотации мало, чтобы объявить какой-то механизм лучшим для любого случая. Но она показывает главное: запуск передачи — часть опыта исправления сбоя, а не нейтральная обёртка вокруг него.
В практичной системе путей к человеку несколько:
– Держите путь к человеку открытым: клиент не должен сначала потерпеть неудачу, чтобы им воспользоваться.
– Воспринимайте прямую просьбу позвать человека как команду, а не как возражение, которое нужно отработать.
– Пусть ИИ сам предлагает передачу, когда упирается в предел данных, исполнения или полномочий.
– При известных критических сбоях и в срочных сценариях открывайте передачу автоматически, но не отправляйте сообщение и не делитесь данными без подтверждения клиента.
Момент важен: позднее вмешательство получает в наследство уставшего клиента и уже остывшего оператора. Рандомизированный полевой эксперимент в службе поддержки Taobao, маркетплейса Alibaba, показал, что раннее подключение человека помогает сотрудникам не сбавлять усилий в эскалированных диалогах. Кроме того, технические и эмоциональные поводы для эскалации дали разные результаты. Это препринт по одному крупному маркетплейсу, а не универсальное правило, но он подкрепляет полезное различие: логика эскалации должна учитывать тип сбоя и момент, когда он случился, а не только общую оценку тональности.
Проактивность здесь не означает молча завести тикет. Она означает сократить путь от сбоя, который система уже распознала, до понятного выбора, как его исправить, — выбора, который остаётся за клиентом.
Передавайте состояние проблемы
Отправить в очередь переписку лучше, чем не отправить ничего. Но это ещё не продуманная передача.
Переписка фиксирует порядок сообщений. А следующему оператору нужно состояние работы. Как минимум при передаче должно быть легко найти шесть вещей:
1. Цель клиента. Чего он пытался добиться — его собственными словами?
2. Контекст. С каким аккаунтом, объектом, разделом, тарифом или процессом он работал?
3. Попытки. Что ИИ предложил или сделал и что происходило после каждого шага?
4. Препятствие. Какая ошибка, недостающее право доступа, неподтверждённый факт или несработавшее изменение состояния остановили дело?
5. Срочность. Есть ли дедлайн, повторный сбой, влияние на оплату или другая причина поднять приоритет обращения?
6. Данные с согласия клиента. Какими диагностическими сведениями клиент решил поделиться?
Сохраняйте доступ к исходному диалогу: сгенерированное резюме может упустить деталь, которая меняет диагноз. А над ним разместите краткий черновик описания проблемы, чтобы человеку не пришлось восстанавливать картину по двадцати репликам.
Но этот черновик не должен запирать человека в интерпретации ИИ. Анализ диалогов поддержки 2026 года, в которых чат-бот передавал клиента человеку, показал: устраняя недопонимание, чат-боты склонны к обобщениям, а живые операторы задают более конкретные уточняющие вопросы. Полезная передача даёт человеку фору и оставляет место для вопроса, который бот не задал.
Для диагностики нужно отдельное правило. Текущая страница, недавние ошибки в консоли или состояние аккаунта помогают гораздо быстрее разобраться в технической проблеме. Но в них может оказаться и то, чем клиент делиться не собирался. Опишите, что это за данные, по умолчанию оставьте опцию выключенной и дайте клиенту решить самому. Контекст ценен, только если его сбор не превращает исправление сбоя в ещё один удар по доверию.
– Цель клиента указана до резюме от ИИ.
– Каждая попытка идёт в паре с наблюдаемым результатом, чтобы человек не повторял советы, которые уже не сработали.
– Актуальное состояние проблемы отделено от полной переписки.
– Чувствительная диагностика необязательна, конкретна и одобрена пользователем.
– Человек может поправить резюме и продолжать задавать вопросы.
Сделайте смену ответственного явной
Между решением ИИ эскалировать обращение и моментом, когда за него действительно отвечает человек, есть хрупкий промежуток. Продукты часто прикрывают его расплывчатыми фразами вроде «Я сообщил команде». Эта фраза может означать, что существует черновик, сработал вебхук, тикет попал в очередь — или что не произошло вообще ничего.
Интерфейс должен показывать реальное состояние. Если ИИ подготовил черновик, называйте его черновиком. Дайте клиенту изменить тему и текст сообщения. Покажите, на какой адрес придёт ответ. Перед отправкой попросите подтверждение. Когда сервер примет обращение, покажите его номер и честно скажите, чего ждать дальше. Если срок ответа неизвестен, не выдумывайте его.
Роль ИИ тоже должна чётко заканчиваться. Когда обращение передано, ему не стоит продолжать генерировать догадки о возможных решениях поверх очереди операторов. Он может подтвердить получение, сохранить диалог и остаться на связи для других вопросов. Теперь за эту проблему отвечает команда поддержки.
Такая ясность — больше, чем успокаивающий текст. Она создаёт состояния, которые можно проверить: черновик создан, клиент отредактировал, клиент отправил, команда получила, человек ответил, проблема решена. Сбой на любом из них виден, и шаг можно повторить. С расплывчатым обещанием в облачке чата так не выйдет.
Измеряйте исправление сбоя, а не один канал
Единицей анализа должна быть проблема клиента, а не автоматическая сессия. Иначе неудачный чат, за которым последовало успешное письмо, выглядит как одно взаимодействие с ИИ, закрытое без оператора, и один не связанный с ним тикет для человека. Дашборд празднует первое и записывает второе в издержки, хотя это один и тот же путь клиента через сервис.
Модели исходов не нужен идеальный универсальный идентификатор проблемы с первого дня. Для начала связывайте взаимодействия, когда совпадают клиент, намерение, затронутый объект и разумное временное окно. Сопоставление должно быть объяснимым, а сотрудники поддержки должны иметь возможность его поправить. Затем разделите исходы:
– Подтверждённое решение силами ИИ: продукт фиксирует запрошенное изменение состояния, или клиент подтверждает, что справочный ответ решил проблему.
– Решение при участии ИИ: автоматизация собрала нужные сведения или выполнила полезную часть работы, а затем ту же проблему решил человек.
– Оправданная эскалация: запрос вышел за заявленные границы знаний, возможностей или полномочий и попал к нужному ответственному.
– Лишняя эскалация: ответ или действие были в пределах возможностей, но автоматизация не справилась.
– Не решено или неизвестно: клиент бросил попытки, вернулся с той же проблемой или ушёл, не оставив достаточно данных, чтобы определить исход.
Отслеживайте уровень автоматизации наравне с этими категориями, а не над ними. Добавьте время до того, как обращение переходит к человеку, долю клиентов, которым пришлось объяснять проблему заново, повторные обращения по той же проблеме и итоговое решение. На выборке обращений проверяйте, было ли переданное состояние точным и достаточным. Окно и порог доказательств должны соответствовать задаче. Настройку аккаунта можно проверить сразу. Спор по оплате может оставаться открытым несколько дней.
Это меняет стимулы. Агенту засчитывается самостоятельное решение, если он может доказать успех, и чистая передача, если правильным ответственным был человек. А за то, что он измотал клиента внутри автоматического канала, ему не засчитывается ничего.
Как с этой границей обходится Barkan
Barkan создан, чтобы решать типовые вопросы «как это сделать» прямо там, где они возникают, опираясь на то, что сейчас отображается на экране клиента, и на подключённые знания о продукте. Когда ни один из этих источников не даёт опоры для ответа или когда посетитель прямо просит сообщить о проблеме, Barkan может подготовить сообщение для команды поддержки сайта, вместо того чтобы додумывать недостающее по памяти.
Мы сделали это сообщение черновиком, а не фоновым действием. Посетитель может изменить тему и текст, указать e-mail для ответа и решить, прикладывать ли технические подробности. Флажок диагностики по умолчанию снят. Только когда посетитель сам отправит сообщение, тикет попадает во входящие поддержки сайта — вместе с диалогом и, если посетитель это разрешил, контекстом страницы или недавними ошибками.
Такой сценарий не доказывает, что проблема в итоге была решена, — и не должен делать вид, что доказывает. Он сохраняет разницу между ответом, предложенной эскалацией и отправленным тикетом. Последующее решение по тикету — отдельный исход.
ИИ-агент поддержки неизбежно будет ошибаться. Продуктовое решение в том, чем станет эта ошибка: замкнутым кругом, тихим уходом клиента или хорошо подготовленным исправлением.
Помогайте посетителям прямо в продукте, а там, где автоматизация упирается в свой предел, открывайте им путь к вашей команде — через обращение, которое они проверяют сами.
«Большинству пользователей не нужен ещё один ответ. Они хотят, чтобы им показали путь или чтобы всё сделали за них. В этом весь продукт.»
Gabriel Lancelot
Сооснователь Barkan
