Агент запущен, разработчик показал красивую демонстрацию, команда говорит «вроде работает». Проходит два месяца, и собственник задаёт простой вопрос: «Мы потратили на это деньги — что изменилось?» В ответ он получает либо технические отчёты про токены и latency, либо общие слова про «разгрузку менеджеров». Ни то, ни другое не помогает принять решение: развивать агента дальше, оставить как есть или выключить.
Проблема в том, что метрики AI-агента обычно выбирают разработчики, а смотреть на них должен владелец бизнеса. В этой статье — набор показателей, которые понятны без технического бэкграунда, способ их считать без дорогой аналитики и честный разговор о том, что измерить не получится.
Три уровня метрик: что видит разработчик, менеджер и собственник
Удобно разделить показатели на три слоя. Они не конкурируют, а отвечают на разные вопросы.
- Технический слой — доступность, время ответа модели, стоимость запроса, доля ошибок API. Нужен разработчику, чтобы агент не падал. Собственнику достаточно знать, что он существует.
- Операционный слой — сколько обращений агент закрыл сам, сколько передал людям, как быстро, насколько точно. Это зона руководителя отдела.
- Бизнес-слой — что изменилось в деньгах и времени: конверсия, скорость реакции, стоимость обработки обращения, высвобожденные часы. Это и есть ответ на вопрос «что изменилось».
Типичная ошибка — показывать собственнику первый слой и ждать, что он сам сделает выводы. Второй и третий слой нужно проектировать до запуска, иначе через два месяца сравнивать будет нечего: никто не зафиксировал, как было «до».
Метрики, которые стоит смотреть собственнику
Ниже семь показателей. Не все подходят каждому агенту: для агента поддержки важны одни, для агента квалификации заявок — другие. Выбирайте три–четыре и смотрите их еженедельно.
1. Доля обращений, закрытых без человека
Самая понятная метрика. Из ста диалогов сколько агент довёл до результата сам: ответил, записал, оформил, отправил. Ориентир для агента поддержки с нормальной базой знаний — от половины до двух третей обращений, но сильно зависит от отрасли. Важно считать не «ответил», а «клиент не вернулся с тем же вопросом и не попросил человека».
2. Время первого ответа и время до решения
До агента: заявка с сайта ждала ответа часами, вечером и в выходные — до следующего рабочего дня. После: минуты. Это одна из немногих метрик, где эффект виден сразу и однозначно. Стоит фиксировать отдельно по времени суток — ночные и выходные обращения как раз и были зоной потерь.
3. Доля эскалаций и их причины
Сколько диалогов агент передал человеку и почему. Сама по себе высокая доля эскалаций не плохо — агент, который передаёт сложные случаи, лучше агента, который на них выдумывает ответы. Но если 40% эскалаций — это один и тот же вопрос про доставку в регион, значит в базе знаний дыра, и закрыть её стоит дешевле, чем платить за ручную обработку.
4. Точность по контрольной выборке
Раз в неделю или две руководитель отдела просматривает 20–30 случайных диалогов и ставит оценку: корректно, с недочётами, ошибка. Это ручная работа на полчаса, но она даёт честную картину качества, которую не заменит ни одна автоматическая метрика. Критичные ошибки — выдуманная цена, обещанная несуществующая услуга — считаются отдельно и в идеале равны нулю.
5. Стоимость одного обработанного обращения
Расходы на API модели, хостинг и поддержку, делённые на количество обращений. Сравнивается с тем, во сколько обходилось обращение при ручной обработке: зарплата сотрудника, делённая на число диалогов в месяц. Ориентировочно агент на облачной модели обрабатывает обращение в десятки раз дешевле человека, но в этом расчёте важно не забыть разовые затраты на разработку. Подробнее о структуре расходов — в статье о стоимости AI-агента.
6. Конверсия на участке, где работает агент
Для агента квалификации заявок: какая доля обращений дошла до менеджера с заполненной карточкой, какая из них превратилась в сделку. Для записи на услуги: доля диалогов, закончившихся записью. Эта метрика сильнее всего связана с деньгами и сильнее всего зависит от внешних факторов — сезона, рекламы, цен. Поэтому её сравнивают не «до и после», а с контрольной группой, если это возможно.
7. Высвобожденные часы
Самая спорная, но самая убедительная для собственника метрика. Число обращений, закрытых агентом, умноженное на среднее время ручной обработки. Честный расчёт берёт консервативную оценку времени и не считает освободившиеся часы доходом — это ресурс, который ещё нужно куда-то направить.
Как снять базу «до», если агент ещё не запущен
Без исходной точки все метрики превращаются в мнения. Минимальная подготовка занимает одну–две недели до запуска:
- Выгрузите из CRM или мессенджера количество обращений за месяц и распределение по часам.
- Попросите менеджеров неделю отмечать время, потраченное на обращения. Не идеально, но лучше, чем ничего.
- Посчитайте, сколько обращений осталось без ответа или с ответом позже суток.
- Зафиксируйте текущую конверсию на участке, который отдаёте агенту.
Эти четыре цифры стоит записать в тот же документ, где лежит техническое задание на агента, — тогда критерии приёмки и метрики после запуска будут одной системой.
Где брать данные и как их показывать
Для малого бизнеса не нужна отдельная BI-система. Рабочая схема выглядит так: агент пишет в таблицу или базу запись о каждом диалоге — время, канал, итог (закрыт, эскалирован, брошен), тема, оценка клиента, если она собирается. Поверх этого строится простой дашборд в Looker Studio или Metabase с пятью–семью графиками.
Для собственника удобнее не дашборд, а короткая сводка в Telegram по понедельникам: обращений за неделю, закрыто агентом, эскалировано, средняя оценка, три самых частых темы эскалаций. Такую сводку собирает тот же n8n или Make, который обслуживает агента. Если дашборд уже есть для других показателей бизнеса, метрики агента логично добавить туда — об этом статья про дашборд для собственника.
Пример: агент записи в сети салонов
Три салона, администраторы, запись через WhatsApp и Telegram. До агента: ориентировочно четверть обращений вечером оставалась без ответа до утра, часть клиентов за это время записывалась к конкурентам.
После запуска агента смотрели четыре метрики: доля записей без участия администратора, время первого ответа, доля эскалаций и неявки. Через месяц стало видно: записи агент делает хорошо, а эскалации в основном связаны с переносами — клиенты писали «перенесите на завтра», и агент не понимал, какую именно запись переносить. Это не метрика «успех или провал», а конкретная задача на доработку, которую закрыли за несколько дней. Без еженедельного просмотра причин эскалаций проблема жила бы месяцами.
Чего измерить не получится
Честно о границах.
- Удовлетворённость клиентов по одной кнопке «оцените ответ» измеряется плохо: отвечает малая часть, в основном недовольные или очень довольные. Можно смотреть динамику, но не абсолютные значения.
- Чистый вклад агента в выручку отделить от рекламы, сезона и работы менеджеров почти невозможно без контрольной группы, которую малый бизнес редко может себе позволить.
- Качество ответов автоматически — есть подходы, когда одна модель оценивает ответы другой, и они полезны для масштаба, но заменить ручную выборку руководителя они пока не могут.
- Эффект в первые две недели — агент ещё донастраивается, база знаний дополняется, цифры скачут. Решения стоит принимать не раньше, чем через месяц стабильной работы.
Итог
Эффективность AI-агента измеряется не токенами и не скоростью модели, а тем, что изменилось в процессе: сколько обращений закрывается без людей, как быстро отвечаем, сколько стоит одно обращение и почему агент зовёт человека. Для этого нужно снять базу до запуска, выбрать три–четыре метрики, записывать итог каждого диалога и раз в неделю смотреть на выборку глазами.
Мы в AiKrok закладываем учёт диалогов и еженедельную сводку в первую же версию агента — без этого через два месяца разговор про результат превращается в спор о впечатлениях. Если агент у вас уже работает, а цифр нет, добавить учёт поверх существующего решения обычно проще, чем кажется.