De gevolgen van afwegingen monitoren bij de bouw van AI-producten

Door verborgen afwegingen bloot te leggen, kunnen teams problemen met AI-producten diagnosticeren en betere beslissingen nemen.

Belangrijkste conclusies

  • Meer meetwaarden leiden niet per se tot meer inzicht. Veel dashboards bevatten meerdere meetwaarden voor hetzelfde onderliggende gedrag. Meetwaarden bieden meer diagnostische waarde wanneer ze worden gecombineerd tot onderling strijdige paren: kosten en kwaliteit, afhandeling zonder overdracht en sentiment, of nauwkeurigheid en latentie.

  • Welke paren geschikt zijn, verandert naarmate een AI-product van pilot naar productie gaat. De metingen moeten aansluiten op de beslissingen die het team in elke fase moet nemen.

  • Operationele monitoring en strategische metingen dienen verschillende doelen. Teams kunnen honderden systeemsignalen volgen, maar slechts enkele paren gebruiken om productbeslissingen te sturen.

Kerncijfers kunnen een overtuigend verhaal vertellen, terwijl een belangrijke productbeslissing onopgelost blijft.

Klarna's AI-assistent werd publiekelijk in verband gebracht met een grotere doorvoer, lagere kosten en klanttevredenheidsscores die vergelijkbaar waren met die van menselijke agenten. Het jaar daarop besloot het bedrijf menselijke ondersteuning toegankelijker te maken. De CEO erkende dat er te veel nadruk op kostenbesparing had gelegen.

Dit was geen afwijzing van de AI-assistent of de onderliggende technologie. Het bedrijf paste de balans tussen automatisering en menselijke dienstverlening aan op basis van de praktijkervaring met het product. Naarmate automatisering steeds meer eenvoudige vragen in grote aantallen afhandelde, had Klarna medewerkers nodig die complexe, gevoelige gevallen konden afhandelen.

Meer meetwaarden bieden niet altijd meer duidelijkheid

Nadat organisaties vooraf hebben bepaald wat hun AI-product moet bereiken, krijgen de meeste uiteindelijk dezelfde vraag: werkt het echt?

Als het antwoord onduidelijk is, bestaat vaak de neiging om meer meetwaarden toe te voegen. Drie worden er 10 en vervolgens worden 10 er 30. Het dashboard wordt uitgebreider, maar het inzicht van het team hoeft niet toe te nemen.

Het probleem ligt niet altijd bij de kwaliteit van de afzonderlijke meetwaarden, maar bij hun onderlinge samenhang. Klanttevredenheid, Net Promoter Score, beoordelingen en percentages duimpjes omhoog kunnen allemaal nuttige signalen geven, maar weerspiegelen mogelijk vergelijkbare veranderingen in het algemene sentiment. Als ze gelijk opgaan, bevestigen ze dat er iets is gebeurd, maar verklaren ze niet per se waarom.

AI-teams moeten daarom verder kijken dan meetwaarden die elkaar bevestigen en waarden kiezen die concurrerende uitkomsten blootleggen. Deze onderling strijdige paren maken de gevolgen van afwegingen achter productprestaties zichtbaar en meetbaar, zodat betere beslissingen mogelijk worden.

Afwegingen monitoren bij de bouw van realtime spraakagenten: toen meer meetwaarden niet meer hielpen

Bij een implementatie vóór de lancering ontwikkelde het gezamenlijke team een realtime AI-spraakagent voor inkomende gesprekken met de klantenservice. Een van de lastigste vragen ging niet over de keuze van een model of over orkestratie. De vraag was hoe de organisatie zou weten of het product werkte zodra klanten het op grote schaal gingen gebruiken.

Het aanvankelijke kader gebruikte drie meetwaarden:

  • Afhandelingspercentage zonder overdracht: hoe vaak de AI een gesprek afhandelt zonder het naar een medewerker door te verbinden.

  • Escalatiepercentage: hoe vaak een gesprek wordt doorverbonden naar een menselijke agent.

  • Oplossingspercentage: hoe vaak het probleem van de klant uiteindelijk wordt opgelost.

Elke meetwaarde was op zichzelf zinvol. Samen konden ze echter geen antwoord geven op een voor de hand liggende vraag: wat zegt een stijgend escalatiepercentage ons?

Het team splitste escalaties op in acht subtypen. Daarna voegde het meetwaarden toe voor afgebroken gesprekken, klantreizen en timing, plus scores voor taalbegrip en oplossingspercentages per vraagtype. Uiteindelijk omvatte het kader 31 meetwaarden in zes categorieën.

