Een wijziging in SUPP zet automatisch de klantcommunicatie in gang
Zodra er iets verandert, kan er direct iets gebeuren
Verzekeringen staan niet stil.
Een verzekeraar past een verzekerde waarde aan, een premie wijzigt, een dekking verandert of er vindt een andere mutatie op een bestaande verzekering plaats.
Veel van die wijzigingen komen tegenwoordig automatisch digitaal binnen bij het assurantiekantoor. Via Aplaza ontvangt SUPP mutatieberichten van verzekeraars en volmachten en worden wijzigingen verwerkt in de administratie.
Maar daarmee hoeft de automatisering niet te stoppen.
Een van onze kantoren heeft eigen software ontwikkeld waarmee het zijn klanten informeert en begeleidt wanneer er iets verandert in hun verzekeringen.
De uitdaging daarbij was eenvoudig: hoe weet die externe software dat er in SUPP iets is gebeurd?
Daarvoor gebruiken we de webhooks van de SUPP API.
Van periodiek controleren naar direct een seintje krijgen
Bij een traditionele koppeling haalt een extern systeem gegevens op uit een ander systeem.
De eigen software van het kantoor zou bijvoorbeeld iedere zoveel minuten aan SUPP kunnen vragen:
"Is er sinds de laatste keer nog iets veranderd?"
Dat werkt, maar is eigenlijk een omslachtige manier van koppelen. Het externe systeem moet voortdurend controleren of er misschien iets is gebeurd, terwijl SUPP dat zelf al weet.
Met een webhook draaien we dit principe om.
De eigen software hoeft niet steeds bij SUPP aan te kloppen. SUPP geeft zelf een seintje zodra er een relevante gebeurtenis plaatsvindt.
Dat maakt het mogelijk om gebeurtenissen binnen SUPP vrijwel direct als startpunt te gebruiken voor processen in andere software.
Een mutatiebericht van de verzekeraar komt binnen
Een goed voorbeeld is een mutatiebericht dat via Aplaza binnenkomt.
Stel dat een verzekeraar of volmacht een wijziging doorvoert op een bestaande verzekering van een klant. In het mutatiebericht staat bijvoorbeeld dat de verzekerde waarde van een object is aangepast.
SUPP ontvangt en verwerkt dit bericht.
Normaal gesproken zou daarmee vooral de administratie zijn bijgewerkt. Een medewerker kan de gewijzigde gegevens vervolgens in SUPP terugzien en daar eventueel een vervolgactie aan verbinden.
Bij dit kantoor gebeurt er meer.
Zodra de relevante wijziging in SUPP plaatsvindt, kan via de webhook van de SUPP API automatisch een bericht naar de eigen software van het kantoor worden gestuurd.
Die software weet daardoor:
er is iets veranderd bij deze klant en op deze verzekering.
En dat kan direct het startsein zijn voor een volledig eigen proces.
Van administratieve wijziging naar klantcommunicatie
Dat is waar de echte kracht van deze koppeling zichtbaar wordt.
Het kantoor heeft zelf bepaald hoe het zijn klanten wil informeren en welke dienstverlening het rondom bepaalde wijzigingen wil aanbieden.
SUPP hoeft dat proces niet te kennen of zelf uit te voeren.
SUPP hoeft alleen aan de software van het kantoor door te geven dat er een relevante gebeurtenis heeft plaatsgevonden. Vervolgens bepaalt de eigen software van het kantoor wat daarmee moet gebeuren.
Bijvoorbeeld:
Verzekeraar → Aplaza → SUPP → webhook → software van het kantoor → actie richting de klant.
Een wijziging die bij de verzekeraar begint, kan daarmee automatisch leiden tot communicatie richting de klant, zonder dat een medewerker eerst hoeft te constateren dat er iets gewijzigd is en vervolgens handmatig een ander systeem in beweging moet zetten.
Bijvoorbeeld: een wijziging van de verzekerde waarde
Stel dat via Aplaza een mutatiebericht binnenkomt waarin een verzekeraar een verzekerde waarde heeft aangepast.
SUPP verwerkt deze wijziging op de verzekering.
Via de webhook wordt vervolgens de eigen software van het kantoor getriggerd. Die software kan op basis van de gebeurtenis bepalen welk proces moet worden gestart.
Het kantoor kan bijvoorbeeld zijn eigen communicatietraject starten om de klant over de wijziging te informeren, aanvullende uitleg te geven of de klant ergens op te laten reageren.
Hoe dat proces er precies uitziet, bepaalt het kantoor zelf.
En juist dát is belangrijk.
De SUPP API schrijft niet voor hoe een kantoor zijn dienstverlening moet organiseren. De API zorgt ervoor dat andere systemen kunnen reageren op wat er binnen SUPP gebeurt.
De administratie wordt het startpunt
Daarmee verandert de rol van een administratieve mutatie.
Een wijziging in een verzekering is niet langer alleen iets wat in het klantdossier wordt bijgewerkt.
Het wordt een gebeurtenis waarop andere systemen kunnen reageren.
Dat opent veel meer mogelijkheden dan alleen het voorbeeld van een gewijzigde verzekerde waarde.
Afhankelijk van de inrichting kan een gebeurtenis in SUPP aanleiding zijn om een klant te informeren, een eigen workflow te starten, gegevens in een ander systeem bij te werken of een andere geautomatiseerde actie uit te voeren.
SUPP registreert wat er gebeurt.
De webhook vertelt het externe systeem dát het gebeurt.
En de software van het kantoor bepaalt vervolgens wat er moet gebeuren.
Geen medewerker meer als tussenschakel
Zonder zo'n koppeling is er vaak een menselijke schakel nodig tussen twee systemen.
Een wijziging komt binnen in de administratie. Een medewerker ziet die wijziging, beoordeelt deze en moet vervolgens een handeling uitvoeren om ergens anders een proces te starten.
Dat kan betekenen dat gegevens worden overgenomen, een ander systeem wordt geopend of dat handmatig een communicatietraject wordt gestart.
Bij grote aantallen wijzigingen kost dat niet alleen tijd, het betekent ook dat de snelheid waarmee een vervolgactie plaatsvindt afhankelijk is van het moment waarop een medewerker de wijziging ziet.
Met de webhook kan dat anders.
De gebeurtenis zelf wordt de trigger.
Zodra SUPP de relevante wijziging verwerkt, kan het externe systeem automatisch worden geïnformeerd en zijn eigen proces starten.
Er hoeft niemand tussen te zitten om systeem A te vertellen dat er in systeem B iets is gebeurd.
SUPP als onderdeel van het eigen softwarelandschap
Deze use case laat ook goed zien dat SUPP niet per definitie een gesloten systeem hoeft te zijn.
Sommige assurantiekantoren gebruiken naast SUPP eigen software. Soms omdat ze een heel specifieke werkwijze hebben ontwikkeld, soms omdat ze bepaalde dienstverlening zelf hebben gebouwd en soms omdat ze zich daarmee juist willen onderscheiden van andere kantoren.
Wij vinden niet dat zo'n kantoor vervolgens alles opnieuw binnen SUPP zou moeten bouwen.
Als het kantoor al goede eigen software heeft, moet die software juist kunnen samenwerken met SUPP.
De SUPP API en webhooks maken dat mogelijk.
SUPP blijft de centrale plek voor onder andere klanten, verzekeringen en processen, terwijl eigen toepassingen van het kantoor daar omheen hun eigen taak kunnen uitvoeren.
Niet alleen gegevens uitwisselen, maar systemen laten samenwerken
Een API-koppeling wordt vaak gezien als een manier om gegevens van het ene systeem naar het andere systeem te sturen.
Maar deze use case laat zien dat een integratie veel verder kan gaan.
Het gaat niet alleen om het kunnen opvragen of wijzigen van gegevens.
Het gaat er ook om dat systemen op elkaar kunnen reageren.
Er gebeurt iets in SUPP en daardoor komt automatisch een ander systeem in beweging.
Dat andere systeem voert zijn eigen logica uit en kan vervolgens bijvoorbeeld communicatie richting de klant starten.
Daarmee ontstaat een keten waarin iedere toepassing doet waar deze goed in is.
De verzekeraar of volmacht voert een wijziging door.
Aplaza levert het mutatiebericht aan.
SUPP verwerkt de wijziging.
De webhook informeert de software van het kantoor.
De eigen software start automatisch de gewenste actie richting de klant.
En dat allemaal zonder dat een medewerker de verschillende systemen handmatig met elkaar hoeft te verbinden.
Vrijheid om je eigen dienstverlening te bouwen
Voor ons is dat misschien wel het interessantste aan deze use case.
Niet ieder kantoor werkt hetzelfde. En zeker kantoren die zelf software ontwikkelen, willen soms processen creëren die heel specifiek aansluiten op hun eigen dienstverlening.
Dan moet SUPP geen beperking zijn, maar juist een onderdeel van die oplossing.
Met de SUPP API kan eigen software informatie met SUPP uitwisselen. En met webhooks kan die eigen software automatisch reageren op gebeurtenissen die binnen SUPP plaatsvinden.
Zo kan een kantoor bovenop SUPP zijn eigen toepassingen en dienstverlening blijven ontwikkelen, terwijl de administratie en processen met elkaar verbonden blijven.
SUPP hoeft niet alles zelf te doen. Soms hoeft SUPP alleen maar te vertellen dat er iets is gebeurd.
En precies op dat moment kan de software van het kantoor het overnemen.