Renewal week
Every month a cohort of policies comes up for renewal. Your policy administration system runs a renewal batch: it re-rates each policy, produces renewal terms and drafts invitations. Then the operations team starts checking.
They look for policies with claims in the year that should go to an underwriter. Policies where the rating produced a strange result. Customers whose monthly payments have been failing. Policies on an old product version that should move to the new one. Businesses whose turnover or vehicles changed mid-term. Each check is a filter in a spreadsheet exported from the system. Anything missed goes out as an invite with the wrong price or terms.
Why the batch needs a babysitter
Renewal batches in many policy systems treat the book as uniform. The exceptions live elsewhere.
- Claims data is in the claims system or a third-party administrator's file, not joined to the renewal.
- Payment problems are in the payment provider.
- Rating changes since last year can move some premiums a long way, and nothing flags that before invites are drafted.
- Product version migrations need specific handling.
- Checks are done by filtering exports, so they depend on who does them.
Renewal pricing and terms are your pricing team's and underwriters' decisions, within your agreements and whatever rules apply to how you price renewals. We make sure each policy gets the treatment they decided.
The cost of a leaky renewal run
Invites with wrong terms create complaints and reissues. Policies that should have been reviewed by an underwriter renew automatically, which your capacity provider may not welcome. Customers who get a large, unexplained increase leave. Operations spend renewal week on spreadsheets. Retention suffers for reasons nobody can see clearly afterwards.
A renewal pipeline with checks up front
What we build runs ahead of your system's renewal batch, or around it.
- A set period before renewal, each policy in the cohort is loaded with its claims, payments, mid-term changes and product version.
- Checks you define run on each policy: claims in the period, payment failures, data that needs confirming, product migration.
- Policies that need a person go to the underwriting or operations queue with the reason and the data attached.
- The rest are priced through your rating service or policy system, and the result is compared with last year.
- Price movements outside the bands your pricing team set are flagged for review before invites are drafted.
- Invites are generated from templates and released in batches once the checks are cleared.
- A renewal dashboard shows the cohort by status: auto-renewal ready, in review, invited, renewed, lapsed.
| Check | Source | Outcome if triggered |
|---|---|---|
| Claims in the period | Claims system or administrator data | Underwriter review |
| Repeated payment failures | Payment provider | Operations review |
| Large price movement | Rating result versus last year | Pricing review |
| Old product version | Policy data | Migration route |
| Mid-term data changes to confirm | Policy history | Customer asked to confirm in the invite |
Renewal week, reorganised
The checks are the part your team shapes most. We start with the filters people already apply to the exports by hand, write each one as a rule with an owner, and add new ones as renewal weeks show what was missed.
The cohort is checked days before invites are due. Underwriters handle the referred policies in their queue. Pricing looks at the flagged movements. The rest are invited on time. Operations look at the dashboard, not a spreadsheet.
After renewal, the same data shows why policies lapsed by segment, which is useful for pricing and product decisions next time.
Does your renewal run look like this?
- Renewal checks are done by filtering exports.
- Invites have gone out with wrong terms.
- Policies with claims have renewed without review.
- Large price movements are spotted by customers first.
- Nobody can see the cohort's status at a glance.