Chat agents voor dakdekkers: 1.340 lekkages per week triëren

Drie uur elf op een woensdag in oktober. Een weerfront trekt oostwaarts over Brabant. De telefoon op het kantoor van de dakdekker in Breda begint te rinkelen. In de twee uur daarna neemt het kantoor 47 telefoontjes, 22 WhatsApps en 11 e-mails aan. In elke melding gaat het ergens over water.

Zo zien 1.340 lekmeldingen per week eruit, uitgesmeerd over een maand herfstweer. Het bedrijf heeft 21 man. Drie van hen zitten vandaag op de telefoon. Geen van hen is een fulltime triagist.

We bouwden de chat agent eind 2025. Hij ging live in februari 2026. Dit is wat hij in de praktijk doet.

De tweeuursklok

BDA-garantie — het garantieregime in de bouw waar de meeste commerciële platte daken in Nederland onder vallen — kent een clausule die hier telt. Als er stilstaand water wordt gemeld en de dakdekker er langer dan twee uur over doet om uit te rukken, kan de garantie vervallen. BDA Dakadvies is het keuringsinstituut waar het beleid uiteindelijk op terugslaat. Twee uur klinkt royaal. Dat is het niet. De klok start zodra de klant meldt. Niet wanneer de dakdekker het ticket aanmaakt. Niet wanneer de medewerker het juiste contract in Syntess heeft gevonden.

De eerste taak van de chat agent was dus nooit "slim zijn". Die was: het gat verkleinen tussen het moment dat de klant op verzenden drukt en het moment dat er iemand van vlees en bloed op het dak staat.

Hoe 1.340 eruitziet

Ik blijf dit getal gebruiken. 1.340 is het voortschrijdend 7-daags gemiddelde aan inkomende lek-gerelateerde berichten over alle kanalen — telefoon (getranscribeerd door een aparte Twilio + Whisper-hook), e-mail, WhatsApp Business en het formulier op de website van de dakdekker. Ongeveer 70% is routine: een vastgoedbeheerder die een klein druppeltje noteert, een huiseigenaar met een vlek bij de dakkapel, een facilitair manager die meldt dat de schoonmaker drie dagen geleden iets zei over water in de liftschacht. De andere 30% is urgent, en een klein deel daarvan — afhankelijk van de week tussen de 4% en 9% — valt onder de garantieklok.

Het hele punt van de agent is om die 4–9% binnen 90 seconden eruit te halen, ongeacht via welk kanaal het bericht binnenkwam en ongeacht of het pand in Syntess staat of alleen in het oude SQL Server-archief.

De twee systemen achter het bureau

De dakdekker draait op Syntess Atrium, een Nederlandse bouw-ERP die sinds 2014 hun system of record is. Klanten, contracten, planmatig onderhoud, facturatie — Syntess. Het werkt prima. Het is ook redelijk gesloten: er is een SOAP API en een dagelijkse ODBC-export, maar geen event stream waar je in real time iets aan hebt.

Het tweede systeem noemen ze het dak-paspoort archief. Een SQL Server 2014-database met ongeveer 3.800 daken erin, elk met een opbouw per laag, een laatste inspectiedatum en notities die tussen 2013 en 2021 zijn ingetikt door een inmiddels gepensioneerde projectleider. Microsoft heeft de uitgebreide support voor SQL Server 2014 in juli 2024 stopgezet, wat betekent dat hij staat op een Windows Server in de bergkast van de dakdekker, achter een Watchguard-firewall, met een vast IP en een back-up-script dat niemand sinds het vertrek van de projectleider heeft aangeraakt. Ze wisten dat hij gemigreerd moest worden. Ze waren er niet klaar voor om dat te doen. Wij werkten met wat er stond.

De agent praat met beide. Syntess via een dunne proxy die de SOAP-endpoints inpakt en klant- en contract-lookups 30 seconden cachet. SQL Server via een read-only login over VPN, gekoppeld aan de proxy. De agent schrijft naar geen van beide systemen. Schrijfacties blijven het werk van de medewerker.

De SOAP API heeft zijn eigenaardigheden. Klant-lookups op KvK-nummer geven een schone hit; lookups op postcode geven de eerste match, en op een postcode met meerdere panden is dat bijna nooit de juiste. Contract-lookups hebben een expliciet boekjaar nodig, ook als het contract doorloopt. De nachtelijke export-job draait om 02:14 en zet twee tabellen ongeveer elf minuten op slot — onzichtbaar voor het kantoor, vervelend voor een agent die nu een antwoord moet geven. We hebben dit allemaal geleerd door een request te schrijven, te zien dat er niets nuttigs terugkwam, en een Syntess-support engineer op vrijdagmiddag vier uur een mail te sturen.

