Добавянето на показатели невинаги подобрява разбирането. Много табла съдържат няколко показателя за едно и също основно поведение. Показателите са по-полезни за диагностика, когато се съчетават във взаимно изключващи се двойки: разходи и качество, самостоятелно разрешаване и нагласи или точност и латентност.
Подходящите двойки се променят с прехода на даден AI продукт от пилотен проект към реална експлоатация. Измерването трябва да следва решенията, които екипът трябва да взема на всеки етап.
Оперативното наблюдение и стратегическото измерване служат за различни цели. Екипите може да следят стотици системни сигнали, но да използват само няколко двойки за продуктовите решения.
Водещите показатели могат да разказват убедителна история, без да дават отговор на важно продуктово решение.
AI асистентът на Klarna беше публично свързван с по-висока производителност, по-ниски разходи и оценки за удовлетвореност на клиентите, сравними с тези при човешки Агенти. През следващата година компанията реши да разшири достъпа до човешка поддръжка, а изпълнителният ѝ директор призна, че е било наблегнато прекомерно на намаляването на разходите.
Това не означаваше отказ от ИИ асистента или от технологията, върху която е изграден. Компанията коригира баланса между автоматизацията и обслужването от хора въз основа на натрупания опит с продукта. Тъй като автоматизацията поемаше все повече от многобройните по-прости запитвания, Klarna се нуждаеше от служители, подготвени да се справят със сложни и деликатни случаи.
След като още в началото са определили какво трябва да постигне продуктът, повечето организации, разработващи AI продукти, накрая се изправят пред един и същ въпрос: действително ли работи?
Ако отговорът не е ясен, първият импулс често е да се добавят още показатели. Три стават 10, а после 10 стават 30. Таблото се обогатява, но разбирането на екипа може да не се подобри.
Проблемът невинаги е в качеството на отделните показатели, а във връзката между тях. Удовлетвореността на клиентите, индексът за потребителска лоялност, отзивите и делът на положителните оценки могат да дават полезни сигнали, но е възможно да отразяват сходни промени в общите нагласи. Когато се движат заедно, те потвърждават, че нещо се е случило, но невинаги обясняват защо.
Затова AI екипите трябва да гледат отвъд взаимно потвърждаващите се показатели и да откриват мерки, които разкриват конкуриращи се резултати. Тези взаимно изключващи се двойки разкриват и помагат да се наблюдава въздействието на компромисите зад представянето на продукта, което води до по-добри решения.
При едно внедряване преди пускането съвместният екип разработваше гласов AI Агент в реално време за входящи обаждания до отдела за клиентска поддръжка. Един от най-трудните въпроси не беше свързан с избора на модел или с оркестрацията. Въпросът беше как организацията ще разбере дали продуктът работи, след като клиентите започнат да го използват масово.
Първоначалната рамка използваше три показателя:
Дял на самостоятелно разрешените случаи: колко често AI разрешава обаждането, без да го прехвърля към човек.
Дял на ескалациите: колко често обаждането се прехвърля към човешки Агент.
Дял на разрешените случаи: колко често проблемът на клиента в крайна сметка е разрешен.
Всеки показател беше обоснован. Взети заедно обаче, те не можеха да отговорят на очевиден въпрос: ако ескалациите нараснат, какво ни показва това?
Екипът раздели ескалациите на осем подтипа. След това добави показатели за отказване, клиентския път и времето, оценки за разбиране на езика и дял на разрешените случаи по вид запитване. Накрая рамката включваше 31 показателя в шест категории.
Тя можеше подробно да опише ескалацията, но все още не можеше надеждно да диагностицира причината за нея. Повечето показатели бяха варианти на едно и също поведение, затова се движеха заедно, вместо да проверяват конкуриращи се обяснения.
Таблото вече служеше за наблюдение, а не за диагностика.
Екипът не се нуждаеше от още едно ниво на разбивка. Нуждаеше се от показатели, които се ограничават взаимно.
Наричаме ги взаимно изключващи се двойки: два показателя, при които подобряването само на единия може да навреди на резултата, представен от другия. Наименованието описва нежелания резултат от едностранната оптимизация, а не желаното състояние.
Когато и двете страни остават в добро състояние, продуктът вероятно работи устойчиво. Когато се раздалечат, посоката на разминаването помага на екипа да реши къде да търси причината.
С какво разполагахме | Взаимно изключваща се двойка | Какво може да разкрие двойката |
|---|---|---|
Дял на ескалациите, разделен на осем подтипа | Дял на ескалациите ↔ време до ескалация | Незабавната ескалация може да сочи проблем с доверието или представянето; по-късната може да означава, че системата не успява да изпълни задачата. |
Дял на самостоятелно разрешените случаи и дял на разрешените случаи, отчитани поотделно | Дял на самостоятелно разрешените случаи ↔ нагласа на клиента | Дали самостоятелното разрешаване означава удовлетворително решение, или че клиентът се е отказал. |
Дял на разрешените случаи по вид намерение | Дял на разрешените случаи ↔ дълбочина на разговора | Дали успешното разрешаване е ефективно, или изисква изтощително взаимодействие. |
За да разгледаме по-задълбочено как се разкрива това и как да използваме извода, нека съпоставим дела на ескалациите и времето до ескалация. Екипът няма да знае как се държат клиентите, докато не постъпят реални обаждания, но може да определи хипотезите, които трябва да провери.
Ако повече обаждания започнат да се ескалират и клиентите напускат AI изживяването през първите 30 секунди, екипът трябва да проучи доверието, информирането, тона и началните взаимодействия. Ако клиентите ескалират, след като няколко минути са опитвали да изпълнят дадена задача, по-вероятният проблем е във възможностите или обхвата на работните процеси.
Водещата стойност за ескалациите е една и съща. Продуктовото решение е различно.
Полезната двойка не доказва сама по себе си причината. Тя стеснява обхвата на разследването и изяснява следващото решение.
Представеният по-рано пример с Klarna показва как този принцип се прилага при взаимодействието между разходите и качеството на обслужването. Той показва как оперативен модел с AI може да се развива, докато компанията наблюдава ефекта от компромисите и се учи от внедряването.
През февруари 2024 г. компанията съобщи, че през първия си месец нейният AI асистент е обработил 2,3 милиона разговора, свършил е работа, равностойна на тази на 700 Агенти на пълно работно време, и е постигнал оценки за удовлетвореност на клиентите, сравними с тези при човешки Агенти. Klarna изчисли, че през 2024 г. асистентът ще допринесе за увеличение на печалбата с 40 милиона щатски долара. Това бяха резултати, отчетени от самата Klarna, а не независима оценка.
През май 2025 г. изпълнителният директор на Klarna заяви, че компанията е наблегнала прекомерно на намаляването на разходите за клиентско обслужване, и описа планове за разширяване на достъпа до човешка поддръжка. Това беше корекция на баланса между автоматизираното и човешкото обслужване, а не отказ от AI асистента или от технологията, върху която е изграден.
Публичните данни показват защо показателите за ефективност трябва да се разглеждат заедно с нуждите на различните клиенти и видове взаимодействия. Една AI система може да се представя добре средно, но при някои сложни, чувствителни или необичайни случаи достъпният човешки канал все още е от полза.
Наблюдението на двете страни на тази връзка помага на компанията да решава къде автоматизацията създава стойност, къде човешката поддръжка остава важна и как да променя баланса при появата на нови данни.
Други взаимно изключващи се двойки при AI продуктите може да включват:
Взаимно изключваща се двойка | Рискът, който помага да се разкрие |
|---|---|
Точност на отговора ↔ латентност на отговора | Система, която е технически точна, но твърде бавна за работния процес. |
Изпълнение на задачите ↔ дял на ръчните корекции | AI работен процес, който изпълнява задачи, но потребителите многократно ги правят отново. |
Разход за взаимодействие ↔ оценено качество на резултата | Икономии, постигнати чрез влошаване на изживяването на клиентите или служителите. |
Внедряване ↔ време до получаване на стойност | Ръст на регистрациите без съответна стойност за потребителите. |
Целта не е и двата показателя да се увеличават безкрайно. Целта е компромисът да стане видим, преди едностранната оптимизация да създаде оперативен проблем.
Подобно предизвикателство възникна при внедряване за поддръжка на играчи в компания за мобилни игри. Системата обработваше често възникващи проблеми като загубен напредък, спорове за плащания и достъп до профили.
Показателите за ефективност бяха важни, защото системата работеше в голям мащаб. Но поддръжката на играчите не е просто оперативна опашка. Играчите често идват недоволни, защото нещо вече се е объркало на друг етап от изживяването им.
Това изходно състояние променя начина, по който трябва да се тълкуват данните за удовлетвореността на клиентите. Играч, чийто проблем е разрешен правилно, може все пак да посочи ниска удовлетвореност, защото първоначално е загубил напредъка си. Разглеждането на тази оценка без контекст може несправедливо да натовари взаимодействието с поддръжката с недоволство, възникнало по-рано в клиентския път.
Затова екипът трябваше да разграничи първоначалната нагласа на клиента от ефекта на изживяването с поддръжката. По-полезният въпрос не беше: „Доволен ли беше играчът?“ А беше: „Подобри ли взаимодействието ситуацията спрямо изходното положение на играча?“
Това сравнение може да помогне за разграничаването на неудовлетворението от продукта от качеството на поддръжката, стига екипът да разполага с надежден начин да измерва и двете.
AI продуктите се променят, но показателите им често остават непроменени.
При пилотен проект основният въпрос може да е дали системата е достатъчно надеждна, за да оправдае по-нататъшни инвестиции:
Изпълнява ли надеждно основната задача?
Доверяват ли ѝ се потребителите достатъчно, за да продължат?
Как се държи извън най-често срещаните сценарии?
Могат ли неизправностите да се откриват и отстраняват безопасно?
Тези въпроси насочват към двойки като:
успех на основната задача ↔ представяне в редки случаи;
степен на автоматизация ↔ дял на човешките намеси; и
скорост на изпълнение ↔ увереност на потребителите.
Когато продуктът придобие оперативна значимост, въпросите се променят:
Може ли да се мащабира, без да се понижава качеството?
Подобрява ли се икономическата му ефективност с използването?
Остава ли представянето стабилно с разширяването на внедряването?
Намесват ли се хората на правилните места?
Съответните двойки може да се променят към:
разход за взаимодействие ↔ оценено качество на резултата;
обхват на внедряването ↔ дълбочина на използване; и
степен на автоматизация ↔ излагане на оперативен риск.
Първоначалните показатели не са непременно погрешни. Те отговарят на въпросите, които са били важни на по-ранен етап.
Рискът възниква при прехода. Показателите от пилотния етап често се запазват, защото екипите знаят как да ги отчитат, а никой не отговаря за решението да бъдат премахнати. Показатели, които някога са подпомагали ученето, постепенно могат да се превърнат в показатели за престиж.
Затова двойките трябва да имат жизнен цикъл. Екипите трябва да ги въвеждат за конкретно решение, да проверяват дали още разкриват съществен компромис и да ги премахват, когато продуктът или решението се промени.
AI системите изискват подробна наблюдаемост, предупреждения, осигуряване на качеството и оценяване. Премахването на тези сигнали би затруднило безопасната експлоатация на продукта. Оперативното наблюдение обаче не е същото като измерването за нуждите на ръководството.
Наблюдението помага на екипите да откриват инциденти, да проследяват неизправности и да разбират поведението на системата. Показателите за решения помагат на продуктовите и бизнес ръководителите да решат дали да инвестират, да се намесят, да променят посоката или да приемат даден компромис.
Една организация може да наблюдава стотици технически и оперативни сигнали, но да изведе само две или три взаимно изключващи се двойки за конкретно продуктово решение. Ограничаването на това ниво за решения улеснява определянето на приоритети.
Подходящата честота на преглед зависи от продукта. Нова или бързо променяща се система може да изисква седмични прегледи на решенията, а при зрял продукт те може да са месечни или тримесечни. Принципът е по-важен от интервала: преглеждайте двойката достатъчно често, за да действате, преди компромисът да стане скъп или опасен.
Двойката става полезна едва когато организацията се споразумее какво ще се случи при влошаването ѝ.
За това не е достатъчно само да се определи критична граница на разминаването. Екипите трябва да разгледат три условия:
Абсолютен неуспех: единият показател преминава неприемлив праг независимо от другия.
Разминаване: единият показател се подобрява, а уравновесяващият го показател се влошава.
Съвместно влошаване: и двете страни се влошават, което подсказва по-широк продуктов или оперативен проблем.
Всяка двойка трябва да има:
конкретно посочен отговорник;
ясно решение, което подпомага;
съгласувани прагове или критерии за оценка;
план за разследване; и
набор от възможни действия.
Без тези елементи организацията само наблюдава продукта, вместо да го управлява.
Преди да добавите нов показател, изберете едно важно продуктово решение и разгледайте следните въпроси. Запишете отговорите, така че прегледът да завърши с договорена следваща стъпка.
1. Какво решение трябва да ни помогнат да вземем тези показатели?
Бъдете конкретни: решаваме ли дали да разширим автоматизацията, да сменим даден модел или да подобрим прехвърлянето към човек? Назовете решението, преди да изберете показателите.
2. Ако този показател се подобри, какво може да се влоши?
Определете резултата, който трябва да защитите, и показател, който би разкрил вредата. Например съчетайте разхода за взаимодействие с оцененото качество на резултата, за да проверите дали по-евтините отговори остават полезни.
3. Какво може да прикриват водещите стойности?
Разгледайте двата показателя за едни и същи потребители, задачи и период, след което потърсете групи с по-лоши резултати. Отчетете и изходните условия: ниската удовлетвореност може да отразява недоволство, възникнало преди взаимодействието с поддръжката.
4. Какво би ни накарало да действаме и кой отговаря за реакцията?
Задайте критерии за действие, когато показател премине неприемлива граница, единият се подобрява за сметка на другия или и двата се влошават. Уточнете кой ще разследва, какво ще провери първо и кога ще докладва резултатите.
5. Подходяща ли е тази двойка за текущия етап на продукта?
Решете дали да я запазите, замените или премахнете. Пилотният проект може да се съсредоточи върху надеждността на задачите и увереността на потребителите; работеща услуга може да изисква по-внимателен контрол на разходите и качеството. Определете дата за преразглеждане на избора.
Измерването на AI продуктите не трябва само да описва представянето. То трябва да разкрива компромисите, които прави организацията, и да изяснява следващото решение.