AI-agent voor het triëren en prioriteren van supporttickets

Een ticket triëren is niet hetzelfde als het beantwoorden. Het is beslissen waar het over gaat, hoe dringend het is, en wie het moet oppakken. Die stap lijkt eenvoudig van veraf, maar kost een enorme hoeveelheid tijd zodra het volume stijgt, en verslechtert snel als niemand er continu op toeziet. Een autonome AI-agent kan precies deze stap overnemen, degene die aan het eigenlijke antwoord voorafgaat.

Het probleem

Het aantal tickets daalt niet. Volgens een McKinsey-onderzoek geciteerd door Zendesk verwacht 57 procent van de bestuurders dat het volume aan telefoontjes en klantenservicetickets de komende een tot twee jaar met tot een vijfde zal stijgen (https://www.zendesk.fr/blog/customer-service/satisfaction/customer-service-statistics/). Tegelijk stijgen de verwachtingen: het CX Trends 2026-rapport van Zendesk, gebaseerd op meer dan 11.000 ondervraagde consumenten en CX-verantwoordelijken in 22 landen, geeft aan dat 88 procent van de klanten sneller antwoord verwacht dan een jaar geleden, en dat 74 procent van de consumenten 24/7 beschikbare support inmiddels als de norm beschouwt (https://cxtrends.zendesk.com/). Hetzelfde rapport is streng over de gevolgen van slechte triage: 85 procent van de CX-verantwoordelijken vindt dat klanten een merk verlaten na een onopgelost probleem, zelfs al bij het eerste contact.

Triage behoort ook tot de meest tijdrovende taken voor supportteams, wat de beschikbare tijd beperkt voor het deel dat er echt toe doet: het antwoord aan de klant. Het Customer Service Transformation-rapport van Intercom (2025) meldt dat 76 procent van de supportteams vorig jaar uiteindelijk in AI heeft geïnvesteerd, tegenover 54 procent die dat aanvankelijk van plan was, een teken dat de operationele druk vaak de oorspronkelijke plannen inhaalt (https://www.intercom.com/blog/customer-service-transformation-report-2025/). Hetzelfde rapport constateert dat slechts 19 procent van de supportteams vindt dat hun huidige tools volledig aan hun behoeften voldoen, wat suggereert dat een groot deel van de triagelast vandaag nog altijd handmatig gebeurt.

Deze handmatige triage heeft, naast de traagheid, een verborgen kost: de consistentie. Iemand die al acht uur tickets triëert, classificeert ze niet meer met dezelfde nauwkeurigheid als bij het begin van de dag, en in het weekend of buiten de wachtdienstureen triëert niemand tot het team terugkeert. Een urgent ticket dat op een zaterdagochtend binnenkomt, kan dus tot maandag wachten voor het zelfs maar wordt gezien, niet alleen voor het wordt behandeld. Dit dekkingsgat, meer nog dan de verwerkingssnelheid zelf, weegt het zwaarst op de klantervaring bij organisaties zonder eigen supportwachtdienst.

Wat de agent doet, stap voor stap

Bij Atako draait deze agent continu, niet alleen tijdens de kantooruren van het supportteam. Hij ontvangt nieuwe tickets via de gekoppelde integraties met Zendesk, Intercom of Freshdesk, afhankelijk van de tool van het bedrijf, en analyseert elk bericht om de intentie, het onderwerp en een urgentiescore te bepalen.

Vervolgens verrijkt hij het ticket met de klanthistorie uit het CRM (anciënniteit, afgesloten plan, eerdere tickets), voor hij het classificeert per categorie (facturatie, bug, productvraag, opzegging) en per bestemmingsteam. Op dat moment worden configureerbare escalatieregels toegepast: VIP-status van het account, vermelding van gevoelige trefwoorden zoals een opzegging of juridische vermelding, of een ticket dat te lang zonder antwoord bleef. Het ticket wordt vervolgens gerouteerd naar de juiste wachtrij, met alle context al bijgevoegd, en een melding gaat naar Slack voor urgente of geëscaleerde gevallen. Elke classificatiebeslissing wordt vastgelegd, zodat een mens die achteraf kan corrigeren en de regels kan verfijnen.

Wat deze agent bewust niet doet: het uiteindelijke antwoord aan de klant schrijven, of het ticket sluiten. Dat is de rol van een agent voor automatisering van supporttickets, een aparte bouwsteen die het overneemt zodra de triage is gebeurd.

De gebruikte integraties

Zendesk levert het lezen van binnenkomende tickets en de historie (get_ticket, search_tickets), met het bijwerken van categorie en prioriteit via update_ticket zodra de classificatie is gebeurd. Op Intercom koppelt de agent aan de conversaties om berichten in real time te classificeren en dubbelzinnige gevallen naar een mens door te sturen. Voor teams die Freshdesk gebruiken in plaats van Zendesk geldt dezelfde lees- en herclassificatielogica.

HubSpot dient om het ticket te verrijken voor de prioriteit wordt bepaald: een zoekopdracht naar een contact (search_contacts) of een lopende deal kan aan het licht brengen dat het om een grootzakelijk account of een naderende verlenging gaat, twee elementen die de werkelijke prioriteit van een ticket veranderen. Slack ontvangt ten slotte de melding wanneer een ticket als urgent wordt geclassificeerd, via post_message in het door het team gekozen supportkanaal.

Wat bij de mens blijft

De agent antwoordt nooit in plaats van het supportteam aan de klant, en hij sluit geen enkel ticket. Zijn rol stopt bij classificatie, verrijking en routering. Elke integratie die hij gebruikt hangt af van een precieze grant, met een vastgelegde reikwijdte (alleen lezen of lezen en schrijven): op Zendesk kan een grant bijvoorbeeld het volledig lezen van tickets toestaan maar de schrijftoegang beperken tot alleen het bijwerken van de categorie, zonder de inhoud van het ticket zelf te raken.

Drie dingen blijven structureel bij de mens. Eerst tickets behandelen en beantwoorden zodra ze getriëerd zijn, de agent bereidt het terrein voor, hij schrijft het antwoord aan de klant niet. Vervolgens verkeerd geclassificeerde tickets herclassificeren: een foute classificatie blijft zichtbaar en aanpasbaar als elk ander ticket, en de agent corrigeren hoort bij de normale werking, niet bij een falen dat verborgen moet blijven. Ten slotte de criteria voor urgentie en escalatie vastleggen en laten evolueren, werk dat de fijnzinnige kennis van het supportvak vereist die het team behoudt.

Deze taakverdeling komt overeen met wat human-in-the-loop wordt genoemd: de agent absorbeert het volume en de herhaling van de triage, de mens houdt de beslissing over het antwoord en over de regels zelf. Elke integratieaanroep die de agent uitvoert (een ticket lezen, een categorie bijwerken, een Slack-melding), wordt vastgelegd met de status, zichtbaar in de activiteitentijdlijn van de agent, en in detail raadpleegbaar door een beheerder in het bedrijfsbrede integratielogboek.

Meetbaar resultaat

Het belangrijkste voordeel is de consistentie: een ticket dat op een zondagavond om middernacht binnenkomt, wordt even snel geclassificeerd en gerouteerd als een ticket dat op een dinsdagochtend om 10 uur binnenkomt. Dat hangt niet langer af van wie op dat precieze moment beschikbaar is om de wachtrij te openen en handmatig te triëren. Voor een team met een groeiend ticketvolume, zoals het McKinsey-onderzoek hierboven suggereert, is dit het deel van het werk dat de volumestijging het best opvangt zonder een even snel recruteringstempo, met een stabiele triagetijd zelfs als het aantal tickets van kwartaal tot kwartaal verdubbelt.

Het Standard-plan van Atako kost 20 euro per maand per agentslot, met 1000 credits inbegrepen per maand voor de modelaanroepen die worden gebruikt voor het lezen, classificeren en verrijken van elk ticket. Deze kost hangt af van noch het volume behandelde tickets, noch het aantal leden van het supportteam dat de classificaties raadpleegt, alleen het aantal gelijktijdig actieve agents telt. Het volledige detail staat op de pagina tarieven.