OXIAE / AI AGENTS & CHATBOTS

AI-agent voor klantvragen.

Ondersteun klantcontact met een agent die kennis gebruikt en gericht doorverwijst.

Bespreek jouw project

Een chatbot of een klantenservice-oplossing?

Een assistent moet ook toegestane acties in achterliggende systemen uitvoeren.

AI Klantenservice Agent (deze dienst)
DE DIENST UITGELEGD

Wanneer is een supportvraag echt overgedragen aan een medewerker?

Een AI-klantenserviceagent kan een vraag innemen, het onderwerp herkennen, toegestane informatie verzamelen en de volgende stap voorbereiden. Het proces eindigt niet zodra er een ticketsamenvatting is geschreven. Er moet zichtbaar zijn of de overdracht alleen is aangevraagd, in een bevestigde wachtrij staat of door een medewerker is aangenomen. Ik ontwerp die stappen met je supportteam, inclusief wie eigenaar wordt van een open vraag en wat er gebeurt als de overdracht niet wordt bevestigd. Voor de bredere keuze tussen antwoordsuggesties, kenniszoeken en automatisering biedt AI-klantenservice het overzicht.

Wanneer is dit passend?

Dit past bij terugkerende vragen die meerdere voorbereidende stappen vragen voordat de juiste medewerker kan handelen. Denk aan het scheiden van een algemene procedurevraag en een vraag over een specifieke bestelling, het herkennen van ontbrekende informatie en het overdragen van context. Begin met één vraagtype, één intakekanaal en een team dat de overdrachten daadwerkelijk kan aannemen.

Wanneer kies je beter anders?

Gebruik bestaande ticketregels als onderwerp en bestemming al uit vaste velden volgen. Een agent is geen vervanging voor een ontbrekende supportbezetting of een onduidelijk besluit over uitzonderingen. Een klacht, verzoek om terugbetaling of vraag over een individueel account vraagt de afgesproken menselijke en toegangscontroles. Het model mag geen vergoeding, vervanging of antwoordtermijn toezeggen om de vraag af te sluiten.

PRAKTISCHE VERDIEPING

Een klantenservice-agent moet ook kunnen overdragen

Voor een klantenservice-agent maak ik eerst onderscheid tussen algemene informatie, klantgebonden informatie en acties op een account. Een openingstijd beantwoorden vraagt andere toegang dan een order opzoeken. De identiteit en rechten van de klant worden gecontroleerd voordat afgeschermde gegevens beschikbaar komen. [1]

De overdracht aan een medewerker bevat de vraag, de geraadpleegde informatie en wat al is geprobeerd. We spreken af welke onderwerpen direct worden doorgezet. Een opgelost gemarkeerd gesprek telt pas als succes wanneer de uitkomst inhoudelijk juist is; alleen minder menselijke overdrachten is geen voldoende kwaliteitsmaat. [2]

Vragen om vooraf te beantwoorden

  • Welke vragen vereisen identificatie of directe menselijke behandeling?
  • Waar komt de overdracht terecht en binnen welke werkafspraak?

Maak de oplevering meetbaar

  • Tests met onbekende klanten en verzoeken om andermans accountinformatie.
  • Beoordeling van antwoordjuistheid én bruikbaarheid van de overdracht.
FICTIEF SUPPORTPROCES

Een ontbrekend trainingspakket: wie neemt de vraag over?

