How a UK General Insurer Cut Claims Handling Costs by 40% with an Amazon Connect AI Voice Agent

Arkadas Kilic 6 min read · 2026-08-20

Claims handling is where insurers win or lose on unit economics. Every inbound call costs money. Every agent minute spent reading out a claim status, confirming a policy number, or walking a customer through a settlement figure is a minute that could be handled autonomously.

This is the story of how we built a production Amazon Connect AI voice agent for a UK general insurer, deployed it across three core claims journeys, and delivered a 40% reduction in claims handling costs within the first 90 days of go-live.

The Problem: High-Volume, Low-Complexity Calls Consuming Agent Capacity

The insurer was handling roughly 18,000 inbound claims calls per month. When we audited the call mix, the breakdown was stark:

• 42% were status update requests: "Where is my claim?"
• 28% were first notification of loss (FNOL) triage calls requiring structured data collection
• 19% were settlement conversation calls where customers wanted to understand or accept an offer
• 11% were complex escalations genuinely requiring a human agent

Nearly 90% of call volume was structured, repeatable, and rule-bound. Yet every call landed in the same queue, staffed by the same agents, at the same cost per minute.

The insurer had looked at traditional IVR. It had also evaluated offshore BPO expansion. Neither addressed the core issue: callers wanted a real conversation, not a touchtone menu, and offshore agents introduced compliance risk under FCA consumer duty obligations.

The Architecture: Amazon Connect Native, No Third-Party Middleware

We built entirely within the AWS ecosystem. No third-party voice platforms. No middleware that creates data residency ambiguity. Every component runs in the insurer's own AWS account, in eu-west-2 (London), satisfying their data sovereignty requirements from day one.

The core stack:

• Amazon Connect for contact flow orchestration and telephony
• Amazon Lex for conversational intent recognition and slot filling
• AWS Lambda for business logic, claims system integration, and decision routing
• Amazon DynamoDB for session state and conversation context
• Amazon S3 and CloudWatch for call recording, audit logging, and compliance archiving
• AWS Secrets Manager for secure credential handling to the claims management system

The claims management system integration was REST-based, authenticated via OAuth2 tokens managed in Secrets Manager. Every API call was logged with a full audit trail, timestamp, and agent identity for FCA record-keeping purposes.

Journey 1: Automated Claims Status Updates

This was the highest-volume journey and the fastest to deliver value.

The voice agent authenticates the caller using two factors: policy number and date of birth, matched against the live claims system. Once authenticated, it retrieves the current claim status and reads it out in plain English, not a status code.

If the claim is with a third-party assessor, the agent states the assessor name and expected completion window. If a payment has been issued, it confirms the amount and payment method. If the claim is on hold pending documentation, it lists exactly what is outstanding.

Key design decisions that made this work in a regulated context:

1. No hallucination risk on factual data. The agent reads structured data from the claims system. It does not generate or infer claim status. The language model handles only natural language understanding and response formatting, not data retrieval.

2. Full call recording and transcript storage for FCA compliance, retained for 7 years in S3 with object lock.

3. Clear escalation path. Any caller who says "speak to someone" or expresses dissatisfaction is immediately routed to a live agent with full context transferred.

Result: 87% of status update calls handled end-to-end without agent involvement. Average handle time dropped from 4.2 minutes to under 90 seconds.

Journey 2: First Notification of Loss Triage

FNOL triage is structurally complex. The agent needs to collect incident date, incident type, policy details, third-party involvement, injury indication, and vehicle or property details depending on the claim type. It then needs to make a routing decision: fast-track, standard, or complex.

We built a dynamic conversation flow using Amazon Lex with custom slot types mapped to the insurer's claims taxonomy. The flow adapts based on answers: a motor claim with third-party injury immediately triggers a different path than a single-vehicle incident with no injuries.

All collected data is written to the claims system in real time via Lambda before the call ends. When the call routes to a specialist handler for complex cases, the handler opens their screen to a pre-populated claim record. They do not re-ask any question the voice agent already answered.

Compliance requirements addressed:

• The agent identifies itself as an automated system at the start of every call, satisfying FCA guidance on AI disclosure
• Vulnerable customer signals (distress indicators, mention of injury, bereavement) trigger immediate escalation with a priority flag
• All FNOL data is treated as sensitive personal data under UK GDPR, with appropriate encryption in transit and at rest

Result: Average FNOL triage call time reduced from 8.7 minutes to 5.1 minutes for calls that reach a human. For straightforward FNOL cases, 34% were handled entirely by the voice agent with no human involvement, moving directly to automated acknowledgement and next-steps communication.

Journey 3: Settlement Conversations

This was the most technically and commercially sensitive journey. Settlement calls involve presenting a financial offer to a customer and, in some cases, accepting their agreement to settle.

We scoped this carefully with the insurer's legal and compliance teams before building. The agent handles a defined subset of settlement scenarios only:

• Presenting a pre-approved settlement offer where the amount is already calculated and authorised
• Confirming the customer understands the offer and the settlement terms
• Recording verbal acceptance where the insurer's legal team confirmed this is sufficient for the claim type
• Routing to a human agent for any negotiation, dispute, or customer who requests time to consider

The agent does not calculate settlement amounts. It does not negotiate. It presents and records. This constraint was deliberate and is what made the compliance sign-off achievable.

Result: 61% of eligible settlement calls handled without agent involvement. Customer satisfaction scores on these calls averaged 4.1 out of 5, higher than the 3.8 average for equivalent human-handled calls, driven largely by shorter wait times and consistent, clear communication.

Deployment Timeline: Production in 6 Weeks

Week 1: Discovery, claims system API documentation review, compliance scoping with legal team, Amazon Connect environment provisioning in the insurer's AWS account.

Week 2: Contact flow architecture, Lex intent and slot design, Lambda function scaffolding, claims system integration build.

Week 3: Status update journey build and internal testing, FNOL flow build.

Week 4: Settlement journey build, full integration testing, security review, penetration test on API layer.

Week 5: UAT with insurer team, compliance sign-off, call recording and audit logging validation, FCA disclosure language review.

Week 6: Phased go-live. 10% of traffic on day 1, 50% by day 3, 100% by day 5. No incidents.

The Numbers at 90 Days

Total annualised cost saving based on 90-day run rate: approximately £540,000.

What Made This Work in a Regulated Environment

Insurers considering this path consistently ask the same question: how do you get compliance sign-off on an AI voice agent handling claims conversations?

The answer is architecture discipline, not persuasion.

1. The AI handles language, not decisions. Every consequential decision (claim status, settlement amount, routing logic) comes from the claims system or pre-defined rules. The AI interprets what the customer said and formats what the system returns. It does not reason about outcomes.

2. Audit trails are first-class citizens. Every interaction is logged, timestamped, and retrievable. Compliance teams can replay any call and see every system call made during it.

3. Escalation is always available and always fast. No customer is ever trapped. The escalation path is tested as rigorously as the automation path.

4. Data never leaves the insurer's AWS account. No third-party SaaS platforms. No data sharing agreements to negotiate. The insurer owns the infrastructure and the data.

Is Your Claims Operation Ready for This?

If your contact centre is handling more than 5,000 claims calls per month and more than 50% of those calls are status updates, FNOL triage, or structured settlement conversations, the economics of an Amazon Connect AI voice agent are almost certainly compelling.

We build these systems in production, in 4 to 6 weeks, inside your AWS account, with compliance built in from the first line of code.