Claims-intake chat agent: van 14 minuten naar 95 seconden

Het is dinsdagochtend 09:14 in Utrecht. Een bezorger heeft net de leasebus van een klant op de A2 van achteren aangereden. De klant opent op de vluchtstrook de website van de makelaar, tikt op de chat agent in de hoek van de pagina, en begint met één duim Nederlands te typen. Veertig seconden later heeft ze een schadenummer, een uploadlink voor foto's, en een terugbelmoment met de schade-expert. Nog niemand bij de makelaar heeft een toetsenbord aangeraakt.

De makelaar schrijft jaarlijks zo'n €38 miljoen aan bruto getekende premie, verdeeld over motorrijtuigen, beroepsaansprakelijkheid en klein zakelijk vastgoed. Negenentwintig mensen. Drie schadebehandelaars, twee telefoonlijnen, één gedeelde inbox. Ze zijn niet groot. Ze mogen ook geen schademelding kwijtraken, geen gereguleerde tijdstempel laten vallen en niet improviseren rond Solvency II. Dat is de echte beperking van dit verhaal.

De intakedesk voordat wij in beeld kwamen

De gemiddelde first-notice-of-loss-intake duurde 14 minuten. Daarvan was zo'n vier minuten het eigenlijke gesprek. De rest was dezelfde gegevens overtikken in Anva, het polisadministratiesysteem, en daarna een tweede ronde om het gesprek netjes vast te leggen voor compliance. Op een drukke maandag stonden er voor de lunch al 180 mails in de inbox, en op woensdag was het team nog bezig met het bevestigen van de inzendingen van vrijdag.

Het team wilde geen chatbot. Ze hadden er al eentje geprobeerd. Een product van een leverancier was na drie maanden stilletjes uitgezet, omdat de behandelaars steeds excuses moesten maken voor wat hij klanten had verteld. De briefing die wij kregen was specifiek: hetzelfde gesprek, maar sneller, zonder dat er iets in het reglementaire dossier achteruit ging. Als het een minuut van de doorlooptijd afhaalde maar een audit trail kostte, was het mislukt.

Wat een FNOL eigenlijk is

First Notice of Loss is het moment waarop een polishouder de verzekeraar laat weten dat er iets mis is gegaan. Onder Solvency II Pijler 3 en de rapportageverwachtingen van toezichthouder DNB zijn bepaalde velden niet optioneel: tijdstip van het incident, locatie, polisnummer, betrokken partijen, een bandbreedte voor de schade-inschatting, en een helder onderscheid tussen wat de polishouder claimt en wat onafhankelijk is geverifieerd. Het intakegesprek moet een dossier opleveren dat jaren later gereconstrueerd kan worden door een auditor die er niet bij was.

De fout die de meeste teams maken als ze hier een language model op zetten: ze behandelen het als een vrij gesprek. FNOL is geen vrij gesprek. Het is een gestructureerd formulier met een beleefde stem ervoor. De chat is het interview, het formulier is het eindproduct, en allebei moeten ze een audit overleven.

De vorm van de agent

We bouwden de agent in drie lagen. Een conversation layer die in de eigen taal van de klant praat. Een schema layer die een strikt FNOL-object invult. Een bridge layer die dat object wegschrijft naar Anva, Outlook en de auditlog.

Het schema is het dragende stuk. Hieronder de ingekorte versie zoals 'ie in productie draait:

type FNOLDraft = {
  policy_ref: string | null
  reported_at: string            // ISO 8601, server-stamped
  incident_at: string | null     // ISO 8601, claimant-stated
  language: 'nl' | 'en'
  party: { name: string; role: 'policyholder' | 'third_party' | 'witness' }
  location: { freeform: string; geo?: { lat: number; lng: number } }
  line_of_business: 'motor' | 'pi' | 'property' | 'other'
  damage_estimate_eur: { min: number; max: number } | null
  third_party_involved: boolean
  injuries_reported: boolean
  attachments: Array<{ kind: 'photo' | 'pdf' | 'video'; url: string }>
  verbatim_log: Array<{ role: 'user' | 'agent'; text: string; ts: string }>
  provenance: Record<string, { from_turn: number; confidence: 'stated' | 'inferred' }>
}

De agent doet per beurt één van drie dingen: aanvullen op verbatim_log, een veld updaten met een provenance-entry, of de volgende ontbrekende vraag stellen. Verder niets. Geen samenvattingen, geen commentaar, geen meningen. De tooling layer maakt zichtbaar wat er nog mist, de conversation layer bepaalt hoe je daar netjes naar vraagt.