Dit uitgewerkte ontwerpvoorbeeld gaat over een fictieve leverancier van trainingsmaterialen. Een klant schrijft: “Ik heb mijn pakket bij order TR-482 niet ontvangen. Mijn cursus is morgen; stuur alvast een nieuw pakket.” Het voorbeeld laat triage en overdracht zien. Het is geen werkende agent, klantcase of test van account- en ticketrechten.

  1. Bewaar de melding en haar herkomst

    De intake krijgt referentie SUP-482 en bewaart de oorspronkelijke vraag. Bekend is wat de klant meldt en vraagt. Of het pakket is verzonden, waar het zich bevindt en of de afzender toegang tot de order heeft, is nog onbekend. De gewenste cursusdatum is een klantmelding, geen door de leverancier bevestigde leverafspraak.

  2. Scheid algemene uitleg van orderinformatie

    In de fictieve algemene werkinstructie staat dat support vragen over niet ontvangen pakketten beoordeelt aan de hand van een orderreferentie. Die bron bevat geen recht op een vervangend pakket en geen gegarandeerde antwoordtermijn. De agent kan het proces toelichten, maar haalt er geen toezegging uit die er niet staat.

  3. Stop waar accountcontrole nodig is

    In dit voorbeeld is de afgesproken accountcontrole nog niet voltooid. De agent haalt daarom geen orderstatus of adres op en doet daarover geen uitspraak. Hij maakt de open controle zichtbaar en verwijst naar de bestaande afgesproken identificatiestap. Een ordernummer in de chat telt niet als toestemming om accountinformatie te openen.

  4. Vraag een overdracht met bruikbare context aan

    Voor deze intake is alleen het vastleggen en aanbieden van de supportvraag toegestaan, na de daarvoor afgesproken rechtencontrole. De voorgestelde overdracht noemt SUP-482, de oorspronkelijke melding, de gevraagde vervanging, de ontbrekende accountcontrole en de grenzen van de algemene bron. Een bevestigd ticket betekent alleen dat de vraag is vastgelegd. Pas na bevestiging van de bedoelde supportwachtrij staat de status op “in wachtrij — nog niet aangenomen”. Er wordt geen vervanging besteld en de vraag blijft open.

  5. Herstel een onbevestigde overdracht

    Valt de verbinding weg vóór de bevestiging, dan is de uitkomst “overdracht onbevestigd”. De toepassing zoekt eerst met SUP-482 of de plaatsing al bestaat; opnieuw proberen mag geen tweede losstaand ticket maken. Kan de uitkomst niet worden vastgesteld of neemt niemand de bevestigde wachtrijmelding aan, dan wordt de afgesproken wachtrijverantwoordelijke ingeschakeld. De klant krijgt geen melding dat een medewerker de vraag al behandelt.

  6. Laat een medewerker het eigenaarschap aannemen

    Een medewerker neemt de vraag expliciet aan; daarna wordt de verantwoordelijke bij SUP-482 zichtbaar en verandert de status naar “aangenomen — nog niet opgelost”. Die medewerker rondt de accountcontrole af en beoordeelt de order en het verzoek volgens de geldende afspraken. Een eventuele vervanging, vergoeding of klanttoezegging wordt apart geautoriseerd; het aannemen van de vraag voert die actie niet uit.

Wat dit proces oplevert

Het resultaat is een open supportvraag met controleerbare context, zichtbare ontbrekende informatie en een bevestigde stand van de overdracht. “Aangenomen” betekent dat iemand verantwoordelijk is voor de volgende stap; het betekent niet dat de bestelling is gevonden of de klantvraag is opgelost. Dit beschrijft een mogelijk ontwerp, geen gemeten resultaat.

Zo toets je dit voorbeeld

  • Laat het team de klantmelding en de bron vergelijken: worden niet ontvangen, niet verzonden en recht op vervanging terecht als verschillende zaken behandeld?
  • Bied dezelfde orderreferentie zonder voltooide accountcontrole aan: accountgegevens blijven buiten het antwoord en de ontbrekende controle blijft zichtbaar.
  • Onderbreek de overdracht na een mogelijke plaatsing: zoek de uitkomst op SUP-482 terug voordat opnieuw wordt aangeboden en controleer op dubbele tickets.
  • Laat de wachtrijbevestiging en daarna de menselijke acceptatie apart plaatsvinden: de status verandert pas bij de bijbehorende bevestiging en sluit de vraag niet af.

Welke aanpak past bij jouw vraag?

Kies op basis van het werk, de betrokken mensen en wat je kunt beheren.

AanpakGeschikt wanneerAfweging
Ticketregels en formulierenDe benodigde gegevens en de route naar het juiste team liggen vooraf vast.Vaste regels zijn vaak voldoende. Test ook onvolledige aanvragen, een onbereikbaar team en de route voor uitzonderingen.
Ondersteuning van de medewerkerEen medewerker blijft aan de beurt en wil hulp bij samenvatten, zoeken en een conceptantwoord.De medewerker beoordeelt en verzendt het antwoord. Er is geen zelfstandige overdrachtsketen nodig als het werk al bij de juiste eigenaar ligt.
Begrensde klantenserviceagentDe intake vraagt meerdere stappen en moet met gecontroleerde context naar een verantwoordelijke medewerker.Bij een AI-agent laten bouwen worden de toegestane stappen en systeemacties afgebakend. Een gevonden antwoord of aangemaakte wachtrijmelding is nog geen aangenomen klantvraag.

