Email-agent voor debiteurenbeheer: een Haarlemse case

Het dinsdagochtendritueel

Het is 11:14 uur op een dinsdag in Haarlem. Sanne, die debiteurenbeheer doet bij een belasting- en boekhoudkantoor van 19 mensen aan het Spaarne, heeft 287 openstaande facturen op haar scherm. Drie ervan zijn meer dan zestig dagen te laat. Eén is van een klant in Berlijn die alleen in het Duits antwoordt. Eén is van een logistiek bedrijf in Antwerpen dat alleen Engels leest. De rest zijn Nederlandse MKB'ers die herinneringen behandelen als een vriendelijk advies.

Sanne doet dit al zes jaar elke dinsdag. Drie collega's ook. Samen besteden ze ongeveer 22 uur per week aan het schrijven, versturen en bijhouden van betalingsherinneringen. Het werk is niet vervelend op zich. Wat vervelend is, is voor de vierhonderdste keer hun eigen template teruglezen en "I hope this email finds you well" tikken in een taal die ze niet op school hebben gehad.

Dit is het verhaal van hoe we dat ritueel vervingen. Niet met een bot die zelf op send drukt. Met een email-agent die opstelt, classificeert en de volgende stap klaarzet, en die het makkelijke deel aan de mens laat: lezen, beslissen, klikken.

Het werk achter de herinnering

Voordat we één regel code schreven, zaten we twee dagen op de debiteurenafdeling. Dat doen we bij elk email-automatiseringsproject. De PowerPoint klopt nooit met de inbox.

Wat het team van vier feitelijk deed, viel ongeveer zo uiteen. Ongeveer 40% van de week was het voor de hand liggende stuk: de lijst met openstaande facturen ophalen, kiezen wie te benaderen, de mail schrijven. Ongeveer 25% was vertaalwerk. Ruwweg 15% van de klanten is Duitstalig en 10% Engelstalig. Sanne en één collega waren de enige Duitssprekers, dus mails naar Duitse klanten stapelden zich op hun twee queues op. Ongeveer 20% was triage: er komt een antwoord binnen, is dat een betalingsbevestiging, een dispuut, een faillissementsmelding, een verzoek om in drie termijnen te splitsen? Elk gaat ergens anders heen. De laatste 15% was het stuk dat niemand op de functieomschrijving zet: het bijhouden van wat je hebt verstuurd. Loggen dat er een mail uit is. Het CRM bijwerken. Een follow-up klaarzetten voor volgende week. De juiste factuur-PDF uit het boekhoudpakket trekken om bij te voegen.

De hefboom zit niet in het schrijven. Hij zit in de vertaling, de triage, en het bijhouden van wat je hebt verstuurd. Daar hebben we de agent omheen gebouwd.

De vorm van de agent

Het systeem heeft vier onderdelen.

Een reader. Die koppelt met het Exact Online-boekhoudpakket van het kantoor via de REST API en haalt elke ochtend om 06:00 uur Amsterdamse tijd de lijst met openstaande facturen op. Voor elke factuur die langer dan een instelbare drempel over de vervaldatum is (het kantoor koos 7, 21 en 45 dagen als drie buckets), trekt hij de klantgegevens op, de oorspronkelijke factuur-PDF, de eerdere herinneringen, en eventuele inkomende antwoorden op die thread.

Een writer. Voor elke factuur die een touch nodig heeft, stelt die een mail op in de voorkeurstaal van de klant. De taalhint komt uit het klantrecord in Exact, met een fallback op een kleine classifier op eerdere correspondentie. De toon past bij de bucket: warm op 7 dagen, stevig op 21, zakelijk op 45. Elke draft noemt het factuurnummer, de vervaldatum, het bedrag en een IBAN. De Berlijnse klant krijgt Duits dat niet leest als Duits geschreven door een Nederlander.

Een reviewer. Dit deel wilde het kantoor niet uit handen geven. Elke draft komt in een queue terecht binnen de bestaande Microsoft 365-mailbox, getagd met het factuurnummer. Sanne of een collega opent de draft, leest hem door, past hem aan als dat nodig is (zelden, na week twee), en drukt op send. We hebben de tijd gemeten van draft-klaar tot mens-klikt-send. De mediaan kwam uit op 38 seconden.