De 30 mm-regel

Er is één regel in de agent die de rest bepaalt. Als de klant een platdak beschrijft met stilstaand water van meer dan ongeveer 30 mm, gaat het bericht direct naar de spoed-dakdekker-queue en gaat er een pager af.

30 mm is niet willekeurig gekozen. Op een bitumen platdak met een typische Nederlandse winterbelasting begint 30 mm plasvorming de aannames voor constructieve belasting in NEN 6702 / EN 1991-1-3 onder druk te zetten, en het correleert sterk met naadfalen als de regen blijft doorzetten. De senior projectleider van de dakdekker schreef dit getal voor ons op een whiteboard. We hebben het niet zelf bedacht.

Het lastige is dat klanten niet zeggen "30 millimeter stilstaand water". Ze zeggen een plas, best wel veel water, het staat tot aan mijn enkels. De agent moet dat vertalen. Hieronder het prompt-fragment dat de classificatie aanstuurt, licht geredigeerd:

# water_depth_classifier.py
WATER_DEPTH_RUBRIC = """
Classify reported ponding depth on a flat roof into one of:
  - NONE       (no standing water mentioned)
  - WET        (damp, droplets, sheen)
  - PUDDLE     (visible plas, < 20 mm equivalent)
  - PONDING    (sustained pool, 20-40 mm)
  - CRITICAL   (> 40 mm OR described relative to ankle/calf)

Rules:
  * "tot mijn enkels" or "tot mijn schoenen"  -> CRITICAL
  * "plas zo groot als een tafel"              -> PONDING minimum
  * "het loopt over de dakrand"                -> CRITICAL
  * If uncertain between PUDDLE and PONDING,
    take the higher class. The cost of a false
    PONDING is a phone call. The cost of a
    false PUDDLE is a warranty claim.
"""

Die laatste opmerking telt. We hebben de classifier zo afgesteld dat hij richting urgent neigt. De dakdekker stuurt liever een man die bij de stoep weer omdraait dan dat hij er één mist. De agent draait de classifier op elk binnenkomend bericht, ook op berichten die routine lijken, want klanten verstoppen de kern: drie zinnen over een dakkapel, en dan één regel over de loods ernaast waar het water tot aan de veiligheidsleuning staat.

Het 90-seconden-budget

90 seconden is de tijd tussen binnenkomst van het bericht en het plaatsen in de spoed-dakdekker-queue, als dat plaatsen gerechtvaardigd is. Zo verdeelt dat budget zich in de praktijk:

T+00.0s  message ingested (Twilio / SMTP / WhatsApp webhook)
T+00.3s  language + channel normalised, attachments fetched
T+01.2s  LLM classification pass 1 (intent, urgency, reply channel)
T+04.8s  customer + address resolution: Syntess SOAP, fallback SQL Server
T+05.6s  if commercial flat roof: dak-paspoort lookup
T+07.1s  LLM classification pass 2 (depth rubric above, full context)
T+07.4s  decision: route to spoed queue OR routine queue
T+08.0s  spoed queue insert + pager fan-out (Pushover + group SMS)
T+08.1s  customer auto-reply sent with case number and ETA window

Het grootste deel van het budget zit in de Syntess SOAP-call. Hij is traag op een koude cache en onbetrouwbaar in een druk uur. We cachen agressief — 30 seconden op klant-lookups, 5 minuten op contract-lookups, alleen ongeldig verklaard door webhook-hints — en we accepteren stale data op read-only paden. De 90 seconden is de SLO die we beloven. De mediaan in maart 2026 was 11 seconden.

Wat ons over de 30 seconden tilt is bijna altijd hetzelfde: een klant die de agent niet kan vinden. Een vastgoedbeheerder van een nieuw account, een pand dat nog niet in Syntess staat, een adres met een typefout. In dat geval escaleert de agent naar een medewerker met een samenvatting van één regel: "Mogelijke spoed, platdak, water 'tot mijn enkels', klant niet in systeem. Verifieer en bel terug binnen 15 min." De medewerker beslist. De agent verzint geen klantrecord.

Twee blunders waar we van geleerd hebben

Week 3 meldde een klant "het lekt bij de zonnepanelen". De agent klasseerde het als routine. Dat was het niet. Het dak was plat. Het water stond 50 mm hoog rond een omvormerbeugel. De classifier was getraind op taal over water; er was geen regel dat lek bij zonnepanelen op een platdak automatisch moet escaleren, ongeacht de expliciet genoemde diepte. Die regel hebben we toegevoegd. Zonnepaneelbeugels op platte daken zijn een bekend naadfalen-patroon.

