Customer journey QA beoordeelt alles wat een klant heeft doorlopen om één probleem opgelost te krijgen: elke bot, AI-agent, chat, telefoon en elk contact met een medewerker over dat probleem binnen een vaste periode. De vraag is niet of elk gesprek goed was, maar of de journey eindigde met een opgelost probleem, zonder loops, verloren context of genegeerde verzoeken om een mens.
In het kort
- Gesprekskwaliteit scoort één contact. Journey QA scoort het hele pad dat een klant aflegde om één probleem op te lossen, over bots, AI-agents, kanalen en mensen heen.
- De meeste fouten van het AI-tijdperk zitten tussen gesprekken: een genegeerd “ik wil een mens spreken”, een loop tussen chat en telefoon, verloren context, een herhaalcontact, een klant die stil afhaakt.
- Definieer een journey als dezelfde klant met hetzelfde probleem binnen een vaste periode, standaard 7 dagen.
- Meet journeys die correct zijn opgelost, contacten per journey, mislukte overdrachten, verloren context, gehonoreerde verzoeken om een mens, stil afhaken en doorlooptijd tot oplossing.
- Beoordeel hele journeys op een journey-scorecard, kies ze op basis van risicosignalen, en geef elke mislukte journey één eigenaar die de oorzaak oplost.
Wat is customer journey QA?
Customer journey QA is kwaliteitscontrole waarbij de eenheid van beoordeling het probleem van de klant is, niet het losse gesprek. Een beoordelaar, of een geautomatiseerde controle, volgt één klant en één probleem over elk contactpunt heen (bot, AI-agent, chat, e-mail, telefoon, medewerker) binnen een vaste periode, en beoordeelt of de journey het probleem correct en zonder onnodige moeite oploste.
Traditionele kwaliteitscontrole leest één ticket en scoort de medewerker die het afhandelde. Met AI-agents vooraan wordt één probleem vaak drie of vier contacten: een gesprek met de bot, een escalatie naar de chat, een telefoontje, een opvolgmail. Elk contact kan voor zijn eigen scorecard slagen terwijl de klant drie dagen nergens komt.
“Customer journey AI agents” betekent vaak marketingtools, zoals de Journey Creation Agent van Microsoft (in het Engels), die journeys via e-mail, sms en pushberichten bouwt op basis van een doel in gewone taal. Deze gids gaat over support: de journeys controleren die klanten echt afleggen als ze hulp nodig hebben.
Waarom mist het scoren van losse gesprekken waar support in het AI-tijdperk misgaat?
Losse gesprekken scoren mist de fouten van het AI-tijdperk, omdat die fouten tussen gesprekken gebeuren. Een bot die “ik wil een mens spreken” negeert, een chat die de klant naar de telefoonlijn stuurt, een overdracht die het ordernummer kwijtraakt of een klant die stil opgeeft: elk gesprek ziet er dan acceptabel uit. Alleen de volledige journey toont de schade.
Klanten zien dit aankomen. In een enquête van Gartner onder 5.728 klanten (december 2023) zei 64% liever te hebben dat bedrijven geen AI inzetten voor klantenservice (in het Engels), en hun grootste zorg was dat een mens bereiken moeilijker zou worden. Gartner adviseert dat een chatbot die het probleem niet kan oplossen, overdraagt aan een chat met een medewerker die “picks up where the chatbot left off” (verdergaat waar de chatbot stopte). Dat is een eis aan de journey.
Het rapport over chatbots in de consumentenfinanciering van het Amerikaanse Consumer Financial Protection Bureau (in het Engels) noemt hetzelfde patroon “doom loops”, vaak veroorzaakt doordat een probleem buiten de beperkte mogelijkheden van de chatbot valt.
Vijf faalpatronen veroorzaken de meeste schade:
| Faalpatroon | Wat de klant ervaart | Waarom een gespreksscore het mist | Signaal in de journey |
|---|---|---|---|
| “Ik wil een mens spreken” genegeerd | Vraagt om een persoon, krijgt meer botantwoorden of loopt vast | De bot bleef beleefd en bij het onderwerp, dus zijn gesprek slaagt | Expliciet verzoek om een mens zonder contact met een mens in de journey |
| Kanaalloop | De chat zegt bellen, de telefoon zegt chatten, niemand lost het op | Elk contact stuurde de klant “correct” ergens naartoe | Hetzelfde probleem, 2 of meer kanaalwissels, geen oplossing |
| Context verloren bij een overdracht | Herhaalt het ordernummer, het probleem, de stappen die al geprobeerd zijn | De medewerker was vriendelijk en stelde de juiste vragen | De klant geeft hetzelfde gegeven twee keer in één journey |
| Herhaalcontact | Het probleem was “opgelost” en komt dagen later terug | Het eerste gesprek eindigde met een zelfverzekerd antwoord | Nieuw contact over hetzelfde probleem binnen de periode |
| Stil afhaken | Geeft halverwege op, zegt misschien op of vertrekt | Geen klacht, geen enquête, het ticket sluit als opgelost | De journey eindigt zonder oplossing en zonder verder contact |
Klanten op openbare supportfora beschrijven de kanaalloop in één zin: de chat stuurt ze naar de telefoonlijn, en de telefoonlijn stuurt ze terug of hangt op. Het chattranscript en het telefoongesprek zouden apart gescoord geen van beide zakken. Voor de fouten binnen één AI-gesprek die dashboards als winst tellen, zie onze gids over stille fouten van AI-agents.
Hoe definieer je een customer journey voor QA?
Definieer een customer journey als elk contact van dezelfde klant over hetzelfde probleem binnen een vaste periode, bijvoorbeeld 7 dagen vanaf het eerste contact. Je hebt drie geschreven regels nodig voordat je iets beoordeelt: hoe je dezelfde klant herkent, hoe je hetzelfde probleem herkent, en wanneer een journey als beëindigd telt.
Dezelfde klant. Gebruik de sterkste identificatie die je hebt: klant-ID of accountnummer, dan een geverifieerd e-mailadres, dan het telefoonnummer. Tel anonieme chats apart in plaats van te gokken.
Hetzelfde probleem. Koppel op het intent-label, het order- of casenummer, of een gekoppeld ticket. Zijn de labels onbetrouwbaar, laat een beoordelaar de koppelingen dan eerst op een steekproef bevestigen.
De periode. Kies die per type probleem en houd ze daarna vast:
| Type probleem | Voorgestelde periode | Waarom |
|---|---|---|
| Eenvoudige hoe-doe-ik- of accountvragen | 3 dagen | Komt het later terug, dan is het meestal een nieuwe vraag |
| Bestellingen, leveringen, retouren | 7 dagen | Dekt het wachten op een levering of een terugbetaling |
| Facturatie, terugbetalingen, betwistingen | 14 dagen | Een verkeerd antwoord komt naar boven op het volgende overzicht of de volgende betaling |
| Claims, opzeggingen, gereguleerde cases | 30 dagen | Lange processen met meerdere verplichte stappen |
Deze periodes zijn onze startregels, geen standaard uit de sector. Zet de dagen tussen het eerste en het tweede contact over hetzelfde probleem in een grafiek, en leg de periode waar de meeste echte opvolgcontacten al binnen zijn.
Hoe een journey eindigt. Opgelost (het eigenlijke probleem is opgelost en er volgde niets binnen de periode), afgehaakt (de klant stopte zonder oplossing) of open (later beoordelen). First contact resolution (in het Engels) gebruikt dezelfde herhaalperiode maar kijkt alleen naar het eerste contact; journey QA beoordeelt het hele pad.
Welke metrics meet je op het niveau van de journey?
Meet zeven journey-metrics: het aandeel journeys dat correct is opgelost, contacten per journey, het percentage mislukte overdrachten, het percentage verloren context, gehonoreerde verzoeken om een mens, het percentage stil afhaken en de doorlooptijd tot oplossing. Samen tonen ze of klanten geholpen worden, hoeveel moeite dat ze kost en welke naad het vaakst breekt. Rapporteer ze per type probleem en per kanaal van binnenkomst.
| Metric | Zo bereken je het | Startregel (van ons, stem af op je eigen basislijn) |
|---|---|---|
| Journeys correct opgelost | Journeys waarin het eigenlijke probleem correct is opgelost / afgesloten journeys | Onderzoek elk type probleem onder 85% |
| Contacten per journey | Alle contacten, elk kanaal / journeys | Onderzoek elk type probleem boven 1,5 |
| Percentage mislukte overdrachten | Overdrachten die context verloren, te laat kwamen of de klant terugstuurden / beoordeelde overdrachten | Streef naar minder dan 5% |
| Percentage verloren context | Journeys met meerdere contacten waarin de klant een gegeven herhaalde / journeys met meerdere contacten | Onderzoek boven 5% |
| Verzoeken om een mens gehonoreerd | Expliciete verzoeken om een persoon gevolgd door contact met een mens / alle zulke verzoeken | Streef naar 95% of meer |
| Percentage stil afhaken | Journeys die onopgelost eindigden zonder klacht / afgesloten journeys | Beoordeel elke week een steekproef, wat het percentage ook is |
| Doorlooptijd tot oplossing | Eerste contact tot oplossing, mediaan en 90e percentiel | Let op het 90e percentiel |
Een hoge containment rate (in het Engels) kan een slechte journey verbergen: een klant die de bot verlaat en de telefoonlijn belt, telt nog steeds als contained. Contacten per journey vangt dat op. En houd “opgelost” gescheiden van “correct opgelost”: een zelfverzekerd verkeerd antwoord ziet eruit als opgelost tot het herhaalcontact binnenkomt. Onze audit van het oplossingspercentage van AI-agents laat zien hoe je dat controleert.
De journey-scorecard (kopieer deze)
De journey-scorecard is een korte set criteria die alleen zin hebben over een hele journey. Elk criterium heeft een duidelijke voorwaarde voor zakken en noemt de data die een beoordelaar nodig heeft. Scoor elk gesprek zoals gewoonlijk op je normale scorecard; scoor de journey daarbovenop op deze criteria, zodat het ene het andere nooit vervangt.
| # | Journey-criterium | Wat telt als zakken | Data die je nodig hebt |
|---|---|---|---|
| 1 | Het eigenlijke probleem was aan het eind correct opgelost | Probleem niet opgelost, verkeerd opgelost, of “opgelost” en terug binnen de periode | Alle contacten in de periode, het eindresultaat, het beleid of kennisartikel dat geldt |
| 2 | Verzoeken om een mens zijn gehonoreerd (kritiek) | De klant vroeg om een persoon en kreeg die niet, of pas na 2 of meer keer vragen | Transcripten van bot en AI-agent, escalatielog |
| 3 | Geen loop tussen bots, kanalen of teams (kritiek) | De klant werd teruggestuurd naar een kanaal of agent die hij al had geprobeerd voor hetzelfde probleem | Kanaal en behandelaar per contact, routeringslog |
| 4 | Context is bij elke overdracht meegegaan | De klant herhaalde een identificatie, het probleem of stappen die al geprobeerd waren | Transcripten aan beide kanten van elke overdracht, de overdrachtssamenvatting als die er is |
| 5 | Escalatie gebeurde op de juiste trigger | Te laat geëscaleerd (na herhaalde mislukte antwoorden) of zonder reden doorgeschoven naar een mens | Escalatieregels, transcript op het moment van overdracht |
| 6 | Consistente antwoorden over kanalen en behandelaars heen | Twee contacten gaven de klant verschillende antwoorden over hetzelfde beleid | Alle gegeven antwoorden, het beleid dat geldt |
| 7 | Beloftes zijn nagekomen | Een terugbelactie, terugbetaling of opvolging beloofd in één contact gebeurde niet | Beloftes in transcripten, order- of casesysteem |
| 8 | De moeite stond in verhouding | Meer contacten of dagen dan het type probleem nodig heeft (boven je regel voor contacten per journey of doorlooptijd) | Aantal contacten, tijdstempels |
| 9 | Het einde was expliciet | De journey eindigde in stilte met het probleem onopgelost (stil afhaken) | Laatste contact, resultaat, eventuele opzegging of vertrek |
Scoringsregel. Een journey zakt als hij zakt op criterium 1, 2 of 3 (de kritieke). Tel anders de overige keren zakken: 0 is geslaagd, 1 is geslaagd met een bevinding, 2 of meer is gezakt. Leg voor elke keer zakken één oorzaaksegment vast: de bot, een benoemde AI-agent, de routerings- of overdrachtsregel, een kanaal, een medewerker, of de content van beleid of kennisbank. Die toewijzing maakt van een journeyscore een oplossing.
Criterium 4 is dezelfde continuïteitscontrole die onze gids over het beoordelen van de overdracht tussen AI en mens diepgaand behandelt, één naad tegelijk. Voor journeys waarin meerdere AI-agents een case aan elkaar doorgeven, behandelt onze uitleg over AI-agent orkestratie de routeringspatronen achter criteria 3 en 5.
Hoe kies en beoordeel je hele journeys?
Kies journeys in twee lagen: beoordeel elke journey die een risicosignaal geeft (een genegeerd verzoek om een mens, 3 of meer contacten, 2 of meer kanalen, een loop of afhaken), en voeg een willekeurige steekproef van gewone journeys toe om het echte foutpercentage te meten. Beoordeel elke journey in tijdsvolgorde, op één tijdlijn, met elk contact naast elkaar.
Laag 1: journeys met een risicosignaal. Hier concentreren de fouten zich, dus lees ze allemaal, of een vast aantal per signaal per week:
- Een expliciet verzoek om een persoon (“medewerker”, “mens”, “iemand spreken”) in een transcript van een bot of AI-agent.
- 3 of meer contacten, of 2 of meer kanaalwissels, over hetzelfde probleem.
- Een herhaalcontact na een contact dat als opgelost was gemarkeerd.
- Een journey die onopgelost eindigt zonder verder contact.
Laag 2: een willekeurige steekproef. Signalen tonen waar je moet kijken, niet hoe vaak het misgaat. Om een foutpercentage te rapporteren dat je kunt verdedigen, voeg je een willekeurige steekproef van afgesloten journeys toe; 150 tot 400 per maand geeft een bruikbare foutmarge voor één type probleem. Ons stuk over statistiek van QA-steekproeven (in het Engels) legt uit waarom kleinere steekproeven misleiden.
Zo beoordeel je één journey. Bouw de tijdlijn opnieuw op: elk contact in datumvolgorde, met kanaal en behandelaar (bot, AI-agent, medewerker, keuzemenu). Lees het eerste en het laatste contact vóór het midden; het verschil tussen waar de klant om vroeg en waar hij mee eindigde, is het oordeel. Loop daarna elke naad na. Telefoongesprekken hebben een transcript of samenvatting nodig om op dezelfde tijdlijn te staan; veel contactcenters scoren al een steekproef van gesprekken, en de journeybeoordeling zet ze naast de contacten via chat en bot.
Het template voor journeybeoordeling
Kopieer dit naar een spreadsheet of beoordelingsformulier. Eén blok per journey.
| Veld | Wat je invult |
|---|---|
| Journey-ID | Je eigen ID, of het eerste ticketnummer |
| Klant en probleem | Klantidentificatie, type probleem, order- of casenummer |
| Periode | Datum eerste contact, lengte van de periode, eindstatus (opgelost, afgehaakt, open) |
| Tijdlijn | Eén rij per contact: datum en tijd, kanaal, afgehandeld door (bot, benoemde AI-agent, medewerker, keuzemenu), wat er gebeurde in één regel, context meegekomen (ja of nee), resultaat |
| Risicosignalen | Welke signalen uit laag 1 er waren, als die er waren |
| Journey-scorecard | Geslaagd of gezakt op criteria 1 tot 9, met het contactnummer als bewijs |
| Oordeel | Geslaagd, geslaagd met bevinding, gezakt |
| Oorzaaksegment | Bot, AI-agent (naam), routerings- of overdrachtsregel, kanaal, medewerker, beleid of kennis |
| Eigenaar en oplossing | Wie eigenaar is van dat segment, de afgesproken oplossing, de datum waarop ze live gaat |
| Hercontrole | De datum waarop je hetzelfde type journey opnieuw beoordeelt |
Een uitgewerkt voorbeeld (illustratie, de cijfers zijn verzonnen om de berekening te tonen)
Een supportteam handelt 50.000 contacten per maand af via een chatbot, een AI-agent in chat en e-mail, een telefoonlijn en medewerkers. Samengevoegd tot journeys met een periode van 7 dagen vormen die contacten 38.000 journeys:
- 31.800 journeys (84%) hebben één contact.
- 6.200 journeys hebben er twee of meer, met samen 18.200 contacten (2,94 per journey).
- Contacten per journey in totaal: 50.000 / 38.000 = 1,32.
De gesprekskwaliteit ziet er gezond uit: 91% van de gesprekken in de steekproef slaagt. Dan beoordeelt de QA-lead een willekeurige steekproef van 150 journeys met meerdere contacten. Er zakken 48 (32%):
| Oorzaak | Gezakte journeys | Aandeel van de fouten |
|---|---|---|
| Context verloren bij de overdracht van bot naar mens | 17 | 35% |
| Verzoek om een mens genegeerd of vertraagd | 12 | 25% |
| Loop tussen chat en telefoon | 9 | 19% |
| Verkeerde oplossing, klant kwam terug | 6 | 13% |
| Verschillende antwoorden over beleid in chat en aan de telefoon | 4 | 8% |
| Totaal | 48 | 100% |
In die 48 gezakte journeys zitten 141 gesprekken, en 118 daarvan (84%) slaagden voor de scorecard voor gesprekken. De journeys zakten terwijl de meeste gesprekken erin slaagden.
Opgeschaald is 32% van 6.200 ongeveer 1.980 gezakte journeys per maand. De foutmarge bij 95% betrouwbaarheid is ongeveer plus of min 7,5 punten (1,96 × √(0,32 × 0,68 / 150) = 0,075), dus het echte aantal ligt tussen ongeveer 1.520 en 2.450. Beide uitersten zijn het oplossen waard. En 29 van de 48 fouten (60%) komen uit twee naden, de overdrachtsgegevens en de regel voor verzoeken om een mens, dus daar gaan de eerste oplossingen naartoe.
Zie het op je eigen gesprekken. Kaizo scoort 100% van je supportgesprekken, van medewerkers en AI-agents, tegen je eigen scorecard, en koppelt elke score aan het bewijs in het gesprek. Boek een demo.
Wie is eigenaar van de kwaliteit van de customer journey?
Eén persoon moet eigenaar zijn van de journeykwaliteit van begin tot eind, meestal het hoofd support of support operations, omdat geen eigenaar van een kanaal of agent het hele pad ziet. Die eigenaar beheert de journey-metrics en de wekelijkse review. Elke gezakte journey gaat daarna naar de eigenaar van het segment dat de fout veroorzaakte.
| Rol | Is eigenaar van | Handelt bij |
|---|---|---|
| Journey-eigenaar (hoofd support of support operations) | De journey-metrics, de journey-scorecard, de wekelijkse review | Prioriteiten over teams heen; escaleert als een oplossing blijft hangen |
| Eigenaar AI-agent (per bot of AI-agent) | De instructies, kennis en escalatietriggers van de agent | Fouten toegewezen aan die agent: verkeerde antwoorden, genegeerde verzoeken om een mens |
| Eigenaar routering en overdracht | Routeringsregels, overdrachtsgegevens, overdracht tussen kanalen | Loops, verloren context, late escalatie |
| Kanaalleads (chat, e-mail, telefoon) | Het proces en de bezetting van elk kanaal | Kanaalloops, mislukte terugbelacties, inconsistente antwoorden |
| QA-lead | Steekproeven, kalibratie van beoordelaars, het beoordelingstemplate | Betrouwbare journeyscores; nieuwe faalpatronen |
| Eigenaar kennis en beleid | De content waaruit mensen en AI-agents antwoorden | Inconsistente antwoorden over kanalen heen |
Twee regels voorkomen dat dit een schuldvergadering wordt. Elke gezakte journey krijgt precies één oorzaaksegment; leg de rest vast als bijkomende bevindingen. En de oplossing hangt af van wie de fout maakte: een persoon krijgt coaching, een AI-agent krijgt een wijziging in zijn instructies, kennis of triggers. Zie mensen coachen versus AI-agents verbeteren.
Hoe los je de fouten op die journey QA vindt?
Los journeyfouten op bij de naad die ze veroorzaakte, niet in het gesprek waarin ze zichtbaar werden. De meeste oplossingen zijn regelwijzigingen: een escalatietrigger, de overdrachtsgegevens, een regel die zegt wanneer een verzoek om een mens altijd wordt gehonoreerd, of één gedeeld antwoord over een beleid in alle kanalen. Beoordeel daarna hetzelfde type journey opnieuw om te bevestigen dat de oplossing standhoudt.
| Gevonden fout | Typische oplossing | Lees meer |
|---|---|---|
| “Ik wil een mens spreken” genegeerd | Een harde regel: een expliciet verzoek, of een tweede mislukt antwoord, leidt tot een overdracht met samenvatting | AI-agent guardrails |
| Kanaalloop | Schrap antwoorden als “bel ons” of “gebruik de chat” voor problemen die het andere kanaal ook niet kan oplossen; bied in plaats daarvan terugbellen of een ticket aan | Waarom AI-gesprekken mislukken |
| Context verloren bij overdracht | Vaste overdrachtsgegevens: klant-ID, probleem, geprobeerde stappen, wat de klant wil | De overdracht tussen AI en mens beoordelen |
| Inconsistente antwoorden | Eén beleidsbron waaruit zowel mensen als AI-agents antwoorden, met versiebeheer | Beleid voor AI-agents |
| Verkeerde oplossing, herhaalcontact | Beperk wat de AI-agent alleen mag oplossen; audit zijn oplossingen | Autonomieniveaus van AI-agents |
| Stil afhaken | Beoordeel afgehaakte journeys elke week; voeg een opvolging toe voor onopgeloste problemen met hoog risico | AI-agent monitoring |
Test elke wijziging voordat ze klanten bereikt, en meet ze daarna in productie. Onze gids over AI-agents evalueren behandelt beide: testsets vóór de lancering, en live gesprekken scoren daarna.
Wanneer is journey QA niets voor jou?
Journey QA is de opzet niet waard als de meeste problemen in één contact worden opgelost en je geen bot of AI-agent vooraan hebt. Liggen de contacten per journey rond 1,1, wisselen klanten zelden van kanaal en heb je een paar honderd contacten per week, dan tonen gesprekskwaliteit plus een eenvoudig cijfer voor first contact resolution al wat je nodig hebt.
Het is te vroeg als je contacten niet aan een klant kunt koppelen: zijn de meeste chats anoniem en hebben telefoongesprekken geen klantidentificatie, los dat dan eerst op. Lees intussen elk transcript met een expliciet verzoek om een mens, waarvoor je niets hoeft te koppelen. En journey QA vervangt kwaliteitscontrole van gesprekken nooit: het ene toont waar het pad brak, het andere wat er binnen een contact misging.
Hoe je deze week begint
Je kunt deze week met journey QA beginnen, met een spreadsheet en één type probleem. Het doel van week één is geen dashboard. Het is de ene naad vinden die de meeste journeys breekt, zodat de eerste oplossing de moeite terugbetaalt.
- Kies één type probleem met hoog volume waarbij een bot of AI-agent het eerste contact afhandelt, zoals orderstatus of terugbetalingen.
- Schrijf de drie regels op: welke identificatie, welk label of casenummer, welke periode.
- Haal 30 journeys op: 20 met een risicosignaal en 10 willekeurige.
- Beoordeel ze op de journey-scorecard en het template, met één oorzaaksegment per fout.
- Benoem de eigenaar van de slechtste naad en spreek één oplossing met een datum af.
- Herhaal het volgende week op hetzelfde type probleem om te zien of de oplossing standhoudt.
Bewijst de handmatige beoordeling het patroon, automatiseer dan wat schaalt. Kwaliteitscontrole van AI-agents met Kaizo scoort gesprekken van AI-agents en medewerkers op dezelfde scorecard, inclusief de vraag of de agent op de juiste trigger escaleerde en de context doorgaf, en AutoPilot scoort elk gesprek zodra het in Zendesk of Salesforce is opgelost. Die gesprekken samenvoegen tot journeys doe je met je helpdeskdata: gekoppelde tickets, klant-ID’s en intent-labels. Voor het grotere plaatje, zie onze gids over agentische klantenservice.
Veelgestelde vragen
Wat is een goed aantal contacten per journey?
Er is geen universele benchmark, want het hangt af van het type probleem. Gebruik je eigen basislijn per type probleem en onderzoek alles wat stijgt. Als startregel horen eenvoudige vragen dicht bij 1,0 te liggen, en verdient alles boven 1,5 een blik op de journeys erachter.
Is customer journey QA hetzelfde als customer journey mapping?
Nee. Journey mapping ontwerpt het pad dat je klanten wilt laten volgen, vaak voor marketing of service design. Journey QA controleert de paden die klanten echt aflegden, contact voor contact, en beoordeelt of elk pad het probleem oploste zonder loops, verloren context of genegeerde verzoeken om een mens.
Kun je journeys via telefoon en chat samen beoordelen?
Ja, als elk telefoongesprek een transcript of geschreven samenvatting heeft op dezelfde plek als je contacten via chat en e-mail. De journeybeoordeling zet het gesprek dan op dezelfde tijdlijn als de contacten met bot en chat en past dezelfde journey-criteria toe. Zonder transcript of samenvatting kan een beoordelaar het gesprek alleen op de uitkomst beoordelen.
Is journey QA hetzelfde als AI-agent monitoring?
Nee. Monitoring volgt live signalen voor één AI-agent, zoals het escalatiepercentage, fouten en drift, en geeft een alert als die bewegen. Journey QA beoordeelt afgeronde journeys over elke bot, agent, elk kanaal en elke persoon heen, en beoordeelt of het probleem van de klant is opgelost. Monitoring vertelt je dat er iets veranderde; journey QA vertelt je wat het de klant kostte.
Hoe ontdek je stil afhaken?
Zoek naar journeys die onopgelost eindigden zonder verder contact: een botgesprek dat halverwege stopte, een escalatie waar de klant nooit op reageerde, een terugbelactie die nooit tot stand kwam. Sommige van deze klanten losten het elders op; sommige zegden op. Beoordeel elke week een steekproef en controleer waar je kunt opzeggingen of vertrek in de weken erna.
