Main site

Insurance AI agent · FNOL

FNOL-Intake & Routing AI Agent

Take first notice of loss on any channel, match it to the policy in force at the date of loss, capture the facts and route it — and state no coverage position.

Typical delivery
4–6 weeks
Deployment
Your stack
Coverage position
Person only
After launch
Agent Care

What this agent does

Opens the claim, never the coverage

In

  1. 01

    Take the notice as it arrives — phone, portal, app, broker or email — and keep the words the notifier used.

  2. 02

    Find the policy and the period in force at the date of loss, endorsements, lapse and cancellation included.

Reason

  1. 03

    Capture what happened, when and where, the property or vehicle involved, and everyone else who was there.

  2. 04

    Ask about injuries, third parties, witnesses and emergency services, and record the answers as given.

  3. 05

    Raise total-loss, catastrophe, liability and vulnerability indicators, and check for a claim already open.

Decide

  1. 06

    Where the policy matches and no indicator fires, the claim opens and routes to the queue that owns it.

  2. 07

    Injury, distress, a policy that will not match or any question about cover goes to a person at once.

Out

  1. 08

    Open the claim, timestamp the notice, send the acknowledgement you approved, and request what is missing.

  2. 09

    Retain the channel, the words used, the policy version read, the indicators raised and the queue it went to.

Product statement

The agent captures, checks the policy was in force and routes. It states no coverage position — not on the call, not in the portal, not in the acknowledgement — and anything that sounds like one belongs to a person.

Example workflow

One notice, end to end

  1. 1Notice receivedA call, a portal or app submission, a broker notification or an email, with the channel and the time it arrived
  2. 2Policy matched at the date of lossCover, period, endorsements, lapse and cancellation as they stood, and whether more than one policy could respond
  3. 3Loss facts capturedWhat happened, when and where, the property or vehicle, third parties, injuries and emergency services attending
  4. 4Indicators checkedInjury, liability, total-loss, catastrophe, duplicate and vulnerability flags, and the documents still outstanding

No human action required

Stages 1 to 4 run without a person in the loop — the policy match, the loss facts and the indicator checks are finished before anything is opened. Nothing has been said about cover.

5DecisionSplits on whether the policy matched and no indicator needs a person
Policy matched, nothing flagged

Opens and routes to the owning queue.

Injury, distress or a coverage question

Goes to a person, on the spot.

Claims handler

Takes the notice while the notifier is still there where the channel allows, with the flags named and the policy as read. Anything about cover is theirs.

Open · Correct · Escalate

Handled — handed back

  1. 6Claim opened and routedTimestamped, acknowledged on your approved template, and sent to the queue that owns that claim type
  2. 7Outcome evaluatedPolicy-match accuracy, capture completeness, duplicates, escalation appropriateness and time to open, by channel and language

Handler changes

Every field a handler corrects after intake is counted, by channel.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Telling a claimant whether the loss is covered.
    • Denying, declining or closing a notified claim.
    • Advising on excess, limits or likely settlement.
    • Recording a reported loss as anything but a claim.

  • Automation boundary

    Agent acts unaided

    • ✓Match the policy and the period in force at the date of loss.
    • ✓Capture the loss facts, parties and injuries as the notifier gives them.
    • ✓Raise total-loss, catastrophe, duplicate and vulnerability indicators.
    • ✓Open the claim, acknowledge on your template and route to the owning queue.

    Write actions run only inside the approval boundaries agreed during implementation. Opening and routing a claim is one of them; saying anything about cover is not, on any tier.

    • Handling an injured, bereaved or distressed caller alone.
    • Taking a recorded statement about fault or liability.
    • Promising a repairer, hire car or benefit entitlement.
  • Changing routing rules, indicators or escalation triggers.

Example output

One notice of loss, annotated

Everything the agent records is attached to the channel and the policy version it came from.

FNOL output · single notice

Illustrative example
Channel
Out-of-hours call
Policy at loss date
In force, endorsed
Reported
Escape of water
Routed to
Property — mitigation
Confidence
93%
Coverage position
None — a handler's

As received

The notice as it was given, on the channel it arrived, with the time of receipt and the policy as it stood that day.

Checks cleared

  • Policy in force at loss
  • No open claim on file
  • No injury reported

Why this queue

From the peril, the indicators and your routing rules — not from any view about cover.

What the score decides

Whether the capture may route unattended. It decides nothing about cover.

Action

OpenCorrectEscalate

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every notice of loss

From phone, portal, app, broker and email

03Policy & period

Match the policy and period in force that day

