• contact@verticalserve.com
Home / Engineering / Post 16
Engineering Blog · Post #16

Auto-Generating Renewal Submissions from Expiring Policies: Flag Detection, Priority Scoring, and Zero-Touch Renewal Creation

How InsightUW scans 2,400 expiring policies nightly, detects risk flags, scores priority, and auto-creates a pre-populated renewal submission for Bluefin Dining Group's $192K GL policy — so the underwriter opens their queue Monday morning to a fully staged renewal package instead of a spreadsheet reminder.


The Problem

A mid-market carrier writes 8,000 commercial General Liability policies. Each year, every one of those policies expires and needs a renewal decision. The renewal process begins — in theory — 90 days before expiration. In practice, it begins when someone remembers.

The current state at most carriers:

  • A monthly spreadsheet export from the policy admin system lists expiring policies for the next 90 days. A manager distributes it via email. Half the team downloads it; the other half assumes someone else is handling it.
  • No prioritization. A $12K restaurant BOP renewal sits next to a $450K multi-location GL account with an open large loss. Both appear as one row in a spreadsheet.
  • Manual submission creation. The underwriter must open the policy admin system, find the expiring policy, manually transcribe insured name, locations, limits, deductibles, class codes, and premium into the underwriting workbench. This takes 15-25 minutes per account.
  • Missed renewals. Industry data shows 3-7% of renewals are missed entirely — the policy lapses, the broker moves the account, the carrier loses the premium without ever making a conscious decision.
  • No flag awareness. The underwriter does not know that the policy has an AW (Account Warning), or that a $3M claim was paid last year, or that the reinsurance is FAC-placed, until they manually pull each data source.

The math: 8,000 policies x 15 minutes manual creation = 2,000 hours/year of pure data transcription — before any underwriting judgment begins.

The InsightUW Renewal Generation Architecture

InsightUW runs a nightly renewal scan engine that identifies expiring policies, detects risk flags from connected source systems, calculates a priority score, and auto-creates renewal submissions pre-populated with the expiring policy data. The underwriter's first interaction with the renewal is reviewing a staged package — not building one from scratch.

graph TD subgraph Scan["Nightly Renewal Scan"] A["Policy Admin System<br/>8,000 active policies"] B["Scan: Expiring in 90/60/30 days"] C["Flag Detection Engine<br/>8 flag sources checked"] end subgraph Score["Priority Scoring"] D["Base Score: Premium Size"] E["Flag Weights Applied"] F["Priority Tier Assignment<br/>P1 / P2 / P3 / P4"] end subgraph Create["Renewal Submission Creation"] G["Auto-Create Submission<br/>Pre-populated from expiring policy"] H["Attach Flags + Score"] I["Fifo Assignment to UW"] J["Notification: Bell + Email"] end subgraph Queue["UW Renewal Queue"] K["Sorted by Priority Score<br/>P1 at top, P4 at bottom"] L["Flag badges visible<br/>AW / FAC / Large Loss / Punitive"] M["One click → full renewal package"] end A --> B B --> C C --> D D --> E E --> F F --> G G --> H H --> I I --> J J --> K K --> L L --> M

The Nightly Scan Engine

The renewal scan runs as a scheduled job at 2:00 AM ET nightly. It queries the policy admin system for all policies with effective dates falling within configurable windows (default: 90, 60, and 30 days out). For each expiring policy, it performs the following steps:

Step 1: Identify Expiring Policies

The scan queries policies by expiration window and filters out policies already in the renewal pipeline (status: renewal created, renewal in progress, or renewal quoted).

Step 2: Flag Detection

For each expiring policy, the engine queries 8 connected source systems to detect risk flags:

