Software für Versicherer

// Das Problem

Versicherungsnehmer melden Schäden am Telefon und schicken Fotos per E-Mail, also beginnen Sachbearbeiter jede Akte mit dem Nachjagen von Informationen statt mit der Beurteilung.

// Was wir bauen würden

Eine App für iOS und Android, in der Versicherungsnehmer einen Schaden melden, Fotos hinzufügen und ihren Fall verfolgen, mit einem Webportal für die Sachbearbeitung, das Akten zuweist, Reserven verfolgt und mit dem Schadensystem spricht.

// Was drin ist

// Tech-Stack

• Next.js
• React Native
• PostgreSQL
• API von Guidewire oder des Schadensystems
• AWS Kanada

// Das Problem

Jedes Foto eines Kfz-Schadens öffnet ein Sachbearbeiter, um zu entscheiden, ob die Akte eine schnelle Reparatur oder wahrscheinlich ein Totalschaden ist, und das bremst die einfachen aus.

// Was wir bauen würden

Ein eigenes Bildmodell, auf den eigenen Fotos abgeschlossener Schäden des Versicherers nachtrainiert und in dessen eigenem AWS-Konto betrieben, das neue Akten nach wahrscheinlicher Schwere und betroffenen Teilen sortiert, damit die Sachbearbeitung schneller entscheidet. Ein allgemeines Spitzenmodell kennt Ihre Reparaturergebnisse nicht; Ihres schon.

// Was drin ist

// Tech-Stack

• PyTorch
• Python
• Amazon S3
• Next.js
• AWS-GPU-Instanzen

// Das Problem

Underwriter verbringen Stunden am Tag damit, Deckungsfragen von Maklern zu beantworten, deren Antwort irgendwo in langen, öffentlichen Bedingungswerken und Nachträgen steht.

// Was wir bauen würden

Ein Assistent für Makler, der aus den veröffentlichten Bedingungswerken und Nachträgen antwortet und die Klausel zitiert, auf einem Spitzenmodell, weil die Dokumente öffentlich sind und das Aufkommen gering ist, was es zum schnellsten und günstigsten Weg macht.

// Was drin ist

// Tech-Stack

• API eines Spitzenmodells
• PostgreSQL mit pgvector
• Next.js
• DigitalOcean

// Das Problem

Regresse zwischen Versicherern werden per Brief und Telefon vereinbart, jede Seite führt ihre eigene Aufzeichnung, und abgerechnete Beträge werden bestritten, wenn das Personal wechselt.

// Was wir bauen würden

Ein privates Register mit Zugangsberechtigung, in dem jeder beteiligte Versicherer einen Knoten betreibt und Forderungen, Angebote und vereinbarte Regulierungen einmal erfasst, mit einer Web-Konsole für die Regressabteilung. Wo eine Branchenclearingstelle das schon leistet, ist eine Datenbank dahinter günstiger, und wir sagen Ihnen das.

// Was drin ist

// Tech-Stack

• Hyperledger Besu (privat, mit Zugangsberechtigung)
• Next.js
• PostgreSQL
• AWS

// Das Problem

Die Schadenregulierer eines Versicherers suchen die Deckung im Policensystem, kopieren sie ins Schadensystem und fordern Zahlungen per E-Mail bei der Finanzabteilung an, sodass jeder Schaden darauf wartet, dass jemand etwas abtippt.

// Was wir bauen würden

Eine Integration, die Policen- und Deckungsdaten in jeden neuen Schaden holt, freigegebene Zahlungen mit den richtigen Freigaben an Ihr Zahlungssystem schickt und die Ergebnisse am Schaden vermerkt, mit einer Statusansicht für jeden Austausch.

// Was drin ist

// Tech-Stack

• Node.js
• PostgreSQL
• REST
• OpenAPI
• AWS Canada

// Das Problem

Der Angebotsrechner einer Assekuradeur-Agentur ist ein Desktop-Programm mit eingebauten Tariftabellen; Makler müssen ihn installieren, Updates gehen per E-Mail hinaus, und eine Tarifänderung dauert Wochen.

// Was wir bauen würden

Ein Neubau als Web-App für Ihre Makler: die Tarifregeln aus dem alten Programm herausgelöst, aufgeschrieben und gegen seine Ergebnisse getestet, Tarife in Tabellen, die Ihre Underwriter mit Freigabe pflegen, und jedes Angebot gespeichert.

// Was drin ist

// Tech-Stack

• Next.js
• PostgreSQL
• TypeScript
• Playwright
• DigitalOcean