Jouw datatemplate voor claimverwerking
Jouw datatemplate voor claimverwerking
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om te volgen
- Extractie-instructies voor Duck Creek Claims
Attributen voor claimsverwerking
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van de bedrijfsactiviteit of gebeurtenis die op een specifiek moment voor een claim plaatsvond. | ||
| Beschrijving Dit attribuut beschrijft een specifieke stap of taak binnen het claimproces, zoals 'Claim Submitted', 'Adjuster Assigned' of 'Payment Issued'. Elke activiteit staat voor een afzonderlijk moment in de levenscyclus van de claim. Het analyseren van de volgorde en frequentie van deze activiteiten vormt de kern van process mining. Hiermee kun je procesmodellen ontdekken, bottlenecks vinden, herstelrondes detecteren en procesafwijkingen ten opzichte van een standaardmodel analyseren. Waarom dit belangrijk is De Activity Name bepaalt de stappen in de procesflow. Dit is de basis voor het ontdekken, analyseren en monitoren van het claimproces. Waar je het vindt Meestal afgeleid van event logs, transactienamen of statuswijzigingen in Duck Creek Claims. Hiervoor kan een koppeling tussen meerdere bronvelden of tabellen nodig zijn. Voorbeelden Claim ingediendSchadebehandelaar toegewezenOnderzoek gestartBetaling uitgevoerdClaim gesloten | |||
| Schadedossier-ID ClaimId | De unieke identificatie van één verzekeringsclaim, die als primaire case-identificatie dient. | ||
| Beschrijving De Claim ID is de belangrijkste sleutel die alle gebeurtenissen en activiteiten van één verzekeringsclaim koppelt, van indiening tot sluiting. Zo kan de volledige levenscyclus van een claim samenhangend worden gevolgd. Bij process mining is dit attribuut essentieel voor het opbouwen van de caseweergave. Analisten kunnen hiermee het volledige verloop van elke claim volgen, end-to-end-doorlooptijden meten en procesvarianten analyseren. Waarom dit belangrijk is Dit is de essentiële Case ID die alle gerelateerde gebeurtenissen in het proces koppelt. Zo ontstaat een volledig end-to-end-overzicht van de levenscyclus van de claim. Waar je het vindt Dit is een primaire sleutel in de hoofdentiteit of tabel voor claims binnen Duck Creek Claims. Raadpleeg de systeemdocumentatie voor de specifieke tabel- en veldnaam. Voorbeelden CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| Tijdstip van gebeurtenis EventTime | De timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis plaatsvond. | ||
| Beschrijving Event Time bevat de exacte datum en tijd van elke activiteit in de levenscyclus van de claim. Deze tijdinformatie is belangrijk voor prestatieanalyse. In analyses wordt deze timestamp gebruikt om doorlooptijden tussen activiteiten te berekenen, wachttijden te vinden, de totale duur van een case te meten en procesprestaties over verschillende perioden te analyseren. Dit is de basis van elke tijdsgebonden procesmeting. Waarom dit belangrijk is Deze timestamp is essentieel voor het berekenen van alle tijdsgebonden metingen, zoals doorlooptijden en duur. Daarmee ondersteunt het prestatieanalyse en het vinden van bottlenecks. Waar je het vindt Dit is een standaard timestamp-veld in event- of transactielogs van Duck Creek Claims. Zoek naar velden zoals 'CreateDate', 'Timestamp' of 'EventDate'. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Afdeling Department | De afdeling of het team dat op een bepaald moment verantwoordelijk is voor de activiteit of de claim. | ||
| Beschrijving Dit attribuut geeft de functionele groep of afdeling aan, zoals 'Initial Intake', 'Investigation Unit' of 'Settlement Team', die de claim behandelt. Het voegt een organisatorische context toe aan de procesflow. Analyse per afdeling is belangrijk om procesprestaties op geaggregeerd niveau te begrijpen. Je kunt er knelpunten tussen afdelingen mee vinden, efficiëntie op teamniveau meten en zien hoe werk door de organisatie stroomt. Waarom dit belangrijk is Maakt prestatieanalyse per functioneel gebied mogelijk en brengt overdrachten tussen afdelingen en teamspecifieke bottlenecks aan het licht. Waar je het vindt Raadpleeg de documentatie van Duck Creek Claims. Deze informatie is vaak gekoppeld aan het profiel van de toegewezen gebruiker of aan een wachtrij- of werkgroeptoewijzing. Voorbeelden AutoschadesSchades aan eigendommen - grote schadeAfdeling bijzondere onderzoekenBetalingsverwerking | |||
| Claimstatus ClaimStatus | De algemene status van de claim op een bepaald moment, zoals Open, Pending of Closed. | ||
| Beschrijving Claim Status geeft de huidige fase van de claim in de levenscyclus weer. Het biedt een overzicht op hoofdlijnen van de positie van de claim in het totale proces. Dit attribuut is nuttig voor overzichten van de claimvoorraad en voor het filteren van cases. Het is vooral belangrijk om de definitieve uitkomst van een claim te bepalen, bijvoorbeeld 'Closed - Paid' of 'Closed - Denied'. Dat is nodig voor uitkomstanalyse en inzicht in afwijzingspercentages. Waarom dit belangrijk is Geeft een momentopname van de huidige status en definitieve uitkomst van de claim. Dit is belangrijk voor uitkomstanalyse en het filteren van cases. Waar je het vindt Raadpleeg de documentatie van Duck Creek Claims. Dit is een fundamenteel veld in het hoofdrecord van de claim. Voorbeelden OpenIn behandeling - wacht op informatieGesloten - afgehandeldGesloten - afgewezen | |||
| Claimtype ClaimType | De categorie van de verzekeringsclaim, zoals Auto, Property of Liability. | ||
| Beschrijving Claim Type deelt claims in op basis van de branche of de aard van de schade. Dit is een belangrijke dimensie om claimdata te segmenteren en analyseren. Je gebruikt dit attribuut om procesprestaties tussen verschillende claimtypen te vergelijken. Een claim van het type 'Auto - Total Loss' volgt bijvoorbeeld een heel ander proces en heeft andere KPI's dan een claim van het type 'Property - Water Damage'. Analyse per Claim Type geeft context, maakt prestatievergelijkingen betekenisvoller en helpt bij het bepalen van gerichte verbeteracties. Waarom dit belangrijk is Dit is een belangrijke dimensie voor het segmenteren van analyses, omdat verschillende claimtypen vaak hun eigen processen, SLA's en complexiteitsniveaus hebben. Waar je het vindt Raadpleeg de documentatie van Duck Creek Claims. Dit is een kernattribuut in het hoofdrecord van de claim. Voorbeelden Personenauto - aanrijdingBedrijfseigendommen - brandArbeidsongeschiktheidAlgemene aansprakelijkheid | |||
| Ernst van claim ClaimSeverity | Een classificatie van de financiële of operationele complexiteit van de claim, zoals Low, Medium of High. | ||
| Beschrijving Claim Severity geeft een indicatie van de verwachte impact of complexiteit van een claim. De classificatie kan zijn gebaseerd op de eerste schade-inschatting, de aard van het incident of andere vooraf bepaalde bedrijfsregels. Dit attribuut is belangrijk voor prestatieanalyse, omdat claims met een hoge ernst meestal meer stappen, langere verwerkingstijden en gespecialiseerde bronnen vragen. Door KPI's per ernstniveau te segmenteren, kun je realistische prestatiedoelen vaststellen en begrijpen hoe complexiteit de procesefficiëntie en resultaten beïnvloedt. Waarom dit belangrijk is Helpt claims op complexiteit te segmenteren. Zo krijg je een genuanceerdere prestatieanalyse en kun je doorlooptijden en kosten realistischer vergelijken. Waar je het vindt Raadpleeg de documentatie van Duck Creek Claims. Dit kan een apart veld zijn of worden afgeleid van het eerste schadebedrag. Voorbeelden LaagGemiddeldHoogCatastrofaal | |||
| Schadebedrag LossAmount | Het geschatte of werkelijke financiële bedrag van de schade die in de claim is gemeld. | ||
| Beschrijving Dit attribuut staat voor de eerste geschatte waarde van de schade die bij de claim hoort. Het is een belangrijke financiële meting die vaak invloed heeft op de routering, ernst en benodigde onderzoeksdiepte van de claim. In analyses wordt het schadebedrag gebruikt om claims te segmenteren en te begrijpen hoe financiële impact samenhangt met procesgedrag. Claims met een hogere waarde kunnen bijvoorbeeld een ander proces volgen of langere doorlooptijden hebben. Het biedt financiële context bij de operationele procesdata. Waarom dit belangrijk is Biedt financiële context bij de claim. Zo kun je analyseren hoe de waarde van een claim invloed heeft op de verwerkingsroute, duur en uitkomst. Waar je het vindt Raadpleeg de documentatie van Duck Creek Claims. Dit is een belangrijk financieel veld in de claim, vaak aangeduid als 'Reported Loss' of 'Initial Reserve'. Voorbeelden 1500.0025000.50125000.00 | |||
| Toegewezen schadebehandelaar AssignedAdjuster | De naam of ID van de schadebehandelaar die op een bepaald moment verantwoordelijk is voor de claim. | ||
| Beschrijving Dit attribuut identificeert de gebruiker of bron die een activiteit uitvoert. Het kan tijdens de levenscyclus van de claim veranderen wanneer de case wordt overgedragen tussen verschillende schadebehandelaars of teams. Dit is essentieel voor het analyseren van prestaties, werkverdeling en overdrachten. Dashboards over de verwerkingscapaciteit van schadebehandelaars, verschillen in werkdruk en bottlenecks gebruiken dit attribuut vaak om te begrijpen hoe werk wordt verdeeld en uitgevoerd. Waarom dit belangrijk is Maakt analyse mogelijk van prestaties, werkverdeling en samenwerkingspatronen. Zo kun je bottlenecks en opleidingsbehoeften vinden. Waar je het vindt Raadpleeg de documentatie van Duck Creek Claims. Zoek naar velden voor gebruiker, eigenaar of toegewezen medewerker in tabellen voor claimtaken, gebeurtenissen of de primaire claimentiteit. Voorbeelden John SmithJane DoeRobert Brownadjuster_1138 | |||
| Afwikkelingsbedrag SettlementAmount | Het definitieve financiële bedrag dat is overeengekomen om de claim af te wikkelen. | ||
| Beschrijving Dit attribuut registreert de waarde van de afwikkeling die is berekend en geautoriseerd voor betaling. Het is een belangrijke resultaatgerichte meting voor elke claim die tot een betaling leidt. Dit attribuut is belangrijk voor financiële analyse en dashboards zoals 'Payment Authorization & Issuance Time'. Je kunt het vergelijken met het oorspronkelijke 'Loss Amount' om de nauwkeurigheid van reserves te analyseren. Ook helpt het om de financiële uitkomsten van het claimproces te begrijpen. Waarom dit belangrijk is Vertegenwoordigt de belangrijkste financiële uitkomst van een claim. Dit is essentieel voor financiële rapportage en voor het analyseren van de nauwkeurigheid van de eerste schade-inschattingen. Waar je het vindt Raadpleeg de documentatie van Duck Creek Claims. Deze informatie staat meestal in financiële transactie- of betalingsgerelateerde tabellen die aan de claim zijn gekoppeld. Voorbeelden 1450.7522000.00115800.20 | |||
| Beoogde oplossingsdatum ResolutionTargetDate | De datum waarop de claim naar verwachting is opgelost, op basis van SLA's of interne doelen. | ||
| Beschrijving Dit attribuut bevat de deadline voor het sluiten van de claim. De datum wordt vaak bepaald door wettelijke vereisten, service level agreements (SLA's) of interne key performance indicators (KPI's) en kan verschillen per claimtype of ernstniveau. Dit vormt de basis voor de KPI 'On-Time Claim Resolution Rate' en ondersteunt het dashboard 'Claim Resolution Target Adherence'. Je kunt hiermee claims volgen die het risico lopen hun SLA te overschrijden en het werk prioriteren. Waarom dit belangrijk is Maakt het mogelijk om prestaties te meten ten opzichte van service level agreements (SLA's) en interne doelen. Dit heeft direct invloed op klanttevredenheid en compliance. Waar je het vindt Raadpleeg de documentatie van Duck Creek Claims. Dit kan een specifiek SLA-datumveld zijn of worden berekend op basis van de indieningsdatum van de claim en bedrijfsregels. Voorbeelden 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
| Bronsysteem SourceSystem | Het systeem waaruit de eventdata is geëxtraheerd. | ||
| Beschrijving Dit attribuut identificeert de bronapplicatie waar de claimdata vandaan komt. In deze context is dat altijd 'Duck Creek Claims'. Als alle data uit één systeem komt, lijkt dit misschien overbodig. Toch is het belangrijk voor datagovernance, traceerbaarheid en situaties waarin data later uit meerdere systemen wordt samengevoegd. Het geeft context bij de herkomst en structuur van de data. Waarom dit belangrijk is Biedt belangrijke informatie over de herkomst van data en de context ervan. Dat is van groot belang voor datagovernance en het oplossen van problemen, vooral in omgevingen met meerdere geïntegreerde systemen. Waar je het vindt Dit is meestal een statische waarde die tijdens het data-extractie- en transformatieproces wordt toegevoegd om de herkomst van de data aan te geven. Voorbeelden Duck Creek Claims | |||
| Eindtijd EndTime | De timestamp die aangeeft wanneer een activiteit is voltooid. | ||
| Beschrijving Dit attribuut markeert het moment waarop een activiteit is voltooid. StartTime geeft aan wanneer een activiteit begon, terwijl EndTime het andere punt vormt voor de berekening van de doorlooptijd van die specifieke taak. In process mining kun je prestaties veel grondiger analyseren als activiteiten zowel een start- als eindtijd hebben. Je kunt dan nauwkeurig onderscheid maken tussen 'Processing Time', de actieve werktijd voor een taak, en 'Waiting Time', de tijd tussen taken. Dat onderscheid is belangrijk om bottlenecks goed te vinden. Waarom dit belangrijk is Maakt het mogelijk om nauwkeurige verwerkingstijden per activiteit te berekenen en actieve werktijd te onderscheiden van inactieve of wachttijd. Dat is belangrijk voor een betrouwbare bottleneckanalyse. Waar je het vindt Kan als afzonderlijk timestamp-veld in event logs beschikbaar zijn of worden afgeleid als de StartTime van de volgende activiteit in de reeks voor dezelfde case. Voorbeelden 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| Is geautomatiseerd IsAutomated | Een booleaanse vlag die aangeeft of de activiteit automatisch door het systeem is uitgevoerd, zonder menselijke tussenkomst. | ||
| Beschrijving Deze vlag maakt onderscheid tussen taken die door menselijke gebruikers zijn uitgevoerd en taken die door systeemautomatisering zijn uitgevoerd, zoals automatische meldingen, de eerste datavalidatie of stappen voor straight-through processing. Door dit attribuut te analyseren, krijg je inzicht in de mate van automatisering in het claimproces. Je kunt hiermee het effect van automatiseringsinitiatieven meten, mogelijkheden voor verdere automatisering vinden en controleren of geautomatiseerde stappen werken zoals verwacht zonder problemen verderop in het proces te veroorzaken. Waarom dit belangrijk is Helpt het effect van automatisering op efficiëntie en kosten te meten en mogelijkheden voor straight-through processing te vinden. Waar je het vindt Deze informatie kan worden afgeleid uit de 'user' die aan een event is gekoppeld, bijvoorbeeld 'SYSTEM' of 'BATCH', of uit een specifieke vlag in het eventrecord. Voorbeelden truefalse | |||
| Is herwerk IsRework | Een berekende vlag die aangeeft of een activiteit onderdeel is van een herwerklus. | ||
| Beschrijving Dit boolean-attribuut krijgt de waarde true als een activiteit voor een claim wordt herhaald nadat er al andere activiteiten hebben plaatsgevonden. Bijvoorbeeld wanneer het proces van 'Loss Assessed' teruggaat naar 'Investigation Started'. Dit attribuut is belangrijk om herwerk te kwantificeren en te analyseren. Het ondersteunt de KPI 'Claim Rework Rate' en het dashboard 'Claim Rework & Reprocessing Patterns' doordat je activiteiten en cases met herwerk rechtstreeks kunt filteren en markeren. Zo vind je inefficiënties en kwaliteitsproblemen in het proces. Waarom dit belangrijk is Kwantificeert herwerk op activiteitsniveau, zodat je de oorzaken en effecten van procesinefficiënties eenvoudig kunt meten, visualiseren en analyseren. Waar je het vindt Dit is geen veld uit het bronsysteem. Het wordt tijdens de datavoorbereiding berekend met algoritmen die herhaalde reeksen activiteiten binnen een case detecteren. Voorbeelden truefalse | |||
| Is op tijd opgelost IsOnTimeResolution | Een berekende vlag die aangeeft of een claim op of vóór de beoogde oplossingsdatum is gesloten. | ||
| Beschrijving Dit boolean-attribuut wordt afgeleid door de timestamp van de activiteit 'Claim Closed' te vergelijken met de 'ResolutionTargetDate' van die claim. Het markeert elke claim als op tijd (true) of te laat (false). Dit attribuut ondersteunt rechtstreeks de KPI 'On-Time Claim Resolution Rate'. Je kunt hiermee SLA-naleving eenvoudig aggregeren en visualiseren in dashboards en verder inzoomen om gemeenschappelijke kenmerken van te late claims te vinden, zoals specifieke claimtypen, afdelingen of procespaden. Waarom dit belangrijk is Meet SLA-compliance rechtstreeks per claim en maakt krachtige filters en root-causeanalyses van achterstallige claims mogelijk. Waar je het vindt Dit is geen veld uit het bronsysteem. Het wordt tijdens de datavoorbereiding berekend door de timestamp van de laatste activiteit te vergelijken met het veld 'ResolutionTargetDate'. Voorbeelden truefalse | |||
| Laatste data-update LastDataUpdate | De timestamp van de meest recente data-update vanuit het bronsysteem. | ||
| Beschrijving Dit attribuut geeft aan wanneer de dataset voor het laatst is bijgewerkt. Het biedt een referentiepunt voor de actualiteit van de geanalyseerde data. In dashboards en analyses wordt dit gebruikt om gebruikers te informeren over de actualiteit van de inzichten. Zo weten ze of de nieuwste transacties in de procesweergave zijn opgenomen. Waarom dit belangrijk is Informeert gebruikers over de actualiteit van de data. Dat is belangrijk om de analyse goed te interpreteren en tijdig beslissingen te nemen. Waar je het vindt Deze timestamp wordt gegenereerd tijdens het data-extractie-, transformatie- en laadproces (ETL) en meestal opgeslagen in de metadata van de dataset. Voorbeelden 2024-05-21T02:00:00Z | |||
| Polisnummer PolicyNumber | De unieke identificatie van de verzekeringspolis waaronder de claim is ingediend. | ||
| Beschrijving Dit attribuut koppelt de claim aan de oorspronkelijke verzekeringspolis. Het geeft context bij de dekking, voorwaarden en klant die bij de claim horen. Hoewel het polisnummer niet altijd rechtstreeks wordt gebruikt in procesflowanalyse, is het waardevol om claimdata aan te vullen. Je kunt het koppelen aan polis- en klantdata om te analyseren hoe procesprestaties verschillen per klantsegment, polistype of polisduur. Zo ontstaat een breder bedrijfsoverzicht. Waarom dit belangrijk is Koppelt de claim aan de klant en polis. Zo kun je breder analyseren hoe procesprestaties verschillende klantsegmenten of polistypen beïnvloeden. Waar je het vindt Raadpleeg de documentatie van Duck Creek Claims. Dit is een standaardreferentieveld in de hoofdentiteit van de claim. Voorbeelden PA-987654321CP-123456789WC-555444333 | |||
| Reden van afwijzing RejectionReason | De specifieke reden waarom een claim is afgewezen. | ||
| Beschrijving Wanneer wordt besloten een claim af te wijzen, geeft dit attribuut de onderliggende reden voor dat besluit. Meestal wordt de reden gekozen uit een vooraf bepaalde lijst met codes of omschrijvingen. Analyse van afwijzingsredenen is belangrijk voor het dashboard 'Claim Decision & Rejection Insights'. Hiermee kun je veelvoorkomende problemen in aanvragen, mogelijke fraudepatronen of onduidelijke polisvoorwaarden vinden. Deze inzichten kunnen leiden tot verbeteringen in het intakeproces of de acceptatieregels. Waarom dit belangrijk is Legt uit waarom claims worden afgewezen. Zo krijg je concrete aanknopingspunten om het intakeproces te verbeteren, ongeldige aanvragen te verminderen en opleidingsbehoeften te vinden. Waar je het vindt Raadpleeg de documentatie van Duck Creek Claims. Dit veld wordt meestal ingevuld wanneer de claimstatus wordt gewijzigd naar 'Denied' of een vergelijkbare status. Voorbeelden Geen gedekt risicoPolis verlopenDubbele schadeclaimVermoeden van fraude | |||
Activiteiten voor claimsverwerking
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Besluit over claim genomen | Deze activiteit staat voor het officiële besluit over de claim, zoals 'Approved', 'Partially Approved' of 'Denied'. Dit is een belangrijke mijlpaal die wordt afgeleid uit een wijziging naar een definitieve besluitstatus. | ||
| Waarom dit belangrijk is Dit is een belangrijk besluitvormingsmoment. De tijd tot dit punt en de uitkomst van het besluit staan centraal in procesanalyse en efficiëntie. Waar je het vindt Afgeleid van een wijziging in een speciaal veld voor 'Claim Decision' of 'Claim Status' naar een eindstatus zoals 'Approved' of 'Denied'. De timestamp van deze wijziging wordt vastgelegd. Vastleggen Afgeleid van een wijziging in de primaire status- of beslisveld van de claim. Eventtype inferred | |||
| Betaling geautoriseerd | Dit staat voor de formele goedkeuring om het berekende afwikkelingsbedrag uit te betalen. Vaak is dit een aparte stap waarbij een manager of andere bevoegde persoon betrokken is. De stap wordt vastgelegd als een expliciete goedkeuringstransactie. | ||
| Waarom dit belangrijk is Dit is een belangrijk controlepunt en mogelijk bottleneck vóór de betaling. De duur van 'Claim Decision Made' tot dit punt wordt gemeten met de KPI 'Average Claim Approval Time'. Waar je het vindt Dit is meestal een expliciete gebeurtenis in een workflow of financiële module, waarbij een gebruiker met specifieke rechten de betaling goedkeurt. Je vindt deze gebeurtenis in een goedkeuringslog. Vastleggen Expliciete goedkeuringsgebeurtenis die wordt vastgelegd in een workflow- of transactielog. Eventtype explicit | |||
| Betaling uitgevoerd | Deze activiteit markeert de uitvoering van de financiële transactie waarmee de claim wordt betaald. Het is een duidelijke, expliciete gebeurtenis die wordt gegenereerd wanneer de betaling via een cheque, EFT of een andere methode wordt verstuurd. | ||
| Waarom dit belangrijk is Dit betekent dat aan de financiële verplichting voor een goedgekeurde claim is voldaan. De tijd tussen 'Payment Authorized' en 'Payment Issued' laat zien hoe efficiënt de financiële afdeling werkt. Waar je het vindt Vastgelegd in de tabel met financiële transacties in Duck Creek Claims. Deze tabel registreert alle uitgaande betalingen met een specifieke transactiecode en timestamp. Vastleggen Er wordt een afzonderlijke regel in het financiële transactielog aangemaakt wanneer de betaling wordt verwerkt. Eventtype explicit | |||
| Claim afgewezen | Deze activiteit is een alternatief einde van het proces, waarbij de claim officieel wordt afgewezen. Dit wordt vastgelegd wanneer de definitieve claimstatus op 'Denied' of 'Rejected' wordt gezet. | ||
| Waarom dit belangrijk is Dit is een belangrijke uitkomst die apart moet worden geanalyseerd. Als je begrijpt waarom en wanneer claims worden afgewezen, kun je de intakeprocessen verbeteren en compliance beheren. Waar je het vindt Afgeleid van de timestamp van de laatste statuswijziging van de claim naar 'Denied', 'Rejected' of 'Closed without Payment' in de claimentiteitstabel. Vastleggen Afgeleid van een definitieve claimstatus die een afwijzingsreden aangeeft. Eventtype inferred | |||
| Claim gesloten | Dit is de laatste activiteit. Hiermee wordt het claimdossier administratief gesloten nadat de betaling is uitgevoerd of de claim is afgewikkeld. Dit wordt vastgelegd met de laatste statuswijziging naar 'Closed'. | ||
| Waarom dit belangrijk is Deze activiteit markeert het succesvolle einde van het proces. Dit is het eindpunt voor het berekenen van de KPI 'Average End-to-End Claim Cycle Time' en andere belangrijke duurmetingen. Waar je het vindt Afgeleid van de timestamp van de laatste statuswijziging naar 'Closed' of 'Settled' in de hoofdtafel met claimdata. Vastleggen Afgeleid van de definitieve claimstatus 'Closed'. Eventtype inferred | |||
| Claim ingediend | Dit is de eerste gebeurtenis. Hierbij ontvangt de verzekeraar de First Notice of Loss (FNOL). Meestal wordt dit als een expliciete transactie vastgelegd wanneer een agent of polishouder de eerste claiminformatie in het systeem invoert. | ||
| Waarom dit belangrijk is Deze activiteit markeert het begin van de volledige levenscyclus van de claim. Door de tijd tussen deze gebeurtenis en latere gebeurtenissen te analyseren, krijg je inzicht in de totale verwerkingsduur en de efficiëntie van de intake. Waar je het vindt Dit is meestal een expliciete gebeurtenis in een claim- of FNOL-logtabel, wanneer in Duck Creek Claims voor het eerst een nieuw claimrecord wordt aangemaakt. Vastleggen Gebeurtenis die wordt vastgelegd bij het voor het eerst aanmaken van een nieuw claimrecord. Eventtype explicit | |||
| Aanvullende informatie ontvangen | Dit markeert de ontvangst van de opgevraagde informatie, waarna de claimafhandeling kan doorgaan. De schadebehandelaar kan dit handmatig vastleggen, of het gebeurt automatisch wanneer de informatie via een digitaal portaal wordt ingediend. | ||
| Waarom dit belangrijk is De tijd tussen 'Information Requested' en 'Information Received' is een belangrijke wachttijd. Door deze duur te analyseren, kun je afhankelijkheden buiten de organisatie en knelpunten in de communicatie vinden. Waar je het vindt Dit kan een expliciete gebeurtenis zijn uit een integratie met een documentbeheersysteem, of een handmatige logregel of statuswijziging die de schadebehandelaar invoert na ontvangst van de documenten. Vastleggen Gebeurtenis die wordt vastgelegd na het uploaden van een document of na een handmatige invoer door een schadebehandelaar. Eventtype explicit | |||
| Aanvullende informatie opgevraagd | Deze activiteit vindt plaats wanneer de schadebehandelaar vaststelt dat meer informatie nodig is en een verzoek naar de polishouder of een derde partij stuurt. Vaak is dit een expliciete gebeurtenis die aan de communicatie- of correspondentiemodule van het systeem is gekoppeld. | ||
| Waarom dit belangrijk is Een hoge frequentie van deze activiteit kan wijzen op problemen in het proces voor het verzamelen van de eerste data. De activiteit zorgt ook voor veel wachttijd en heeft daarmee invloed op de totale doorlooptijd. Waar je het vindt Vastgelegd in logs voor uitgaande communicatie, zoals brieven en e-mails, of als een specifieke 'Request for Information'-transactie in Duck Creek Claims. Vastleggen Wordt vastgelegd wanneer een correspondentie of taak voor het opvragen van informatie wordt aangemaakt. Eventtype explicit | |||
| Afwikkelingsbedrag berekend | Na een goedkeuringsbesluit staat deze activiteit voor de berekening van het definitieve afwikkelings- of betalingsbedrag. Dit kan een expliciete stap zijn of worden afgeleid uit het definitief vastleggen van betalingsbedragen in de financiële module van het systeem. | ||
| Waarom dit belangrijk is Deze activiteit is belangrijk voor het meten van de KPI 'Settlement Rework Rate'. Meerdere voorkomens van deze gebeurtenis voor één claim wijzen op inefficiëntie, fouten of onderhandelingen tijdens de afwikkeling. Waar je het vindt Dit kan een expliciete regel in het transactielog zijn of worden afgeleid uit wijzigingen in het veld 'Settlement Amount' in de financiële claimdata. Auditlogs van dit veld zijn de belangrijkste bron. Vastleggen Gebeurtenis die wordt vastgelegd wanneer het definitieve betalingsbedrag is berekend en opgeslagen. Eventtype explicit | |||
| Claim geregistreerd | Dit markeert de formele acceptatie en registratie van de ingediende claim. Op dat moment wordt officieel een unieke Claim ID toegewezen. Vaak is dit een geautomatiseerde systeemgebeurtenis na een eerste validatie van de data. | ||
| Waarom dit belangrijk is Hiermee begint de claim formeel en worden vervolgprocessen gestart, zoals de toewijzing van een schadebehandelaar. De tijd tussen indiening en registratie kan wijzen op problemen met de kwaliteit van de eerste data of met de systeembelasting. Waar je het vindt Afgeleid van de timestamp waarop de primaire Claim ID wordt gegenereerd en de claimstatus in de hoofdentiteitstabel verandert van 'pending' of 'submitted' naar 'open' of 'registered'. Vastleggen Afgeleid van de aanmaaktimestamp van het primaire claimrecord of van een statuswijziging naar 'Open'. Eventtype inferred | |||
| Eerste beoordeling afgerond | Dit staat voor de afronding van de eerste volledige beoordeling van de claim door de toegewezen schadebehandelaar. Meestal wordt dit afgeleid uit een statuswijziging na de toewijzing, bijvoorbeeld van 'Assigned' naar 'Under Review' of 'Investigation'. | ||
| Waarom dit belangrijk is Deze mijlpaal helpt de tijd tot de eerste actie van een schadebehandelaar te meten en kan wijzen op achterstanden in diens werkvoorraad. Dit is het eerste belangrijke controlepunt dat door een medewerker wordt uitgevoerd. Waar je het vindt Afgeleid van een wijziging in het veld voor de claimstatus, bijvoorbeeld een overgang naar 'Initial Review Complete' of 'Pending Information'. De timestamp van deze statuswijziging wordt gebruikt. Vastleggen Afgeleid van een wijziging in het veld voor de claimstatus na toewijzing aan een schadebehandelaar. Eventtype inferred | |||
| Onderzoek afgerond | Dit staat voor het einde van de onderzoeksactiviteiten, waarbij alle benodigde feiten zijn verzameld. Meestal wordt dit afgeleid wanneer de claimstatus verandert van 'Under Investigation' naar een status voor besluitvorming, zoals 'Pending Decision'. | ||
| Waarom dit belangrijk is De afronding van het onderzoek is een belangrijke mijlpaal die de besluitvorming en afwikkeling mogelijk maakt. Vertragingen op dit punt hebben veel invloed op de vervolgstappen. Waar je het vindt Afgeleid van de timestamp van een claimstatuswijziging van een onderzoeksstatus naar een beoordelings- of besluitstatus. Vastleggen Afgeleid van een wijziging in de claimstatus die het einde van de onderzoeksactiviteiten aangeeft. Eventtype inferred | |||
| Onderzoek gestart | Deze activiteit markeert het begin van de formele onderzoeksfase van de claim. Vaak wordt dit afgeleid uit een wijziging van de claimstatus naar 'Under Investigation' of een vergelijkbare status. | ||
| Waarom dit belangrijk is Hiermee begint een fase die veel bronnen vraagt. Het meten van de onderzoeksduur is belangrijk voor de KPI 'Average Investigation Duration' en helpt bij het beheren van een belangrijk onderdeel van het proces. Waar je het vindt Afgeleid van de timestamp van een claimstatuswijziging naar 'Investigation in Progress' of 'Pending Inspection' in het hoofdveld voor de claimstatus. Vastleggen Afgeleid van een wijziging in de claimstatus die het begin van de onderzoeksactiviteiten aangeeft. Eventtype inferred | |||
| Schade beoordeeld | Deze mijlpaal markeert het moment waarop financiële reserves worden vastgesteld of bijgewerkt op basis van de onderzoeksresultaten. Hiermee wordt de financiële impact van de claim ingeschat. De gebeurtenis wordt vastgelegd wanneer reservebedragen worden ingevoerd of aangepast. | ||
| Waarom dit belangrijk is Dit is een belangrijk financieel controlepunt in het proces. Door te analyseren wanneer dit plaatsvindt, krijg je inzicht in de snelheid en nauwkeurigheid van de financiële beoordeling. Waar je het vindt Dit is vaak een expliciete financiële transactie in het log met financiële claimtransacties of in de tabel met de reservehistorie binnen Duck Creek Claims. Vastleggen Financiële transactie die wordt vastgelegd bij het instellen of bijwerken van claimreserves. Eventtype explicit | |||
| Schadebehandelaar toegewezen | Deze gebeurtenis legt vast dat een schadebehandelaar of claimbehandelaar aan de geregistreerde claim wordt toegewezen. Het systeem registreert deze toewijzing. Daarmee ontstaat een duidelijk overdrachtsmoment en wordt het eigenaarschap van de claim vastgelegd. | ||
| Waarom dit belangrijk is Belangrijk voor het analyseren van de toewijzing van bronnen, de werkdruk van schadebehandelaars en vertragingen bij de claimtoewijzing. Dit is een belangrijk overdrachtsmoment waar wachttijd kan ontstaan. Waar je het vindt Wordt gevolgd via een wijziging in het veld 'Assigned Adjuster' in de hoofdtafel met claimdata. De timestamp staat in de historie of auditlog van dit veld. Vastleggen Wordt vastgelegd in een audittrail wanneer het veld voor de schadebehandelaar wordt ingevuld of gewijzigd. Eventtype explicit | |||
Extractiegidsen
Stappen
- Open de configuratietool van Duck Creek Data Hub: Log in op de Duck Creek-omgeving en ga naar de Data Hub-applicatie. Je hebt de juiste rechten nodig om data-exportconfiguraties te maken of aan te passen.
- Maak een nieuwe data-exporttaak: Start in de Data Hub-tool een nieuwe exporttaak. Geef deze een duidelijke naam, bijvoorbeeld ProcessMind_Claims_Event_Log_Export.
- Definieer de databron: Configureer de taak om verbinding te maken met de primaire SQL-database van Data Hub. Je moet de servernaam, databasenaam en inloggegevens opgeven van een gebruiker met leestoegang tot de relevante schema's.
- Voer de extractiequery in: Ga naar het gedeelte voor de querydefinitie van de exporttaak. Kopieer het volledige script uit het onderstaande querygedeelte en plak het in de query-editor.
- Stel queryparameters in: Ga naar het parameter gedeelte van de configuratie. Definieer waarden voor de parameters @StartDate en @EndDate uit de query en stel deze in op de gewenste extractieperiode. Bijvoorbeeld '2023-01-01' en '2023-12-31'.
- Koppel uitvoerkolommen: Configureer de instellingen voor het uitvoerbestand. Controleer of de kolommen uit de SELECT-instructie, zoals ClaimId, ActivityName en EventTime, correct zijn gekoppeld aan de kolommen in het uitvoerbestand. De kopteksten in het uitvoerbestand moeten exact overeenkomen met deze namen.
- Configureer het uitvoerbestand: Kies CSV als uitvoerformaat. Gebruik een komma (,) als scheidingsteken en UTF-8 als tekencodering, zodat het bestand goed werkt met ProcessMind.
- Definieer de bestemming: Geef het bestandspad of de netwerklocatie op waar het gegenereerde CSV-bestand wordt opgeslagen. Controleer of het systeem schrijfrechten heeft op deze locatie.
- Plan de exporttaak: Configureer het schema van de taak. Voor een eerste analyse kun je de taak handmatig uitvoeren. Stel voor doorlopende monitoring een terugkerend schema in, bijvoorbeeld dagelijks of wekelijks.
- Voer de taak uit en haal het bestand op: Voer de taak uit om het event log-bestand te genereren. Haal het CSV-bestand na afloop op uit de bestemming die je in stap 8 hebt opgegeven.
- Bereid het bestand voor op upload: Open het CSV-bestand voordat je het naar ProcessMind uploadt voor een laatste controle. Controleer of de kopteksten kloppen, de datumnotatie consistent is (YYYY-MM-DD HH:MI:SS) en de data eruitziet zoals verwacht.
Configuratie
- Vereisten: Je hebt toegang nodig tot de Duck Creek Data Hub-module. De gebruiker of serviceaccount dat de exporttaak uitvoert, moet leestoegang hebben tot de onderliggende databasetabellen van Data Hub, zoals [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim] en [DataHubSchema].[DimStatusHistory].
- Configuratie van de datumperiode: De query gebruikt de parameters @StartDate en @EndDate. Stel deze in om de extractieperiode te bepalen. Voor een eerste analyse raden we een periode van 6 tot 12 maanden aan, zodat je voldoende afgeronde en lopende cases meeneemt.
- Filteren: De query bevat binnen de Common Table Expression (CTE) de tijdelijke regel /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */. Haal de commentaartekens weg en pas deze regel aan om specifieke bedrijfstakken te filteren, bijvoorbeeld 'Personal Auto' of 'Commercial Property'. Zo beperk je het datavolume en richt je de analyse op een specifiek onderdeel.
- Verversingscyclus van Data Hub: Houd rekening met de vertraging in de data van Data Hub. De data is niet realtime en wordt meestal volgens een schema ververst, bijvoorbeeld elke nacht. De geëxtraheerde data is zo actueel als de laatste geslaagde verversing van Data Hub.
- Uitvoerformaat: Configureer de exporttaak om een plat bestand te maken, bij voorkeur CSV. Stel de tekstkwalificatie in op dubbele aanhalingstekens (") om komma's in datavelden goed te verwerken.
a Voorbeeldquery sql
-- Common Table Expression (CTE) to fetch core claim attributes
-- This improves readability and performance by querying base tables once.
WITH ClaimBase AS (
SELECT
DC.ClaimId,
DC.ClaimNumber,
DC.ClaimType,
DC.Severity AS ClaimSeverity,
DC.CurrentStatus AS ClaimStatus,
FC.LossAmount,
DA.AdjusterName AS AssignedAdjuster,
DD.DepartmentName AS Department,
-- Timestamps for various events
FC.FNOLReportedDate AS ClaimSubmittedTime,
FC.ClaimRegisteredDate AS ClaimRegisteredTime,
FC.AdjusterAssignmentDate AS AdjusterAssignedTime,
FC.PaymentIssuedDate AS PaymentIssuedTime,
FC.ClaimClosedDate AS ClaimClosedTime
FROM
[DataHubSchema].[DimClaim] AS DC
LEFT JOIN
[DataHubSchema].[FactClaim] AS FC ON DC.ClaimKey = FC.ClaimKey
LEFT JOIN
[DataHubSchema].[DimAdjuster] AS DA ON FC.AssignedAdjusterKey = DA.AdjusterKey
LEFT JOIN
[DataHubSchema].[DimDepartment] AS DD ON FC.DepartmentKey = DD.DepartmentKey
WHERE
FC.FNOLReportedDate BETWEEN @StartDate AND @EndDate
/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ -- Optional: Uncomment to filter by Line of Business
)
-- 1. Claim Submitted
SELECT
cb.ClaimId,
'Claim Submitted' AS ActivityName,
cb.ClaimSubmittedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Submitted' AS ClaimStatus, -- Status at the time of this event
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimSubmittedTime IS NOT NULL
UNION ALL
-- 2. Claim Registered
SELECT
cb.ClaimId,
'Claim Registered' AS ActivityName,
cb.ClaimRegisteredTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Registered' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimRegisteredTime IS NOT NULL
UNION ALL
-- 3. Adjuster Assigned
SELECT
cb.ClaimId,
'Adjuster Assigned' AS ActivityName,
cb.AdjusterAssignedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Assigned' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.AdjusterAssignedTime IS NOT NULL
UNION ALL
-- 4. Initial Review Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Initial Review Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus IN ('Assigned', 'Registered') AND sh.NewStatus IN ('Under Review', 'Investigation')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Under Review', 'Investigation'))
UNION ALL
-- 5. Additional Information Requested
SELECT
cb.ClaimId,
'Additional Information Requested' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationRequestSent'
UNION ALL
-- 6. Additional Information Received
SELECT
cb.ClaimId,
'Additional Information Received' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationResponseReceived'
UNION ALL
-- 7. Investigation Started (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Started' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Under Investigation'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus = 'Under Investigation')
UNION ALL
-- 8. Investigation Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus = 'Under Investigation' AND sh.NewStatus = 'Pending Decision'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.PreviousStatus = 'Under Investigation' AND s2.NewStatus = 'Pending Decision')
UNION ALL
-- 9. Loss Assessed (Reserve Set/Updated)
SELECT
cb.ClaimId,
'Loss Assessed' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount -- Use transaction amount for this event
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'ReserveSet'
UNION ALL
-- 10. Claim Decision Made (Inferred from status change)
SELECT
cb.ClaimId,
'Claim Decision Made' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus IN ('Approved', 'Partially Approved', 'Denied')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Approved', 'Partially Approved', 'Denied'))
UNION ALL
-- 11. Settlement Calculated
SELECT
cb.ClaimId,
'Settlement Calculated' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'SettlementCalculated'
UNION ALL
-- 12. Payment Authorized
SELECT
cb.ClaimId,
'Payment Authorized' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'PaymentAuthorized'
UNION ALL
-- 13. Payment Issued
SELECT
cb.ClaimId,
'Payment Issued' AS ActivityName,
cb.PaymentIssuedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'PaymentIssued' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.PaymentIssuedTime IS NOT NULL
UNION ALL
-- 14. Claim Denied
SELECT
cb.ClaimId,
'Claim Denied' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Denied' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Denied'
UNION ALL
-- 15. Claim Closed
SELECT
cb.ClaimId,
'Claim Closed' AS ActivityName,
cb.ClaimClosedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Closed' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimClosedTime IS NOT NULL; Klaar om aan de slag te gaan?
Met deze template heb je alles wat je nodig hebt om je claimverwerking te verbeteren. Begin vandaag met je data-analyse en ontdek waardevolle inzichten.
Werk claimachterstanden weg: optimaliseer je claimverwerking nu
Bereik 70% straight-through processing en verlaag kosten en vertragingen.
14 dagen gratis proefperiode, zonder creditcard.