Flere måltall gir ikke nødvendigvis bedre forståelse. Mange kontrollpaneler inneholder flere mål på den samme underliggende atferden. Måltall blir mer diagnostiske når de kombineres i gjensidig destruktive par: kostnad og kvalitet, løsningsgrad og kundeholdning eller nøyaktighet og responstid.
Hvilke par som er riktige, endres når et KI-produkt går fra pilot til produksjon. Målingen bør følge beslutningene teamet må ta på hvert trinn.
Operasjonell overvåking og strategisk måling har ulike formål. Team kan følge hundrevis av systemsignaler, men bare bruke noen få par til å styre produktbeslutninger.
Overordnede måltall kan fortelle en overbevisende historie uten å avklare en viktig produktbeslutning.
Klarnas KI-assistent ble offentlig forbundet med større gjennomstrømming, lavere kostnader og kundetilfredshet på nivå med menneskelige kundebehandlere. Året etter besluttet selskapet å gi bedre tilgang til menneskelig kundestøtte, og konsernsjefen erkjente at kostnadsreduksjon hadde fått for stor vekt.
Dette var ikke en avvisning av AI-assistenten eller teknologien den bygget på. Det var en justering av balansen mellom automatisering og menneskelig service basert på selskapets erfaringer med produktet i drift. Etter hvert som automatiseringen tok over flere av de enklere henvendelsene med høyt volum, trengte Klarna kundebehandlere som var rustet for komplekse og sensitive saker.
Når virksomheter som utvikler KI-produkter, først har definert hva produktet skal oppnå, møter de fleste etter hvert det samme spørsmålet: Fungerer det faktisk?
Hvis svaret er uklart, er instinktet ofte å legge til flere måltall. Tre blir til 10, og deretter blir 10 til 30. Kontrollpanelet blir mer innholdsrikt, men teamets forståelse blir ikke nødvendigvis bedre.
Problemet er ikke alltid kvaliteten på de enkelte målene, men forholdet mellom dem. Kundetilfredshet, Net Promoter Score, anmeldelser og andelen tommel opp kan alle gi nyttige signaler, men de kan gjenspeile lignende endringer i kundenes generelle holdning. Når de beveger seg i samme retning, bekrefter de at noe har skjedd, uten nødvendigvis å forklare hvorfor.
KI-team bør derfor se forbi måltall som samsvarer, og finne mål som avdekker konkurrerende utfall. Disse gjensidig destruktive parene synliggjør og gjør det enklere å overvåke hvordan avveininger påvirker produktytelsen, slik at beslutningene blir bedre.
I én utrulling før lansering utviklet det felles teamet en KI-basert taleagent i sanntid for innkommende kundestøttesamtaler. Et av de vanskeligste spørsmålene handlet ikke om valg av modell eller orkestrering. Det handlet om hvordan virksomheten skulle vite om produktet fungerte når kundene begynte å bruke det i stor skala.
Det opprinnelige rammeverket brukte tre mål:
Løsningsgrad uten overføring: hvor ofte KI-en løser en samtale uten å overføre den til en person.
Eskaleringsgrad: hvor ofte en samtale overføres til en menneskelig kundebehandler.
Løsningsgrad: hvor ofte kundens problem til slutt blir løst.
Hvert av målene var fornuftig. Samlet kunne de imidlertid ikke besvare et opplagt spørsmål: Hva forteller det oss hvis eskaleringen øker?
Teamet delte eskalering inn i åtte undertyper. Deretter la det til mål for avbrudd, kundereise og tidsbruk, poengsummer for språkforståelse og løsningsgrad etter type henvendelse. Rammeverket endte til slutt med 31 måltall fordelt på seks kategorier.
Det kunne beskrive eskalering i detalj, men fortsatt ikke fastslå årsaken pålitelig. De fleste måltallene var varianter av den samme atferden. Derfor beveget de seg sammen i stedet for å teste konkurrerende forklaringer.
Kontrollpanelet hadde blitt observerende snarere enn diagnostisk.
Teamet trengte ikke enda et lag med oppdeling. Det trengte måltall som begrenset hverandre.
Vi kaller disse gjensidig destruktive par: to mål der en isolert forbedring av det ene kan skade utfallet som det andre representerer. Navnet beskriver svikten som ensidig optimalisering kan skape, ikke den ønskede tilstanden.
Når begge sider holder seg på et sunt nivå, kan produktet være bærekraftig i drift. Når de spriker, hjelper retningen på avviket teamet med å avgjøre hva som bør undersøkes.
Det vi hadde | Gjensidig destruktivt par | Hva paret kan avdekke |
|---|---|---|
Eskaleringsgrad fordelt på åtte undertyper | Eskaleringsgrad ↔ tid til eskalering | Umiddelbar eskalering kan tyde på et problem med tillit eller innramming. Senere eskalering kan tyde på at systemet ikke klarer å fullføre oppgaven. |
Løsningsgrad uten overføring og samlet løsningsgrad rapportert separat | Løsningsgrad uten overføring ↔ kundeholdning | Om en løsning uten overføring innebærer at problemet ble løst på en tilfredsstillende måte, eller at kunden ga opp forsøket. |
Løsningsgrad etter hensikt | Løsningsgrad ↔ samtalelengde | Om en vellykket løsning er effektiv eller krever en utmattende samhandling. |
For å se nærmere på hvordan dette kommer til uttrykk, og hva innsikten kan brukes til, vurderer vi eskaleringsgrad og tid til eskalering. Teamet vet ikke hvordan kundene vil opptre før de virkelige samtalene kommer inn, men det kan definere hypotesene som må testes.
Hvis flere samtaler eskaleres og kundene forlater KI-opplevelsen innen de første 30 sekundene, bør teamet undersøke tillit, åpenhet, tone og innledningen på samtalen. Hvis kundene eskalerer etter å ha brukt flere minutter på å forsøke å utføre en oppgave, er manglende funksjonalitet eller arbeidsflytdekning en mer sannsynlig årsak.
Det overordnede eskaleringstallet er det samme. Produktbeslutningen er en annen.
Et nyttig par beviser ikke årsaken alene. Det avgrenser undersøkelsen og tydeliggjør den neste beslutningen.
Klarna-eksempelet ovenfor viser hvordan dette prinsippet gjelder når kostnad og tjenestekvalitet påvirker hverandre. Det viser hvordan en KI-støttet driftsmodell kan utvikle seg når et selskap overvåker effekten av avveininger og lærer av utrullingen.
I februar 2024 rapporterte selskapet at KI-assistenten hadde håndtert 2,3 millioner samtaler den første måneden, utført arbeid tilsvarende 700 heltidsansatte kundebehandlere og oppnådd kundetilfredshet på nivå med menneskelige kundebehandlere. Klarna anslo at assistenten ville bidra til en resultatforbedring på 40 millioner dollar i løpet av 2024. Dette var Klarnas egne rapporterte resultater, ikke en uavhengig evaluering.
I mai 2025 sa Klarnas konsernsjef at selskapet hadde lagt for stor vekt på kostnadsreduksjon i kundeservice, og beskrev planer om å gi bedre tilgang til menneskelig kundestøtte. Dette innebar en justering av balansen mellom automatisert og menneskelig service, ikke en avvisning av KI-assistenten eller teknologien den bygget på.
Den offentlig tilgjengelige dokumentasjonen viser hvorfor effektivitetsmål bør vurderes opp mot behovene i ulike kundegrupper og typer samhandling. Et KI-system kan i gjennomsnitt yte godt, selv om enkelte komplekse, sensitive eller uvanlige saker fortsatt har nytte av en lett tilgjengelig menneskelig kanal.
Ved å overvåke begge sider av forholdet kan et selskap avgjøre hvor automatisering skaper verdi, hvor menneskelig støtte fortsatt er viktig, og hvordan balansen bør endres når ny dokumentasjon kommer til.
Andre gjensidig destruktive par for KI-produkter kan være:
Gjensidig destruktivt par | Risikoen det bidrar til å avdekke |
|---|---|
Svarnøyaktighet ↔ responstid | Et system som er teknisk nøyaktig, men for langsomt for arbeidsflyten. |
Oppgavefullføring ↔ andel brukeroverstyringer | En KI-arbeidsflyt som fullfører oppgaver brukerne stadig gjør om igjen. |
Kostnad per samhandling ↔ evaluert kvalitet på resultatet | Besparelser som oppnås ved å svekke kunde- eller medarbeideropplevelsen. |
Bruk ↔ tid til verdiskaping | Vekst i registreringer uten tilsvarende verdi for brukerne. |
Målet er ikke at begge målene skal øke i det uendelige. Målet er å synliggjøre avveiningen før ensidig optimalisering skaper et driftsproblem.
En lignende utfordring oppsto under utrulling av spillerstøtte for et mobilspillselskap. Systemet håndterte store mengder saker som tapt fremdrift, betalingstvister og kontotilgang.
Effektivitetsmål var viktige fordi systemet var i drift i stor skala. Men spillerstøtte er ikke bare en operasjonell kø. Spillere er ofte frustrerte når de tar kontakt, fordi noe allerede har gått galt tidligere i opplevelsen.
Dette utgangspunktet endrer hvordan data om kundetilfredshet bør tolkes. En spiller som får problemet løst på riktig måte, kan likevel rapportere lav tilfredshet fordi fremdriften gikk tapt i utgangspunktet. Hvis poengsummen leses uten kontekst, kan støttesamtalen bli straffet for frustrasjon som oppsto tidligere i kundereisen.
Teamet måtte derfor skille kundens opprinnelige holdning fra effekten av støtteopplevelsen. Det mest nyttige spørsmålet var ikke: «Var spilleren fornøyd?» Det var: «Forbedret samhandlingen situasjonen sammenlignet med spillerens utgangspunkt?»
Denne sammenligningen kan bidra til å skille frustrasjon over produktet fra kvaliteten på støtten, forutsatt at teamet har en pålitelig måte å måle begge deler på.
KI-produkter endres, men måltallene forblir ofte uendret.
I en pilotfase kan det sentrale spørsmålet være om systemet er pålitelig nok til å forsvare videre investeringer:
Fullfører det kjerneoppgaven pålitelig?
Har brukerne nok tillit til å fortsette?
Hvordan oppfører det seg utenfor de vanligste scenarioene?
Kan feil oppdages og håndteres på en trygg måte?
Disse spørsmålene taler for par som:
suksess med kjerneoppgaven ↔ ytelse i spesialtilfeller;
automatiseringsgrad ↔ andel menneskelige overstyringer; og
fullføringshastighet ↔ brukertillit.
Når produktet blir viktig for driften, endres spørsmålene:
Kan det skaleres uten at kvaliteten reduseres?
Blir økonomien bedre med økt bruk?
Holder ytelsen seg stabil etter hvert som bruken øker?
Skjer menneskelige inngrep på de riktige stedene?
De tilhørende parene kan endres til:
kostnad per samhandling ↔ evaluert kvalitet på resultatet;
bredde i bruk ↔ bruksdybde; og
automatiseringsgrad ↔ eksponering for operasjonell risiko.
De tidlige måltallene er ikke nødvendigvis feil. De besvarer spørsmålene som var viktige på et tidligere stadium.
Risikoen oppstår i overgangen. Måltall fra pilotfasen videreføres ofte fordi teamene vet hvordan de skal rapportere dem, og ingen har ansvar for beslutningen om å avvikle dem. Mål som en gang bidro til læring, kan gradvis bli forfengelighetsmåltall.
Parene bør derfor ha en livssyklus. Team bør innføre dem for en definert beslutning, vurdere om de fortsatt avdekker en vesentlig avveining, og avvikle dem når produktet eller beslutningen endres.
KI-systemer krever detaljert observerbarhet, varsling, kvalitetssikring og evaluering. Uten disse signalene ville det vært vanskeligere å drifte produktet på en trygg måte. Men operasjonell overvåking er ikke det samme som styringsmåling.
Overvåking hjelper team med å oppdage hendelser, spore feil og forstå systematferd. Beslutningsmåltall hjelper produkt- og forretningsledere med å avgjøre om de skal investere, gripe inn, endre retning eller godta en avveining.
En virksomhet kan overvåke hundrevis av tekniske og operasjonelle signaler, men bare løfte frem to eller tre gjensidig destruktive par for en bestemt produktbeslutning. Et lite beslutningsnivå gjør det enklere å prioritere.
Hvor ofte gjennomgangen bør skje, avhenger av produktet. Et nytt system eller et system i rask endring kan kreve ukentlige beslutningsgjennomganger, mens et modent produkt kan gjennomgås månedlig eller kvartalsvis. Prinsippet er viktigere enn intervallet: Gjennomgå paret ofte nok til å kunne handle før avveiningen blir kostbar eller utrygg.
Et par blir først nyttig når virksomheten er enig om hva som skal skje hvis det forverres.
Det krever mer enn å definere en kritisk grense for avvik. Team bør vurdere tre forhold:
Absolutt svikt: Ett mål passerer en uakseptabel terskel, uavhengig av det andre.
Avvik: Ett mål blir bedre mens motvekten blir dårligere.
Samtidig forverring: Begge sider svekkes, noe som tyder på et bredere produkt- eller driftsproblem.
Hvert par bør ha:
en navngitt ansvarlig;
en tydelig beslutning det skal støtte;
avtalte terskler eller evalueringskriterier;
en plan for undersøkelsen; og
et sett med mulige tiltak.
Uten disse elementene observerer virksomheten produktet i stedet for å styre det.
Før dere legger til enda et mål, velger dere én viktig produktbeslutning og jobb dere gjennom disse spørsmålene. Skriv ned svarene, slik at gjennomgangen ender med en avtalt neste handling.
1. Hvilken beslutning skal disse måltallene hjelpe oss med å ta?
Vær konkret: Skal vi avgjøre om vi skal utvide automatiseringen, endre en modell eller forbedre overføringen til mennesker? Definer beslutningen før dere velger målene.
2. Hva kan bli dårligere hvis dette tallet blir bedre?
Finn utfallet dere må beskytte, og et mål som kan avdekke skade. Kombiner for eksempel kostnad per samhandling med evaluert kvalitet på resultatet for å kontrollere om billigere svar fortsatt er nyttige.
3. Hva kan de overordnede tallene skjule?
Les begge målene for de samme brukerne, oppgavene og tidsperiodene, og se deretter etter grupper som får dårligere resultater. Vurder også utgangspunktet: Lav tilfredshet kan skyldes frustrasjon som oppsto før kontakten med kundestøtten.
4. Hva vil få oss til å handle, og hvem har ansvar for responsen?
Fastsett kriterier for handling når et mål passerer en uakseptabel grense, det ene forbedres mens det andre forverres, eller begge blir dårligere. Avtal hvem som skal undersøke, hva de skal kontrollere først, og når de skal rapportere tilbake.
5. Passer dette paret fortsatt til produktets nåværende stadium?
Avgjør om det skal beholdes, erstattes eller avvikles. En pilot kan konsentrere seg om oppgavepålitelighet og brukertillit. En tjeneste i drift kan kreve tettere oppfølging av kostnad og kvalitet. Fastsett en dato for å vurdere valget på nytt.
Måling av KI-produkter bør gjøre mer enn å beskrive ytelsen. Den bør synliggjøre avveiningene virksomheten gjør, og tydeliggjøre den neste beslutningen.