Wat is nodig om te starten?

  • Eén type supportvraag met een begin, toegestane voorbereidende stappen en expliciete stopvoorwaarden. Leg vast welke vraag rechtstreeks naar een medewerker gaat en welke handelingen buiten de eerste versie blijven.
  • Goedgekeurde algemene kennis met een eigenaar en geldigheidsafspraken. Een AI-kennisbank kan die bronnen ondersteunen. Houd algemene procedures apart van actuele gegevens over een persoon, account of bestelling.
  • Afspraken over identificatie en rechten buiten het taalmodel. Bepaal via welk bestaand proces iemand toegang tot accountgegevens krijgt. Een genoemd ordernummer, een naam of een overtuigend verhaal mag die controle niet vervangen; vraag ook niet om extra gegevens die voor de taak niet nodig zijn.
  • Een bestemming, een verantwoordelijke voor de wachtrij en een expliciete manier waarop een medewerker de vraag aanneemt. Houd voorgestelde classificatie, bevestigd ticket, toewijzing aan een wachtrij en menselijke acceptatie apart. Leg ook vast wie onbevestigde overdrachten opvangt en wanneer die zichtbaar worden voor handmatige opvolging.
  • Een stabiele referentie voor intake en overdracht, met een bevestigde of onbekende uitkomst per stap. Een API-integratie met een bestaand supportsysteem vraagt controle op beschikbare functies, rechten, herhaalde verzoeken en het terugzoeken van de uitkomst. Leesrechten geven geen recht om een ticket te wijzigen, een bericht te versturen of een vergoeding te boeken; de toepassing moet die acties afzonderlijk autoriseren.

Hoe beoordelen we het resultaat?

  • Het team controleert per gegeven of het afkomstig is uit de klantvraag, een toegestane bron of nog onbekend is. Een klantmelding over niet ontvangen goederen wordt niet zonder controle als bevestigd leveringsfeit vastgelegd.
  • Zonder de afgesproken accountcontrole worden geen klantspecifieke gegevens opgehaald of onthuld. Test dit ook met een geldig ogend ordernummer dat bij een ander account hoort; een instructie aan het model is geen toegangscontrole.
  • De werklijst onderscheidt een nog te bevestigen overdracht, een bevestigde wachtrijplaatsing en een vraag die door een medewerker is aangenomen. Zonder ontvangstbevestiging mag de toepassing niet melden dat het werk bij een medewerker ligt.
  • Bij een onderbreking wordt de uitkomst op dezelfde referentie gecontroleerd voordat een overdracht opnieuw wordt aangeboden. Een herhaald verzoek veroorzaakt geen tweede losstaand ticket en een ontbrekende bevestiging blijft zichtbaar voor de afgesproken verantwoordelijke.
  • Toets met het team de inhoudelijke juistheid, ontbrekende context, verkeerde bestemmingen en tijd tot menselijke acceptatie. Een snelle samenvatting of een leeggelopen intakeoverzicht bewijst niet dat de klantvraag is opgelost. Terugbetaling, vervanging en andere toezeggingen vragen afzonderlijke beoordeling en autorisatie.
SCOPE & INVESTERING

Wat bepaalt de kosten?

Een bruikbare kosteninschatting begint bij de scope. Ik onderscheid ontwikkelwerk van terugkerende gebruiks- en beheerkosten. Dit zijn de belangrijkste factoren:

  • Een eerste pilot: één vraagtype, één intakekanaal, geselecteerde kennis en een team dat de overdracht in representatieve voorbeelden beoordeelt.
  • De variatie in klantvragen, benodigde accountcontext en voorbereiding van een beoordelingsset. Neem onvolledige vragen, onjuiste aannames en ontbrekende bevestigingen mee.
  • Koppelingen met het bestaande supportsysteem, identificatie, rechten, bevestigde statussen en herstel na een onzekere uitkomst. Spreek vastlegging en klantcommunicatie apart af.
  • Terugkerend modelgebruik, eventuele licenties, hosting en beheer, naast menselijke review en het onderhouden van bronnen, routes en bezettingsafspraken.
