Building a renewal review workflow

Every agency intends to review its book annually. Very few do it, and the reason is not laziness — it is that the annual review is the only significant piece of agency work with no natural trigger.

New business is triggered by a lead. Service is triggered by a client calling. A claim is triggered by a loss. The review is triggered by nothing at all, which means it happens only if somebody builds the trigger, and it loses every scheduling contest against work that announces itself.

This is a systems problem with a systems answer. Four components, and none of them require hiring anyone.

Component one: the trigger

Pick a date your system already emits and hang the review on it.

Renewal is the strongest candidate. It is automatic, it is spread evenly across the year, and the client is already thinking about the policy — which makes the conversation feel natural rather than prospecting.

Two practical points. Run it far enough ahead that changes can be made before the policy renews — reviewing after the renewal has processed means every recommendation becomes a mid-term endorsement, which is more work and less likely to happen. And handle multi-policy households once, not per policy: a client with auto and home should be reviewed once, on the earlier date, not twice.

If renewal does not work for your structure, policy anniversary or client anniversary are fine. What matters is that the system produces the list without anyone deciding to make one.

Component two: the agenda

A review without an agenda becomes a conversation about the premium, because that is what the client will raise if nobody raises anything else.

A fixed list makes the call fifteen minutes, makes it repeatable by anyone in the agency, and makes it productive. Six items, in this order:

Last year’s declinations. Start here. It is the highest-yield item and almost nobody does it. Last year you declined water backup and an umbrella — here is what has changed since, do you want to look again? This turns a check-in into a specific proposal and it is only possible because somebody documented the declination.

Household changes. Ask directly rather than generally. “Has anything changed?” reliably returns “no” from a household that added a driver and finished a basement. Ask about drivers, vehicles, renovations, valuables, business activity, rental property, and anyone who moved in or out.

Property figures. Dwelling replacement cost, when it was last calculated, and whether the inputs are still right.

Limits. Liability, and UM/UIM against it. Both drift, and the second one is usually a default nobody chose.

Exposures not currently covered. Flood in particular, whether or not you can place it. This is a standard, and it is one of the few items where the right answer may be “we can’t sell you this, and you should have it.”

What we recommend this year. Ending with a recommendation is what makes it a review rather than a survey.

Component three: the log

One field. Offered, date, channel.

The temptation is to log outcomes — reviewed, declined, rescheduled, changes made. Resist it. A log requiring a narrative note will not survive a busy week, and the outcome is not the thing the standard measures anyway.

Log the offer because the offer is what the agency controls. A client who does not want a review is exercising a legitimate choice; an agency that never offered is not.

The log then does three jobs at once: it is the working queue, it is the coverage metric for the book, and it is the E&O record.

Component four: the exception report

This is the component agencies skip, and skipping it is why review programmes die around month three.

The report answers one question: who is inside the review window and has not been offered?

Three properties make it work.

Weekly. Monthly is too slow to correct drift; daily is noise.

Owned by one named person. Not reviewed by the team. Somebody whose job includes looking at it and chasing the gaps.

Short. If the report is routinely fifty names long, the programme has already failed and the report becomes something people stop opening. A functioning report is a handful of names.

Sequencing the build

Do not build all four at once.

Weeks one to two: get the trigger producing a list. Even a spreadsheet exported from the management system counts at this stage.

Weeks three to four: write the agenda and put it somewhere everyone uses. One page.

Week five: add the log field and start recording offers.

Week six onward: start the exception report and give it an owner.

An agency that tries to launch the complete programme in one go will spend six weeks on process design and never run a single review. Starting with a list and an agenda gets reviews happening in a fortnight, and the measurement can be added around a thing that is already running.

What comes out of it

Two things worth expecting, because they change how the programme gets funded internally.

Recommendations that produce revenue. Umbrellas, higher limits, endorsements, scheduled items, policies that should have been rewritten. A review programme generally pays for itself, and it does so from the existing book rather than from new acquisition.

Declination letters. Every recommendation not taken generates one, which means the review programme is also the largest single source of the documentation described in the pillar article.

Those two outputs are the argument for the programme. It is not an administrative burden that also happens to satisfy a standard — it is the most productive hour an agency spends on an existing client.

What to check in your own agency

Pick a month from last year at random. Pull every active client whose renewal fell in it, and count how many have a logged review offer.

If you cannot answer that from your system within a few minutes, component three does not exist yet — and without it, component four cannot exist either.