Engineering Blog · Post #78

Broker Book: Key Products Per Region with Target vs Actuals

Marsh writes Cyber in the Northeast, Property in the South, and Casualty everywhere. Which of those are key for your relationship? How are you tracking against target in each cell? InsightUW answers in a grid.

The Problem

Broker relationships aren't uniform. A single broker can be strategic in one LOB × region and tactical in another. Traditional broker-360 pages flatten that into "here are all the policies" — you get a list, not a map. When the broker-relations manager asks, "how are we doing on Marsh Cyber in the Northeast?" — you Excel it.

The InsightUW Approach

InsightUW's Broker Book renders a product × region matrix per broker. Each cell shows actuals (premium, submissions, hit ratio), target, key-product flag, and optional YoY. UWs flag key products; managers set targets. Everything is tied back to real Policy bound premium — no estimates.

graph LR subgraph Inputs["Inputs"] I1["Policy.broker id<br/>+ insured.state → region"] I2["Submission Queue.broker id<br/>for in-flight"] I3["Broker Product Appetite<br/>is key · priority · target_*"] end subgraph Build["Matrix builder"] B1["Group policies by (product, region)"] B2["Overlay appetite row for each cell"] B3["Compute hit ratio from submissions"] B4["Optional: YoY same grid, 1 year prior"] end subgraph Grid["Product × region grid"] G1["★ Key flag"] G2["Actual / Target bar"] G3["YoY %"] G4["Hit ratio + subs + bound"] end I1 --> B1 I2 --> B3 I3 --> B2 B1 --> Grid B2 --> Grid B3 --> Grid B4 --> G3

Region Resolution

Region is derived from the risk side — the insured's state, mapped via Reference Data(entity_type='territory') with a built-in US fallback (Northeast / Southeast / Midwest / South-Central / West). A broker's own office region is a separate secondary scope, so you can also ask: "what does Marsh's Chicago office book with us?"

The Grid

★ = flagged key product for this broker. The progress bar colors: red < 50%, orange 50–79%, blue 80–99%, green ≥ 100%.

Roles

UWs can flag is key / priority / strategy note for any cell — their relationship POV.
Managers (manager / senior_uw role) additionally set target premium / target submissions / target hit ratio.
The role gate is enforced server-side; UW-only payloads drop through, target-setting payloads are rejected with 403 if the caller lacks the role.

Click a Cell

Opens a modal with the 12-week premium sparkline for that cell, inline edit for key/priority/note/targets, and a delete option if the appetite row is no longer relevant.

Bulk Seeding

For onboarding a broker relationship, POST /brokers/{guid}/appetite/bulk accepts an array of rows — the broker-relations team can seed the whole matrix at once instead of clicking 40 cells.

Saved Views

Each UW saves their frequent cuts: "Marsh Cyber deep-dive", "Top 10 brokers by Property", "All my key products this quarter." Views persist server-side per UW via Broker View Pref.

Under the Hood

One SQL query per matrix — Policy joined to Insured for state, Broker for office region, aggregated by (product, region) in Python.
Broker Product Appetite is dual-purpose — it's both the key-product flag and the target row. Period-scoped (monthly / quarterly / yearly / null = evergreen), so targets can reset without losing the strategy note.
Actuals use Policy.written_premium with a fallback to premium; no 0.02×limit estimates.
Top-brokers leaderboard — a companion GET /top-brokers?region=&product=&period= ranks all brokers for a slice, letting a manager cross-compare.

What This Means

Broker relationships are multi-dimensional — treat them that way.
Targets stay where the work is — in the cell the UW clicks.
Role split is clean — UWs flag what matters, managers set the numbers.
No estimate math — actuals come from policy records with real effective dates.

What's Next

Next: My Accounts, My Lines, My Renewals: Three Personal Dashboards

Want a broker book that actually shows the relationship? Request a demo.