Tweetalig zonder language router

De portefeuille van de makelaar is grofweg 70% Nederlands en 30% Engels, met veel expatklanten in Utrecht en Amsterdam. Het eerste ontwerp dat we schetsten had bij beurt één een taaldetectiestap die naar twee aparte prompts routeerde. Binnen een week hebben we dat eruit gegooid.

Het probleem is code-switching. Een Nederlandse klant die in het Nederlands begint, gooit er soms een Engelse zin tussendoor ("the other driver said it was his fault") omdat het gesprek nou eenmaal zo gaat. Een aparte prompt per taal dwingt een harde switch af en levert een verwarde agent op die dezelfde vraag twee keer stelt.

Wat wel werkt: één system prompt, allebei de talen vooraan benoemd, en een instructie om de klant te spiegelen.

Reply in the same language the customer just used.
If they switch mid-conversation, switch with them.
Always log the customer's verbatim words in the language they used.
Never translate the customer's words in the audit log.

Die laatste regel telt voor Solvency II. De audit trail moet laten zien wat de polishouder daadwerkelijk zei, niet wat een model dacht dat hij bedoelde. Vertaling hoort thuis in een aparte, duidelijk gelabelde kolom voor het gemak van de behandelaar, niet in het dossier zelf.

Het audit-trail-probleem

De eerste build sneuvelde in de compliance review op één zin in onze specificatie: "de agent vat de schade in één paragraaf samen voor de behandelaar." Makelaars onder DNB-toezicht mogen geen samenvatting indienen die de polishouder zelf nooit heeft gezien. De behandelaar die de samenvatting leest, kan handelen op een gehallucineerd detail en het nooit weten.

We bouwden de overdracht zo om dat de behandelaar er altijd drie dingen ziet staan, nooit twee: het gestructureerde FNOL-concept, het verbatim transcript byte voor byte, en een veld-voor-veld provenance map. Vult de agent injuries_reported: false in, dan wijst de provenance map naar de exacte beurt waarop de klant zei "geen gewonden". Heeft de agent het uit een stilte afgeleid, dan blijft het veld null en verschijnt er een "unconfirmed"-vlag in de view van de behandelaar. We maakten zichtbaar wat er niet gevraagd was. Die ene verandering veranderde het gesprek van een black box in iets waar de compliance officer een handtekening onder zette.

Waarom dit nu minder theoretisch is

Europese rechters en toezichthouders bewegen naar een duidelijke lijn over door AI gegenereerde uitspraken: zegt jouw systeem iets onjuist over een gereguleerde gebeurtenis, dan ben jij aan zet, niet de modelleverancier. Bij een DNB-dossier bestaat er geen verweer met "het model zei het".

Voor een verzekeringsmakelaar moet elke schadesamenvatting die de agent uitstuurt te verdedigen zijn, ofwel als de eigen woorden van de polishouder, ofwel als een duidelijk gemarkeerde afleiding. De provenance map is geen nice-to-have. Het is het verschil tussen een verdedigbaar dossier en een publieke rechtszaak.

Week één in productie

De agent ging op een woensdag live. Vrijdagmiddag hadden we drie incidenten die we live moesten fixen.

De eerste was demografisch. Een gepensioneerde klant noemde de chat "robot" en stopte met reageren. We zetten bovenaan de widget een opt-out van één zin: "Liever een mens? Stuur 'mens' en we bellen je binnen 5 minuten." Ongeveer 4% van de gesprekken gebruikt 'm. Prima, de routering klopt, en het team verliest liever een chat dan dat ze een veertigjarige relatie irriteren.

De tweede was een autoschade die binnenkwam met damage_estimate_eur: null, omdat de klant zei "ik weet het nog niet, de motorkap is verbogen". De behandelaar moest terugbellen, en dat is precies wat we niet wilden. We bouwden er een verhelderende micro-vraag in die uit een vocabulaire lijst (kras, deuk, paneelschade, ernstig, total loss) een bandbreedte oplevert en elk label aan een euro-range koppelt. De gok van de bandbreedte is niet perfect, maar genoeg om te triëren.

De derde was het soort bug dat alleen in productie opduikt. Eén gesprek raakte het polisnummer kwijt omdat de klant het intikte als NL-1234.567/A in plaats van NL1234567A. De agent vroeg vrolijk drie keer of de klant het "opnieuw wilde proberen". We zetten de normalisatie in de schema layer, niet in de conversation layer. Een gesprek hoort de klant niet te leren hoe de makelaar zijn eigen polisnummers formatteert.

