An illustrative food manufacturer in Columbus, Ohio renews five lines on February 18. It is late October: 112 days out, just inside the 120-day mark. The expiring program is $1.8M of premium. Readiness is 11%. Two of the five loss runs have not even been ordered.
Nothing has gone wrong yet. That is the point of the 120-day mark: it is the last moment when everything an underwriter will ask for can still be gathered without a rush. This post follows that moment in InsightPlacement — the calendar, the weighted readiness checklist, the renewal readiness agent’s prepared loss-run orders and what the account manager does with them. The client, its carriers and every figure are illustrative, generated for the demo book.
| Actors | Account manager (owns the data), placement broker, account executive; the client's risk manager |
|---|---|
| Trigger | The placement crosses the 120-day mark before its effective date |
| Lines | Commercial property, general liability, commercial auto, workers compensation, umbrella / excess |
| Agents involved | Renewal readiness agent, data-gap chaser, submission builder, supervisor agent |
| Decisions | Ordering loss runs from the incumbent carriers; what to ask the client for; when the placement is ready to move to submission |
| Systems touched | The data room (expiring policies, SOV, signed application), InsightPulse for the company profile |
| Outcome | Every loss run ordered within the week, a dated list of what is still owed, readiness that moves before the 90-day mark |
| What is measured | Readiness at each mark, days from 120-day mark to loss runs received, placements behind the calendar |
The calendar every renewal runs on
InsightPlacement reads each placement against four milestones: 120, 90, 60 and 30 days before the effective date. Each mark has a stage the placement should have reached by then — data collection by 120, submission by 90, marketing by 60, the proposal by 30. A placement is behind when its stage is earlier than the one its mark expects. The engine computes this from two inputs, the effective date and the stage; nothing about it is a model’s opinion.
The screen above is a different placement, at 29 days and fully ready, so you can see what the finished checklist looks like. Our manufacturer is at 112 days with most of the list still open.
Readiness is a weighted checklist, not a feeling
Readiness is the share of the checklist’s weight that is met. The weights say what an underwriter actually needs first:
| Check | Weight | Met when |
|---|---|---|
| Exposures collected | 2.0 | Every exposure a line needs is present and updated within 120 days |
| Loss runs ordered | 1.0 | Every line has a loss run ordered or received |
| Loss runs received | 2.0 | Every line received, valued within 90 days |
| SOV updated | 1.5 | Updated in the last 12 months (property only) |
| SOV complete | 1.0 | No more than 10% of locations with gaps (property only) |
| Expiring policies on file | 1.0 | Every line’s expiring policy in the data room (renewals only) |
| Signed application | 1.0 | In the data room |
On our manufacturer only the signed application is met, so readiness is 1.0 of 9.5 — 11%. The checklist says exactly why: drivers are missing from the exposures, three of five loss runs are not in, the SOV was last updated in September 2025 and two of its nine locations have gaps, and the umbrella’s expiring policy is not on file.
What happens when the agents run
Pressing Analyze (or an event like a new document) runs the ten agents in order on the shared pipeline. The first three work the readiness playbook: each playbook item runs an engine check, the engine’s figures become numbered facts, and the agent reasons over those facts. With the model on, the agent writes a reading; with it off, the engine’s own finding stands and says so.
Two decisions are prepared. The renewal readiness agent proposes ordering loss runs from the incumbent carriers on the two lines not yet ordered — workers compensation and umbrella — and says it starts there because those take two to three weeks to arrive. The data-gap chaser proposes asking the client for four items: this year’s drivers, the construction class at location 5, the sprinkler status at location 8, and an updated statement of values.
Step by step
The placement is inside the 120-day mark and in data collection, which is where it should be: it is on the calendar, not behind. Readiness computes to 11%.
Order loss runs from Larkspur National (workers compensation) and Fernhollow Excess (umbrella). Commercial auto is ordered from Thistledown Casualty but not received. Every carrier named is the expiring carrier on file; the agent never invents a date or a loss figure.
Four items the markets need, each traced to the SOV row or exposure it fills.
Two placement controls warn: the SOV is more than a year old, and more than one in ten locations has gaps. Neither blocks; both go on the decision record and onto the account’s insights.
Accepting carries the order out as the account manager and marks both loss runs ordered. The answer, and who gave it, is written to the decision record.
The account manager adds a note to the client request and accepts. Today the message is a dry run recorded by the platform’s dry-run provider; nothing is e-mailed from the demo.
As loss runs arrive (valued within 90 days) and the client returns the SOV, the checklist re-scores. The 90-day mark expects the submission stage; the calendar will say if the placement falls behind.
What the agents prepared, and what each rests on
| Agent | What it prepared | What it cites | Who decides |
|---|---|---|---|
| Renewal readiness | Order loss runs for 2 lines from the incumbent carriers | Loss run status per line; the expiring program’s carriers | Account manager |
| Data-gap chaser | Ask the client for 4 items the markets need | SOV rows 5 and 8; exposure data updated 2026-10-04 | Account manager |
| Submission builder | Version 3 drafted with 9 open items flagged; not yet proposed for approval | Every section’s source | Placement broker |
| Supervisor | Two controls on the record; nothing to sign off | SOV_STALE, SOV_QUALITY | Practice leader if one refers |
Edge cases
| What happens | What InsightPlacement does |
|---|---|
| A loss run arrives valued 120 days ago | It counts as received but stale; the received check stays unmet until a run valued within 90 days is in. |
| Inside 60 days with a loss run still missing | The LOSS_RUNS_LATE control refers the placement to a practice leader. |
| New business with no expiring program | The expiring-policies check does not apply; the checklist re-weights without it. |
| An exposure moves 15% or more on last year | It is listed as a big change so the submission explains it before an underwriter asks. |
The decision record for this placement
| Section | Hit | Outcome |
|---|---|---|
| Control | SOV_STALE: the statement of values hasn’t been updated in more than a year | warn |
| Control | SOV_QUALITY: more than one in ten SOV locations has gaps | warn |
| Agent | Renewal readiness: order loss runs for 2 lines (accepted by the account manager) | proceed |
| Agent | Data-gap chaser: ask the client for 4 items (changed, then accepted) | proceed |
For the account team
The list of what is owed is written for you, with the carrier for each loss run and the location for each SOV gap. You accept, change or reject; you do not rebuild it from email.
For broker IT
Every figure on the page comes from place_engine functions over plain rows; the agents receive numbered facts and their output is checked before anyone sees it.
For practice leaders
Readiness at each mark is a number you can trend across the book, and “behind the calendar” is a count on the renewals page rather than a surprise in week sixteen.
Questions we get asked
Does the agent order the loss runs itself?
No. It prepares the order; a person accepts it. Every action in InsightPlacement is capped at L2 (ask first).
Where do the weights come from?
They are the product’s readiness engine defaults, chosen so exposures and received loss runs count most. They are visible on the readiness tile’s formula.
What if the client sends the SOV as a spreadsheet?
Import it as CSV in the Readiness zone; the SOV engine re-checks every row and the gaps update.