Een bookkeeper. Na het versturen logt de agent het send-event terug in Exact, plant de volgende follow-up op basis van de nieuwe bucket, en wacht op antwoord. Komt er een reactie binnen, dan classificeert de agent die (betalingsbevestiging, dispuut, verzoek om termijnbetaling, out-of-office, vijandig, faillissement) en stuurt hem door naar de juiste persoon of de juiste volgende draft.

Opstellen in drie talen zonder als vertaling te klinken

Hier lopen de meeste herinneringsautomatiseringen vast. Pak een willekeurig cloud-boekhoudpakket en kijk naar de standaard herinneringsteksten. Ze lezen als een stempel.

Onze writer werkt niet met templates. Hij werkt met een kleine prompt die drie dingen kent: de klant (branche, historie, de zachte observatie dat deze vorig jaar twee keer te laat betaalde en een wat minder verontschuldigende toon kan waarderen), de factuurcontext (bedrag, aantal dagen te laat, of er iets in de thread wordt aangevochten), en de huisstem van het kantoor.

De huisstem was het lastige deel. We hebben een middag met de senior partner gezeten en die afgeleid uit achttien maanden van zijn eigen verstuurde mails. Hij heeft een specifieke manier om een Duitse mail te openen die niet klinkt als een leerboek. Die hebben we vastgelegd. Hetzelfde voor de Nederlandse en Engelse varianten.

voice:
  nl:
    opening_warm: "Beste {first_name},"
    opening_firm: "Geachte heer/mevrouw {last_name},"
    sign_off: "Met vriendelijke groet,"
    do_not_use:
      - "wij hopen dat deze e-mail u in goede gezondheid bereikt"
  de:
    opening_warm: "Liebe Frau {last_name},"
    opening_firm: "Sehr geehrte Damen und Herren,"
    sign_off: "Mit freundlichen Grüßen,"
  en:
    opening_warm: "Hi {first_name},"
    opening_firm: "Dear {last_name},"
    sign_off: "Kind regards,"
    do_not_use:
      - "I hope this email finds you well"

Dat fragment is een doorsnede. De echte config is zo'n 140 regels en bevat uitdrukkingen die je moet vermijden, escalatiezinnen per bucket, en de kantoor-specifieke eigenaardigheden die de senior partner pas kon benoemen toen we hem slechte drafts lieten zien en vroegen wat eraan mankeerde.

Het menselijke knikje

Het kantoor was vanaf week één duidelijk: er gaat niets de deur uit zonder dat iemand het heeft gelezen.

Wij ook. Niet alleen om de voor de hand liggende juridische reden, hoewel die ertoe doet. Om twee praktische redenen.

Ten eerste: de failure modes van een volautomatische herinneringsbot zijn catastrofaal en stil. Stuur een stevige herinnering naar een klant van wie de moeder gisteren is overleden, en je verliest niet de factuur. Je verliest de relatie. De 38 seconden die een mens besteedt aan het lezen van de draft is de goedkoopste verzekering in het systeem.

Ten tweede: de drafts worden beter als mensen ze aanpassen. Elke aanpassing wordt vastgelegd. Elke aanpassing wordt een trainingssignaal voor de volgende versie van de prompt en de few-shot voorbeelden. Na zes weken was het editpercentage op Nederlandse drafts gedaald van 31% naar 4%. Op Duitse drafts van 19% naar 7%. Op Engelse van 22% naar 6%.

De classifier die beslist wat je niet stuurt

Het nuttigste onderdeel van het systeem, volgens Sanne zelf, is niet de writer. Het is de classifier aan de antwoordkant.

Als een klant op een herinnering antwoordt, gebeurt er meestal één van zes dingen. Betalingsbevestigingen (47% van de antwoorden). Verzoeken om een kopie van de factuur (18%). Out-of-office antwoorden (12%). Verzoeken om een betalingsregeling (11%). Disputen (9%). Boos, failliet of anderszins raar (3%). Vóór de agent kwamen al deze in dezelfde gedeelde inbox terecht en moest een mens ze lezen, beslissen en doorzetten. Nu komen alleen categorieën vier tot en met zes koud bij een mens. De rest wordt gerouteerd: betalingsbevestigingen sluiten de loop automatisch en worden bij Exact afgeletterd, factuurkopie-verzoeken triggeren een nieuwe draft met bijlage (een mens knikt nog steeds), out-of-office antwoorden zetten de volgende touch op de datum dat de OOO afloopt.

