This page is an example of how we run a claims intake build for a general insurer, and it does not describe a client.
The situation
A general insurer receives first notice of loss, the first report of a claim, by email, web form, PDF and call centre notes. Claims staff read each one to work out the line of business, how serious the claim is and which queue it belongs in. Then they find which documents are missing and write to the customer or broker for them. The insurer knows the job well and wants a fixed scope and a fixed price.
What we build
We run this as project delivery with a fixed scope. We agree the scope, the acceptance tests and the price with the insurer in writing before the build starts.
The intake layer turns every channel into one structured record per claim in PostgreSQL. Email bodies, attachments, PDFs and web form fields go through one data pipeline. We build it in Dagster or Airflow to match what the insurer already runs.
The classifier gives each claim a line of business, such as motor or home, and a severity, such as minor or major. It uses an LLM with the insurer’s own definitions in the prompt. The model is an open-weight model served with vLLM in the insurer’s own cloud account. Fixed rules from the claims team sit on top for cases that always go one way, such as a claim that mentions an injury.
The checklist compares what arrived with what each claim type needs, for example photos and the other driver’s details on a motor claim. It lists what is missing and drafts a request to the customer or broker for a person to send.
Each result goes back into the claim record through the API of the claims system, with its reason. Claims officers keep working in the system they already use. A claims officer decides every claim, and the system does not accept, decline or pay anything.
We log each classification with its input, its output, the model version and the decision of the officer. The log includes any change an officer makes to the severity or queue, with the reason. Before go-live, the system runs in shadow mode on live claims. Shadow mode means the system classifies each claim while officers work as before, and we compare the two. The insurer signs off against the acceptance tests in the scope.
What your team owns
The insurer’s IT team owns and runs the automation from go-live. The code sits in the insurer’s repositories and runs in its own AWS, Azure or Google Cloud account. The claims team owns the rules: the severity definitions, the document checklist for each claim type and the routing. They change a rule in one configuration file, without a code change. We hand over runbooks for the common jobs, and a warranty period covers defects against the agreed scope.
What to expect
Each claim arrives in a queue with a line of business, a severity and a list of missing documents. Every classification and every change by an officer sits in a log that the insurer can audit. Work outside the agreed scope gets its own quote.