Как измерить пользу ИИ в одном процессе: метрики вместо числа запросов

Начните с решения, ради которого запускают пилот

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

Сформулируйте одну фразу: «Мы считаем пилот полезным, если…». Она должна содержать наблюдаемое изменение и условие качества. Например, «менеджер тратит меньше времени на подготовку карточки без роста числа ошибочных телефонов и потерянных источников». Цифровой порог задайте после исходного замера, а не из красивого чужого кейса.

Разделите скорость, качество и риск

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

Соберите исходный уровень

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

Для операционных задач удобно хранить примеры «до» и «после» без персональных данных. По каждому спорному случаю укажите, кто признал ответ правильным и по какому источнику. Это особенно важно, когда сотрудники сами по-разному понимают правило.

Не назначайте метрику единственным судьёй

Условная команда увидела рост скорости ответов на 30%. При проверке выяснилось, что бот быстро давал общую фразу, а менеджеры всё равно возвращались к клиенту с уточнениями. Вместо скорости первого сообщения команда стала измерять время до содержательного ответа и повторные контакты. Число в отчёте уменьшилось, зато стало ближе к реальной пользе.

Microsoft описывает измерение использования Copilot, но метрики активности требуют связи с рабочим результатом. NIST AI RMF также отделяет измерение от управления рисками. Практический вывод: выберите несколько показателей, которые вместе позволяют сказать «ускорились, качество не ухудшилось, риск остаётся приемлемым».

Когда пересматривать показатели

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

Как устроить простую карточку измерения

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

Вопросы, которые ломают красивую цифру

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

Почему полезно смотреть на распределение

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

Почему число запросов всё же стоит сохранять?

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