Flag Source System Detection Logic Weight
AW (Account Warning) Policy Admin account_warning = true on insured record +25
FAC (Facultative Reinsurance) Reinsurance System Policy has active FAC certificate +20
Large Loss (>$250K) Claims System Any claim with incurred > $250K in last 5 years +20
Punitive Damages Claims System Any claim with punitive damages allegation +15
Experience Mod > 1.10 Actuarial System EMR exceeds 1.10 (WC) or loss ratio > 65% (GL) +15
Multi-State / Multi-Location Policy Admin Policy covers 10+ locations or 5+ states +10
New Business (1st Renewal) Policy Admin Policy is in its first term +10
Premium > $100K Policy Admin Expiring premium exceeds $100K +10

Step 4: Auto-Create Renewal Submission

The engine creates a new submission record in InsightUW, pre-populated with every field from the expiring policy. No manual transcription. The submission is created with status renewal pending review and assigned via FIFO to the expiring policy's underwriter of record (or, if that UW has left the team, to the next available UW by FIFO).

The Renewal Generation API

External systems and scheduled jobs trigger renewal generation through the API:

Use Case: General Liability — Bluefin Dining Group

The Scenario

Bluefin Dining Group LLC operates a chain of 45 casual dining restaurants across California, Nevada, Arizona, Oregon, and Washington. Their GL policy — $192,400 annual premium, $1M/$2M limits with liquor liability — expires July 1, 2026. The account has been with the carrier for 6 years.

Last year, a patron slipped on a wet floor at the Sacramento location, resulting in a $387,000 settled claim. The account also has 45 locations across 5 states, making it operationally complex.

The underwriter of record is Rachel Torres. Here is what happens without InsightUW, and what happens with it.

Without InsightUW

Day What Happens
April 1 Monthly expiration report generated. 312 policies listed in a spreadsheet.
April 3 Manager emails spreadsheet to team of 6 UWs. Rachel downloads it.
April 7 Rachel starts working through her portion (52 policies). She begins at the top, alphabetically.
April 22 Rachel reaches "Bluefin Dining Group" on the spreadsheet. She opens the policy admin system, searches for the policy, and begins manually transcribing data into the renewal workbench. This takes 22 minutes.
April 22 Rachel does not check the claims system. She is unaware of the $387K claim.
April 28 Rachel sends a renewal indication to the broker at expiring terms.
May 5 The broker responds: "Did you see the large loss? We need to discuss." Rachel pulls the claim file for the first time.
May 12 Rachel revises the indication with a 15% rate increase and updated terms. The broker pushes back.
June 2 After 3 rounds of negotiation, the renewal binds — 29 days before expiration, with the broker openly shopping the account due to delays.

With InsightUW

Time Event System Action
April 2, 2:01 AM Nightly scan detects GL-2025-BFD-004812 expiring July 1 (90-day window) Policy flagged for renewal
April 2, 2:01 AM Flag detection: LARGE_LOSS ($387K claim), MULTI_LOCATION (45 sites), HIGH_PREMIUM ($192K) 3 flags attached
April 2, 2:01 AM Priority score: Base 40 (premium $150K-$500K) + 20 (large loss) + 10 (multi-location) + 10 (high premium) = 80 → P1 Critical Rush SLA assigned (48h)
April 2, 2:01 AM Renewal submission RNW-2026-GL-00847 auto-created with all policy data pre-populated Zero manual transcription
April 2, 2:01 AM FIFO assigns to Rachel Torres (UW of record) Assignment notification sent
April 2, 7:30 AM Rachel opens InsightUW. Bell shows 3 new notifications. Top item: "P1 Renewal: Bluefin Dining Group — Large Loss Flag" Rachel clicks → full renewal package
April 2, 7:35 AM Rachel sees pre-populated submission with all 45 locations, limits, class codes, and the $387K claim highlighted in the flag panel No data entry needed
April 2, 9:00 AM Rachel reviews the loss run (auto-attached), adjusts pricing, and sends renewal indication with 12% rate increase and slip-and-fall exclusion discussion Informed decision on Day 1
April 5 Broker responds. One round of negotiation. Renewal bound 87 days before expiration