Week 7 kwam er buiten kantooruren een WhatsApp binnen in dialect — een Brabants idioom voor waterhoogte, ruwweg "tot in mijn schoenen", geformuleerd zoals alleen iemand van ten westen van Tilburg dat doet, dat de classifier las als PUDDLE. Het was CRITICAL. We hebben niet hertraind. We hebben een regionaal frasewoordenboek toegevoegd dat vóór de LLM-pass draait, en de default-escalatie voor onbekende frases verbreed naar PONDING. Vals positieven kosten een telefoontje. Die rekening betalen we.

Wat we niet hebben gedaan

We hebben Syntess niet vervangen. De dakdekker heeft er 12 jaar aan proces in zitten en de medewerkers weten waar elk menu hangt. We hebben de SQL Server niet gemoderniseerd. Dat is een apart project met een eigen budget en een eigen kopzorg. We hebben de agent geen tickets laten sluiten — alleen openen. We hebben de agent nergens laten schrijven behalve in zijn eigen queue-tabel. Elke schrijfactie in Syntess blijft een mens.

Dit is het saaie deel van het werk, en het is het grootste deel van het werk. De chat agent bouwen kostte ongeveer drie weken. De medewerkers vertrouwen laten krijgen kostte drie maanden en heel veel uren in dat kantoor in Breda.

Vertrouwen verdienen op kantoor

De eerste vier weken na go-live trokken de medewerkers elke spoed-classificatie van de agent in twijfel. Dat lieten we ze doen. De agent schrijft bij elke beslissing een shadow-record naar een aparte log: wat een baseline op alleen regels zou hebben gedaan, wat een keyword-scan zonder LLM zou hebben gedaan, en wat de agent uiteindelijk besloot. De medewerkers konden controleren of de agent tot dezelfde conclusie kwam als hun onderbuik. Ze gingen hardop in discussie met de shadow-log, in het kantoor, met ons erbij.

Tegen week acht namen de shadow-checks af. Tegen week twaalf begonnen twee van de medewerkers waar we het meest mee hadden samengewerkt agent-beslissingen te verdedigen in de planningsmeeting tegen de tegenwerping van de projectleider. Dat was het moment waarop we wisten dat het was geland. De shadow-log draait nog steeds. We hebben hem niet uitgezet en zijn dat ook niet van plan. De dag dat iemand merkt dat hij van mening verschilt met de live-beslissing, is precies de dag waarop we dat willen horen.

Wat er veranderde

Mediane tijd-tot-dakdekker bij een spoedmelding ging van 38 minuten (de eigen meting van het kantoor, van vóór de agent) naar 9 minuten in het eerste kwartaal na livegang. In 17 weken draaitijd heeft de agent geen enkele CRITICAL-classificatie op een bevestigd platdak-lek gemist. Hij heeft 14 vals positieven geproduceerd — uitrukken waarbij een dakdekker uitreed terwijl het niet nodig was. Het kantoor vindt dat een goede ruil.

De dakdekker kreeg er ook iets bij waar ze niet om gevraagd hadden: een schone stroom gestructureerde data over elke lekmelding, met classificatie, kanaal, klant, pand en afloop. Dat hadden ze nog nooit gehad. Hun planner zet preventieve inspecties nu in op basis van de daadwerkelijke lekdichtheid per pand, niet op basis van het geheugen van de gepensioneerde projectleider. Een junior projectleider, in 2024 aangenomen zonder Brabants accent en zonder whiteboard-intuïtie, gebruikt diezelfde data inmiddels om de offerte-documenten voor onderhoud te schrijven die haar leidinggevende vroeger een week kostten.

Het kleinste wat je vandaag kunt doen

Heb je een operations-team met een klok eroverheen — garantie, SLA, responstijd, een regelgever — tel dan de mediane seconden tussen bericht komt binnen en iemand-met-gereedschap rijdt uit. Niet de tijd die je op de factuur zet. Het echte getal. Kun je het niet meten, bouw dan eerst de meting. De agent is de tweede taak.

Toen wij deze chat agent bouwden voor de Bredase dakdekker, liepen we vooral aan tegen het feit dat de tweeuursklok van BDA geen enkele observability had — niemand in het team kon je, vóór ons werk, vertellen hoe vaak die klok was gemist. We hebben de agent uiteindelijk vanaf de eerste seconde van het project timing-telemetrie laten uitsturen, zodat het team kon discussiëren met de data in plaats van met hun onderbuik.