The situation
The client is a regional property & casualty carrier writing auto and homeowners policies across a mid-Atlantic footprint, including a coastal territory that generates a heavy seasonal spike in weather-related claims. First notice of loss (FNOL), the initial report a policyholder makes when something has happened, came in through a 24-hour call center staffed thinly overnight, and the client's own quality review had found that overnight FNOL reports were measurably less complete than daytime ones: fewer details about the sequence of events, less consistent capture of other parties involved, and photo or documentation requests that frequently didn't get followed up on until the policyholder called back days later, frustrated.
This mattered beyond customer experience: incomplete initial reports made the adjuster's first substantive call with the policyholder less efficient, sometimes requiring policyholders to re-explain a stressful event from scratch, and occasionally led to details that mattered for coverage determination being missed entirely until much later in the claims process.
Why off-the-shelf didn't fit
Several insurtech vendors offer FNOL chatbots and IVR-style intake systems, and the client had evaluated two. Both were built around structured, menu-driven intake, pressing or saying a number for the type of claim and then answering a fixed sequence of questions, which worked adequately for the simplest, most common claim type (a straightforward auto fender-bender) but handled poorly the messier, more emotionally charged calls that made up a meaningful share of overnight volume: a homeowner reporting storm damage while still assessing it in real time, a policyholder involved in a more serious accident who was shaken and not answering questions in the expected order. Rigid menu-driven systems either forced these callers through an ill-fitting script or bailed out to a human immediately, which mostly recreated the original problem for exactly the calls where a good structured report mattered most.
Scoping the real workflow
We scoped this one by listening, with the client's permission and existing call-recording consent framework already in place, to a sample of 50 real overnight FNOL calls, spanning both straightforward and difficult cases, alongside two senior claims adjusters who narrated what information they wished had been captured at intake versus what they typically had to chase down later. That exercise produced a clear, prioritized information model: certain facts (date, time, location, parties involved, general description, whether anyone was injured, whether emergency services were called) needed to be captured on every claim regardless of type, while other detail requirements branched by claim type in ways the adjusters could articulate precisely once asked directly.
What we built
The agent answers the FNOL line (and a web-based intake form, for policyholders who prefer not to call) at any hour, conducting a conversational intake that adapts to how the policyholder is actually communicating rather than forcing a fixed script. If someone starts by describing what happened in their own words, the agent extracts the structured facts it can from that narrative and only asks follow-up questions for what's genuinely missing, rather than re-asking things the caller already said. It captures the full required information model for the relevant claim type, requests photos or documentation where applicable with clear, specific instructions (which angles, which documents), and creates a structured claim file in the client's existing claims management system before the call even ends, tagged with an urgency flag for cases involving injury, uninhabitable property damage, or other time-sensitive circumstances so those route to an on-call adjuster immediately rather than waiting for the next business day.
Critically, the agent does not make any coverage determination or promise about claim outcomes. It is explicitly scoped and prompted to gather facts and route the claim, never to tell a policyholder whether something is covered, which stays entirely with a licensed adjuster. This boundary was a specific, written requirement from the client's legal and compliance team, and one we agreed with independently, since coverage determination requires a license and carries regulatory obligations we were not going to build an agent to simulate.
Where it got hard
Handling genuinely distressed callers well was both the most important and the hardest part of this build, and it's not a purely technical problem. Some overnight callers, someone who's just been in an accident or someone watching water come into their home during a storm, are not in a state to answer methodical questions, and a system that pushes forward with its checklist regardless of emotional context reads as callous, which is exactly the kind of thing that erodes trust in an insurer at the worst possible moment. We built explicit handling for this: the agent is prompted to recognize distress signals in the conversation and shift into a slower, more acknowledging register, explicitly offering an immediate warm transfer to a live on-call adjuster for anyone who wants one, at any point, with no obstacles. We tested this extensively with the claims team role-playing distressed-caller scenarios before launch, and revised the agent's response patterns twice based on adjuster feedback that early versions still felt too procedural in emotionally heavy moments.
The urgency-flagging logic for injury and uninhabitability also needed more conservative tuning than our first pass: we initially set the threshold for flagging a case as urgent fairly narrowly (to avoid over-flagging and burning out the on-call adjuster rotation), and the claims team pushed back firmly that the cost of under-flagging a genuinely urgent case was so much higher than the cost of an unnecessary page that we should tune toward over-flagging instead. We rebuilt the threshold accordingly and consider that adjustment one of the more important changes made during the entire build.
Rollout & results
FNOL reports meeting the client's full completeness standard rose from 61% to 84% in the first quarter post-launch, and adjuster follow-up calls made solely to gather information missing from the initial report dropped 41%. Overnight and weekend FNOL volume, previously the weakest-performing segment on completeness, became statistically indistinguishable from daytime, staffed-call completeness within two months.
"The number I actually cared about wasn't the completeness stat, it was whether policyholders having the worst night of their year felt heard. Getting the escalation and distress-handling logic right took longer than the rest of the build combined, and it was worth every extra week." Head of Claims Operations, client engagement
What we'd do differently
We'd bring claims adjusters into distress-scenario testing in week one rather than week four. We initially treated the emotional-handling logic as a refinement layer on top of a functionally complete intake flow, when for this specific workflow it was arguably the core requirement, not a refinement. On any customer-facing agent handling reports of loss, harm, or distress, we now scope emotional-response testing as a first-class deliverable alongside functional completeness, not an afterthought.