AN AI AGENT THAT ANSWERS THE PHONE, NO WAITING
"Amanda" is a voice & WhatsApp AI agent that lodges a First Notice of Loss (FNOL) insurance claim without a customer ever waiting in a human queue. Built solo, end-to-end, in days - not a production system, but a working demonstration of the value case.
THE PHONES DON'T STOP RINGING IN A CATASTROPHE.
A major storm or typhoon can hit thousands of customers in a single night. Every one of them wants to lodge a claim at once, and a human contact centre has a hard ceiling on how many calls it can answer in parallel - exactly when demand spikes hardest.
"An AI agent doesn't have a queue. Every customer who calls gets a lodgement officer immediately - the same night as the event, not three days later when call volumes finally clear."
That's the upside this PoC is built to prove: lodgement capacity that scales with the event, not with headcount. On a normal day, it's a faster, always-on front door. On the worst night of the year, it's the difference between every affected customer being heard immediately versus sitting on hold.
MEET AMANDA, THE CLAIMS LODGEMENT OFFICER.
A caller - or a WhatsApp user - talks to an AI agent that greets them, works out whether they're lodging a new claim, and figures out if it's a vehicle claim (by registration) or a property claim (by address). From there, Amanda collects everything the claim needs, either by asking one question at a time, or by parsing it all in one go if the customer volunteers it up front.
Amanda closes every call with a fixed line once the required fields are gathered. She never says the claim was "lodged," never issues a claim number, and never promises an email; a deliberate boundary separating the Voice Agent from downstream policy verifications.
-
01
Guided or Express Lodgement Asks fields one-by-one, or parses everything a talkative customer volunteers up front.
-
02
Name Confirmation, Voice Only Spells back the customer's name on calls; skipped on WhatsApp, where typed text is already exact.
-
03
Vehicle or Property, Auto-Detected Works out claim type from what the customer says, then asks for the right fields - registration vs. address.
-
04
A Fixed, Deliberate Sign-Off Ends on the same closing line every time - no ad-libbed promises about what happens next.
CALL OR WHATSAPP
Customer reaches Amanda instead of a human queue, on the phone or via WhatsApp.
AI LODGEMENT CONVERSATION
Amanda determines claim type, collects required fields, and handles edge cases along the way.
WEBHOOK HANDOFF
ElevenLabs emails the transcript and associated LLM Evals, retaining it for training and quality purposes.
HUMAN REVIEW & POLICY CHECK
Summary + transcript land in the workflow, triggering the policy cross-check before lodgement into the core claims system.
Today, this app emails the call transcript, LLM evaluations, and summary to a downstream lodgement Agent for review before lodgement into the core claims system.
THE POLICY CHECK IS THE GATE, NOT THE AGENT.
An AI agent lodging a claim doesn't mean an AI agent decides what's covered. Everything Amanda collects still passes through the core claims platform's own verification step, which cross-references the claim against a real policy number and its policy information. If that doesn't validate, the claim cannot proceed - full stop.
The agent's job is to have a good conversation and capture accurate information. The policy platform's job is to decide, deterministically, whether that information is real. The AI never gets to skip that gate.
For this PoC, that means customers still need to supply real, specific policy information for the demo to validate end-to-end. Below is the fictional test data used to exercise both branches of the flow:
| POLICY NUMBER | TYPE | TEST DETAILS |
|---|---|---|
| 06H000011801 | Property | 49 Limestone Ave, Braddon |
| 06H000101902 | Property | 68 Dangarsleigh Road, Armidale |
| 24C607708501 | Motor | Rego 122ABC12 · 2020 Peugeot 363 32 · Incident at Unit 4/12 The Esplanade, Perth WA 6000 |
Test data only - no real customer or policy information. Used solely to demonstrate the validate/reject branches of the policy gate.
KNOWING WHEN NOT TO BE AN AGENT.
An always-on agent needs to recognise when it shouldn't try to help. The most important guardrail: if a caller describes a life-threatening emergency, Amanda doesn't attempt to lodge anything - she ends the call and redirects the person to 000.
-
01
Emergencies Ends the call and redirects to 000 - no lodgement is attempted.
-
02
Wrong Numbers & Non-Claims Recognises when a caller isn't there to lodge a claim, and doesn't force the flow.
-
03
Small Talk & Unresponsive Callers Handles tangents gracefully and disengages cleanly if a caller goes quiet.
-
04
WhatsApp Session Timeouts Manages chat sessions that go idle without leaving a claim half-collected.
Right now, the agent itself decides when the interaction is "complete" - there's no external enforcement of that boundary. Getting this to production means adding real state management around the conversation, rather than trusting the model's own judgement of when it's done. GCP's GXAS Phone Agent slot-filling pattern is the reference point for how to do that properly.
WHERE THE POC STOPS, ON PURPOSE.
This is a proof of concept and evaluation artifact, not a production system - and it's built that way deliberately, to test the idea fast and cheaply before committing real engineering investment. It covers the "front door" (the conversational agent) and the microservice that gets structured data out of ElevenLabs' webhook. Nothing more.
ElevenLabs was chosen specifically for how quickly it integrates with WhatsApp phone numbers - the point of this build was proving the concept with minimal friction, not picking the most feature-complete platform on paper. The formal evaluation of whether this architecture is viable beyond a PoC lives in ADR 0004 in the repo.
READ THE CODE.
Full source, the ElevenLabs agent config, the webhook microservice are all in the repo.