Regional carriers, MGAs, and mid-size agencies and brokerages. Assumes a policy system, an agency management system, and a claims system with partial overlap.
Submission triage and appetite matching
In one line: Ranks the submission queue so underwriters work the accounts most likely to bind and most likely to be profitable.
Who uses it and when: the underwriter, first thing, on a queue ordered by fit and likely profitability instead of the order submissions arrived in. It changes one decision: which account gets quoted first.
What it does not do: it will not bind the policy. It orders the queue; the underwriting decision is still the underwriter’s.
Usually needs building.
It depends on submissions that were declined or never quoted, and those do not make it into the policy system, because the policy system is built to hold policies. What survives is only what was bound, so there is no record of what was seen and turned away, only of what was written. Capturing every submission at the moment it arrives, not just the ones that become policies, is the project. The feature is what happens after it.
The pain: “Submissions pile up, we quote whatever is on top, and the good ones go to whoever answered first.”
What it runs on
- One row per: one submission received, at one version, for one effective date. Declines and not-taken-ups are rows too. Especially those.
- Described by: producer and agency, named insured, line of business, class or industry code, geography, effective date, underwriter, limits and attachment, distribution channel, outcome.
- Must agree across systems: producer, insured, line of business, and class code. Producer codes in the agency management system and in the policy system are usually different, which quietly breaks every producer-level number.
- History: you need history on your own appetite. Which classes were in appetite, at what limits, on the date the submission arrived.
Why it usually fails: declined and never-quoted submissions never make it into the policy system, because the policy system is built to hold policies. The data therefore contains only what you bound, so the model can learn what you wrote but not what you should have declined, which is the more expensive question.
Claim severity early warning
In one line: Flags the claim that is heading for a large payout early, while reserve strategy and counsel decisions are still open.
Who uses it and when: the adjuster or claims manager, inside the first ninety days, on a flagged claim instead of a surprise at settlement. It changes one decision: whether reserve strategy or counsel gets revisited now.
What it does not do: it will not set the reserve. It flags which claim is moving that way while the decision is still open.
Usually needs work.
It depends on claims and their financial transactions, which are already recorded. The reserve is the problem: the system stores only the current figure and overwrites it on every change, so the pattern of how a reserve moved in the first ninety days, the thing worth predicting from, was never kept. Nothing new has to be built. Reserve changes get kept instead of overwritten, and cause-of-loss codes, which mostly land on “other,” get enforced against a real list.
The pain: “The claims that hurt us did not look like much for the first ninety days.”
What it runs on
- One row per: one financial transaction on a claim. One reserve change or one payment, on one claim, on one coverage, on one date. Every movement, kept.
- Described by: claim, policy, insured, coverage, adjuster, loss date, report date, cause of loss, jurisdiction, litigation status, claimant attorney involvement.
- Must agree across systems: policy, insured, coverage, and cause-of-loss codes. A claim that cannot be tied to the policy that covers it is not analyzable.
- History: this feature is history. The pattern of how a reserve moved over the first ninety days is the entire signal. Adjuster reassignment history matters too, because a claim that changed hands three times behaves differently.
Why it usually fails: the claim system stores only the current reserve and overwrites it on every change. The development pattern, which is the thing worth predicting from, was never written down. Cause-of-loss codes are the other problem: nobody was trained on the list, so a large share land on “other” and the most useful descriptor is empty.