AI policy checking and renewal comparison for a commercial insurance broker
A commercial insurance broker in Manchester checked every schedule, renewal, and wording by hand. ZingZee built a policy desk that reads the documents against the client file and drafts the client letter, and the upsell finder has lifted cross-sales by 60%.
Client A commercial insurance broker in Manchester, authorised and regulated by the FCA, placing commercial combined and standalone liability cover for trade and industrial businesses across the North of England.
At a glance
The broker's account handlers now check every policy on one desk with four tools, and every flag is cited to the clause it came from.
A commercial insurance broker in Manchester, authorised and regulated by the FCA, placing commercial combined and standalone liability cover for trade and industrial businesses across the North of England.
The engagement was to take the manual reading out of the firm's policy administration.
The firm had not changed how it checked a policy in five years.
A policy desk with four tools on it: a verifier that checks a schedule and statement of fact against what the client asked for, a compare tool that sets a renewal against the expiring policy, an upsell finder that reads a client's website and lists the covers the business should hold, and a draft editor that writes the renewal terms letter.
Outcomes
A policy check from about an hour of reading to under five minutes of review.
A renewal cross-reference from half a day across two schedules and two wordings to about 90 seconds, run on every renewal and not only the ones there was time for.
Upsells found and quoted up 60%, from the upsell finder alone.
Around 12 hours a week returned to each account handler.
Renewal terms with the client the same day the quote arrives, from three or four days later.
A discrepancy flagged on roughly one schedule in eight before it reached the client, including an employers' liability section a previous broker had missed.
The challenge
A commercial broker's year runs on the renewal cycle, and every step of it was read by hand.
A team of account handlers looks after several hundred client policies a year through the full cycle of quote, bind, mid-term adjustment and renewal. Until this build, every document an insurer issued was checked by hand before anything went to the client, and the firm's checking procedure ran to a written page that each handler followed line by line.
Every new quote and every renewal was read by an account handler with the client's file open on the other screen, and the record of what had been checked was whatever the handler typed into the broking system that day.
The renewal cycle
For each client the handler gathers the risk information, presents it to insurers, receives quotes and puts the best of them to the client. When the client accepts one, the insurer issues a schedule setting out the cover and a statement of fact recording the information the quote was based on, and the handler binds cover on those terms. Mid-term adjustments arrive whenever the client moves premises or changes what it does, and each one produces a revised schedule. Renewal terms arrive a few weeks before expiry, and the whole check is done again against the expiring policy.
The check against the file
The handler's first job on any schedule was to prove that it agreed with what the client had asked for. The insured entities, the risk addresses, the business description, the sums insured for buildings, contents, stock and machinery, the business interruption gross profit and its indemnity period, the liability limits, the excesses and the retroactive dates were each read off the PDF and matched against the client's file, which was a folder of emails and forms open on the other screen. A tenant's improvements figure typed as £210,500 where the client had asked for £201,500 reads as correct at a glance and costs the client a shortfall at claim time.
The wording behind the schedule
Behind the schedule sat the policy wording, often 100 pages or more, with endorsements laid on top. The handler read it for the conditions and warranties the client had to be told about: minimum security conditions, working height and depth limits, hot work permits, unoccupancy conditions, claims notification windows and conditions precedent to liability. Each one got a rating note on the broking system, a short plain-English line saying what the condition required and why it mattered to this client, and a paragraph in the client letter. The FCA's conduct rules require a broker to record the client's demands and needs and to keep evidence of what was checked and what the client was told, and the rating notes were that evidence.
Renewal against a different insurer
At renewal the same work was done against the expiring policy, and the difficulty doubled when the quote came from a different insurer. Two insurers describe the same cover in different words, so the handler was matching "machinery and plant" on one schedule against "contents" on the other, and "increased cost of working" against "additional expenditure", by eye. The basis of settlement, reinstatement or indemnity, sits in the wording and not on the schedule, so both wordings had to be read for it. A client held on two separate policies, property and liability, who received a single combined quote meant three schedules and three wordings open side by side.
The consequences
- 01
A full check on a new policy took an hour and often longer, and a renewal cross-reference took most of a morning, so the handlers checked what they had time to check.
- 02
Renewal terms reached the client three or four days after the quote arrived, which left little room to go back to the underwriter before the expiry date.
- 03
A change in the basis of settlement between the expiring policy and the renewal quote could pass unnoticed, because the two wordings used different words for it.
- 04
Missed items surfaced late, when the client asked or a claim was made, and each one was a professional indemnity exposure for the firm.
- 05
The record the FCA expects of what was checked and what the client was told existed only as far as the handler had typed it that day.
- 06
Cover a client should have held, and would have bought, was never quoted because nobody had the time to look for it.
The handlers now run every new policy and every renewal through the desk, and the broking system remains the system of record.
A policy check from about an hour of reading to under five minutes of review.
The solution
ZingZee built the desk in the order in which each part of the manual check cost the handlers the most time.
Verification came first, because the check against the client's file took the most handler time every day. The compare tool followed, then the upsell finder, then the draft editor, and the issue log once the tools were in daily use. The desk is a web application the handlers use alongside the broking system, which stayed as the system of record. Every flag and every condition carries the line it was read from, and nothing leaves the firm until a handler has read the flags and pressed send.
Checking a policy
Policy verification
A handler drops the insurer's documents into a job: schedule, statement of fact, wording and any endorsements, PDF or Word. The tool checks more than twenty scheduled figures against the client's file, from the insured entities and addresses to the sums insured, indemnity periods, liability limits, excesses and retroactive dates. Each field shows a tick or a flag with the line it was read from, and the flags sort to the top. A new schedule now opens as a short list of flagged lines to check against the file, and the PDF is opened only to confirm a flag.
Conditions and exclusions
The wording and every endorsement are read in full, and each condition that matters to the client's trade is pulled out with a draft rating note and the page it sits on, ranked by relevance to the trade. A demolition contractor sees the hot work and height conditions at the top of the list; a card wholesaler sees stock and security. The rating notes the handler used to write from a blank screen now arrive drafted, in the order that matters to the client, with the page reference already in place.
Comparing policies
The compare tool
Two policies are set against each other: a renewal against the expiring cover, or up to five separate policies against one combined quote. The tool reads every schedule and wording on both sides and lists the differences by severity, matching items across insurers' terminology, with the source lines from both sides. The basis of settlement is read from each wording, and a change from reinstatement to indemnity is flagged at the highest severity with both clauses quoted. A renewal cross-reference is now a ranked list of differences with the two source lines beside each other, and the handler's time goes on assessing the differences.
Schedules
A multi-property schedule is read property by property, so a client with several sites is compared site by site. A handler with a client on six sites sees six rows of figures, each matched to its address, where before a merged total could hide a missing site.
Finding cover to sell
The upsell finder
A handler types in a company name and website, and the tool reads the client's own site and lists the covers the business should hold, ranked from essential to optional, against what the broker already places. The gaps are the upsell list. A handler preparing for a renewal call has the gap list in front of them before the call, in place of what they remember of the client's trade.
Writing and keeping the record
The draft editor
From the flags and the conditions, the tool writes the renewal terms letter in the firm's own format, for the client or for the underwriter, in an editor the handler corrects and sends. The letter is a five-minute edit in place of a half-hour write, and the conditions paragraph never omits a flagged item because the flags are what it is written from.
The audit trail
Every job keeps the documents, the flags, the rating notes and the letter as sent, with the source clause behind each one. When the FCA or a client asks what was checked and what was told, the handler opens the job, with no reconstruction from the broking system's notes and an inbox search.
The issue log
A button on every page lets a handler report a wrong or missing extraction against the job it happened on, and the report reaches ZingZee with the case attached. A handler who spots a bad read logs it in the moment, on the job, and the fix ships against that job.
The desk runs on a cloud service ZingZee manages for the firm, with the documents held in a private database and file store that only the desk can reach. The broking system was not modified.
What was hard
Three problems took most of the engineering time, and each was found on the firm's own documents.
- 01
Reading the whole wording, on both sides.
A commercial wording runs to 100 pages and 150,000 characters, and the first version passed each document to the language model in a single pass. On long documents the model ran out of reading room and reported figures as "not stated" that sat on page four, and it read the new quote more thoroughly than the expiring policy, so the comparison was lopsided. We replaced the single pass with a deterministic extractor that works on layout-preserved text and runs identically on both sides. Every figure it finds is anchored to the exact line it came from, and the Word parser was rebuilt to read schedule tables row by row so a label stays beside its figure. The language model is now asked only for the qualitative differences, with the extracted figures given to it as context. The tenant's improvements and business interruption gross profit figures that had been reported as missing were matched on both sides with source lines, and the comparison that failed in front of the handlers passed the next day.
- 02
Finding the basis of settlement and citing the right clause.
A 100-page wording has several headings that read "basis of settlement". The liability section has its own, and the property section's sits around page 80, after the index-linking clause. A keyword scan took the first one it found and reported the wrong basis with confidence, and a truncated read never reached the right one. We now locate every occurrence across the full text and score each window by the language of a material damage settlement basis, "condition when new" against "value at the time of the loss". The strongest windows go to a grounded model call that must return a verbatim quote. With no quote there is no answer, and the field shows "unknown" in place of a guess. The same rule was applied to every flag on the desk: a flag with no source line is discarded before it reaches the handler. A reinstatement quote set against an indemnity quote is now flagged at the highest severity with both clauses quoted.
- 03
Terminology that differs between insurers.
One insurer writes "machinery" where another writes "machinery and plant", and "tenant's improvements" on one schedule is "improvements and betterments" on the next. A literal match reported the same figure as missing on one side and present on the other, which produced a false difference and hid a real similarity. We gave each checklist item a set of aliases so a figure labelled either way lands in the same field, and the model reasons on equivalence for clauses. The firm's own insurer terminology list is being folded into the alias set so the matching is exact. A matching sum insured labelled differently by two insurers now shows as a similarity with both lines, where before it was two flags the handler had to reconcile by hand.
How it was delivered
- MondayThe firm sent ZingZee a real quote pack: the schedule, the statement of fact, the wording and the summary of cover the handler had written from them.
- End of that weekA working version that read those documents and produced the flags and a draft letter was in front of the handlers. The front end was built first, against the real documents, so the handlers reviewed their own case from the first session.
- Three weeks inThe handlers brought a live comparison of their own to a review session and it failed on screen: two figures reported as missing that were on the page, and a Word schedule that would not read. That session produced the punch list above.
- Within daysThe fixes shipped, verified against the same jobs that had failed. The issue log followed so that every later miss could be reported on the job it happened on.
The desk is a Python service with a React front end, backed by a Postgres database and a private file store, with a large language model doing the qualitative reading behind a deterministic extraction layer. The site is password-gated and blocked from search indexing, and the service answers only to the firm's key. No client document is used to train any model, and a handler reads every flag before anything is sent.
The results
The handlers now run every new policy and every renewal through the desk, and read flags in place of pages.
Verification, comparison, rating notes and the first draft of the client letter now run without a handler reading a wording.
Every flag cites the clause and the page it came from, and nothing reaches a client until a handler has read the flags and pressed send.
What's next
The compare tool will be tuned to the insurers' own terminology list so that matching across wordings is exact. Rating notes will post to the broking system directly, and mid-term adjustments will be checked the same way as renewals, so a revised schedule gets the same flags as a new one. The same desk can run for any UK commercial broker with the same checking procedure.
