The Challenge
Twenty-two minutes. That's how long an average First Notice of Loss (FNOL) call takes in UK insurance.
Not because the claim is complex. Because the process is. A claims handler asks the same questions, types the same fields into the same CMS, and generates the same intake record 200 times a week, 70+ person-hours of purely administrative work. The founding team at ClaimBot two former claims adjusters had spent years inside this process and knew the inefficiency wasn't a technology problem. It was an architecture problem. The phone call was doing three jobs simultaneously: gathering structured data, providing customer guidance, and creating a compliance record. No single tool addressed all three. So handlers did it manually, every time, for every claim.
Three compounding problems made it unsustainable.
The first was timing. 40% of claim events happen outside business hours. A kitchen fire at 11 PM. A rear-end collision at 6 AM on a Sunday. Without a 24/7 intake channel, customers waited until Monday morning to report. Every hour of delay degraded their recall, introduced missing details, and inflated the eventual settlement timeline. The broker paid for that delay in data quality.
The second was regulatory. The FCA's Consumer Duty framework, effective since July 2023, requires UK insurers to demonstrate they provided clear, timely information at key points in the claims journey. A phone call between a handler and a customer produces no structured record of what was communicated and when. Every unrecorded interaction was a compliance gap the FCA could flag during audit. Not compliance theatre a real, auditable gap with real regulatory consequences.
The third was handoff. When a claim transferred from the intake handler to a specialist, context passed through informal notes half-complete, sometimes contradictory. The customer repeated everything. The specialist missed details. The handoff was where claims stalled, where data degraded, and where customer satisfaction dropped.
The founders came to TechEniac with a specific requirement: build a chatbot that handles the entire FNOL process 24/7, across web and phone without human involvement for standard claims. Not a call deflector. Not an FAQ bot. A chatbot that collects every required field, validates the data, processes document uploads, pushes structured records into the broker's CMS, and generates an FCA-compliant communication record. Automatically. For every claim.
And it needed to work with both Guidewire ClaimCenter and Duck Creek Claims the two legacy CMS platforms their target brokers relied on.
Product Discovery & Architecture Design
TechEniac spent the first three weeks mapping the actual claims intake workflow not the documented process, but the real one. The team sat with claims handlers, listened to intake calls, and traced every question, every branching path, and every point where the process broke down.
The discovery revealed five problems that a standard chatbot framework couldn't solve:
Claims intake branches by claim type. A motor claim asks about vehicles, drivers, and third parties. A property claim asks about damage extent and emergency services. A travel claim asks about destinations and medical treatment. The chatbot needed a dynamic questionnaire that adapts in real-time not a fixed script.
Customers give incomplete answers. "When did it happen?,Last week sometime." A standard chatbot would loop endlessly on required fields. The production chatbot needed to handle ambiguity confirm what it could, flag what it couldn't, and keep moving.
Documents arrive mid-conversation. Customers upload damage photos, police reports, and medical certificates while chatting. The system needed to process these in real-time extracting structured data and appending it to the claim record without breaking the conversation.
Two CMS platforms with incompatible APIs. Guidewire uses REST. Duck Creek uses SOAP. Field names differ. Validation rules differ. The integration layer needed to normalise chatbot output into two different schemas and handle API failures gracefully.
Voice and chat must use the same engine. Building two separate agents would mean maintaining two conversation flows, two prompt architectures, and two integration layers. One conversational agent needed to power both channels with voice-specific adaptations layered on top.
TechEniac selected Claude Sonnet as the base LLM for its superior instruction-following and low hallucination rate in structured data extraction critical when every field feeds directly into a regulated CMS. The architecture: LangChain orchestration, dynamic FNOL questionnaire engine, Google Cloud Vision for document processing, Twilio and Whisper for voice, and bi-directional CMS integration with both Guidewire and Duck Creek.
Technical Solution
Conversational Claims Intake Agent
A multi-turn conversational agent built on LangChain with Claude Sonnet designed to guide customers through a complete FNOL without human involvement for standard claim types.
A structured entity extraction schema defines required fields per claim type: motor, property, travel, and liability. When a customer initiates a claim, the agent identifies the type from the opening exchanges and loads the corresponding questionnaire. Questions adapt dynamically a motor claim involving a third party triggers liability questions. A property claim mentioning fire triggers emergency services and accommodation questions.
The agent validates every data point in real-time. Dates are parsed and normalised. Postcodes validate against Royal Mail format. Policy numbers check against the broker's active policy database. A maximum retry counter of 3 attempts per field prevents looping on confused or evasive responses after 3 attempts, the field is marked pending and the claim continues.
69% of standard claims processed entirely by AI. 31% escalated for complex cases multi-party disputes, injury claims, and situations requiring specialist judgment.
Document Collection & OCR Pipeline
During the conversation, customers upload damage photos, police reports, medical certificates, and receipts from their mobile browser. Documents process in real-time through Google Cloud Vision OCR extracting dates, amounts, reference numbers, and vehicle details and appending structured data to the claim record.
For motor claims, a damage assessment model analyses uploaded photos and estimates severity: cosmetic, moderate, severe, or write-off. This assessment is included in the claim record, helping brokers prioritise review workflows.
The pipeline runs asynchronously. The conversation continues while documents process in the background. The customer never waits for OCR to complete.
FCA-Compliant Communication Record Generator
Every interaction web or voice automatically generates a timestamped Customer Communication Record documenting every question asked, every customer answer captured verbatim, every piece of information provided to the customer, and the final structured claim data.
Records are stored in an immutable audit log with SHA-256 cryptographic hash verification. Once written, records cannot be modified or deleted satisfying FCA audit requirements under the Consumer Duty framework.
This is the record that proves the broker communicated clearly, captured data accurately, and informed the customer appropriately exactly what the FCA examines during audit. Phone-based intake couldn't produce this. ClaimBot generates it automatically for every claim.
100% FCA compliance across all AI-handled claims.
CMS Integration Layer (Guidewire & Duck Creek)
When intake completes, structured claim data pushes automatically to the broker's CMS creating a new record with all fields pre-populated.
A bi-directional integration layer handles REST adapters for Guidewire ClaimCenter and SOAP adapters for Duck Creek Claims. A normalisation layer translates the chatbot's unified data schema into each platform's specific field mapping and validation rules. In the opposite direction, webhook listeners pull claim status updates from the CMS into the customer-facing portal.
A submission queue with configurable rate limiting (max 10 API calls/second) handles Guidewire's rate limits. Exponential backoff on 429 errors and a dead-letter queue for failed submissions ensure no claim data is lost even during CMS downtime.
94% of AI-collected intake fields passed CMS validation on first submission without human correction.
Voice Claims Channel
Phone-based claims reporting using Twilio Voice for call routing, Whisper for real-time speech-to-text, and ElevenLabs for natural-sounding responses.
The voice agent uses the same LangChain engine as web chat same questions, same validation, same CMS integration. Voice-specific adaptations layer on top: shorter conversational turns, explicit confirmation after every data point, and hold music during CMS operations.
A phonetic normalisation layer addresses Whisper's tendency to mishear alphanumeric strings. Policy numbers like "BRK-2025-78432" were frequently transcribed incorrectly. Post-transcription normalisation maps common error patterns and validates against the policy number regex. If validation fails, the agent asks the customer to spell character by character resolving 98% of remaining mismatches.
The customer hears a natural voice. The broker receives a structured, validated claim record identical to web chat output.
"Can we add phone intake?" The answer was "it already works." A configuration change, not a rebuild.
Key Engineering Challenges
Challenge 1
Agent Looping on Evasive Responses
During testing, the agent looped indefinitely when customers gave genuinely confused answers. "I don't remember exactly" repeated three times produced three rephrased versions of the same question frustrating the customer without resolving the gap.
TechEniac implemented a 3-attempt retry limit per field. After 3 attempts, the field is marked pending, the agent acknowledges the gap naturally ("We'll follow up on that detail separately"), and the intake continues. The claim flags for human review on the pending field only the rest of the data is preserved.
The intake completes in under 5 minutes even when some fields are unresolved.
Challenge 2
Guidewire Rate Limiting During Storm Events
During peak claim periods storm damage, flooding ClaimBot processes dozens of claims simultaneously. Guidewire's API rate limits were consistently exceeded during simulated surge events.
TechEniac built a submission queue capped at 10 API calls per second with exponential backoff and jitter on 429 errors. Submissions exhausting all retries route to a dead-letter queue for manual review.
During a simulated storm-surge with 50 simultaneous claims, zero submissions were lost. All claims pushed successfully within 12 minutes.
Challenge 3
Voice Transcript Errors on Policy Numbers
Whisper consistently misheard alphanumeric reference numbers "BRK-2025-78432" became "BRK twenty twenty-five seventy-eight four three two." These transcription errors cascaded through the entire claim record, corrupting the CMS lookup and breaking policy validation.
TechEniac added a post-transcription phonetic normalisation layer that reconstructs probable reference formats and validates against the broker's policy number regex. If the first pass fails, the voice agent falls back to character-by-character spelling asking the customer to read each character individually.
98% of policy number mismatches resolved without human intervention.