Cover, period, endorsements, lapse and cancellation as they stood on the date of loss — read at intake and stamped with the version.

01Approved path

Capture it once, properly

The facts an adjuster will need are asked for while the notifier is still there, on every channel, so the file opens complete rather than half-built.

02Human review

Hand the hard notices over early

An injury, a death, a shaken caller or a policy that will not match reaches a person straight away — not after the claim has been opened against the wrong cover.

04

Build an evidence trail

Retain the channel and the words used, the policy version read, the indicators raised, the acknowledgement sent and the queue it went to — on both paths.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Policy admin & claims

    • Guidewire
    • Duck Creek
    • Sapiens
    • Majesco
    • Policy and claim APIs

  • Voice & messaging

    • Telephony and IVR
    • chat, SMS and WhatsApp
    • Transcription
    • call recording

  • Portal, app & broker

    • Policyholder portal
    • mobile app
    • Broker and MGA feeds
    • web forms

Agent

FNOL intake & routing

  • Captures the notice
  • Matches the policy
  • Routes the claim

  • Evidence & assistance

    • Photo capture
    • document upload
    • Make-safe dispatch
    • CAT event feeds

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the model and the claim file

Each control wraps the one inside it. A notice clears every layer before a claim is opened, and a coverage position never clears them at all.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeReturn intake on a channel to staff if capture or routing degrades.Roll back
L5TraceabilityRecord the channel, the words used, the policy version and the route.Record
L4Escalation gateInjury, death, distress and vulnerability reach a person immediately.Escalate
L3No-coverage ruleNo coverage position, no excess figure, no view on who was at fault.Withhold
L2Capture completenessThe required fields for that claim type, or the notice does not route.Require
L1Policy match checkThe policy and period in force at the date of loss, or no match at all.Verify
Model coreCaptured notice — the policy matched at the date of loss, the loss facts, the indicators raised and confidence
L1 – L2
Decide whether the notice may route
L3
Keeps a coverage position out of the agent
L4
Puts the hard notices in front of a person
L5 – L6
Keep the trail and pull automation back

How Nestack evaluates it

Evaluate the capture — and what the adjuster had to chase.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the acknowledgement the claimant receives

  1. E1Final-output evaluationWas the claim opened against the right policy and the right period?
  2. E2Capture evaluationDid the file hold what the adjuster later had to go back and ask for?
  3. E3Tool evaluationDid it read the right policy record and open one claim, not two?
  4. E4Escalation evaluationDid injury, distress and vulnerability reach a person, and how quickly?
  5. E5Slice evaluationHow does performance change across channels, languages and claim types?
  6. E6Business outcomeTime to claim open, rework after first touch, and complaints about intake.

Floor — the claim file the adjuster inherits

Failure modes

Where each failure originates in the agent

Seven failure modes plotted against the five stages of the agent lifecycle.

Agent lifecycle

Direction of processing →

  1. 01 · Intake

    2 modes

    • FN-01

      Date of loss taken wrong

      Recorded as the day reported, not the day of loss.

    • FN-02

      Distress met with a script

      A shaken or bereaved caller gets the routine path.

    Stage captures

    The notice as given, on the channel it arrived

  2. 02 · Policy match

    1 mode

    • FN-03

      Wrong policy or period matched

      Cover read as it stands now, not at the loss.

    Stage matches

    The policy and period in force at the date of loss

  3. 03 · Triage

    2 modes

    • FN-04

      Injury or third party missed

      A liability exposure opens as a property claim.

    • FN-05

      Total loss or CAT not flagged

      The claim misses the surge path and the event code.

    Stage flags

    Injury, severity, catastrophe and vulnerability

  4. 04 · Open & route

    1 mode

    • FN-06

      Duplicate opened on one loss

      The same loss notified again on another channel.

    Stage routes

    The claim record, the acknowledgement, the queue

  5. 05 · Drift / Version

    1 mode

    • FN-07

      One channel quietly degrades

      Capture slips on one channel, and in one language.

    Stage tracks

    Rules, channels and how capture holds up

  • Sev-1 · wrong at first contact, and it sticks
  • Sev-2 · the file is thin or wrongly queued
  • Sev-3 · found later, at the claimant's cost
See the complete Insurance failure-mode catalogue

Affected slices

The worst capture draws the fewest complaints

A few channel and language cohorts carry most of the missing fields, and they are the cohorts least likely to complain about it. Routing built from channel, postcode or claim history stands in for who the claimant is. Nestack reports performance by slice, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Non-native-speaker callers6.6%3.8×Review
Out-of-hours phone notices5.1%2.9×Review
Broker-notified losses3.3%1.9×Watch
Repeat routine motor claims1.2%0.7×Normal

