First notice of loss: the fields that turn a call into a workable file
In short
A first notice of loss is the report that a loss has happened. It becomes a workable claim file only when it carries what a handler needs to act without ringing back: the parties, a policy identifier, the loss facts, 3 separate timestamps and a lawful way to make contact. Routing, reserving and the service clock all hang off that minimum.
Key takeaways
- A notice is an event; a claim file is a record. The gap between them is a defined field set, not a formality.
- Split the fields by purpose: mandatory to route, mandatory to reserve, and legitimately allowed to arrive later.
- Store the reporter separately from the insured. Notice often comes from a driver, broker, repairer or claimant.
- Capture 3 timestamps at notice — loss, report, receipt — because different clocks and reports hang off each one.
- A notice never decides coverage. It decides where the file goes and who touches it first.
A first notice of loss is the first report that a loss has occurred. It can arrive by phone, web form, a broker's inbox or a telematics event, and on its own it is an event, not a file. It becomes a claim file the moment it carries enough structure for someone to route it, clock it and set an initial reserve without calling the reporter back.
That threshold is worth defining explicitly, because everything in claims intake, FNOL and triage is built on it. An intake system that accepts free text and a phone number has not created a file; it has created a task for whoever opens it next. BuildspaceLabs builds intake and triage software and is not a carrier, broker or adjuster, so nothing here is coverage advice.
Notice, claim and file are three different objects
- The notice. An immutable record of what was reported, by whom, through which channel, at which instant. It is evidence and should never be edited afterwards.
- The claim. The assertion that a covered event may have occurred under a policy. It carries an identifier and a status, and can be withdrawn or duplicated.
- The file. The working object a handler owns: reserves, tasks, correspondence, vendors, payments. One claim can carry several files where 2 coverages respond.
Collapsing these into one row produces unanswerable questions later, such as what the reporter said before an adjuster corrected it. Keep the notice append-only and derive the claim from it.
The record a single notice has to leave behind
| Field group | What it must hold | Mandatory by |
|---|---|---|
| Policy identity | Policy number as given, the matched internal id, and a match confidence | Routing — an unmatched notice still opens, as an exception |
| Parties | Insured, reporter and their relationship, with separate contact rows | Routing |
| Loss facts | Narrative as spoken, plus a coded cause and a loss location | Routing for the code, reserving for the narrative |
| Timestamps | Date of loss, date reported, date received, each an ISO 8601 instant with a zone | Routing |
| Contact permission | Preferred channel, consent to contact, phone in E.164, language need | Routing |
| Exposure detail | Injuries, third parties, vehicles, property affected, estimated extent | Reserving |
| Evidence | Photographs, documents and telematics payloads, capture times preserved | Later, though quality is fixed at notice |
Two rows repay attention. Loss facts is 2 fields, not 1: the caller's narrative is evidence and the coded value is a key, a separation set out in cause of loss: the coded field. Evidence is deceptive — images upload any time, but their usefulness is decided in the seconds they are taken, which is why unusable damage photographs are a capture-time defect.
Who is on the phone, and why the reporter is its own field
Notice regularly comes from someone other than the policyholder: a spouse, a driver, a site manager, a broker, a repairer, or a third-party claimant with no relationship to you. If the form assumes the caller is the insured, every one of those writes the wrong name into the contact fields, and the correction lands days later after 2 failed callbacks.
Model the reporter as a first-class party with a relationship code, their own contact details and their own consent record. That one decision also lets you run a narrower path for people who are not your customer without leaking the insured's file to them.
The fields that may legitimately arrive late
- Decide, per line of business, which fields block file creation. Keep the list to 8 to 12 for personal lines: every extra required field is an abandoned online report.
- Let everything else be captured as absent, unknown or refused, and store which of the 3 it was. Absent and refused are different facts at review.
- Attach a follow-up obligation to each late field, owned by a queue rather than a person, with the reason it is outstanding.
- Re-run routing when a late field lands. A notice routed low because the injury question went unanswered must be re-evaluated when the answer arrives.
What the notice is not allowed to settle
A notice records and routes. It does not decide coverage, liability or quantum, and no score attached to it should either — the boundary drawn in claim severity as a routing input. Where intake is model-assisted, that assistance must be written down and versioned, the point of the written AI program a regulator expects to see.
This is a data-model problem wearing a workflow costume, and it is the shape of work we do as AI agents and automation in the insurance and claims practice — including the reality that AMS360, Applied Epic, EZLynx and HawkSoft each expose a different subset of what a notice needs to write. The production constraints are those in running AI agents in production: narrow scope, a review step, a log of every automated decision.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is first notice of loss in insurance?
It is the first report that a loss has happened, made to the insurer or its representative, and it starts the claims process. The notice itself is only an event: it becomes a claim file once it carries the parties, a policy identifier, the loss facts, the relevant dates and a lawful way to make contact. Until then nobody can route it or set a reserve without ringing the reporter back.
Who is allowed to report a loss?
Usually the insured, but in practice notice frequently arrives from a driver, a spouse, a site manager, a broker, a repairer or a third-party claimant. An intake system should record the reporter as a party in their own right, with a relationship to the insured and their own contact and consent details, rather than assuming the caller and the policyholder are the same person.
Should an online loss report require every field before it can be submitted?
No. Require only the fields that genuinely block routing, typically 8 to 12 for personal lines, and let the rest arrive later as explicit follow-up obligations. Every additional required field costs completed reports, and a notice that never gets submitted is worse than one that arrives with three answers outstanding and a queue chasing them.
- claims intake
- FNOL
- claims operations
- data model
Read next
- Cause of loss: the coded field, and why the caller's story is not itThe loss narrative and the coded cause of loss are two fields with two jobs. Conflating them gives reporting nobody trusts and routing nobody can explain.definition
- Date of loss, date reported, date received: three fields that are not the same fieldOne date decides coverage, one decides whether notice was late, and one starts your service clocks. Collapsing any two of them breaks something you will not notice for months.definition
- Claim severity score: a routing input, not a reserve and not a decisionA severity score exists to decide which queue a new claim joins and how fast. Everything a licensed person is accountable for stays outside its remit.definition
- The damage photos come back too dark, too close, or missing the one angle the adjuster needsSplit your photo rejections by capture path and device class before redesigning anything. In-app camera and gallery upload fail for entirely different reasons and need different fixes.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation