a.s.r. Policy Application Flow

De hoofdingang voor elke binnenkomende verzekeringsaanvraag bij een van de grootste verzekeraars van Nederland. Ik breidde hem uit naar tientallen extra werkgevers, verminderde de interne fouten die aanvragen lieten stranden en ontwierp en beheerde het release-proces eromheen.

Opdrachtgevera.s.r., een van de grootste verzekeraars in Nederland
Periode2024 tot 2026
RolFreelance full stack engineer, en release-eigenaar
TeamScrum team van 7 developers, 9 mensen in totaal
SchaalHonderdduizenden gebruikers

Uitgebreid naar tientallen extra werkgevers, zodat duizenden extra werknemers hun dekking er via kunnen regelen.
Interne fouten die aanvragen halverwege lieten stranden, opgespoord en verholpen.
Releases werden routine op een proces dat ik ontwierp en voerde, waarbij stakeholders wisten wat er wanneer uitging.

Context

De aanvraagstraat en de rekentool ernaast zijn de manier waarop a.s.r. nieuwe klanten binnenhaalt. Samen worden ze door honderdduizenden mensen gebruikt, en wie aan de andere kant van het scherm zit, regelt dekking voor iets wat er echt toe doet. Bij elke stap gaan er gevoelige persoonsgegevens doorheen. Ik werkte eraan in een scrum team van 7 developers, 9 mensen in totaal.

De uitdaging

Een aanvraag met meerdere stappen kent geen milde vorm van falen. Een interne fout halverwege komt niet binnen als een bugmelding, maar als iemand die het opgaf en niet terugkwam, en daar hebben die persoon noch a.s.r. iets aan. Elke stap verwerkt ook gevoelige persoonsgegevens, dus beveiliging en datacorrectheid zijn geen eigenschappen die je afweegt tegen leversnelheid. Ze vormen de ondergrens.

Wat ik deed

De aanvraagstraat uitgebreid naar tientallen extra werkgevers, waardoor duizenden extra werknemers er überhaupt hun dekking via kunnen regelen. Het opende de aanvraagstraat voor klanten die a.s.r. eerder niet kon bedienen.
De data en functionaliteit afgestemd op gecentraliseerde data binnen a.s.r., zodat de aanvraagstraat leest uit de bron van waarheid van de organisatie. Dat betekent minder onderhoud en een betere aansluiting op hoe het bedrijf echt werkt.
De interne fouten teruggebracht die aanvragen halverwege lieten stranden, zodat minder mensen afhaken in een proces waar voor hen veel op het spel staat.
De calculatietool uitgebreid, naar meer dekkingsvormen en meer werkgevers, zodat meer werknemers hun inkomensbescherming zelf kunnen uitwerken en regelen.
Het releaseproces opgezet en uitgevoerd, van begin tot eind voor het platform, en de ceremonies eromheen voorgezeten. Releases werden routine en stakeholders wisten wat er live ging en wanneer.
De functionele vragen zelf bij de stakeholders neergelegd, in plaats van via een tussenpersoon, en zo raakten de onduidelijkheden opgelost toen ze nog goedkoop waren.
De release van de uitbreiding zelf geleid, een grote, opgeleverd met nauwelijks incidenten.

Het resultaat

Een flow die leest uit de bronregistratie van de organisatie, wat minder onderhoud vraagt en beter aansluit op de business.
Minder aanvragen die halverwege verloren gaan door interne fouten.
Een grote release opgeleverd met nauwelijks incidenten, op een proces dat ook voor de volgende release klaarstond.

Gebruikte technologieën

.NET: De backendservices achter de aanvraagflow.
C#: De taal van die services.
GraphQL: De API-laag over het platform.
Azure: Het cloudplatform waarop het werk wordt gebouwd, uitgebracht en gedraaid.
Azure Pipelines: De deployment-pipelines achter de releases.
CI/CD: Ik heb het releasepad ontworpen en gedraaid.
TypeScript: De taal in de hele applicatielaag.
Vue.js: De stappen van de flow die de gebruiker ziet.
Playwright: Geautomatiseerde testdekking van de aanvraagflow.
SCRUM: Hoe het team werkte, en de ceremonies die ik voorzat.