Software voor schadebeheer: wat er echt toe doet

McKinsey's Claims 2030-onderzoek suggereert dat meer dan de helft van wat schadeteams nu handmatig doen, binnen het decennium geautomatiseerd zou kunnen worden, en dat schadeafhandeling een van de grootste factoren is die bepalen hoe een klant zijn verzekeraar ervaart, in positieve of negatieve zin. De meeste evaluaties van software voor schadebeheer werken nog vanuit een lijst met functies. De systemen die daadwerkelijk veranderen hoe een schadeteam werkt, doen doorgaans een klein aantal specifieke dingen goed, en de functielijst vertelt zelden welke dat zijn.

Wat de categorie eigenlijk omvat

"Software voor schadebeheer" wordt gebruikt voor producten die de grens op verschillende plekken trekken. Aan het ene uiterste behandelt een systeem alleen de intake: een claim vastleggen zodra die wordt gemeld en de juiste documenten erbij koppelen. Aan het andere uiterste proberen sommige platforms het enige systeem van waarheid te worden voor de volledige claim, van eerste melding tot betaling en alle rapportageverplichtingen die daarna volgen. Daartussenin zitten tools die rond één specifieke taak zijn gebouwd, documenten verifiëren of een schadebedrag berekenen.

De verzekeringstak speelt ook een rol. Auto-, woon-, zorg- en aansprakelijkheidsclaims delen een basisvorm, een melding komt binnen, documenten worden verzameld, een besluit wordt genomen, een betaling gaat uit, maar de specifieke details verschillen genoeg dat een tool gebouwd voor de ene tak niet automatisch goed past bij een andere. Een systeem dat is ontworpen rond één indiener die één set documenten aanlevert, heeft vaak moeite zodra een claim een tweede partij betreft die niet de polishouder is, een arts of een tweede bestuurder, wat in verschillende takken eerder de normale situatie is dan de uitzondering, met name bij zorgclaims en autoclaims met meerdere voertuigen.

Het is nuttig om te weten welke van deze vormen een gegeven systeem daadwerkelijk aanneemt, voordat je het vergelijkt met een ander systeem dat een heel ander probleem oplost.

Het pad van de claim, stap voor stap

Onder dit alles doorloopt de meeste claims een vergelijkbare volgorde, en het is nuttig om te weten waar in die volgorde een bepaald stuk software daadwerkelijk actief is.

Eerste melding. De claim wordt gemeld, per telefoon, per formulier, via een document dat rechtstreeks binnenkomt, of steeds vaker via een API-aanroep vanuit het systeem dat als eerste van de schade wist. Hoe een schone eerste melding er echt uitziet behandelt deze fase specifiek, omdat het het moment met de grootste impact is in de hele levenscyclus: wat hier misgaat, wordt overgenomen door elke fase daarna.

Documentatie en coördinatie. Wat ontbreekt wordt opgevraagd, gelezen en gecontroleerd, en als de claim iemand anders dan de polishouder betreft, een arts, een tweede bestuurder, een expert, moet die bijdrage worden gevolgd als onderdeel van hetzelfde dossier in plaats van als een los gesprek. Dit is precies het structurele probleem dat in detail wordt behandeld voor zorgverzekeringsclaims.

Beoordeling. Iemand, of iets, bepaalt wat de claim daadwerkelijk waard is of waarvoor ze in aanmerking komt. Bij claims met een vastgesteld scorings- of ernstkader is dit waar een handmatige raadpleging van een tabel gebeurt, of waar die rechtstreeks in de intake is ingebouwd.

Betaling en verificatie. Het geld gaat uit, en bij veel claims moet iemand nog steeds handmatig bevestigen dat het uitbetaalde bedrag overeenkomt met wat daadwerkelijk verschuldigd is, rekening houdend met eigen risico en tariefverschillen.

