← Back to Work
Process file · Finance Finance

What’s inside: connections to your systems · step-by-step flow

A policy change arrives. Who checks the cover first?

The question this file answersHow often does an endorsement get keyed into policy admin before anyone has checked what the policy actually covers?

Fits: insurers and brokers where claims and policy changes still arrive by email.

Typical day

What the desk looks like today

Typical pattern, not a measured desk; the finance playbook publishes claims volumes, not endorsement counts. A broker emails a changed address, vehicle or sum insured; someone retypes it into policy admin and discovers later the cover was never what the email assumed. It hurts when change and claim land together.

What changes

What Monday looks like after

By mid-morning the routine changes — addresses, named drivers, small limit changes — are in policy admin and confirmed back to the broker, and the operations desk is working a list of the ones that changed the risk. The underwriter's judgement on cover is untouched; what has gone is the retyping.

Typical, not a measured client result. Every figure here comes from the playbook source named below.

Written

the same policy-check build as claims triage — no published figure for endorsements

Before: a broker's email is retyped into policy admin and the cover drifts. After: in-scope changes are checked against the policy and written; anything touching the risk waits on an underwriter. No percentage — the claims figures live on the parent file.

No published figure for this desk. The range lives on the parent file: Simple claims go straight through; adjusters get the disputed →

How this file is built

McKinsey Insurance 2030 (2023) and Accenture (2023) measure claims processing; an endorsement is not a claim, so their ranges stay on the claims file and this one carries no percentage. Not a cover-accuracy claim.

What we install

What we put in front of the systems you already run

Your policy administration system stays, whatever it is, and Outlook or the broker portal stays the front door. This is the same check-against-the-policy build as our claims triage, pointed at changes:

  1. the requested change is extracted from the broker's email or attachment
  2. it is validated against the live policy — is this cover, this limit, this endorsement type in scope
  3. in-scope changes are written into policy admin through its interface or import for your usual approval, and anything touching the risk itself goes to an underwriter with the email and the policy side by side.
What stays human — and what this will not do

Interpretation of cover. Broker relationships. Anything that changes the risk itself.

Not a cover-accuracy claim.

What can go wrong — and what we do about it

Broker emails are ambiguous — 'update the vehicle' without a registration — and an ambiguous change is not guessed; it goes to a person, so a messy broker channel means a long review list at first. Older policy admin platforms often have no usable interface, in which case writes go through file import or a screen-level bridge that needs your IT and is slower.

What it costs to get there

The path: free 60-second estimate → free 20-minute review → paid audit of this one process (€1.5–3K, typically two weeks) → pilot with your people in the loop (€10–20K, weeks, not quarters). No transformation programme. Prices are public, on the services page →

Scoped in the audit — the playbook has no estimate for this exact desk.

This is about you if…
What does this mean in euros?

That depends on your volumes and wage costs — this page will not invent the number. The free 60-second estimate runs that calculation from your answers, with every multiplier sourced.

Get your free savings estimate 60 seconds · no sales call Or write first → Map a finance process like this one — free, 60 seconds →

Not a named Aperanda client. Process file · Finance.

Short process file. Same build as its parent file; the playbook has no separate volume or benchmark for this desk.

All process files