De classifier is een klein model dat lokaal draait op een eigen machine van het kantoor, geen frontier API. We hebben beide getest. Het frontier model was 2% nauwkeuriger en op het volume van dit kantoor ongeveer 60 keer duurder. De lokale is goed genoeg en houdt factuurinhoud binnen het kantoor, wat de compliance officer blij maakt en netjes aansluit op AVG Artikel 28 over verwerkersrelaties. De recente golf laptopgrote open modellen, waaronder de Gemma 4 QAT-release waar deze week een lange draad over op Hacker News stond, blijft het gat dichten tussen "draait in de kast" en "goed genoeg voor productieclassificatie". Die trend maakt deze local-only architectuur hier haalbaar.

Cijfers na zes weken

Zes weken later is dit wat er is veranderd.

• Uren per week aan debiteurenbeheer: van ongeveer 22 naar ongeveer 6. Het grootste deel van die zes uur is werk dat menselijk moet blijven (disputen, betalingsregelingen, de ongemakkelijke telefoontjes).
• Days Sales Outstanding: van 47 naar 38. De verbetering van negen dagen komt deels door de agent (consistente touches op de juiste momenten) en deels als bijeffect van betere datahygiëne die uit het integratiewerk rolde.
• Antwoordpercentage op eerste herinneringen: van 31% naar 44%. Die stijging schrijven we vooral toe aan taalmatch. Duitse klanten reageren vaker als ze in het Duits worden aangesproken.
• Editpercentage op agent-drafts: 4% NL, 7% DE, 6% EN. Gedaald van 31%, 19% en 22% in week één.
• Fouten die de agent maakte en die een mens ving: 11. Fouten die de agent maakte en die een mens niet ving: tot nu toe 0.

Het team van vier is nog steeds vier mensen. Niemand is ontslagen. Twee zijn doorgeschoven naar adviseringswerk in de portefeuille van de senior partner, wat ze wilden. Eén pakt de uitbreiding richting Britse klanten op. Eén doet gelukkiger de zes uur debiteurenwerk die wel interessant is.

Wat we onderweg fout deden

Drie dingen, opgeschreven zodat we ze niet opnieuw doen.

We hadden de bucketlogica overontworpen. Onze eerste versie had vijf overdue-buckets met aparte toonprofielen. Het kantoor was er duidelijk over: drie buckets, drie tonen, klaar. We verzonnen complexiteit die het operations-team niet wilde. Als de klant zegt "simpeler", heeft de klant gelijk.

We routeerden in eerste instantie elk antwoord via een frontier model. De kosten gingen in week twee 40x omhoog toen één klant in een dispuut van 17 mails belandde en elke nieuwe boodschap de hele thread opnieuw classificeerde. We zetten de classifier over op een lokaal model en capten het context window. De kosten kwamen weer onder controle. De nauwkeurigheid bleef.

We waren btw vergeten. De eerste versie van de writer stelde vrolijk herinneringen op voor facturen waar het dispuut over de btw-behandeling ging, niet over niet-betalen. De senior partner ving dat op dag drie. We voegden een "dispuut in thread gedetecteerd"-flag toe die de draft omzet naar een "we moeten praten voordat we opnieuw herinneren"-template die naar een mens gaat, punt.

De audit van vijf minuten

Als jij een debiteurenfunctie runt en het bovenstaande klinkt bekend, dan kun je zo uitzoeken of er een agent-vormig gat in je week zit.

Open je verzonden-map. Filter op de laatste dertig dagen. Zoek op "vriendelijke herinnering", "kind reminder", "freundliche Erinnerung". Tel de resultaten. Vermenigvuldig met vier minuten (de gemiddelde tijd per touch in onze metingen). Dat getal is jouw wekelijkse uren aan debiteurenbeheer.

Komt het boven de 8 uit, dan verdient een email-agent zich terug in het eerste kwartaal. Komt het boven de 15 uit, dan verdient hij zich terug in week drie. Zit je onder de 4, dan heb je geen automatiseringsprobleem, maar een incassoprobleem, en het antwoord is een telefoontje.

Toen we dit voor het Haarlemse kantoor bouwden, liepen we steeds tegen de kloof aan tussen "de agent kán technisch versturen" en "het kantoor vertrouwt erop dat hij verstuurt". We hebben dat opgelost door auto-send helemaal te schrappen en het knikje van 38 seconden van een mens als een feature te behandelen, niet als wrijving. De meeste AI-agents die we voor operations-teams bouwen, krijgen uiteindelijk dezelfde vorm: de goedkoopste verzekering is de menselijke klik.