Een servicedesk die netjes in tickets werkt, kan toch geen antwoord geven op de simpelste managementvraag: hoeveel klanten lopen tegen hetzelfde probleem aan? De tickets zijn er wel. Maar ze zijn geschreven voor de afhandeling van dat ene geval, niet voor analyse achteraf.
Tickettriage lost het eerste probleem op: elk ticket krijgt een categorie, een prioriteit en een eigenaar, zodat het niet blijft liggen. Zie daarvoor Service tickets automatisch triageren met AI. Waar triage ophoudt, begint het lastiger werk: van duizenden afgehandelde tickets naar een paar segmenten waar iemand iets mee kan. De intakekant daarvan, mail, formulier of chat die alsnog handmatig wordt uitgezocht, is wat slimme inbox regelt.
Een ticket is een gebeurtenis, geen klantprofiel
Een ticket legt vast wat er op één moment misging. Een segment gaat over een groep klanten die iets gemeen hebben. Dat zijn twee verschillende dingen met een verschillende houdbaarheid.
Wie ze op één hoop gooit, krijgt een dashboard dat per maand van samenstelling verandert zonder dat iemand weet waarom. Houd de bron apart en bereken het segment periodiek opnieuw.
De velden die je vastlegt voordat je iets analyseert
Je hebt geen datawarehouse nodig om te beginnen. Wel een export met een handvol velden die consequent gevuld zijn:
- klantnummer of ordernummer
- contactadres
- kanaal: mail, formulier, chat of telefoon
- categorie en, waar van toepassing, product of dienst
- datum van binnenkomst en van sluiting
- of het ticket heropend is
- een korte samenvatting in gewone taal
Die laatste is belangrijker dan hij lijkt. Zonder samenvatting leunt elke analyse op de eerste regel van de klantmail, en dat is vaak een begroeting met een ordernummer erachter.
Twee dingen gaan bijna altijd mis. De categorie "overig" is in veel servicedesks de grootste categorie, en daar zit juist het signaal. Je komt er alleen achter door de eerste paar honderd tickets handmatig langs te lopen. Het tweede is de afsluiting: een medewerker die een ticket sluit met "opgelost" en verder niets invult, maakt het onderwerp onbruikbaar voor analyse. Dat is geen onwil. Aan het eind van een drukke dag is de volgende klant dringender dan de administratie van de vorige.
De grens die je vooraf vastlegt
Die afweging is geen formaliteit. Ticketdata bevat vaak meer dan de klant verwacht: een klacht over een kapotte machine verraadt iets over de bedrijfsvoering, en een mailwisseling over een zieke medewerker hoort niet in een segmentatieproject. Beperk je tot wat het doel nodig heeft en laat vrije tekst waar het kan buiten de analyse. AI-governance voor het MKB gaat dieper in op het vastleggen van dat soort grenzen.
Koppelen aan het klantprofiel: de matching is het echte werk
Segmenteren op klantniveau betekent dat je tickets aan een klant moet hangen. Dat gaat zelden fout op de techniek en bijna altijd op de gegevens.
Het e-mailadres lijkt de makkelijkste sleutel en is tegelijk de zwakste. Bij een garantieaanvraag mailt de klant vaak vanaf een persoonlijk e-mailadres terwijl de order op het zakelijke adres staat. Bij een bedrijf met drie contactpersonen krijg je drie profielen voor dezelfde klant, of één profiel waar drie mensen in staan. Koppel daarom op klantnummer of ordernummer waar dat kan, en gebruik het e-mailadres alleen als tussenstap.
Wie de koppeling automatiseert, moet ook de uitval accepteren. Een deel van de tickets blijft ongekoppeld, bijvoorbeeld omdat de klant eenmalig was of omdat het klantnummer nooit is ingevuld. Zet die groep apart in plaats van hem aan een willekeurig profiel te plakken.
Vier segmenten die je zonder dashboardproject kunt bijhouden
Begin met een paar segmenten die direct iets zeggen over het werk:
- klanten met drie of meer tickets in een kwartaal
- klanten waarbij hetzelfde thema binnen een maand terugkomt
- tickets die heropend zijn na sluiting
- klanten met een lange doorlooptijd op één specifiek product
Die vier vragen geen model, alleen een groepering en een drempel. De drempel is de lastige keuze: te laag en elk segment is ruis, te hoog en je ziet alleen de uitschieters die je toch al kende. Zet hem in een rapportage die maandelijks meedraait, niet in een query die één iemand zich herinnert. Rapportages automatiseren gaat over die kant van het werk. Voordat een segment leidt tot een actie richting klant, is het de moeite waard om te bepalen wanneer een medewerker moet goedkeuren.
Steekproef van dertig tickets
Pak dertig tickets uit één segment en lees ze. Niet om de telling te controleren, maar om te zien of het label klopt. Vraag de medewerkers die ze hebben afgehandeld wat zij ervan vinden; zij herkennen een verkeerde categorie sneller dan een dashboard.
Twijfelt de meerderheid van de steekproef, dan zit het probleem bijna nooit in het model. Meestal is de categorielijst te fijnmazig, of zijn twee categorieën in de loop der jaren hetzelfde gaan betekenen.
Herhaal de steekproef na elke wijziging in de categorieën en noteer wat je hebt aangepast. Anders doe je hetzelfde werk over een half jaar opnieuw.
Veelgestelde vragen
Kunnen tickets uit chat en telefoon in dezelfde analyse?
Alleen na normalisatie. Een chatbericht heeft geen onderwerpregel, en een telefoonnotitie is in steekwoorden geschreven door de medewerker. Voeg ze samen op categorie, maar houd het kanaal als aparte dimensie. Anders zie je bij een storing in de chat vooral dat chatten populair is geworden.
Hebben we hiervoor een datawarehouse nodig?
Nee, niet in het begin. Een maandelijkse export uit het ticketingpakket plus een koppeling op klantnummer is genoeg voor de eerste vier segmenten. Een warehouse wordt pas nuttig als je meerdere bronnen structureel wilt vergelijken, of als de historie langer moet zijn dan het ticketingpakket bewaart.
Hoe lang mogen we ticketdata bewaren voor dit doel?
Dat hangt af van je doel en van de bewaartermijn die je hebt vastgelegd, en het antwoord is meestal korter dan mensen denken. Bewaar de gestructureerde velden zo lang als nodig is voor trendvergelijking en gooi vrije tekst eerder weg. Juist in die vrije tekst staat wat je niet wilt bewaren: namen van kinderen, ziekmeldingen, persoonlijke omstandigheden.
Wat doe je met klanten die maar één keer contact hadden?
Houd ze in de noemer. Wie alleen klanten met een account meeneemt, krijgt een vertekend beeld van hoe vaak een probleem voorkomt. Tel eenmalige contacten mee in het totaal en sluit ze uit van segmenten die over herhaling gaan.
Is dit een taak voor AI of voor rapportage?
Het tellen en groeperen is gewoon rekenwerk. AI komt pas kijken bij het lezen van vrije tekst: onderwerp bepalen, samenvatten, en klachten herkennen die anders zijn opgeschreven maar hetzelfde betekenen. Een model inzetten om op te tellen maakt een simpele vraag onnodig duur.