TOEPASSING EN AFBAKENING

Jouw uitdaging.
Een concrete toepassing.

Illustratief scenario; geen gepubliceerde klantcase.

Terugkerende vragen zorgen voor een volle supportwachtrij.

Een klantenserviceagent combineert antwoorden met afgebakende vervolgstappen, terwijl AI-klantenservice ook de inrichting van het bredere supportproces omvat. Een beheerde AI-kennisbank helpt bepalen welke bronnen de agent mag gebruiken en wanneer een vraag naar een medewerker moet.

DE VRAAG DIE IK EERST STEL

Welke vragen kan de agent beantwoorden en welke moeten direct naar je team?

Spreek de eerste stap af

Gebruik de randvoorwaarden, oplevercriteria en kostenfactoren hierboven om je opdracht af te bakenen. Spreek af wie het resultaat beoordeelt en wie de oplossing beheert. In onze werkwijze lees je hoe verkenning, uitvoering en overdracht samenhangen.

Bekijk onze werkwijze
VRAGEN OVER DEZE DIENST

Jouw vragen.
Heldere antwoorden.

Is een ticket aanmaken hetzelfde als overdragen aan een medewerker?

Nee. Een bevestigd ticket kan nog onbeheerd in een wachtrij staan. Ik onderscheid daarom bevestiging door het supportsysteem van acceptatie door een medewerker. De werkwijze bepaalt wie de wachtrij bewaakt en wie ingrijpt wanneer geen acceptatie volgt. Als het systeem geen acceptatiestap ondersteunt, moeten we een andere controleerbare afspraak ontwerpen.

Mag de agent orderinformatie gebruiken als de klant een ordernummer noemt?

Een ordernummer in een gesprek vervangt de afgesproken account- en rechtencontrole niet. Die controle gebeurt in de toepassing of het bestaande klantproces, buiten het model. Totdat die controle rond is, kan de agent algemene uitleg geven en de vraag voorbereiden zonder klantspecifieke gegevens op te halen of te onthullen.

Kan de agent zelf een terugbetaling of vervangende zending goedkeuren?

De hier beschreven eerste scope bereidt de vraag en de overdracht voor. Een medewerker beoordeelt uitzonderingen, vervanging en vergoeding, met aparte autorisatie voor een systeemactie of toezegging. Een aangemaakte supportmelding of een overtuigend conceptantwoord is geen goedkeuring.

Wat gebeurt er als het supportsysteem geen bevestiging teruggeeft?

De uitkomst blijft zichtbaar als onbevestigd. Eerst wordt met dezelfde referentie nagegaan of de overdracht al bestaat. Opnieuw aanbieden vraagt een gecontroleerde werkwijze die dubbele tickets voorkomt. Kan de uitkomst niet worden vastgesteld, dan volgt de afgesproken handmatige route; de vraag wordt niet stilzwijgend afgesloten.

Bronnen en technische onderbouwing

Deze primaire bronnen onderbouwen de technische principes in deze uitleg. De projectaanbevelingen zijn de interpretatie van OXIAE; de uitgevers bevelen OXIAE daarmee niet aan. Productdocumentatie geldt voor het genoemde platform.

  1. Authorization Cheat SheetOWASP

    Onderbouwing voor toegangscontrole op klantinformatie.

    Link en relevantie gecontroleerd:
  2. LLM06:2025 Excessive AgencyOWASP GenAI Security Project

    Begrenzing van acties met gevolgen voor klanten.

    Link en relevantie gecontroleerd:
JOUW VOLGENDE STAP

Bereid je projectgesprek voor.

Verken je AI Klantenservice Agent? Gebruik de projectchecklist om je taak, systemen en gewenste uitkomst te beschrijven. Verzamel open vragen en download een brief voor je gesprek.

Maak je projectbrief
VAN VRAAG NAAR VOLGENDE STAP

Wat wil jij
mogelijk maken?

Plan een kennismaking