Das Problem

Die Signal Iduna wollte die Anzahl der Käufe ihrer Versicherungsprodukte erhöhen. Kunden kontaktierten oft direkt ihre Vertriebsmitarbeiter, um ihre potenzielle Beitragshöhe zu berechnen. Das funktionierte zwar, entsprach aber nicht der wachsenden Online-Nachfrage nach einem "hands-off"-Ansatz. Potenzielle Kunden wollten in der Lage sein, ihre Beiträge zu berechnen, bevor sie mit jemandem sprechen mussten. Einige wollten auch direkt nach der Berechnung ihr gewünschtes Produkt kaufen.

Auf der anderen Seite beanspruchten diese Berechnungen die Zeit vieler Vertriebsmitarbeiter. Die Vertriebsmitarbeiter wollten auch Kunden helfen, die sich sicherer waren. Wenn dies realisiert würde, könnten sie Signal Iduna helfen, ihr ursprüngliches Ziel zu erreichen.

Die Lösung

Wir entschieden uns für einen Online-Prozess, der es den Benutzern ermöglicht, ihre Beiträge zu berechnen und Versicherungsprodukte in ihrer eigenen Zeit abzuschließen. Um dies zu realisieren, bauten wir eine Webanwendung.

Es war wichtig, die Anwendung generisch zu bauen, sodass in Zukunft weitere Versicherungsprodukte aufgenommen werden können. Das heißt, wenn Signal Iduna schnell auf eine neue Richtlinienänderung reagieren wollte, die die Versicherung aller X Produkte vorschreibt, konnten wir schnell reagieren. Nicht nur das, sie würden auch enorme Kosten einsparen, da sie keinen neuen Trichter bauen müssten.

Meine Rolle

Signal Iduna wollte, dass ich in ihrem Frontend-Team mitarbeite, und ich sagte gerne zu. Wir arbeiteten in einer multidisziplinären agilen/ Scrum-Umgebung, in der das Design-Team kontinuierlich Feedback von den Nutzern einholte und wir die von den Nutzern benötigten Änderungen implementierten.

Angular und NGRX waren die Tools, mit denen wir das Frontend der Anwendung erstellt haben. Tools, mit denen ich gut vertraut bin. Ich testete während der Erstellung und nutzte meine umfangreiche Erfahrung mit reaktiven Formularen, um die Antragsstrecke für die Privathaftpflichtversicherung zu erstellen.