Het kon escalaties gedetailleerd beschrijven, maar de oorzaak nog steeds niet betrouwbaar vaststellen. De meeste meetwaarden waren varianten van hetzelfde gedrag. Daardoor bewogen ze samen in plaats van concurrerende verklaringen te toetsen.

Het dashboard was observerend in plaats van diagnostisch geworden.

Gebruik onderling strijdige paren om afwegingen bloot te leggen

Het team had geen extra uitsplitsingslaag nodig. Het had meetwaarden nodig die elkaar begrensden.

We noemen dit onderling strijdige paren: twee meetwaarden waarbij verbetering van de ene afzonderlijk schade kan toebrengen aan de uitkomst die de andere vertegenwoordigt. De naam beschrijft wat er bij eenzijdige optimalisatie misgaat, niet de gewenste situatie.

Als beide kanten gezond blijven, functioneert het product mogelijk duurzaam. Als ze uiteenlopen, helpt de richting daarvan het team te bepalen waar onderzoek nodig is.

Wat we hadden

Onderling strijdig paar

Wat het paar kan onthullen

Escalatiepercentage opgesplitst in acht subtypen

Escalatiepercentage ↔ tijd tot escalatie

Directe escalatie kan wijzen op een probleem met vertrouwen of positionering; latere escalatie kan betekenen dat het systeem de taak niet kan voltooien.

Afhandelingspercentage zonder overdracht en oplossingspercentage afzonderlijk gerapporteerd

Afhandelingspercentage zonder overdracht ↔ klantsentiment

Of afhandeling zonder overdracht duidt op een bevredigende oplossing of op een klant die de poging opgeeft.

Oplossingspercentage per intentietype

Oplossingspercentage ↔ gespreksdiepte

Of een succesvolle oplossing efficiënt wordt bereikt of een uitputtende interactie vereist.

Om beter te begrijpen hoe dit zichtbaar wordt en wat u met dit inzicht kunt doen, bekijken we het escalatiepercentage en de tijd tot escalatie. Het team weet pas hoe klanten zich gedragen wanneer echte gesprekken binnenkomen, maar kan wel bepalen welke hypothesen het moet toetsen.

Als meer gesprekken worden geëscaleerd en klanten de AI-ervaring binnen 30 seconden verlaten, moet het team onderzoek doen naar vertrouwen, transparantie, toon en de opening van het gesprek. Als klanten escaleren nadat ze enkele minuten hebben geprobeerd een taak uit te voeren, ligt het probleem waarschijnlijker bij de mogelijkheden of de dekking van de workflow.

Het escalatiecijfer op hoofdlijnen is hetzelfde. De productbeslissing is anders.

Een nuttig paar bewijst de oorzaak niet op zichzelf. Het bakent het onderzoek af en maakt de volgende beslissing duidelijker.

Kosten en kwaliteit moeten samen worden beoordeeld

Het eerder genoemde voorbeeld van Klarna laat zien hoe dit principe werkt wanneer kosten en servicekwaliteit op elkaar inwerken. Het laat zien hoe een door AI ondersteund bedrijfsmodel zich kan ontwikkelen terwijl een bedrijf de gevolgen van afwegingen monitort en leert van de implementatie.

In februari 2024 meldde het bedrijf dat zijn AI-assistent in de eerste maand 2,3 miljoen gesprekken had afgehandeld, werk had verricht dat gelijkstond aan dat van 700 voltijdsmedewerkers en klanttevredenheidsscores had behaald die vergelijkbaar waren met die van menselijke agenten. Klarna schatte dat de assistent in 2024 zou bijdragen aan een winstverbetering van 40 miljoen dollar. Dit waren door Klarna zelf gerapporteerde resultaten, geen onafhankelijke evaluatie.

In mei 2025 zei de CEO van Klarna dat het bedrijf bij de klantenservice te veel nadruk op kostenbesparing had gelegd. Hij beschreef plannen om menselijke ondersteuning toegankelijker te maken. Dit was een aanpassing van de balans tussen geautomatiseerde en menselijke dienstverlening, geen afwijzing van de AI-assistent of de onderliggende technologie.

De openbare gegevens laten zien waarom efficiëntiemetingen moeten worden beoordeeld naast de behoeften van verschillende klanten en interacties. Een AI-systeem kan gemiddeld goed presteren, terwijl sommige complexe, gevoelige of ongebruikelijke gevallen nog steeds gebaat zijn bij een toegankelijk menselijk kanaal.

Door beide kanten van die relatie te monitoren, kan een bedrijf bepalen waar automatisering waarde creëert, waar menselijke ondersteuning belangrijk blijft en hoe de balans moet veranderen wanneer er nieuwe gegevens beschikbaar komen.

