Як виміряти ROI AI-агента без vanity-метрик

Найбільша помилка, яку я бачу у засновників SMB при запуску першого AI-агента, — вимірювати його як софт, а не як найнятого працівника. Рахують токени. Скрінять кількість промптів. І ніхто не питає головне: чи комусь повернулася година?

Чому більшість ROI-дашбордів брешуть?

Бо міряють не той шар. Типовий перший дашборд показує токени, активних користувачів і кількість промптів. Усі ці числа ростуть незалежно від того, чи дав агент цінність.

Визначення: Vanity-метрика — число, яке стабільно йде вгору незалежно від того, чи покращився реальний бізнес-результат.

Патерн однаковий для SMB на 30-500 людей: 3 місяці гарного графіка, потім хтось з борда питає "а скільки годин зекономили?" — і в кімнаті тиша. Агент використовувався. Нічого не вимірювалося.

Як виглядає чесна ROI-метрика?

Чесна метрика проходить три тести. Перший — повʼязана з одиницею бізнес-роботи (кейс, чернетка, інвойс). Другий — має реальний baseline до агента. Третій — переживає скептика, що питає "а воно б само не покращилось?".

Якщо метрика валить хоча б один — це vanity-число у бізнес-обгортці.

Фреймворк з 5 метрик

Пʼять чисел щотижня на одну сторінку. Кожне ловить інший тип провалу.

1. Time-to-first-draft

Скільки хвилин від "запит прийшов" до "перша придатна чернетка на екрані". Wall-clock, з baseline до запуску.

Визначення: Time-to-first-draft — хвилини від моменту входу до першого виходу, готового до ревʼю, включно з runtime агента і затримками черг.

Єдина метрика, яка ловить реальний користувацький досвід. Токени і промпти не бачать черг, ретраїв і затримок передачі людині.

2. Deflection rate

Частка кейсів, які агент закриває end-to-end без правки людиною (лише підтвердження). Відмінне від "assisted" — assist розмитий, deflection бінарний.

Baseline на день 0 — нуль. Стабілізується за 4-6 тижнів. Якщо плато нижче 20% — scope неправильний.

3. Agent cost-per-task

Повна вартість агента (модель, хостинг, моніторинг) ÷ завершені бізнес-задачі. НЕ ділити на токени. НЕ на промпти. На задачі.

Визначення: Cost-per-task — повна вартість агента (compute + observability + retry overhead) ÷ завершені одиниці бізнесу за той самий період.

Тижневий моніторинг цього показника найшвидше ловить prompt drift. Коли тихий інженер змінив system prompt і модель пішла в цикл — сплеск ціни видно тут раніше, ніж хтось помітить, що агент став гіршим.

4. Reviewer rejection rate

Як часто людина відхиляє або суттєво переписує вихід агента? Цільовий діапазон — 10-25%. Менше 10% — штампування (ревʼюер втомлений), більше 25% — агент видає не ту форму виходу.

5. Downstream rework

Метрика-пастка. Чи створив вихід агента додаткову роботу далі — клієнт повернув, кейс перевідкрили, compliance підняв прапорець? Більшість впроваджень економить час на кроці 1 і тихо створює роботу на кроках 3-5. BCG AI Radar 2025: ~78% організацій запускають AI, лише ~25% бачать значущу цінність — це корелює саме з тими, хто не міряв rework.

Шаблон трекінгу (copy/paste)

Одна таблиця, один рядок на тиждень, окрема вкладка на агента.

Тиждень: [ДАТА]
Агент: [НАЗВА]
Процес: [Напр. "Тріаж support tier-1"]

Об'єм:
- Спроб: [N]
- Завершено (включно з ревʼю): [N]

5 метрик:
- Time-to-first-draft (медіана, хв): [N]   baseline: [N]
- Deflection rate (%): [N]
- Cost-per-task ($): [N]
- Reviewer rejection rate (%): [N]
- Downstream rework rate (%): [N]

Діагностика:
- Топ причина відхилення: [ТЕКСТ]
- Топ причина rework: [ТЕКСТ]
- Дельта cost-per-task до минулого тижня: [+/- %]
- Дія цього тижня: [ТЕКСТ]

Рядок "Дія цього тижня" — те, що відрізняє трекер ROI від декоративного дашборду.

