Какую долю обращений действительно может закрыть ИИ-поддержка

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

Поэтому начинать нужно не с процента, а с трёх вопросов. Что вы считаете решённым обращением? Какие обращения попали в знаменатель? Учтены ли повторные контакты по той же проблеме? После этой статьи вы сможете читать обещание поставщика и понимать, что за ним стоит, выбрать обращения для пилота и измерить результат на собственных данных. А ещё научитесь различать две вещи, которые часто смешивают: ИИ, помогающий оператору, и ИИ, который отвечает клиенту самостоятельно.

Что значит «закрыто»: три разных события

Слово «закрыто» в поддержке имеет как минимум три значения, и они дают очень разные цифры.

Диалог завершился. Клиент перестал писать. Это проще всего измерить, но это меньше всего говорит о результате. Человек мог получить ответ, а мог сдаться, уйти на сайт конкурента или позвонить на горячую линию.

Обращение не передали человеку. В отрасли это часто называют containment, то есть «удержанием» обращения в боте. Метрика показывает, что оператор не подключался. Она не показывает, получил ли клиент то, что ему было нужно.

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

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

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

Как читать цифры поставщиков

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

Прежде чем сравнивать поставщиков или переносить чужой результат в бизнес-план, спросите:

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

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

Учебный расчёт: один поток, несколько разных процентов

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

Одна и та же работа бота даёт 60%, 53%, 36%, 33%, 32% или 20% — в зависимости от того, что на что разделить. Арифметика в каждом случае верна, но вывод будет ошибочным, если 60% от обращений к боту представить как «ИИ закрывает 60% обращений компании». Также важно не скрывать 40 повторных контактов внутри общего числа отмеченных как решённые.

Арифметика: 360 / 600 = 60%; 360 / 1000 = 36%; 200 / 600 ≈ 33%; 200 / 1000 = 20%; 360 − 40 = 320; 320 / 600 ≈ 53%; 320 / 1000 = 32%.

Помощь оператору и автономное решение — разные результаты

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

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

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

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

Какие обращения брать в пилот

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

• частые и похожие друг на друга: статус заказа, часы работы, смена пароля, поиск документа;
• со стабильными правилами: ответ не зависит от настроения менеджера или исключения для конкретного клиента;
• с источником истины: статус берётся из учётной системы, правило — из актуальной базы знаний;
• с проверяемым результатом: можно определить, был ли ответ правильным, не опрашивая клиента.

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

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

Учебная таблица отбора тем

Оценки в таблице условны и вымышлены для примера. Каждый критерий оценивается от 1 до 3.

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

Собственная методика измерения

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

Определите метрики до запуска. Запишите числитель и знаменатель каждой метрики, окно для повторного обращения (например, 7 дней) и правило, по которому определяется «тот же вопрос». Не меняйте определения в середине пилота.

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

Размечайте случайную выборку. Каждую неделю берите случайную выборку разговоров, которые бот отметил как решённые, и просите сотрудника проверить: был ли ответ правильным, полным и соответствовал ли правилам. Без этого вы знаете только, что клиент замолчал, а не что ответ был правильным.

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

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

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

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

Решение о расширении

Расширять ИИ-поддержку на новые темы стоит, когда пилот показал результаты сразу по нескольким метрикам, а не по одной. Расширение оправдано, если:

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

Последний пункт часто недооценивают. Боту нужны люди: кто-то обновляет базу знаний, разбирает ошибочные ответы, настраивает правила передачи. Эту работу нужно включать в расчёт экономии.

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

Вывод: как оценить ИИ-поддержку на своём потоке

1. Зафиксируйте определения: что такое решённое обращение, каково окно повторного контакта и что входит в знаменатель.
2. Посчитайте текущий поток обращений по темам и выберите две-три темы с частыми, стабильными и проверяемыми запросами.
3. Настройте отдельный учёт доли участия бота, закрытых без оператора, подтверждённых клиентом, повторных и переданных обращений.
4. Каждую неделю размечайте случайную выборку «решённых» разговоров.
5. Свяжите обращения из разных каналов, чтобы видеть повторные контакты.
6. Сравнивайте с периодом до запуска или с контрольной частью потока.
7. Расширяйте только те темы, где все метрики стабильны, и учитывайте полную стоимость поддержки бота.
8. Используйте цифры из чужих кейсов только вместе с их определениями, а не как прогноз для себя.

Частые вопросы