Fler mätvärden ger inte nödvändigtvis bättre förståelse. Många kontrollpaneler innehåller flera mått på samma underliggande beteende. Mätvärden blir mer diagnostiska när de kombineras i par som motverkar varandra: kostnad och kvalitet, självbetjäningsgrad och kundattityd eller precision och svarstid.
Vilka par som är rätt förändras när en AI-produkt går från pilotprojekt till produktion. Mätningen bör utgå från de beslut som teamet behöver fatta i varje skede.
Operativ övervakning och strategisk mätning fyller olika syften. Team kan följa hundratals systemsignaler men använda bara några få par som vägledning för produktbeslut.
Övergripande mätvärden kan berätta en övertygande historia utan att lösa en viktig produktfråga.
Klarnas AI-assistent förknippades offentligt med högre kapacitet, lägre kostnader och kundnöjdhet i nivå med mänskliga agenter. Året därpå beslutade företaget att öka tillgången till mänsklig support, och vd:n medgav att kostnadsminskningar hade fått för stort fokus.
Detta var inte ett avslag på AI-assistenten eller dess underliggande teknik. Det var en justering av balansen mellan automatisering och mänsklig service utifrån företagets erfarenheter av att driva produkten. När automatiseringen tog över fler av de enklare förfrågningarna med hög volym behövde Klarna mänskliga agenter som var rustade för komplexa och känsliga ärenden.
När det från början har fastställts vad en produkt ska åstadkomma ställs de flesta organisationer som utvecklar AI-produkter förr eller senare inför samma fråga: fungerar den faktiskt?
Om svaret är oklart blir den spontana reaktionen ofta att lägga till fler mätvärden. Tre blir 10 och sedan blir 10 till 30. Kontrollpanelen blir mer innehållsrik, men teamets förståelse förbättras kanske inte.
Problemet ligger inte alltid i de enskilda måttens kvalitet, utan i förhållandet mellan dem. Kundnöjdhet, Net Promoter Score, recensioner och andelen tummen upp kan alla ge användbara signaler, men de kan spegla liknande förändringar i den övergripande kundattityden. När de rör sig åt samma håll bekräftar de att något har hänt, men förklarar inte nödvändigtvis varför.
AI-team bör därför se bortom mätvärden som bekräftar varandra och identifiera mått som synliggör konkurrerande utfall. Dessa par av motverkande mätvärden synliggör och hjälper till att följa konsekvenserna av de avvägningar som ligger bakom produktens resultat, vilket ger bättre beslutsunderlag.
I en driftsättning före lansering utvecklade det gemensamma teamet en AI-röstagent i realtid för inkommande kundsupportsamtal. En av de svåraste frågorna handlade varken om val av modell eller orkestrering. Den handlade om hur organisationen skulle veta om produkten fungerade när kunderna började använda den i stor skala.
Det ursprungliga ramverket använde tre mått:
Självbetjäningsgrad: hur ofta AI löser ett samtal utan att koppla det vidare till en person.
Eskaleringsgrad: hur ofta ett samtal kopplas vidare till en mänsklig agent.
Lösningsgrad: hur ofta kundens ärende till slut blir löst.
Varje mått var rimligt. Tillsammans kunde de dock inte besvara en uppenbar fråga: vad säger det oss om eskaleringarna ökar?
Teamet delade upp eskalering i åtta undertyper. Därefter lade man till mått för avbrutna försök, kundresor och tidsförlopp, poäng för språkförståelse samt lösningsgrad per frågetyp. Till slut innehöll ramverket 31 mätvärden i sex kategorier.
Det kunde beskriva eskalering i detalj, men fortfarande inte tillförlitligt fastställa orsaken. De flesta mätvärdena var variationer av samma beteende och rörde sig därför tillsammans i stället för att pröva konkurrerande förklaringar.
Kontrollpanelen hade blivit observerande snarare än diagnostisk.
Teamet behövde inte ytterligare en nivå av uppdelning. Det behövde mätvärden som begränsade varandra.
Vi kallar dem par av motverkande mätvärden: två mått där en isolerad förbättring av det ena kan skada det utfall som det andra representerar. Namnet beskriver det felläge som ensidig optimering skapar, inte det önskade läget.
När båda sidor förblir stabila kan produkten fungera hållbart. När de går isär hjälper riktningen på avvikelsen teamet att avgöra vad som bör undersökas.
Vad vi hade | Par av motverkande mätvärden | Vad paret kan avslöja |
|---|---|---|
Eskaleringsgrad uppdelad i åtta undertyper | Eskaleringsgrad ↔ tid till eskalering | Omedelbar eskalering kan tyda på problem med tillit eller inramning. Senare eskalering kan tyda på att systemet inte kan slutföra uppgiften. |
Självbetjäningsgrad och lösningsgrad redovisade separat | Självbetjäningsgrad ↔ kundattityd | Om självbetjäningen innebär en tillfredsställande lösning eller att kunden ger upp försöket. |
Lösningsgrad per avsiktstyp | Lösningsgrad ↔ samtalsdjup | Om en lyckad lösning är effektiv eller kräver en utmattande interaktion. |
För att närmare förstå hur detta synliggörs och hur insikten kan användas tittar vi på eskaleringsgrad och tid till eskalering. Teamet vet inte hur kunderna kommer att bete sig förrän riktiga samtal kommer in, men det kan definiera vilka hypoteser som behöver prövas.
Om fler samtal börjar eskaleras och kunderna lämnar AI-upplevelsen inom de första 30 sekunderna bör teamet undersöka tillit, transparens, tonläge och de inledande interaktionerna. Om kunder eskalerar efter att i flera minuter ha försökt utföra en uppgift är bristande kapacitet eller täckning av arbetsflödet en troligare orsak.
Det övergripande eskaleringsvärdet är detsamma. Produktbeslutet är ett annat.
Ett användbart par bevisar inte orsaken på egen hand. Det avgränsar utredningen och gör nästa beslut tydligare.
Klarna-exemplet ovan visar hur principen tillämpas när kostnad och servicekvalitet samverkar. Det visar hur en AI-baserad verksamhetsmodell kan utvecklas när ett företag följer konsekvenserna av avvägningar och lär sig av driftsättningen.
I februari 2024 uppgav företaget att dess AI-assistent hade hanterat 2,3 miljoner konversationer under sin första månad, utfört arbete motsvarande 700 heltidsanställda agenter och uppnått kundnöjdhet i nivå med mänskliga agenter. Klarna uppskattade att assistenten skulle bidra med en resultatförbättring på 40 miljoner dollar under 2024. Detta var Klarnas egna rapporterade resultat, inte en oberoende utvärdering.
I maj 2025 sade Klarnas vd att företaget hade lagt för stor vikt vid kostnadsminskningar inom kundservice och beskrev planer på att öka tillgången till mänsklig support. Detta var en justering av balansen mellan automatiserad och mänsklig service, inte ett avståndstagande från AI-assistenten eller dess bakomliggande teknik.
De offentliga uppgifterna visar varför effektivitetsmått bör bedömas tillsammans med olika kunders och interaktioners behov. Ett AI-system kan prestera bra i genomsnitt samtidigt som vissa komplexa, känsliga eller ovanliga fall fortfarande gynnas av en lättillgänglig mänsklig kanal.
Genom att följa båda sidor av relationen kan ett företag avgöra var automatisering skapar värde, var mänsklig support fortsatt är viktig och hur balansen bör ändras när nya belägg framkommer.
Andra par av motverkande mätvärden för AI-produkter kan vara:
Par av motverkande mätvärden | Risk som paret synliggör |
|---|---|
Svarsprecision ↔ svarstid | Ett system som är tekniskt korrekt men för långsamt för arbetsflödet. |
Slutförda uppgifter ↔ användarnas åsidosättningsgrad | Ett AI-arbetsflöde som slutför uppgifter som användarna gång på gång gör om. |
Kostnad per interaktion ↔ utvärderad utdatakvalitet | Besparingar som uppnås genom att försämra kund- eller medarbetarupplevelsen. |
Införandegrad ↔ tid till värde | Fler registreringar utan motsvarande användarvärde. |
Syftet är inte att få båda måtten att öka i all oändlighet. Syftet är att synliggöra avvägningen innan ensidig optimering skapar ett operativt problem.
En liknande utmaning uppstod vid driftsättning av spelarsupport för ett mobilspelsföretag. Systemet hanterade stora mängder ärenden om bland annat förlorade framsteg, betalningstvister och kontoåtkomst.
Effektivitetsmått var viktiga eftersom systemet användes i stor skala. Men spelarsupport är inte bara en operativ kö. Spelare är ofta redan frustrerade när de kommer dit, eftersom något annat i upplevelsen redan har gått fel.
Detta utgångsläge påverkar hur uppgifter om kundnöjdhet bör tolkas. En spelare vars problem löses korrekt kan ändå ange låg nöjdhet eftersom framsteg gick förlorade från början. Om poängen tolkas utan sammanhang kan supportkontakten belastas för frustration som uppstod tidigare i kundresan.
Teamet behövde därför skilja kundens ursprungliga attityd från supportupplevelsens effekt. Den mer användbara frågan var inte: ”Var spelaren nöjd?” Utan: ”Förbättrade interaktionen situationen jämfört med spelarens utgångsläge?”
Den jämförelsen kan hjälpa till att skilja frustration över produkten från supportens kvalitet, förutsatt att teamet kan mäta båda på ett tillförlitligt sätt.
AI-produkter förändras, men deras mätvärden förblir ofta oförändrade.
Under ett pilotprojekt kan huvudfrågan vara om systemet är tillräckligt tillförlitligt för att motivera fortsatta investeringar:
Slutför det kärnuppgiften på ett tillförlitligt sätt?
Har användarna tillräckligt stort förtroende för att fortsätta?
Hur beter det sig utanför de vanligaste scenarierna?
Kan fel identifieras och hanteras säkert?
Dessa frågor talar för par som:
framgång i kärnuppgiften ↔ prestanda i undantagsfall;
automatiseringsgrad ↔ grad av mänskligt åsidosättande; och
slutförandehastighet ↔ användarförtroende.
När produkten blir viktig för verksamheten förändras frågorna:
Kan den skalas upp utan att kvaliteten försämras?
Förbättras dess ekonomi i takt med användningen?
Förblir prestandan stabil när användningen ökar?
Sker mänskliga ingripanden på rätt ställen?
De relevanta paren kan då skifta mot:
kostnad per interaktion ↔ utvärderad utdatakvalitet;
användningens bredd ↔ användningsdjup; och
automatiseringsgrad ↔ exponering för operativa risker.
Tidiga mätvärden är inte nödvändigtvis fel. De besvarar de frågor som var viktiga i ett tidigare skede.
Risken uppstår under övergången. Mätvärden från pilotfasen lever ofta kvar eftersom teamen vet hur de ska rapporteras och ingen ansvarar för beslutet att avveckla dem. Mått som en gång bidrog till lärande kan gradvis bli fåfängemått.
Paren bör därför ha en livscykel. Team bör införa dem för ett definierat beslut, granska om de fortfarande synliggör en väsentlig avvägning och avveckla dem när produkten eller beslutet förändras.
AI-system kräver detaljerad observerbarhet, larmhantering, kvalitetssäkring och utvärdering. Utan dessa signaler skulle det bli svårare att driva produkten säkert. Operativ övervakning är dock inte samma sak som ledningens uppföljning.
Övervakning hjälper team att upptäcka incidenter, spåra fel och förstå systemets beteende. Beslutsmätvärden hjälper produkt- och företagsledare att avgöra om de ska investera, ingripa, byta inriktning eller acceptera en avvägning.
En organisation kan övervaka hundratals tekniska och operativa signaler men lyfta fram endast två eller tre par av motverkande mätvärden för ett visst produktbeslut. En begränsad beslutsnivå gör det enklare att prioritera.
Lämpligt granskningsintervall beror på produkten. Ett nytt eller snabbt föränderligt system kan kräva veckovisa beslutsgenomgångar, medan en mogen produkt kan granskas varje månad eller kvartal. Principen är viktigare än intervallet: granska paret tillräckligt ofta för att kunna agera innan avvägningen blir kostsam eller osäker.
Ett par blir användbart först när organisationen är överens om vad som ska hända om det försämras.
Det kräver mer än att fastställa en röd linje för avvikelsen. Team bör ta hänsyn till tre tillstånd:
Absolut fel: ett mått passerar en oacceptabel gräns, oavsett det andra.
Avvikelse: ett mått förbättras medan dess motvikt försämras.
Gemensam försämring: båda sidor försämras, vilket tyder på ett bredare produkt- eller driftproblem.
Varje par bör ha:
en namngiven ansvarig;
ett tydligt beslut som det stöder;
överenskomna tröskelvärden eller utvärderingskriterier;
en utredningsplan; och
en uppsättning möjliga åtgärder.
Utan dessa delar observerar organisationen bara produkten i stället för att styra den.
Innan ni lägger till ytterligare ett mått bör ni välja ett viktigt produktbeslut och gå igenom dessa frågor. Skriv ned svaren så att granskningen avslutas med ett överenskommet nästa steg.
1. Vilket beslut behöver dessa mätvärden hjälpa oss att fatta?
Var specifika: ska vi besluta om att utöka automatiseringen, byta modell eller förbättra överlämningen till människor? Definiera beslutet innan ni väljer måtten.
2. Vad skulle kunna bli sämre om detta värde förbättras?
Identifiera det utfall ni behöver skydda och ett mått som skulle synliggöra skada. Para exempelvis kostnad per interaktion med utvärderad utdatakvalitet för att kontrollera om billigare svar fortfarande är användbara.
3. Vad kan de övergripande siffrorna dölja?
Analysera båda måtten för samma användare, uppgifter och tidsperiod och leta sedan efter grupper som får sämre resultat. Beakta även utgångsläget: låg nöjdhet kan spegla frustration som fanns redan före supportkontakten.
4. Vad skulle få oss att agera, och vem ansvarar för åtgärden?
Fastställ kriterier för åtgärder när ett mått passerar en oacceptabel gräns, när det ena förbättras medan det andra försämras eller när båda försämras. Kom överens om vem som ska utreda, vad personen först ska kontrollera och när återrapporteringen ska ske.
5. Passar detta par fortfarande produktens nuvarande skede?
Besluta om det ska behållas, ersättas eller avvecklas. Ett pilotprojekt kan fokusera på uppgiftstillförlitlighet och användarnas förtroende. En driftsatt tjänst kan kräva noggrannare granskning av kostnad och kvalitet. Bestäm ett datum för att ompröva valet.
Mätning av AI-produkter bör göra mer än att beskriva resultat. Den bör synliggöra organisationens avvägningar och göra nästa beslut tydligare.