Как измерять ИИ-поддержку по решённым задачам
Главная метрика ИИ-поддержки — доля обращений, которые завершились решением задачи без повторного контакта клиента и передачи сотруднику. Но одной цифры недостаточно: важно проверять оценки клиентов, причины передачи человеку и ошибки в базе знаний. Начните с узкого участка поддержки, договоритесь, что считать решением, и сравнивайте результаты с работой команды до запуска.
Коротко — и что с этим делать
Считайте не количество ответов, а результат для клиента. Отслеживайте долю обращений, решённых без повтора и передачи сотруднику, дополняйте её оценками клиентов и разбором ошибок. Для начала выберите одну повторяющуюся тему, например вопросы о записи или статусе заказа, и настройте измерение на ней.
Записаться на бесплатный аудит →Почему количества ответов недостаточно
Система может быстро отправить сообщение и при этом не помочь. Например, клиент спрашивает, можно ли перенести запись в клинику, а получает общий перечень услуг. Формально ответ есть, но задача не решена. Если считать только число обработанных сообщений или скорость ответа, такой случай попадёт в отчёт как успех и скроет проблему.
Для бизнеса полезнее понимать, что произошло с обращением целиком: смог ли клиент записаться, получил ли нужную информацию, пришлось ли ему повторять вопрос или ждать сотрудника. Поэтому измерение должно начинаться не с выбора красивого показателя, а с определения результата для конкретного типа обращений.
В автосервисе результатом может быть подтверждённая запись на диагностику. В салоне — запись к мастеру с подходящим временем. В рознице — понятный ответ о наличии товара или передача вопроса сотруднику, который действительно может проверить остатки. Для каждого сценария критерий будет своим.
Мы советуем отдельно учитывать обращения, где ИИ только подготавливает ответ сотруднику. Это полезный формат поддержки, но его не следует смешивать с полностью решёнными задачами: участие человека меняет трудозатраты и итоговую картину.
Какая метрика главная
Главная метрика — доля обращений, которые закончились решением задачи без повторного контакта клиента или передачи сотруднику. Она показывает, сколько обращений система довела до результата самостоятельно, а не просто начала обрабатывать.
Чтобы считать долю, зафиксируйте число подходящих обращений за период и число тех, которые отвечают всем условиям решения. Затем разделите второе число на первое и умножьте на сто. Важно заранее договориться, что означает «повторный контакт»: это может быть новое сообщение по той же теме в течение установленного для бизнеса срока. Такой срок стоит выбирать с учётом цикла услуги, а не произвольно.
Например, клиент спрашивает о графике работы, получает точный ответ и не возвращается с тем же вопросом. Если же после ответа он уточняет то же самое другими словами или просит сотрудника подтвердить информацию, задачу нельзя считать решённой автоматически. При этом новый вопрос клиента не должен ошибочно попадать в повторы — обращения нужно группировать по теме и истории диалога.
До запуска полезно измерить исходный уровень на тех же типах запросов: сколько обращений решают сотрудники, сколько требуют уточнений, как часто клиенты возвращаются. Тогда после пилота можно сравнить одинаковые периоды и сценарии. Для оценки окупаемости проекта можно также использовать подходы, описанные на странице об оценке окупаемости ИИ.
Какие показатели дополняют долю решений
Главная метрика объясняет общий результат, но не всегда показывает, почему он изменился. Для диагностики соберите небольшой набор дополнительных показателей. Не обязательно выводить все числа на отдельный экран: важнее регулярно разбирать их и принимать решения.
- Доля передач сотруднику. Показывает, в скольких случаях системе не хватило полномочий, данных или уверенности. Высокая доля сама по себе не означает провал: безопасная передача сложного вопроса бывает правильным результатом.
- Повторные обращения по той же теме. Помогают обнаружить ответы, после которых клиенту всё ещё приходится добиваться решения. Учитывайте повтор в согласованном временном окне.
- Оценка клиента. Дает обратную связь о том, помог ли ответ. Особенно полезно сопоставлять её с формальным статусом обращения.
- Ошибки базы знаний. Отмечайте отсутствующие, устаревшие и противоречивые сведения. Иногда проблема не в настройке ИИ, а в том, что бизнес сам не обновил правила, цены или расписание.
- Время до решения. Сравнивайте не только скорость первого ответа, но и время от начала обращения до результата. Быстрый неуместный ответ не ускоряет решение.
Выбирайте показатели, на которые команда может повлиять. Если сотрудникам нечем исправить неточную информацию, отчёт о таких ошибках будет только фиксировать проблему. Назначьте ответственного за источник данных и срок проверки каждого найденного дефекта.
Как читать передачи человеку, оценки и ошибки
Передача сотруднику — это не всегда ошибка. Клиент может просить исключение из правил, сообщать о конфликте или задавать вопрос, требующий доступа к закрытым данным. В таких случаях корректно распознать границу полномочий и передать диалог человеку безопаснее, чем продолжать отвечать. Поэтому причины передачи нужно классифицировать, а не просто стремиться уменьшить их число.
Низкая оценка тоже требует контекста. Клиент мог быть недоволен сроком доставки, хотя ответ системы был точным. Или поставил низкую оценку потому, что ответ звучал уверенно, но не решал его вопрос. Разбирайте сам диалог, результат для клиента и дальнейшие действия. Полезно различать оценку качества ответа и оценку всей услуги компании.
Ошибки знаний обычно можно сгруппировать по источнику: информация отсутствует, устарела, сформулирована неоднозначно либо противоречит другой инструкции. Для каждой группы нужен свой шаг. Добавить правило, обновить документ, указать приоритет сведений или ограничить автоматический ответ до проверки.
Если обращения содержат персональные данные, при настройке учёта и хранения учитывайте требования 152-ФЗ. Определите, какие сведения действительно нужны для контроля качества, кто имеет к ним доступ и как долго они хранятся. В отчётах по возможности используйте обезличенные данные, а доступ к переписке предоставляйте только сотрудникам, которым он нужен для работы.
Не уверены, какие обращения стоит автоматизировать первыми?
На бесплатном аудите команда KM2B поможет выбрать узкий сценарий, определить критерий решения и понять, какие данные понадобятся для оценки пилота. Точный бюджет рассчитывается после аудита; обычно начинают с небольшого пилота, а его окупаемость часто оценивают в горизонте 2–4 месяцев — без гарантии результата, поскольку он зависит от процесса и исходных данных.
Бесплатный аудит за 30 минут →Как улучшать ИИ-поддержку по результатам
Улучшение начинается с разбора случаев, а не с просьбы «сделать ответы умнее». Соберите обращения, которые передали сотруднику, получили низкую оценку или закончились повторным контактом. Для каждого выясните, на каком шаге возникла проблема: система неверно поняла намерение, не нашла нужные сведения, применила неподходящее правило или не распознала необходимость позвать человека.
- Выберите небольшую выборку сложных или неудачных диалогов за период.
- Разметьте причину: пробел в источнике ответа, неясное правило, недостаток данных либо неверная передача.
- Исправьте источник или условие сценария, назначив ответственного за изменение.
- Проверьте на похожих обращениях, стало ли меньше повторов и необоснованных передач.
- Убедитесь, что исправление не ухудшило ответы в соседних сценариях.
Например, если система регулярно передаёт вопросы о переносе записи, проверьте, есть ли в источнике актуальные правила и расписание. Если ответ уже есть, уточните формулировку условия, при котором можно предложить свободное время, а при котором нужно подключить администратора. После изменения проверьте и удачные, и неудачные примеры.
В процессе участвуют не только разработчики. Администратор клиники, мастер-приёмщик автосервиса или руководитель розницы часто лучше знает, какие исключения встречаются в работе. Удобно вести журнал изменений: дата, проблема, исправление и результат повторной проверки. Так команда сможет понять, какие изменения помогли, а какие только перенесли ошибку в другое место.
Как начать измерение без сложной системы
Для первого пилота достаточно выбрать один канал и ограниченный набор повторяющихся тем. Не стоит сразу подключать все обращения компании: если в одной группе смешаны запись, жалобы, консультации и нестандартные случаи, причины результата будет трудно разделить. О подходящих сценариях и вариантах внедрения можно посмотреть на странице услуг по внедрению ИИ и в каталоге решений для бизнеса.
Перед запуском зафиксируйте правила подсчёта. Определите, что считается отдельным обращением, как находить повтор, какие передачи сотруднику исключаются из автоматического решения и кто оценивает спорные случаи. Сохраните исходные показатели за сопоставимый период. Иначе после запуска будет сложно отделить реальное изменение от сезонности, смены графика или рекламной активности.
На пилоте назначьте человека, который проверяет выборку диалогов и актуальность источников. Он не обязан читать каждое сообщение: можно регулярно разбирать все низкие оценки и передачи, а также небольшую выборку обращений, отмеченных как решённые. Последняя нужна, чтобы проверять, не завышается ли доля успеха из-за неверной классификации.
Отчёт можно начать с таблицы, где есть дата, тип задачи, итог, повторный контакт, передача, оценка и замечание проверяющего. Если компания уже ведёт обращения в CRM или другой системе, сначала выясните, можно ли использовать имеющиеся поля и историю диалогов. Не собирайте дополнительные сведения «на всякий случай»: объём данных должен соответствовать цели измерения и внутренним правилам работы с персональными данными.
Как выглядит полезный отчёт руководителя
Хороший отчёт отвечает на три практических вопроса: сколько задач решено, почему часть не решена и что команда исправляет дальше. Руководителю не обязательно ежедневно смотреть десятки технических показателей. Достаточно видеть динамику по выбранным темам, основные причины передачи, оценки клиентов и список повторяющихся дефектов базы знаний.
| Показатель | Что показывает | Как использовать |
|---|---|---|
| Решение без повтора и передачи | Долю обращений с завершённой задачей | Сравнивать с исходным уровнем по тем же темам |
| Передача сотруднику | Где нужны полномочия или знания человека | Отделять правильную передачу от устранимого пробела |
| Оценка клиента | Восприятие помощи самим клиентом | Проверять низкие оценки вместе с историей обращения |
| Повтор и ошибка источника | Где ответ не привёл к результату или опирался на неверные сведения | Исправлять правило, документ или порядок обновления данных |
Если цифры ухудшились, не нужно сразу менять всю систему. Сначала проверьте, не изменился ли состав обращений, расписание, порядок записи или условия обслуживания. Затем разберите конкретные диалоги и выберите одно исправление, результат которого можно проверить. Такой подход помогает развивать поддержку постепенно и сохранять контроль над тем, какие ответы система даёт клиентам.
Начните с измеримого сценария
Если хотите понять, какие обращения подходят для пилота и как оценивать пользу именно в вашем процессе, обсудите задачу с командой KM2B. На аудите определим исходные данные, критерии решения и безопасный порядок проверки.
Записаться на бесплатный аудит →