Time saved: 22 minutes of data entry eliminated. Renewal started 20 days earlier. Large loss awareness from Day 1 instead of Day 33.

The Renewal Status Machine

stateDiagram-v2 [*] --> renewal pending review : Nightly scan creates renewal renewal pending review --> renewal in progress : UW opens and begins review renewal in progress --> renewal quoted : UW sends renewal indication renewal quoted --> renewal bound : Broker accepts, policy renewed renewal quoted --> renewal negotiating : Broker counters renewal negotiating --> renewal quoted : UW sends revised indication renewal negotiating --> non renewed : Carrier declines to renew renewal in progress --> non renewed : UW issues non-renewal notice renewal pending review --> non renewed : Auto non-renew (no action by SLA + grace)

Every status transition is logged in the audit trail with timestamp, user, and reason code. Non-renewals require a reason code selection (e.g., adverse loss experience, class code appetite change, reinsurance withdrawal).

Scan Frequency and Window Configuration

The nightly scan is configurable per carrier and per LOB:

Configuration Default Configurable Range
Scan frequency Nightly (2:00 AM ET) Hourly to weekly
First scan window 90 days before expiration 30-180 days
Second scan window 60 days (escalation) 15-120 days
Third scan window 30 days (final warning) 7-60 days
Auto-assign on creation Yes Yes / No
Rush SLA for P1 48 hours 12-120 hours
Standard SLA for P2 5 business days 1-15 business days
Extended SLA for P3 10 business days 5-30 business days
P4 SLA None (queue only) None or configurable

At the 60-day and 30-day windows, the scan re-checks policies that have not moved past renewal pending review. If a P3 renewal has not been touched in 30 days, it is escalated to P2 and the manager receives an SLA-at-risk notification.

Metrics: Before and After InsightUW Renewal Generation

Metric Before InsightUW After InsightUW Improvement
Time to create renewal submission 15-25 min (manual transcription) 0 min (auto-created) 100% eliminated
Days from scan to UW first touch 7-21 days (spreadsheet lag) < 1 day (morning queue) 90% faster
Missed renewals per year 3-7% of portfolio < 0.2% (system-guaranteed scan) 95% reduction
Flag awareness at first touch 0% (manual lookup later) 100% (flags pre-attached) Complete
P1 renewals identified Ad hoc (manager intuition) 100% auto-detected and prioritized Systematic
UW hours saved per year (8K policies) 0 2,000+ hours (data entry eliminated) Recovered capacity
Average renewal cycle time 45-60 days 20-30 days 50% faster
Broker satisfaction (renewal process) NPS +8 NPS +42 5x improvement

Key Takeaways

  1. Renewal creation is data transcription, not underwriting. InsightUW eliminates the transcription entirely by pre-populating every field from the expiring policy. The underwriter's first action is reviewing, not typing.

  2. Flag detection at creation time changes the conversation. When the underwriter sees the $387K large loss flag on Day 1, they price the renewal correctly from the first indication. No embarrassing revision after the broker points out what the UW should have known.

  3. Priority scoring ensures the riskiest renewals get attention first. A P1 renewal with an account warning and FAC placement will never sit untouched while the UW works through routine P4 renewals alphabetically.

  4. Zero missed renewals. The nightly scan is a system guarantee. Every expiring policy is identified, flagged, scored, and queued. The spreadsheet-and-email approach cannot make this guarantee.

  5. The 90/60/30 escalation ladder catches stragglers. If a renewal is untouched at 60 days, it escalates. If it is still untouched at 30 days, the manager is notified. No policy slips through the cracks.


InsightUW auto-generates renewal submissions so your underwriters start with a complete package, not a blank screen. Schedule a renewal workflow demo to see zero-touch renewal creation for your book of business.

See InsightUW run on your data

A 45-minute working session with a real broker email and your LOBs.

Request a demo