Insurance · Claims triage
Multi-workflowInsuranceClaims triage in three workflows, with the handler deciding cover
A new claim arrives as an email, a form and a few photos. Here is how three workflows turn that into a structured file, a policy check and a routed queue, while every cover and settlement decision stays with a claims handler.
Valnora & Elric team5 min read
- WorkflowsThe visual builder: blocks, models and integrations wired into agent logic.
- TablesA database, built in, for cases, queues and decisions.
- Knowledge BasePolicies and procedures agents search before they answer.
- LogsEvery run traced block by block.
- FilesOne store for documents your team and agents share.
The first hours of a claim are mostly reading. A handler opens an email, works out which policy it relates to, reads an invoice and a repair report, finds the right section of the wording and decides which queue it belongs in. On a busy week, simple claims wait behind complex ones simply because nobody has read them yet.
This post describes an architecture for that first stage, built from three workflows in the Agent Serve workflow builder. They read, check and route. Decisions on cover, liability and settlement stay with claims handlers, which is also where UK rules put the obligation: the FCA’s ICOBS 8.1.1R requires insurers to handle claims promptly and fairly and not to reject them unreasonably.
Why three workflows rather than one
Intake, policy checking and handler preparation change at different speeds and for different reasons. A new claims form changes intake. A new policy wording changes the check. A new letter template changes the handler file.
Keeping them separate means each can be changed, tested and deployed on its own. Workflow 1 calls Workflow 2 with the Workflow block, which runs another workflow as a step, and Workflow 2 calls Workflow 3 the same way. Each run is still traced block by block in Logs, so a claim can be followed from email to queue.
Workflow 1: intake
The intake workflow starts on a webhook from your online claims form. For claims that arrive by email, a schedule runs it every few minutes and reads the claims mailbox through the Gmail or Outlook block.
- Documents to text. The AWS Textract or Reducto block reads invoices, repair reports and scanned forms. Originals are stored in Files.
- Field extraction. An Agent block pulls out the policy number, date and type of loss, amounts and the parties involved, returning a fixed set of fields.
- Personal data. A Guardrails block with PII detection can mask details such as bank account numbers before text reaches later steps that do not need them.
- Claims register. A Table block writes one row per claim to a workspace table, with status set to "received".
Workflow 2: policy check and routing
The second workflow finds the policy wording for the product and version on the claim, using a Knowledge block over wordings stored in the Knowledge Base.
An Agent block then writes coverage notes: the sections that look relevant, exclusions worth checking and information that is missing. It does not conclude whether the claim is covered. Its instructions say so, and the output fields have no place for a decision.
Routing uses two kinds of logic:
- Referral checks written as Condition blocks, such as claims above an amount your authority limits set, losses reported soon after the policy started, or a policy with several recent claims. These are your criteria, not the model’s, and any match goes to a senior handler or the fraud team.
- A Router block that sorts the remaining claims into simple, standard and complex queues based on the extracted fields and coverage notes.
Workflow 3: the handler file
What the solution produces
Claim file summary (illustrative)
Record- Claim
- Escape of water · home contents and buildings
- Reported
- Two days after the loss, by email with photos and a plumber’s invoice
- Amount claimed
- £6,840, of which £1,120 is the repair invoice
- Coverage notes
- Escape of water section applies. Check the exclusion for gradual leaks: the invoice mentions a corroded joint.
- Missing
- Photos of the damaged flooring and the contents list.
- Route
- Standard queue. No referral checks met.
- Suggested next step
- Send the document request below, then book a desk assessment.
The third workflow assembles a one-page claim file: the facts, the coverage notes, what is missing and links to every document. It then pauses on a Human block until the assigned handler accepts the file, edits it or sends it back.
Only after that approval does the workflow send anything to the policyholder: an acknowledgement, or a request for the missing documents, through the Gmail or Outlook block using your approved templates. Nothing reaches a customer without a person seeing it first.
What stays with people
The architecture is deliberate about what it leaves out.
- Cover decisions. The workflows note relevant sections and exclusions. Handlers decide.
- Fraud findings. Referral checks route claims to the fraud team. They do not label a claim as fraudulent.
- Declines and settlements. No workflow can reject a claim or agree an amount.
Controls and governance
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
Row-level access
Row-level policies narrow what each person sees in tables, dashboards, exports and scheduled reports.
Self-hosting
Run Agent Serve in your own cloud or data centre, next to the systems it reads.
Zero data retention
Zero data retention with supported model providers, backed by your own provider keys and agreements or self-hosted models. Some provider features keep data by design, such as Gemini Deep Research, so they are outside zero data retention.
GDPR ready
Retention from one day to five years, deletion and access controls support GDPR obligations. Ready means the controls are in place, not a certification.
More on how Agent Serve handles access, data and audit on the security page.
Workflows run from a deployed version, so a change to referral checks is reviewed before it affects live claims. If claim documents cannot leave your environment, run Agent Serve self-hosted and use your own model keys or a self-hosted model.
What the change could be worth
A home contents claims team receiving 2,400 new claims a month by form and email.
| Assumption | Value |
|---|---|
| New claims per month | 2,400 claims / month |
| Handler minutes to read and route a claim today | 25 min |
| Handler minutes to check a prepared claim file | 10 min |
| Loaded cost of a handler hour | 30 GBP |
- handler hours freed a month: New claims per month × (Handler minutes to read and route a claim today − Handler minutes to check a prepared claim file) ÷ 60
- handler time redirected a year: New claims per month × (Handler minutes to read and route a claim today − Handler minutes to check a prepared claim file) ÷ 60 × Loaded cost of a handler hour × 12
- faster handler reading and routing per claim: Handler minutes to read and route a claim today ÷ Handler minutes to check a prepared claim file
Modelled from the assumptions above to show how the outcome is calculated; not a customer result. Your results depend on your volumes and process.
Where to start
Start with one product line with steady volume and a short wording, such as home contents. Run the three workflows alongside your current intake for a few weeks, compare their routing with the queue handlers would have chosen, and adjust the referral checks before adding the next product.
For the underwriting side of the same book, see underwriting submission intake, and for patterns in what policyholders complain about, see complaints root cause analysis.
What you need
- Access to new claims: a webhook from your claims form or a connected claims mailbox
- Policy wordings for each product and version, uploaded to a Knowledge Base
- Your referral criteria for senior handlers and the fraud team, written as plain conditions
- Queue definitions with the handlers who own each queue
- Approved templates for acknowledgements and document requests
- A link from the claims register to your core claims system, by API or a regular export
From first notice of loss to a routed claim file
Workflow 1 · Intake
- 01New claimA webhook from the claims form, or a schedule that reads the claims mailbox.
- 02Read the documentsAWS Textract or Reducto turns invoices, reports and forms into text.
- 03Extract claim fieldsAn Agent block pulls out policy number, date and type of loss, amounts and parties.
- 04Claims registerOne row per claim, with links to the source documents in Files.
Workflow 2 · Policy check and routing
- 05Find the wordingSearches the policy wordings in a Knowledge Base for the product and version.
- 06Coverage notesLists the sections that look relevant, exclusions to check and missing information.
- 07Referral checksPlain conditions for claims that must go to a senior handler or the fraud team.
- 08Route the claimA Router sends the claim to the simple, standard, complex or referral queue.
Workflow 3 · Handler file
- 09Build the claim fileA one-page summary with facts, coverage notes, open questions and documents.
- 10Handler reviewsA Human block pauses the run until the handler accepts or edits the file.
- 11Acknowledge or requestAfter approval, sends the acknowledgement or document request by Gmail or Outlook.