Insurance Contact Centres Are Built on Repetition
A significant portion of any insurance contact centre's inbound volume follows predictable scripts. Policyholders checking their coverage. Claimants chasing a status update on a claim they submitted two weeks ago. Customers wanting to know their renewal date. Prospects asking for a quote.
Each interaction is individually short and low-complexity. Together they consume the bulk of contact centre capacity — capacity that could otherwise be directed toward complex claims, retention conversations, and the interactions that genuinely benefit from human expertise.
Think about what a typical Friday afternoon looks like for a mid-size personal lines insurer: two agents tied up explaining excess amounts, three more pulling up claims statuses that haven't changed since Tuesday, one handling a renewal notification for a customer who just wants to say "yes, renew it." That's six people doing work that follows a completely deterministic script. The seventh agent, the one with 12 years of experience, is waiting for the line to free up so she can get to the commercial property claim that actually needs her.
AI agents handle the predictable layer. Your team handles everything else.
Where AI Agents Add Most Value in Insurance
First Notice of Loss (FNOL) Intake
When a customer calls to report a claim, FNOL is largely data collection: what happened, when, where, what's the estimated damage, are there third parties involved, is there a police report. This follows a defined script that varies by claim type but is entirely predictable inside each type.
An agent runs the FNOL intake conversation, captures all required information according to your claim type templates, validates completeness, assigns a claim reference, and routes to the appropriate claims handler with a structured summary ready.
The handler receives a completed intake rather than spending 15 minutes on a data collection call. They can begin assessment immediately.
For straightforward, low-value claims — minor glass damage, simple theft of a defined item, small accidental damage — the agent can progress further: checking coverage, obtaining quotes, and in some cases settling directly. A home insurer running a pilot on glass-only claims found that 68% of those could be settled end-to-end without human involvement once the intake was complete and coverage confirmed. Average settlement time dropped from 4.2 days to under 6 hours.
A note we make to every insurance client: the FNOL is also where someone in distress may call. A road traffic accident. A house fire. A theft that has left someone feeling violated. Detecting that and routing to a human gently and quickly is part of the design, not an edge case. Any agent that treats emotional distress signals as a technical afterthought will create problems — regulatory, reputational, and human.
Policy and Coverage Queries
"Am I covered for X?" "What is my excess?" "Does my policy include breakdown cover?" "What is the claims limit for contents?"
These have specific answers that live in the policy document. An agent trained on your policy wordings answers them immediately and accurately, sourcing from the relevant section of the customer's actual policy.
For insurers managing hundreds of policy variants — and most mid-size carriers have far more than they realise once you factor in affinity schemes, white-label products, and vintage wordings still active on long-tail policies — this requires a retrieval system that matches the customer's specific policy type to the relevant wording. A customer on a Classic policy issued in 2021 through an affinity partner has a different wording to a customer on a Standard policy issued directly in 2024. Built correctly, the agent handles this at volume without quoting the wrong product back to someone. Built badly, it confidently gives someone the wrong answer about their cover, which creates both a complaints liability and a potential mis-selling issue.
The gap between "we've loaded our policy documents" and "we've built a retrieval system that reliably identifies the right wording for each customer" is where most off-the-shelf chatbot implementations fall apart in insurance.
Claims Status Updates
A claimant submitted a claim two weeks ago and wants to know where it stands. Currently: they call the contact centre, wait on hold, reach an agent who looks up the claim, reads the status, relays it.
An agent retrieves this in real time from your claims management system and delivers an update immediately, including any outstanding information requirements that are holding up progression. If the claim has moved to a specific stage, the agent explains what happens next. If there's an outstanding engineer appointment, the agent can confirm it or offer to reschedule it on the spot.
Volume reduction for claims status calls typically lands at 30–40% of total inbound contact for claims-heavy businesses — the single highest-impact automation in most insurance contact centres. For a commercial insurer with a large book of property claims, that reduction can free up enough handler capacity to eliminate a planned contact centre headcount increase entirely.
Renewal Management
Renewal conversations have two phases: notification (telling the customer their policy is renewing) and retention (addressing concerns and preventing cancellation).
An agent handles notification entirely — sending notices, confirming current details, processing straightforward renewals where the customer wants to continue on similar terms. For a book of 80,000 personal lines customers with renewals spread across the year, this means the agent is handling roughly 6,500–7,000 straightforward renewal confirmations every month without touching the retention team.
For customers raising price concerns or wanting to compare options, the agent captures the concern and routes to a retention specialist with full context. The retention team focuses exclusively on conversations that need persuasion, not the admin of confirming straightforward renewals. A specialist who previously handled 40 calls per day — a mix of simple confirmations and genuine retention conversations — can handle 55–60 once the confirmations are removed from their queue.
Quote Generation for Standard Products
For standard, low-complexity products — travel insurance, gadget insurance, simple contents cover — an agent can run the full quote journey: collecting the required information, calculating a premium against your rating engine, presenting the quote, and processing payment if the customer wants to proceed.
This works best for products with limited underwriting complexity. For commercial lines, complex personal lines, or anything requiring manual underwriting, the agent captures information and routes to a human underwriter. We've watched insurers push automated quotes into territory the product doesn't support — a broker that tried to automate SME liability quotes and ended up with materially mispriced risks going through without review — and the resulting risk exposure isn't worth the convenience. The correct approach is clear scoping: what products can be rated deterministically, and what products need human judgment at some point in the journey.
Document Requests
Customers regularly want policy documents, claims correspondence, no-claims discount letters, and proof of insurance certificates. Administrative requests with clear, rule-based fulfilment.
An agent handles these automatically — verifying identity, retrieving the document, sending it via the customer's preferred channel. Same-day or instant fulfilment versus the 3–5 day timelines many insurers still operate on. For a fleet manager who needs a certificate of insurance at 7am before a vehicle leaves a yard, that difference matters in a concrete operational sense.
The Compliance Architecture
Insurance is heavily regulated. FCA in the UK, state insurance commissioners in the US, IRDAI in India. An agent operating in insurance has to be built with compliance as a design requirement, not an add-on. Trying to layer compliance on after the fact rarely ends well, and it always costs more than doing it right the first time.
Regulated advice boundary. An agent can provide factual information about policy coverage. It cannot advise whether a product is suitable for a specific customer's needs — that's regulated advice requiring a qualified intermediary. The boundary has to be explicit and consistently enforced. An agent that tells a customer "yes, that policy would cover your home business" rather than "your policy covers X, Y and Z — whether that's right for your needs is something you'd need to discuss with a broker" is crossing a line that creates liability.
Claims handling obligations. AI-driven FNOL and claims triage must comply with claims handling regulations — FCA ICOBS 8 in the UK, equivalent frameworks elsewhere. The agent must not prejudice a claimant's position, must acknowledge claims within required timescales, and must escalate appropriately.
Data protection. Insurance data is sensitive personal and financial data. Processing requirements under GDPR are strict. Third-party LLM API usage must be covered by appropriate data processing agreements. When a policyholder's health data or financial history is involved in a claim, that raises the data sensitivity level further, and the processing basis needs to be explicit.
Audit trails. All interactions logged comprehensively for regulatory compliance and dispute resolution. When a claimant disputes what they were told during FNOL, the transcript is the record. When a regulator asks how a claim was handled, the audit trail is the answer.
Vulnerable customers. FCA guidance on Consumer Duty requires insurers to identify and appropriately serve vulnerable customers. An agent has to be designed to detect vulnerability signals — cognitive difficulty, emotional distress, financial hardship, bereavement — and route to a human immediately. This is where we see the most thoughtful insurers spend the most design time, and rightly so. It's also where the cheapest implementations cut corners, which is precisely where the regulator will look first when reviewing AI deployment.
The Scale of the Opportunity
For a mid-size insurer handling 50,000 inbound customer interactions per month:
| Interaction type | Monthly volume | Automatable % | Automated volume |
|---|---|---|---|
| Claims status queries | 12,000 | 90% | 10,800 |
| Policy queries | 15,000 | 75% | 11,250 |
| Renewal admin | 8,000 | 80% | 6,400 |
| Document requests | 5,000 | 95% | 4,750 |
| FNOL intake | 6,000 | 60% | 3,600 |
| Total | 46,000 | ~80% | ~36,800 |
At an average handling cost of £8 per inbound interaction, 36,800 automated interactions is around £294,400 a month in handling cost reduction. Even halve that and the ROI on the agent build is substantial. We tend to underwrite our cases at roughly half the headline number, because the headline number assumes everything works and nothing ever needs maintenance.
Off-the-Shelf vs Custom-Built for Insurance
Most insurers evaluate a generic chatbot product before commissioning a custom build. The comparison is not abstract:
| Factor | Off-the-shelf chatbot | Custom-built AI agent |
|---|---|---|
| Policy document retrieval | Generic, often uses one flat knowledge base | Retrieves against specific customer policy wording |
| Claims system integration | Rarely available; bolt-on via middleware | Direct integration with your CMS/PAS |
| Compliance controls | Generic; insurance-specific rules require customisation | Built to FCA/state regulator requirements from design |
| Vulnerable customer detection | Basic keyword triggers | Contextual detection with configurable escalation |
| Multi-product support | Limited; breaks on variant policy wordings | Built for your specific product set |
| Time to production | 4–8 weeks | 10–14 weeks |
| Build cost | Low upfront; high customisation cost over time | Higher upfront; lower ongoing customisation cost |
| Accuracy on complex queries | 50–65% without significant tuning | 85–95% with proper retrieval design |
The typical pattern: an insurer buys an off-the-shelf product, spends 6 months customising it to meet compliance requirements, and ends up with something that still doesn't handle multi-variant policy retrieval well. Total cost and time to value often exceed a custom build, with lower accuracy.
What to Expect in Practice
The build is the straightforward part. The harder work is integration and testing — particularly in insurance, where legacy policy administration systems and claims management platforms vary enormously in their API availability and data structure.
A realistic implementation for a mid-size insurer with three core products, integration to a PAS and a claims system, and deployment across web chat and phone:
- Weeks 1–3 are spent on data architecture and compliance design. What data does the agent need access to, how is it processed, where does it live, what are the DPA obligations. You cannot skip this or compress it.
- Weeks 4–7 build and integrate. The integration work almost always surfaces data quality issues in the PAS that weren't visible before — claims statuses stored inconsistently, policy variant codes that don't map cleanly to wordings, customer records with address mismatches.
- Weeks 8–9 are compliance review and testing. Vulnerable customer detection is scenario-tested manually. The regulated advice boundary is red-team tested. FNOL handling is tested against claims handling regulations.
- Week 10 is a controlled pilot — typically 5–10% of live traffic with human monitoring of every conversation. This is non-negotiable in insurance. The failure modes that appear in live traffic are not the ones you anticipated in testing.
- Weeks 11–14 are phased rollout, with volume increasing as confidence in accuracy and compliance builds.
What Can Go Wrong
Wrong retrieval, confident answer. An agent that pulls the wrong policy wording and answers a coverage question with certainty has created a potential liability. A customer who acts on that answer — doesn't buy a separate product, doesn't take a precaution — and then finds out the claim isn't covered will complain. If the agent said it clearly enough, the insurer may be liable. The retrieval architecture is not a technical detail; it's a risk management issue.
Scope creep into regulated advice. Teams often want the agent to do more than it should — to tell a customer whether a policy is a good fit for their situation rather than just describing what it covers. The boundary erodes gradually, usually through well-intentioned attempts to be helpful. It needs to be maintained actively, not set once.
Distress not detected. An agent that routes a customer calling in the aftermath of a serious accident through a standard FNOL script without detecting distress will create a complaint and potentially a breach of Consumer Duty obligations. Detection has to be sensitive. Over-detection (routing everyone who sounds slightly worried) is inefficient but manageable. Under-detection is the regulatory risk.
Integration failures at volume. The claims system returns an error at peak load. The PAS goes into maintenance mode at 2am. The agent needs defined fallback behaviour for every integration failure scenario. What does it say? How does it route? Insurers that don't test failure scenarios in production find out what happens the hard way.
Assuming automation rates from day one. The 80% automation rate is achievable, but not in week one. It builds over 3–6 months as edge cases are identified and handled, as the agent learns what it doesn't know and escalates appropriately, and as the team tunes escalation thresholds. Anyone promising you 80% automation from launch is selling a number, not a plan.
Implementation Timeline for Insurance
Insurance projects require more careful compliance and testing work than most:
- Week 1–3: Regulatory review, compliance framework, data handling design, scope definition
- Week 4–7: Build and integrate with policy administration system, claims management system, and communication channels
- Week 8–9: Compliance review and testing including vulnerable customer detection and regulated advice boundary testing
- Week 10: Controlled pilot with monitoring
- Week 11–14: Phased production rollout
Related guides
- AI agents for financial services
- AI agents for retail banking
- AI agent security: what business owners need to know
- AI agents for customer support
- Our AI agent development services
Talk to us about your contact centre — we build insurance agents with compliance architecture in from the design stage, and we'll tell you upfront where automation isn't appropriate for your specific product set.
Frequently Asked Questions
Can an AI agent handle the full claims process, or just the initial intake?
Most AI agents are best suited to FNOL intake, status updates, and document handling rather than the full claims lifecycle. Simple, low-value claims — glass damage, defined item theft — can sometimes be settled end-to-end by an agent once coverage is confirmed. Complex or high-value claims, anything requiring an adjuster or engineer, or disputes will always need a human. The agent's role is to remove the administrative volume so your claims handlers can focus on assessment and resolution.
How does the agent stay compliant with FCA Consumer Duty requirements?
Consumer Duty compliance has to be designed in from the start, not bolted on. Specifically, this means building explicit detection for vulnerable customer signals with immediate routing to human agents, maintaining a clear and enforced boundary between factual coverage information and regulated advice, logging all interactions with timestamps for audit purposes, and testing escalation behaviour against defined scenarios before go-live. A generic chatbot with a compliance checkbox checked is not the same thing.
What systems does an AI agent need to integrate with in an insurance business?
At minimum: your policy administration system (to pull customer and policy data), your claims management system (for status and progress updates), and your communication channels (web chat, phone via telephony integration, email, or SMS). Document management is often a separate integration. The complexity and timeline of the build depends heavily on the API availability and data quality of your existing systems — legacy PAS platforms in particular often require middleware layers.
How accurate is the agent at answering policy coverage questions?
Accuracy depends almost entirely on the quality of the retrieval architecture. An agent that searches across your full policy document library without matching to the customer's specific product and policy version will give wrong answers. Built correctly — with a retrieval system that identifies the customer's exact policy wording — accuracy for factual coverage questions typically runs at 85–95% in production. The 5–15% that aren't handled are escalated to a human rather than answered incorrectly.
Is there a minimum book size where this makes financial sense?
For a pure cost-reduction case, most insurers need at least 15,000–20,000 inbound customer interactions per month for the build cost to pay back in a reasonable timeframe. Below that, a well-designed chatbot product with custom integration may be more appropriate than a full custom build. The threshold is lower if you're also accounting for quality improvements — faster claims resolution, consistent coverage answers, instant document fulfilment — not just headcount cost reduction.
How long before the agent is handling a meaningful share of contact volume?
Realistically, 3–6 months from go-live to reach steady-state automation rates. The first weeks in production surface edge cases and failure scenarios that weren't visible in testing. Escalation thresholds need tuning. The team needs time to trust the handoffs the agent passes them. Insurers that expect 80% automation from week one are usually disappointed. Insurers that plan for a 3-month ramp see steadier and more durable results.
What happens when the agent gets something wrong?
Every agent interaction should have a defined fallback: when the agent is uncertain, it escalates rather than guesses. When the system it's querying returns an error, it has a scripted response. When a customer is dissatisfied with the answer, there's a clear path to a human. The agent also needs to be monitored continuously — not just during the pilot. Coverage question accuracy, escalation rate, and customer satisfaction signals should be reviewed weekly in the first three months and monthly thereafter. An agent that isn't monitored will drift.