Andere onderling strijdige paren voor AI-producten zijn bijvoorbeeld:

Onderling strijdig paar

Risico dat het zichtbaar helpt maken

Nauwkeurigheid van antwoorden ↔ antwoordlatentie

Een systeem dat technisch nauwkeurig is, maar te traag voor de workflow.

Taakvoltooiing ↔ percentage handmatige aanpassingen door gebruikers

Een AI-workflow die taken voltooit die gebruikers vervolgens steeds opnieuw uitvoeren.

Kosten per interactie ↔ beoordeelde uitvoerkwaliteit

Besparingen die ten koste gaan van de ervaring van klanten of medewerkers.

Adoptie ↔ tijd tot waarde

Meer aanmeldingen zonder evenredige waarde voor gebruikers.

Het doel is niet om beide meetwaarden onbeperkt te laten stijgen. Het doel is de afweging zichtbaar te maken voordat eenzijdige optimalisatie een operationeel probleem veroorzaakt.

De uitgangssituatie van de klant verandert de betekenis van een meetwaarde

Een verwante uitdaging deed zich voor bij de implementatie van spelersondersteuning voor een bedrijf in mobiele games. Het systeem behandelde veelvoorkomende problemen, zoals verloren voortgang, betalingsgeschillen en toegang tot accounts.

Efficiëntiemetingen waren belangrijk omdat het systeem op grote schaal werkte. Maar spelersondersteuning is niet zomaar een operationele wachtrij. Spelers zijn vaak al gefrustreerd omdat er eerder in hun ervaring iets is misgegaan.

Die uitgangssituatie verandert de manier waarop klanttevredenheidsgegevens moeten worden geïnterpreteerd. Een speler wiens probleem correct is opgelost, kan nog steeds een lage tevredenheid rapporteren omdat de voortgang überhaupt verloren is gegaan. Als die score zonder context wordt beoordeeld, kan de ondersteuningsinteractie worden afgerekend op frustratie die eerder in de klantreis is ontstaan.

Het team moest daarom onderscheid maken tussen het aanvankelijke sentiment van de klant en het effect van de ondersteuningservaring. De nuttigere vraag was niet: "Was de speler tevreden?" De vraag was: "Heeft de interactie de situatie verbeterd ten opzichte van het beginpunt van de speler?"

Die vergelijking kan helpen productfrustratie te onderscheiden van de kwaliteit van de ondersteuning, mits het team beide betrouwbaar kan meten.

Metingen moeten met het product meeveranderen

AI-producten veranderen, maar hun meetwaarden blijven vaak hetzelfde.

Tijdens een pilot kan de centrale vraag zijn of het systeem betrouwbaar genoeg is om verdere investeringen te rechtvaardigen:

  • Voltooit het de kerntaak betrouwbaar?

  • Vertrouwen gebruikers het voldoende om door te gaan?

  • Hoe gedraagt het zich buiten de meest voorkomende scenario's?

  • Kunnen fouten worden vastgesteld en kan het systeem zich er veilig van herstellen?

Bij deze vragen passen paren zoals:

  • succes bij kerntaken ↔ prestaties in uitzonderingssituaties;

  • automatiseringspercentage ↔ percentage menselijke interventies; en

  • voltooiingssnelheid ↔ gebruikersvertrouwen.

Zodra het product operationeel belangrijk wordt, veranderen de vragen:

  • Kan het opschalen zonder kwaliteitsverlies?

  • Wordt het economisch rendabeler naarmate het meer wordt gebruikt?

  • Blijven de prestaties stabiel wanneer de adoptie groeit?

  • Vinden menselijke interventies op de juiste plaatsen plaats?

De bijbehorende paren kunnen verschuiven naar:

  • kosten per interactie ↔ beoordeelde uitvoerkwaliteit;

  • breedte van adoptie ↔ gebruiksdiepte; en

  • automatiseringspercentage ↔ blootstelling aan operationele risico's.

Vroege meetwaarden zijn niet per se verkeerd. Ze beantwoorden de vragen die in een eerdere fase belangrijk waren.

Het risico ontstaat tijdens de overgang. Meetwaarden uit de pilot blijven vaak bestaan omdat teams weten hoe ze die moeten rapporteren en niemand verantwoordelijk is voor het besluit om ermee te stoppen. Meetwaarden die ooit het leerproces ondersteunden, kunnen geleidelijk ijdelheidsstatistieken worden.

Paren moeten daarom een levenscyclus hebben. Teams moeten ze invoeren voor een specifieke beslissing, beoordelen of ze nog steeds een wezenlijke afweging blootleggen en ermee stoppen wanneer het product of de beslissing verandert.

