Four quotes, four layouts, one spreadsheet
Terms come back from four insurers for a commercial package. One is a two-page summary with the full wording attached. One is a fifteen-page quote schedule. One arrives in the body of an email with a PDF of endorsements. One is a portal download. The handler has to turn them into a single comparison the client can follow: premium, IPT, limits per section, excesses, key endorsements, subjectivities and anything that has been excluded.
So they open a spreadsheet and start reading. It is slow, and it is the kind of reading where missing a single endorsement matters, such as a new unoccupancy condition or a changed flood excess.
Why the comparison is always manual
Insurers do not share a quote format. Even within one insurer, different products lay terms out differently. The information a client needs to compare is spread across schedules, endorsement lists and wording references. There is no standard data feed for most commercial terms, so the broker becomes the translator.
It is also a judgement task. A lower premium with a much higher theft excess is not a cheaper quote in any useful sense, and the comparison has to make that visible.
Where the time and the risk go
- Handlers retype figures from PDFs, which invites transposition errors.
- Endorsements buried on page nine get missed or summarised loosely.
- Subjectivities, such as a survey or a risk improvement deadline, are not always carried into the client presentation.
- Each handler builds the comparison in their own format, so clients see inconsistent documents.
- The comparison is rebuilt from scratch when a revised quote arrives.
Extraction, side by side, broker checks
- Quote documents arrive by email or are dropped into a folder against the case in your broking system.
- An extraction step reads each document, whatever its layout, and pulls out insurer, premium, taxes, fees, each section's limit and excess, endorsements, exclusions and subjectivities, each with a reference to the page it came from.
- Values are checked for sense, such as a limit that does not match what was requested, and anything the model is unsure about is marked for the handler.
- The terms are laid out in a common structure, section by section, with differences between insurers highlighted and any section missing from a quote flagged.
- The handler reviews each line with the source page one click away, corrects anything, and adds their own commentary.
- The approved comparison is produced as a client-facing document in your format and saved to the case.
- If a revised quote arrives, only that insurer's column is re-extracted and the changes are shown.
We use a language model for the reading because layouts vary so much, but the output is always a draft. The broker is responsible for the comparison and the recommendation, and the tool is built around that check rather than around skipping it.
What the client ends up seeing
| Item | Insurer A | Insurer B | What the tool flags |
|---|---|---|---|
| Buildings excess | As requested | Higher | Difference from request |
| Flood cover | Included | Excluded | Section missing |
| Unoccupancy condition | Standard | Added | New endorsement |
| Subjectivity | None | Survey required | Condition to explain to client |
The table above is illustrative of the structure, not real terms. The handler's time moves from retyping to explaining, and every client gets the same clear format.
Recognise this?
- Building a comparison takes longer than reading the quotes should.
- Endorsements have been missed from a client presentation before.
- Each handler has their own comparison spreadsheet.
- Revised terms mean starting the comparison again.