The admin behind every policy.

From the outside, a protection broker sells policies. From the inside, a broker also checks documents, a lot of them.

We spent time inside the admin team of an Irish life and mortgage protection broker that sells under four brands. Every policy sold came back as a signed pack. Before it could go to the insurer, someone had to prove that the pack was right.

What “checking” actually meant

Three documents had to agree: the Fact Find, the Application and the Statement of Suitability. Names, dates of birth, cover amounts and premiums were all compared by eye.

Then the premium had to be found. It lived in one of seven brand sales sheets, so an admin searched for the right row and compared it to the paperwork. Then the details were typed in again: into a master sales sheet, then into each insurer’s own portal. Five providers meant five different processes.

It took 20 to 30 minutes per policy. And because the checking was done by eye, the errors that slipped through were found late, after submission, when they were hardest to fix. A start date set close to a client’s birthday was the classic example: easy to miss, and expensive when missed.

Let the system check, and people handle the exceptions

The system we built reads every signed pack as it arrives from DocuSign. It classifies each document, extracts the fields that matter, and runs three checks in parallel, on identity, risk and financial details. A separate check flags any start date within 14 days of a birthday. The premium is looked up from the right sales sheet automatically, and bank details are validated.

Then it puts the policy on a board, marked either Verified or Not Matching, with every issue listed. An admin opens it, sees exactly what is wrong (or that nothing is), and acts. Review now takes about 4 minutes per policy.

The important design choice is what the admin sees. Not a score. Not a summary. A list of specific mismatches, each one pointing at the documents it came from. People trust a check they can see.

Volume is the real test

A system that saves time on 70 policies a month is nice. One that keeps working at ten times that is a different thing. In its first month the broker processed 74 policies on the system. By June it was 719 a month. Over the first eight months, 3,205 policies went through, at 99.9% processing reliability. When the broker added a second brand, it ran on the same system.

The admin team did the rest. By September they had asked to roll it out to everyone and retire the old process entirely. That request, from the people doing the work, is the result we watch for most.

The same pattern, elsewhere in broking

We have seen the same shape in commercial insurance broking. There, the paperwork is quotes, schedules and welcome packs, built by hand after every call. Filling the firm’s own templates from the call transcript, and leaving the advisor to edit before anything is sent, follows the same rule: the system prepares, and a person approves.

Where to start

If you run a broker’s back office, look at the moment just before submission. Count how many documents have to agree, how many places the same number is typed, and how often a mistake is found after it has gone. That is usually where the first system pays.

And keep the system on your own infrastructure. This one runs on the broker’s own cloud account. Nothing depends on ours.