FNOL process for insurance brokers: the work before the insurer sees the claim

It is 8:40 on a Monday. A message lands in the shared claims inbox: had an accident on the way to work this morning, what do I do now? Attached is a photo of the other car’s number plate. The accident report is still in the glovebox, half filled in.

To the client, the claim started the moment they pressed send. To the insurer, it does not exist yet. Everything that happens between those two points is the broker’s part of the FNOL process, and the client sees all of it.

That part carries more weight than it looks. In an Accenture survey of more than 6,700 policyholders, 30% of people unhappy with how a claim went had switched insurer within two years, and another 47% were thinking about it. When a client reports the claim through you, a slow or messy start tends to land on your name as much as on the insurer’s.

What the broker does between the email and the declaration

Ask a claims handler at a broker office to walk through a new claim and you get a list that has little to do with insurance judgment. Read the email and open each attachment. Find the client in the broker management system, then the right policy, which is not always in the name of the person who wrote in. Work out what is there and what is missing, and ask for the rest.

One Flemish broker described their routine to us like this. When a declaration comes in, someone first goes through everything that arrived. Then they call the client to say what has been received and what is still needed, and send an email afterwards to confirm it in writing. Only once the file is complete do they declare the claim to the insurer. When an expert is appointed, they tell the client who it is so a visit can be arranged.

Each step is simple on its own. The cost is that there are many of them, and they repeat on every claim. One broker we work with timed it and landed on fifteen to twenty minutes per claim to open the file and gather what was needed, before the insurer had done anything at all.

Car claims make the pattern sharper. At two broker offices we spoke with, they were just over half of all claims, which means the same accident report and the same kind of photos arriving in slightly different shapes many times a week.

Where the minutes go

Most of the time leaks in a handful of predictable places.

The first message is rarely complete. A client writes from their phone right after the accident, without the report, or with a photo of only one side of it. The handler replies, waits, opens the second email, compares it with the first, and sometimes asks again. Each round starts the reading over.

The data gets typed more than once. The date, the place, the vehicles and the other party come off the accident report into the broker management system, and then again into the insurer’s declaration form or portal. Two copies means two chances for a typo.

The record has to be complete as well. Brokers keep every incoming and outgoing email and every document with the claim file, because that file is what they rely on when a question comes up months later. Saving and filing attachments by hand is small work that never shows up in any estimate.

And some accidents are two claims. A collision can mean a damage claim with one insurer and a legal protection claim with another, which the same handler then follows side by side.

A first notice that is ready the first time

The better version starts in the inbox the client already writes to. The email is recognised as a claim when it arrives and matched to the client and their policies in your broker management system. The attachments are read as they come in, so the accident report and the photos are already turned into fields before anyone opens the message.

Because what is missing is visible straight away, the first reply can ask for exactly that. The client gets a short message in the language they wrote in, with a link where they can add the missing documents from their phone. When they do, the case updates and nobody has to line up two email threads to see what changed.

The data is captured once. The fields read from the accident report go into the claim in the broker management system, together with the emails and documents, so the record is complete without anyone saving attachments by hand. Declaring the claim to the insurer still happens the way it does today, only now from a file that is already complete and already typed in.

To put rough numbers on it, picture a broker office with three people handling about fifty claims a month. At fifteen minutes each just to open the file, that is more than twelve hours a month of reading and typing before any claim reaches an insurer. With the reading and filing done as the email arrives, the handler’s first touch becomes a check of what was read and a reply that is already drafted. The time that frees up goes to the claims that need a conversation.

What stays with the broker

Automating the first notice does not decide whether a claim is covered, and it should not. A handler still checks the policy on the awkward cases and still calls the client who is shaken after a serious accident. That is the work clients pay a broker for.

What changes is where the handler’s morning goes. Less of it on finding the client in the system and retyping the accident report, more of it on the claims where advice actually matters.

So the useful question for a broker office is a plain one: of the fifteen or twenty minutes your team spends opening a claim, how many of them need a broker?

Penbox works from the claims inbox you already have and writes the claim into Brio, so the first notice reaches your file complete. For the insurer’s side of the same moment, here is why FNOL software decides claim length. And if you want the wider picture, this is how Penbox works for insurance brokers.