Monitoring en besluitvorming zijn verschillende lagen

AI-systemen vereisen gedetailleerde observeerbaarheid, waarschuwingen, kwaliteitsborging en evaluatie. Zonder die signalen zou het moeilijker zijn om het product veilig te beheren. Maar operationele monitoring is niet hetzelfde als metingen voor het management.

Monitoring helpt teams incidenten te detecteren, fouten te herleiden en systeemgedrag te begrijpen. Beslissingsmeetwaarden helpen product- en bedrijfsleiders te bepalen of ze moeten investeren, ingrijpen, van koers veranderen of een afweging accepteren.

Een organisatie kan honderden technische en operationele signalen monitoren, maar voor een bepaalde productbeslissing slechts twee of drie onderling strijdige paren uitlichten. Door die beslissingslaag klein te houden, wordt prioriteren eenvoudiger.

Hoe vaak evaluatie nodig is, hangt af van het product. Een nieuw of snel veranderend systeem vereist mogelijk wekelijkse besluitvormingssessies, terwijl voor een volwassen product een maandelijkse of driemaandelijkse cyclus kan volstaan. Het principe is belangrijker dan het interval: beoordeel het paar vaak genoeg om te kunnen handelen voordat de afweging duur of onveilig wordt.

Bepaal tot welke actie het paar moet leiden

Een paar wordt pas nuttig wanneer de organisatie afspreekt wat er gebeurt als het verslechtert.

Daarvoor is meer nodig dan een rode lijn voor uiteenlopende waarden. Teams moeten rekening houden met drie situaties:

  • Absolute tekortkoming: één meetwaarde overschrijdt een onaanvaardbare grens, ongeacht de andere.

  • Uiteenlopende ontwikkeling: één meetwaarde verbetert terwijl het tegenwicht verslechtert.

  • Gezamenlijke verslechtering: beide kanten gaan achteruit, wat wijst op een breder product- of operationeel probleem.

Elk paar moet het volgende hebben:

  • een aangewezen eigenaar;

  • een duidelijke beslissing die het ondersteunt;

  • overeengekomen drempelwaarden of evaluatiecriteria;

  • een onderzoeksplan; en

  • een reeks mogelijke interventies.

Zonder deze elementen observeert de organisatie het product slechts, in plaats van het te beheren.

Vijf vragen voor uw volgende evaluatie van meetwaarden

Kies voordat u nog een meetwaarde toevoegt één belangrijke productbeslissing en doorloop deze vragen. Schrijf de antwoorden op, zodat de evaluatie eindigt met een overeengekomen vervolgstap.

1. Welke beslissing moeten deze meetwaarden ons helpen nemen?

Wees specifiek: beslissen we of we automatisering uitbreiden, een model wijzigen of de overdracht naar een medewerker verbeteren? Benoem de beslissing voordat u de meetwaarden kiest.

2. Als dit cijfer verbetert, wat kan er dan verslechteren?

Bepaal welke uitkomst u moet beschermen en met welke meetwaarde eventuele schade zichtbaar wordt. Koppel bijvoorbeeld de kosten per interactie aan de beoordeelde uitvoerkwaliteit om te controleren of goedkopere antwoorden nog steeds nuttig zijn.

3. Wat kunnen de kerncijfers verhullen?

Beoordeel beide meetwaarden voor dezelfde gebruikers, taken en periode en zoek vervolgens naar groepen met slechtere uitkomsten. Houd ook rekening met de uitgangssituatie: lage tevredenheid kan voortkomen uit frustratie die al vóór het contact met de ondersteuning bestond.

4. Wanneer komen we in actie en wie is verantwoordelijk voor de reactie?

Stel criteria op om te handelen wanneer een meetwaarde een onaanvaardbare grens overschrijdt, de ene verbetert terwijl de andere verslechtert of beide achteruitgaan. Spreek af wie onderzoek doet, wat diegene eerst controleert en wanneer er wordt teruggekoppeld.

5. Past dit paar nog bij de huidige fase van het product?

Beslis of u het behoudt, vervangt of niet meer gebruikt. Een pilot kan zich richten op taakbetrouwbaarheid en gebruikersvertrouwen; bij een actieve dienst moeten kosten en kwaliteit mogelijk nauwlettender worden gevolgd. Plan een datum om de keuze opnieuw te bekijken.

Metingen van AI-producten moeten meer doen dan prestaties beschrijven. Ze moeten de afwegingen van de organisatie blootleggen en de volgende beslissing verduidelijken.

Auteurs

Ale Zacarias, Josie Steer