The policy lookup says no policy in force on a loss you know is covered

Someone is on the phone reporting a loss and the screen says no policy in force. Understand what that sentence is: a statement about a search, run with particular inputs, against a particular copy of the data, as at a particular date. It is not a statement about whether the insured has coverage. Keeping those apart is the whole discipline here, because every serious failure in this area starts with an intake system quietly converting a data fault into something that sounds like a decision.

The confirming check takes about 2 minutes and does not need a developer. Resolve the same insured by 3 independent keys and compare what comes back: the policy identifier as the caller reads it, the named insured plus the risk address, and the asset — the vehicle identification number or the schedule row for the location. If any of the 3 returns a policy the others do not, you have a lookup fault. If all 3 return nothing, you have a different problem and it may not be a data one.

Resolve the insured 3 ways before you say anything to the caller

1. Search the identifier exactly as given, then again normalised. Strip spaces, punctuation, leading zeros and any carrier prefix or suffix, and search both forms. Record which one matched, because that tells you whether the fix is in the form or in the search.
2. Search by named insured and risk address, ignoring the identifier entirely. Use the address as it sits in the policy schedule rather than as the caller says it, and accept partial matches for review rather than requiring an exact hit.
3. Search by asset. A vehicle identification number or a schedule row for the location is often the most reliable key you have, because it was typed once by an underwriter rather than repeatedly by everyone who has touched the file since.
4. Run all 3 as at the date of loss, not as at today. This single change resolves a large share of these incidents on its own and costs nothing to implement.
5. Compare the 3 results side by side on one screen. Disagreement is diagnostic; a single blank result tells you almost nothing.

5 reasons a policy that exists does not come back

The 5th cause is the one to rule out early and then hand over, because it is not a claims problem. If intake reads a local copy of the book, that copy's freshness is a systems concern with its own failure patterns — policies disappearing from the mirror at renewal is where the fix lives. What matters at the desk is that the not-found path distinguishes 'the source says no' from 'our copy says no'.

You asked the right question about the wrong day

Policy data is effective-dated. A record does not simply exist; it exists across a term, and every attribute inside it — limits, scheduled vehicles, named insureds, additional interests — can differ between one term and the next. A lookup defaulting to today therefore answers a question nobody asked. A loss on the 14th, reported on the 20th of the following month, sits in a term that may already have renewed under a new number, lapsed, or been rewritten with another carrier.

• Default every intake search to the date of loss and show that date on the screen. Staff should be able to see which day they are asking about without opening a settings panel.
• Return the term, not just the policy. Effective and expiry dates alongside the result stop an intake handler from confirming details that belong to a different term.
• Handle the loss reported before it was discovered. Escape of water and theft frequently have a date of loss well before the reported date, and a search anchored to reporting date will miss both.
• Show adjacent terms when the loss date falls near a boundary. A loss 2 days either side of a renewal is a real ambiguity and hiding it does not make it go away.
• Never let the intake screen pick a term when 2 are plausible. Present both and route the file; term selection at a boundary is a coverage judgement wearing a data-entry costume.

A not-found result answers the question you asked, on the day you asked about, against the copy you searched. Three of those four things are usually wrong, and none of them is the insured's coverage.

Why the number the caller reads out never matches

Policy identifiers are printed for humans and stored for machines, and the two forms drift apart immediately. A number on a certificate may carry a carrier prefix, an agency segment, a term suffix that increments at renewal, and separators that exist purely for readability. The caller reads the whole string; the system stores a subset; the search demands equality. Add the standard confusions — O against 0, I against 1, B against 8 — and an exact-match lookup fails on a perfectly valid number.

The fix is a canonical form on both sides, plus a search that tries the given string, the normalised string, and the string with any known term suffix removed. Doing that consistently across intake, documents and downstream systems is a broader piece of work than one screen — normalising policy numbers so documents can be joined is the general treatment. At intake, the narrow version is enough: normalise, try several forms, and log which form matched so you can see the pattern across a month.

Designing the not-found path so the notice still gets taken

The worst outcome of a failed lookup is not a wrong answer. It is a dead end: a claimant ready to report a loss, told to call back with a document they may not have. Take the notice regardless. Capture the loss facts, parties, dates and contact details, allocate a durable claim identifier so everyone refers to the same thing, and mark the file unmatched so it lands in a queue with an owner. Allocating identifiers before a record is complete creates its own housekeeping, handled in issuing claim numbers before the notice is complete.

1. Take the notice and start the clocks. The acknowledgement obligation does not pause because your search failed, and a file that exists is a file somebody can work.
2. Allocate a claim identifier immediately and give it to the caller. It costs nothing and it makes every subsequent contact traceable.
3. Record the search attempts, not just the outcome. Which keys were tried, which values, which as-of date — this is what lets someone resolve it in 3 minutes rather than starting over.
4. Route unmatched notices to a named queue with a service target. Unmatched is a state, not a bin, and it needs an owner in the same way any other queue does.
5. Reconcile daily. Most unmatched files resolve within 24 hours once a person searches with a wider net or calls the agent, and the rest need a decision rather than another automated retry.

Two channel-level points fall out of this. First, identifier capture accuracy differs sharply by how the notice is taken — a guided form can validate a vehicle identification number's length and character set while the reporter is still there, a voice call cannot, and that trade-off is the substance of guided form or voice capture for first notice. Second, a self-service loss report that ends in a not-found message is the single most reliable way to send a claimant to the phone, which is one of the named drop points in claimants starting the online loss report and phoning in anyway.

One thing to design out early is the workaround. When lookups fail often enough, staff email screenshots of policy detail to each other to get the file moving, and documents drift out of the systems that control them — the exposure modelled in a subprocessor breach touching claim documents.

The build is small and specific: a resolver taking 3 keys and an as-of date, a normalisation step, a linked-identifier table so superseded numbers still resolve, and an unmatched queue with an owner. That is ordinary MVP and product build scope, and it removes a category of incident rather than reducing its frequency. The rest of the path from notice to queue sits in claims intake, FNOL and triage, inside our insurance and claims work.

• FNOL
• policy lookup
• coverage verification
• claims intake