Tool tip (Course for Business): Більшість команд міряє токени, бо ніхто на команді не володіє питанням "що таке успіх для цього агента". Принцип Augment, don't replace у нашій 6-week program вимагає явного власника для кожного агента, а ratio AI Champions (1:15-20) ставить одного чемпіона на ~17 співробітників, що веде щотижневий огляд 5 чисел разом з власником процесу. Найскладніше — вбити дашборд із токенами, в який всі закохалися першого місяця. Деталі: https://course.aiadvisoryboard.me/business.

Що дивитися керівнику

• Один названий власник кожного агента: інженерія тримає latency, власник процесу тримає ROI
• Звіт по 5 числах щотижня, не щомісяця
• Токени і промпти прибрані з leadership-в'ю (лишилися в ops)
• Cost-per-task рахується проти бізнес-задач, не проти токенів
• Reviewer rejection у 10-25% — поза цим або рубрика, або scope не той
• Downstream rework міряється навіть коли псує headline
• Time-to-first-draft має реальний pre-agent baseline до запуску
• Кожна метрика має поріг, що тригерить розмову
• Агент має письмовий kill-switch критерій (стеля cost-per-task, дно rejection)
• Жоден агент не лишається в проді понад 90 днів без оновленого ROI-ревʼю

Micro-case (що змінюється за 7-14 днів)

Сервісна компанія на 120 людей запустила AI-агента на тіаж tier-1 (драфт першої відповіді на клієнтський запит). Baseline до агента: ~4 години від запиту до першого ревʼюнутого драфта. Через 2 тижні команда святкувала "94% адопції" і токенів у небо. Реальний time-to-first-draft — 3 години 40 хвилин (майже не зрушило). Reviewer rejection — 38%. Downstream rework виріс, бо драфти агента тригерили уточнення scope, що раніше ловилися людьми у тріажі. Зупинилися, переписали рубрику, звузили scope до двох типів кейсів, почали міряти 5 чисел з 3-го тижня. До 6-го тижня: time-to-first-draft 35 хвилин, deflection 41%, rejection 18%, rework нижче baseline. Графік токенів став нижчим — і нікого це не хвилювало, бо бізнес-кейс нарешті спрацював.

Note on this case: This example is illustrative — based on typical patterns we observe with companies of 30-500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

Tool tip (Course for Business): Команди, що ставлять вимірювання правильно, роблять це бо чемпіон сидить поруч із власником процесу перші 30 днів і переписує дашборд живцем. Shoulder-to-Shoulder hot seat у нашій 6-week program створений саме для цього — тиждень 4 — це сесія перепису метрик: кожна команда вбиває vanity-дашборд і випускає версію з 5 числами. Ми бачили, як ця одна сесія міняє траєкторію пілотів, що виглядали мертвими на 8-му тижні. Книжте 30-хвилинний дзвінок: https://course.aiadvisoryboard.me/business.

FAQ

5 метрик — це не забагато для маленького пілота? Все колапсує в один рядок таблиці на тиждень. 15 хвилин overhead. Альтернатива — 3 місяці інвестицій без жодного захисного ROI-наративу — коштує значно більше.

А що з accuracy моделі або BLEU-скорами? Корисні для інженерної команди під час ітерації промптів. Не корисні для leadership ROI-розмови. Тримайте на окремому ops-дашборді, не на сторінці "чи це зекономило нам гроші?".

Як baseline-нути процес, що сильно коливається? Беріть медіану за 4 тижні, не одну точку. Для low-volume процесів (менше 20 задач/тиждень) — 8 тижнів. Точність важить менше за чесність.

Мій агент майже безкоштовний, бо токени копійки. Cost-per-task мені потрібен? Так — бо саме cost-per-task найшвидше ловить prompt drift і infinite loop. Не число важить, а дельта тиждень-до-тижня.

Чи можна міряти ROI AI-тренінгів так само? Інший фреймворк — там про передачу навичок і поведінкові зміни, не про throughput. Окрема стаття, але принцип той самий: вбийте vanity-метрики першими.

Висновок

ROI AI-агента — це не графік токенів. Це чи комусь повернулася година, чи вихід не відскакує і чи робота тихо не виплила далі по процесу. 5 метрик, одна сторінка, щотижня. Все інше — декорація.

Виберіть першого агента. Напишіть шаблон 5 метрик до запуску. Вбийте будь-який дашборд, що не відповідає "чи це зекономило нам гроші?".

Якщо хочете, щоб кожен співробітник запустив свою першу AI-автоматизацію за 5 днів — з вимірюванням, що захищає бюджет — книжте 30-хвилинний дзвінок: https://course.aiadvisoryboard.me/business.