Afsluiting en audit. Het dossier wordt gesloten, en elk overzicht van wie is benaderd, wanneer, wat is teruggekomen, en hoe dat is gecontroleerd, moet ofwel achteraf worden samengesteld, ofwel bestaat al omdat het proces het onderweg heeft opgebouwd. Hoe een goed verlopen claimsproces er echt uitziet behandelt deze laatste fase, en de verschuiving van een achteraf samengesteld overzicht naar een overzicht dat automatisch bestaat, in meer detail.

Met die kaart op zak, hier is wat er daadwerkelijk toe doet bij het vergelijken van systemen, in plaats van het afvinken van een functielijst.

Handelt het systeem de eerste melding netjes af, niet alleen het papierwerk daarna

De vorm van een claim wordt in de eerste paar minuten bepaald. Een systeem dat pas aandacht besteedt zodra een dossier al open staat en in een wachtrij staat, heeft het deel van het proces gemist waar het meeste extra werk ontstaat.

Kan het systeem een claim met meer dan één partij afhandelen

Bij veel claims zijn er precies één indiener en één verzekeraar. Bij veel andere niet. Een ongeval met twee bestuurders, of een zorgclaim die het rapport van een behandelend arts nodig heeft, en elk systeem dat ervan uitgaat dat één indiener gelijk is aan één claim, behandelt die tweede partij als een uitzondering om handmatig op te vangen. Het is nuttig om specifiek te controleren of een platform een gericht verzoek naar een tweede partij kan sturen als onderdeel van hetzelfde dossier, in plaats van als een apart, ongevolgd vervolg.

Detecteert het systeem een gemanipuleerd document voordat een mens dat moet doen

De Coalition Against Insurance Fraud zet de jaarlijkse kosten van verzekeringsfraude in de VS op 308,6 miljard dollar, en claims zijn de plek waar een groot deel daarvan zichtbaar wordt: een gewijzigde factuur, of een foto die is bewerkt om schade erger te laten lijken dan die is. Dit met het blote oog opsporen, op elk dossier, schaalt niet, en het is precies het soort patroon waarin een mens inconsistent is over honderden documenten per jaar.

Twee verschillende controles zijn hier belangrijk, en het zijn niet dezelfde dingen. De ene is deterministisch: komen de metadata van het bestand overeen met wat het claimt te zijn, en is het bewerkt sinds het is gemaakt. De andere is op basis van beoordeling: toont de afbeelding zelf tekenen van digitale manipulatie die een metadatacontrole alleen niet zou opmerken. Het is nuttig om specifiek te vragen of een claimplatform beide uitvoert, want een systeem dat alleen metadata controleert, mist een document dat is gewijzigd voordat het ooit is opgeslagen, terwijl een systeem dat alleen beeldanalyse uitvoert, de manipulatie op bestandsniveau mist die een metadatacontrole meteen zou opmerken. Deze aanpak met twee lagen, deterministische controles plus AI-gebaseerde beeldanalyse, is wat Penbox uitvoert op elk document dat via een dossier binnenkomt.

Werkt het systeem met wat je al hebt, of vraagt het je om het te vervangen

De meeste schadeteams beginnen niet vanuit het niets. Er is een makelaarsbeheersysteem, een polisadministratieplatform, soms een apart offertesysteem, allemaal al dagelijks in gebruik. Een schadesysteem dat het enige systeem van waarheid wil worden, waarbij alles anders wordt vervangen, is een veel groter en risicovoller project dan een systeem dat is gebouwd om boven op wat er al is te draaien en er gestructureerde data aan door te geven.

Hoe je dit daadwerkelijk gebruikt

Geen van deze vragen staat netjes op een vergelijkingstabel, en dat is precies waarom ze worden gemist bij een evaluatie op basis van een functielijst. Stel elke vraag rechtstreeks aan een leverancier, en let meer op hoe specifiek die kan antwoorden dan op hoeveel vakjes elders zijn aangevinkt.

Penbox voert schadebeheer uit bovenop de systemen die je al gebruikt, met eerste melding en coördinatie tussen meerdere partijen op één plek, en zichtbaarheid voor de gedupeerde en een volledig auditspoor ingebouwd. Wil je eerst het bredere beeld van hoe het onderliggende model werkt, lees dan wat dossierbeheer betekent.