Збільшення кількості метрик не обов’язково покращує розуміння. Багато інформаційних панелей містять кілька показників тієї самої базової поведінки. Метрики стають діагностично ціннішими, коли їх поєднують у взаємно руйнівні пари: вартість і якість, частка звернень без залучення людини й настрої клієнтів або точність і затримка.
Правильні пари змінюються в міру переходу ШІ-продукту від пілотного етапу до промислової експлуатації. Вимірювання мають відповідати рішенням, які команда повинна ухвалювати на кожному етапі.
Операційний моніторинг і стратегічне вимірювання мають різні цілі. Команди можуть відстежувати сотні системних сигналів, але керуватися лише кількома парами під час ухвалення продуктових рішень.
Ключові метрики можуть створювати переконливу картину, залишаючи важливе продуктове рішення невизначеним.
ШІ-асистента Klarna публічно пов’язували з вищою пропускною здатністю, нижчими витратами й оцінками задоволеності клієнтів, порівнянними з показниками агентів-людей. Наступного року компанія вирішила розширити доступ до підтримки з боку людей, а її генеральний директор визнав, що скороченню витрат приділяли надто багато уваги.
Це не означало відмови від ШІ-асистента чи технології, на якій він побудований. Компанія скоригувала баланс між автоматизацією та обслуговуванням людьми з огляду на досвід експлуатації продукту. Оскільки автоматизація перебирала дедалі більше простих запитів високого обсягу, Klarna потребувала людей-агентів, підготовлених до роботи зі складними, делікатними випадками.
Визначивши із самого початку, чого має досягти продукт, більшість організацій, що створюють ШІ-продукти, зрештою постають перед тим самим запитанням: чи справді він працює?
Якщо відповідь неочевидна, інстинктивно хочеться додати більше метрик. Три перетворюються на 10, а потім 10 — на 30. Інформаційна панель стає насиченішою, але розуміння команди може не покращитися.
Проблема не завжди в якості окремих показників, а у взаємозв’язку між ними. Задоволеність клієнтів, індекс споживчої лояльності, відгуки та частка схвальних оцінок можуть бути корисними сигналами, але всі вони можуть відображати подібні зміни в загальних настроях. Коли вони змінюються одночасно, то підтверджують, що щось сталося, але не обов’язково пояснюють причину.
Тому командам ШІ слід виходити за межі узгоджених між собою метрик і визначати показники, які виявляють конкуруючі результати. Такі взаємно руйнівні пари виявляють наслідки компромісів, що визначають ефективність продукту, допомагають їх відстежувати й ухвалювати кращі рішення.
В одному з проєктів до запуску спільна команда розробляла голосового ШІ-агента реального часу для вхідних дзвінків у службу підтримки клієнтів. Одне з найскладніших питань стосувалося не вибору моделі чи оркестрації. Потрібно було зрозуміти, як організація визначатиме, чи працює продукт, коли клієнти почнуть масово ним користуватися.
Початкова система оцінювання містила три показники:
Частка звернень без залучення людини: як часто ШІ вирішує питання під час дзвінка, не переводячи його на людину.
Частка ескалацій: як часто дзвінок переводять на агента-людину.
Частка вирішених питань: як часто проблему клієнта врешті-решт вирішують.
Кожен показник був обґрунтованим. Однак разом вони не давали відповіді на очевидне запитання: якщо частка ескалацій зростає, про що це свідчить?
Команда розділила ескалації на вісім підтипів. Потім вона додала показники відмов, шляху й часу взаємодії, оцінки розуміння мови та частку вирішених питань за типом запиту. Зрештою система оцінювання містила 31 метрику в шести категоріях.
Вона могла докладно описати ескалацію, але все ще не давала змоги надійно визначити її причину. Більшість метрик були варіаціями тієї самої поведінки, тому змінювалися разом, а не перевіряли конкуруючі пояснення.
Інформаційна панель стала радше оглядовою, ніж діагностичною.
Команді був потрібен не ще один рівень деталізації. Їй були потрібні метрики, які обмежували б одна одну.
Ми називаємо їх взаємно руйнівними парами: це два показники, коли ізольоване покращення одного може зашкодити результату, який відображає інший. Назва описує не бажаний стан, а спосіб виникнення збою через однобічну оптимізацію.
Коли обидві складові залишаються на належному рівні, продукт може працювати стабільно й довгостроково. Коли вони розходяться, напрямок розбіжності допомагає команді визначити, що слід дослідити.
Що ми мали | Взаємно руйнівна пара | Що може виявити ця пара |
|---|---|---|
Частка ескалацій, розділена на вісім підтипів | Частка ескалацій ↔ час до ескалації | Негайна ескалація може свідчити про проблему з довірою чи формулюванням очікувань; пізніша — про нездатність системи виконати завдання. |
Частка звернень без залучення людини та частка вирішених питань подаються окремо | Частка звернень без залучення людини ↔ настрої клієнтів | Чи означає відсутність залучення людини задовільне вирішення питання, чи відмову клієнта від подальших спроб. |
Частка вирішених питань за типом наміру | Частка вирішених питань ↔ глибина розмови | Чи є успішне вирішення ефективним, чи потребує виснажливої взаємодії. |
Щоб глибше зрозуміти, як це виявляється та що робити з отриманими даними, розгляньмо частку ескалацій і час до ескалації. Команда не знатиме, як поводяться клієнти, доки не надійдуть реальні дзвінки, але вона може визначити гіпотези, які потрібно перевірити.
Якщо ескалюється більше дзвінків, а клієнти припиняють взаємодію із ШІ протягом перших 30 секунд, команді слід дослідити довіру, розкриття інформації, тон і початок взаємодії. Якщо клієнти ескалують звернення після кількох хвилин спроб виконати завдання, імовірнішою проблемою стають можливості системи або охоплення робочого процесу.
Загальний показник ескалацій однаковий. А продуктове рішення — різне.
Корисна пара сама по собі не доводить причину. Вона звужує напрям розслідування й робить наступне рішення зрозумілішим.
Наведений раніше приклад Klarna показує, як цей принцип діє у взаємозв’язку вартості та якості обслуговування. Він демонструє, як операційна модель із використанням ШІ може розвиватися, коли компанія відстежує наслідки компромісів і навчається на досвіді впровадження.
У лютому 2024 року компанія повідомила, що її ШІ-асистент за перший місяць провів 2,3 мільйона розмов, виконав обсяг роботи, еквівалентний праці 700 агентів із повною зайнятістю, і досяг оцінок задоволеності клієнтів, порівнянних із показниками агентів-людей. За оцінкою Klarna, у 2024 році асистент мав забезпечити зростання прибутку на 40 мільйонів доларів. Це були власні результати Klarna, а не незалежна оцінка.
У травні 2025 року генеральний директор Klarna заявив, що компанія приділяла надто багато уваги скороченню витрат на обслуговування клієнтів, і розповів про плани розширити доступ до підтримки з боку людей. Це було коригуванням балансу між автоматизованим обслуговуванням і підтримкою з боку людей, а не відмовою від ШІ-асистента чи технології, на якій він побудований.
Загальнодоступні дані показують, чому показники ефективності потрібно розглядати разом із потребами різних клієнтів і типів взаємодії. Система ШІ може в середньому працювати добре, хоча в деяких складних, делікатних або незвичних випадках доступний канал зв’язку з людиною досі корисний.
Моніторинг обох складових цього взаємозв’язку допомагає компанії визначати, де автоматизація створює цінність, де підтримка з боку людей залишається важливою та як змінювати баланс із появою нових даних.
Інші взаємно руйнівні пари для ШІ-продуктів можуть включати:
Взаємно руйнівна пара | Ризик, який вона допомагає виявити |
|---|---|
Точність відповіді ↔ затримка відповіді | Система технічно точна, але надто повільна для робочого процесу. |
Виконання завдань ↔ частота втручання користувача | Робочий процес ШІ виконує завдання, які користувачі потім постійно переробляють. |
Вартість взаємодії ↔ оцінена якість результату | Економія коштом погіршення досвіду клієнтів або працівників. |
Впровадження ↔ час до отримання цінності | Зростання кількості реєстрацій без відповідного зростання цінності для користувачів. |
Мета не в тому, щоб обидва показники зростали нескінченно. Мета — зробити компроміс помітним до того, як однобічна оптимізація створить операційну проблему.
Подібна проблема виникла під час упровадження системи підтримки гравців для компанії, що розробляє мобільні ігри. Система опрацьовувала масові проблеми, як-от утрачені досягнення, спори щодо платежів і доступ до облікового запису.
Показники ефективності були важливими, оскільки система працювала у великому масштабі. Але підтримка гравців — це не просто операційна черга. Гравці часто звертаються розчарованими, оскільки щось уже пішло не так на іншому етапі їхньої взаємодії з продуктом.
Цей початковий стан змінює те, як слід тлумачити дані про задоволеність клієнтів. Гравець, проблему якого вирішили правильно, усе одно може низько оцінити задоволеність, адже спочатку він утратив прогрес. Якщо аналізувати цю оцінку без контексту, взаємодію зі службою підтримки можна несправедливо покарати за розчарування, що виникло раніше на шляху клієнта.
Тому команді потрібно було відокремити початкові настрої клієнта від впливу досвіду взаємодії зі службою підтримки. Кориснішим було не запитання: «Чи був гравець задоволений?» Натомість слід було запитати: «Чи покращила взаємодія ситуацію порівняно з початковим станом гравця?»
Таке порівняння допомагає відокремити розчарування продуктом від якості підтримки, якщо команда має надійний спосіб вимірювати обидва чинники.
ШІ-продукти змінюються, але їхні метрики часто залишаються незмінними.
Під час пілотного етапу головне питання може полягати в тому, чи достатньо система надійна, щоб виправдати подальші інвестиції:
Чи надійно вона виконує основне завдання?
Чи достатньо їй довіряють користувачі, щоб продовжувати роботу?
Як вона поводиться поза найпоширенішими сценаріями?
Чи можна виявляти збої та безпечно відновлювати роботу після них?
Для цих запитань доречні такі пари:
успішність основного завдання ↔ ефективність у нестандартних випадках;
рівень автоматизації ↔ частота втручання людини; та
швидкість виконання ↔ упевненість користувача.
Коли продукт стає важливим для операційної діяльності, запитання змінюються:
Чи може він масштабуватися без погіршення якості?
Чи покращуються його економічні показники в міру використання?
Чи залишається ефективність стабільною зі зростанням впровадження?
Чи відбувається втручання людей у належних випадках?
Відповідні пари можуть змінитися на такі:
вартість взаємодії ↔ оцінена якість результату;
широта впровадження ↔ глибина використання; та
рівень автоматизації ↔ схильність до операційного ризику.
Метрики раннього етапу не обов’язково хибні. Вони відповідають на запитання, важливі на попередньому етапі.
Ризик виникає під час переходу. Метрики пілотного етапу часто зберігаються, бо команди вміють звітувати за ними, а за рішення відмовитися від них ніхто не відповідає. Показники, які раніше сприяли навчанню, можуть поступово перетворитися на марнославні метрики.
Тому пари повинні мати свій життєвий цикл. Командам слід запроваджувати їх для конкретного рішення, перевіряти, чи й далі вони виявляють суттєвий компроміс, і відмовлятися від них, коли змінюється продукт або рішення.
Системам ШІ потрібні детальна спостережуваність, сповіщення, контроль якості й оцінювання. Без цих сигналів безпечна експлуатація продукту ускладнилася б. Але операційний моніторинг — не те саме, що вимірювання для керівництва.
Моніторинг допомагає командам виявляти інциденти, відстежувати збої та розуміти поведінку системи. Метрики для ухвалення рішень допомагають керівникам продукту й бізнесу визначати, чи варто інвестувати, втручатися, змінювати напрям або приймати компроміс.
Організація може відстежувати сотні технічних і операційних сигналів, але для конкретного продуктового рішення виділяти лише дві-три взаємно руйнівні пари. Невелика кількість метрик на рівні ухвалення рішень спрощує визначення пріоритетів.
Належна частота перегляду залежить від продукту. Нова система або система, що стрімко змінюється, може потребувати щотижневого перегляду рішень, а для зрілого продукту може бути достатньо щомісячного чи щоквартального циклу. Принцип важливіший за інтервал: переглядайте пару достатньо часто, щоб устигнути відреагувати, перш ніж компроміс стане дорогим або небезпечним.
Пара стає корисною лише тоді, коли організація узгодить, що робити в разі погіршення її показників.
Для цього недостатньо встановити критичну межу розбіжності. Командам слід розглянути три умови:
Абсолютний збій: один показник перетинає неприйнятний поріг незалежно від іншого.
Розбіжність: один показник покращується, а врівноважувальний — погіршується.
Спільне погіршення: обидва показники знижуються, що свідчить про ширшу проблему продукту або його експлуатації.
Кожна пара повинна мати:
призначеного відповідального;
чітко визначене рішення, яке вона допомагає ухвалити;
узгоджені порогові значення або критерії оцінювання;
порядок розслідування; та
набір можливих заходів реагування.
Без цих складових організація лише спостерігає за продуктом, а не керує ним.
Перш ніж додавати ще один показник, виберіть одне важливе продуктове рішення й опрацюйте ці запитання. Запишіть відповіді, щоб завершити перегляд узгодженим наступним кроком.
1. Яке рішення мають допомогти нам ухвалити ці метрики?
Будьте конкретними: ми вирішуємо, чи розширювати автоматизацію, змінювати модель або вдосконалювати передавання звернення людині? Спершу назвіть рішення, а вже потім вибирайте показники.
2. Якщо цей показник покращиться, що може погіршитися?
Визначте результат, який потрібно захистити, і показник, що виявить шкоду. Наприклад, зіставте вартість взаємодії з оціненою якістю результату, щоб перевірити, чи дешевші відповіді залишаються корисними.
3. Що можуть приховувати ключові показники?
Аналізуйте обидва показники для тих самих користувачів, завдань і періоду часу, а потім шукайте групи з гіршими результатами. Також ураховуйте початкові умови: низька задоволеність може бути наслідком розчарування, що виникло ще до звернення в службу підтримки.
4. Що спонукатиме нас діяти та хто відповідатиме за реакцію?
Установіть критерії дій на випадок, якщо показник перетне неприйнятну межу, один показник покращиться, а інший погіршиться, або погіршаться обидва. Узгодьте, хто проводитиме розслідування, що перевірить насамперед і коли повідомить про результати.
5. Чи досі ця пара відповідає поточному етапу розвитку продукту?
Вирішіть, чи залишити, замінити або вилучити її. Пілотний проєкт може зосереджуватися на надійності виконання завдань і довірі користувачів, а робочий сервіс може потребувати ретельнішого контролю вартості та якості. Призначте дату перегляду цього вибору.
Вимірювання ШІ-продукту має не лише описувати його ефективність. Воно має виявляти компроміси, на які йде організація, і робити наступне рішення зрозумілішим.