Bar: missed-capture lift vs. routine motor-claim baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

Every field the adjuster chased is a capture defect

The first thing an adjuster does with a thin file is telephone the claimant again. That second call is the measurement, and it belongs to the intake that caused it.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    A slice starts losing fields, duplicating notices or missing escalations.

  2. 02

    Diagnose

    The question set, the policy match, the indicators or the channel — one of them.

  3. 03

    Improve

    A question, a match rule or a routing rule changes — signed by the claims officer, dated and versioned.

  4. 04

    Verify

    Replayed over held-back notices, and over every file an adjuster had to reopen.

  5. 05

    Learn

    The chased field becomes a required capture, and a case the next release must pass.

  6. Learn → Detect

    The return edge. Every cycle also re-reads the escalation triggers — a distressed caller the agent kept to itself means the trigger was wrong, not the caller.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, channels and policy matching, capture and escalation rules, evaluation, routing and live intake, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Workflow discovery and automation-boundary definition.Week 1
  2. 02Channel inventory and intake-path mapping.Week 1, Week 2
  3. 03Policy admin and claims API assessment.Week 1, Week 2
  4. 04Policy-at-loss-date and in-force checks.Week 2
  5. 05Question sets and capture rules by claim type.Week 2, Week 3
  6. 06Injury, third-party and liability capture.Week 3
  7. 07Total-loss, catastrophe and duplicate flags.Week 3, Week 4
  8. 08Distress and vulnerability escalation triggers.Week 3, Week 4
  9. 09Acknowledgement wording and notice sign-off.Week 4
  10. 10Capture and escalation evaluation.Week 4, Week 5
  11. 11Routing rules, queue ownership and claim opening.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne channel, one claim typeProductionLive intake on one lineAdvancedAll channels / multi-line
Introduced at Pilot
Policy-at-loss-date matching✓✓✓
Structured loss capture✓✓✓
Escalation to a person✓✓✓
Shadow mode — captures, opens nothing✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Claim opening and acknowledgement—✓✓
Injury and third-party capture—✓✓
Duplicate and prior-claim checks—✓✓
Routing rules and queue ownership—✓✓
Introduced at Advanced
Catastrophe surge handling——✓
Multi-channel and enterprise controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on the channels and lines in scope, the policy and claims systems involved, telephony and messaging integrations, notice volume, escalation and routing controls, and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Every channel a loss can arrive on today

    Workflow discovery, channel inventory and the automation boundary

    Week 1

  2. 02Access to policy admin and claims, endorsements included

    Policy-at-loss-date matching and in-force checks

    Week 2

  3. 03The fields your adjusters actually need, by claim type

    Question sets, capture rules and the indicators that fire

    Week 3

  4. 04Your policy on injury, distress and vulnerable customers

    Escalation triggers and the route to a person

    Week 3

  5. 05Your acknowledgement wording, and what may never be said

    Notice templates and the no-coverage rule

    Week 4

  6. 06Recent notices, including the reopened and the duplicated

    Evaluation suite, regression cases and failure-mode testing

    Week 4

  7. 07Named handlers and the queue that owns each claim type

    Routing rules, queue ownership and live intake

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Phases are drawn over the weeks they actually occupy. Nothing is opened in your claims system before week 6 — intake runs alongside your handlers until then.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Channels in scope, escalation policy and who owns each queue

W2Policy-at-loss-date matching and in-force checks

W3Capture rules, injury questions and escalation triggers

W4Acknowledgement wording, evaluation suite and failure-mode testing

W5Live notices captured alongside handlers, and compared field by field

W6Claims opened and routed from the agent's capture, then handover

Reading the band
Bars span only the weeks their work is named in. Week 5 is shadow running — the same notice is captured twice and the two files are compared.
At the end of W6
Claims are opened and routed from the agent's capture, and every question about cover in that period went to a person.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Insurance AI agent

Fix the first five minutes of the claim.

Show us how a loss reaches you on each channel, what your adjusters have to chase afterwards, and your policy on injury and distress. We'll capture one notice end to end, agree the wording that may never appear in an acknowledgement, and mark every point where a person has to take the call.

Typical delivery
4–6 weeks
Deployment
Your claims and contact stack
Coverage position
A person, always
After launch
Agent Care available

Nestack Agents · FNOL intake & routing

AGT-INS-07 · Agent Care available after launch

Build an FNOL intake agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your setup

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.