De cijfers, zes maanden later

740 FNOL-meldingen per week, gemiddeld over mei 2026. 96% afgehandeld zonder dat een behandelaar het gesprek aanraakt. De resterende 4% wordt door de agent zelf geëscaleerd: bij letselschade, total loss boven €100k, of als een derde partij onbereikbaar is. Die escalaties gaan binnen zestig seconden naar een bij naam genoemde mens.

Gemiddelde doorlooptijd, gemeten van het eerste bericht van de klant tot een volledig FNOL-dossier in Anva: 95 seconden. De baseline van 14 minuten werd het jaar ervoor op dezelfde manier gemeten, in hetzelfde team, over een vergelijkbare maandag-tot-vrijdag-spreiding.

Bespaarde tijd per week: ongeveer 145 uur aan intake-behandelaars. Het team is niet kleiner geworden. Ze zijn opgeschoven naar schaderegeling en regres, waar bij €38 miljoen GWP en een drie-persoons rooster chronisch te weinig handen waren. De behandelaars die we in maand vier spraken, zeiden dat het werk nu zwaarder is, en dat ze het prettiger vinden.

Dingen die we niet meer zouden doen

Drie.

We hebben de agent laten beslissen wanneer een gesprek "klaar" was. Hij zat er in ongeveer 8% van de gevallen naast, meestal door te vroeg af te sluiten bij een klant die nog aan het typen was. We vervingen het door een harde regel: het gesprek sluit pas als elk verplicht veld is ingevuld of expliciet is geëscaleerd, en geen seconde eerder. Een model is slecht in het lezen van stiltes tussen menselijke berichten, een schema is daar prima in.

We hebben hetzelfde model gebruikt voor de klantchat en de samenvatting voor de behandelaar. De klantchat heeft warmte en vergevingsgezindheid nodig, de samenvatting heeft koude structuur nodig. Zelfde model, twee verschillende prompts, maar de warmte sijpelde door in de samenvatting en de behandelaars kregen regels als "de klant leek vrij ontdaan" terug die ze niet nodig hadden. We splitsten het op in aparte prompt families en de klachten stopten.

We hebben het terugbelmoment al bij de intake laten inplannen. Klanten beloofden tijden die ze niet konden waarmaken, omdat ze nog naast een verwoeste auto in de regen stonden met een telefoon in de hand. We schoven het terugbelmoment naar nadat de polishouder bevestigt dat hij ergens is waar hij kan praten. De opkomst ging van 71% naar 94%.

Wat dit soort build je aan onderhoud kost

Zodra een chat agent op het kritieke pad van een gereguleerd proces zit, verandert de onderhoudsvorm. Het is geen chatbot die je oplevert en vergeet. Elke modelupgrade moet opnieuw getest worden tegen het FNOL-schema. Elke wijziging in Anva-velden moet doorvertaald worden naar de bridge layer. Elk kwartaal wil de compliance officer een steekproef van vijftig gesprekken zien, met de bijbehorende provenance map.

Drift in modelgedrag is een zorg om serieus te nemen: verandert een model stilletjes van gedrag, dan merk je het misschien pas bij een audit. Voor gereguleerde intake betekent dat: je modelversie vastpinnen, een regressiesuite van honderd-plus historische gesprekken aanhouden, en die opnieuw draaien vóór elke modelbump. Goedkoper dan het alternatief.

De saaie laag is het grootste deel van het werk

Toen wij deze AI-agent voor de Utrechtse makelaar bouwden, viel de negen weken werk grofweg uiteen in vier weken voor het schema en de provenance map, drie voor het gesprek, en twee voor de Anva- en Outlook-bridge. Het lastige zat niet in de chat. Het zat in de saaie laag eronder: de veld-voor-veld provenance, het verbatim log, de overdracht die een compliance officer in twintig seconden kan lezen. We hebben vier andere teams een gereguleerde-intake chat agent zien proberen zonder die laag, alle vier staan ze weer uit.

Wil je deze week testen of dit op je eigen desk past: kies één proces dat per keer meer dan tien minuten kost, teken het gestructureerde object dat het moet opleveren, en schrijf met de hand de provenance map voor tien echte gesprekken uit. Binnen een dag weet je of een agent zijn plek verdient.