ClaimsIQ: What a Claims Dashboard Should Actually Show

Every carrier portal and TPA system has a claims dashboard. Most of them show the same thing: a count of open claims, a count of closed claims, total incurred, and a pie chart by body part. That is a report, not a dashboard. It tells you what the book looked like at the valuation date and nothing about what to do next.

For a PEO operator or an MGA, claims are not a compliance record. They are the single largest driver of next year's cost. On a large-deductible master policy, every dollar of reserve inside the deductible layer is a dollar the PEO is carrying. On a guaranteed-cost program, the claims feed the carrier's renewal pricing and, where the client's own mod still applies, the client's mod. Either way, the claims dashboard should be built around the questions an operator actually asks, and we built ClaimsIQ around those questions.

Open reserves versus paid, and why the gap is the story

The first number an operator should see is not total incurred. It is the split between paid and outstanding reserves on open claims, by client and in aggregate.

Paid is history. Reserves are opinion. An adjuster set them, usually with a formula at first report and then by judgment as the file developed. On a book of any size, the reserve component of total incurred is where most of the uncertainty lives, and it is where the PEO's loss fund is most exposed.

A good dashboard shows the paid-to-incurred ratio over time for each open claim, and flags the ones where reserves have sat unchanged for a long stretch while the claim stays open. An unchanged reserve on an old open indemnity claim means one of two things: the adjuster has not looked at it, or the file has stalled in litigation or a medical hold. Both deserve a call. The dashboard should make those calls obvious, not bury them in a sortable table with forty columns.

ClaimsIQ surfaces the reserve-to-paid split at the claim, client, and book level, and tracks reserve changes between loss-run valuations so an operator can see which claims moved and by how much.

Lag: report lag and close lag

Two lags matter. The first is report lag, the gap between the date of injury and the date the claim was reported to the carrier. Long report lags are the most reliable early signal of a client whose supervisors are not managing injuries. They also correlate with higher ultimate cost, because the employee has often already seen a doctor outside the network and the injury has become a dispute.

The second is close lag, how long claims of a given type stay open. Medical-only claims that linger past a few months are a sign of poor case management. Indemnity claims that stay open past their expected life are where reserve creep happens.

A claims dashboard should show both lags as distributions, by client, and compare each client to the book. A client whose median report lag is three times the book median is a client who needs a safety conversation, and that conversation is far more useful before renewal than after.

Frequency versus severity, by client and by class

Total incurred by client is the number everyone looks at and the least useful one on its own. A client with ten small medical-only claims and a client with one large indemnity claim can have the same incurred and completely different risk profiles.

Frequency is the better predictor of future cost. A high claim count, even of small claims, means exposure that has not yet turned into a large claim but will, given enough time. Severity on a single claim can be bad luck. Frequency is rarely bad luck.

The dashboard should show frequency per hundred employees or per million dollars of payroll, by client, and should also cut it by class code. A PEO that writes both 8810 clerical and 5645 carpentry across its book needs to compare each client to the right peer group. A frequency rate that looks alarming for a clerical client is unremarkable for a framing contractor. ClaimsIQ computes these cuts from the same policy-year aggregation ModIQ uses, so the claims view and the mod view agree on what period they are describing.

The claims that drive the next mod

In California, the experience rating formula weights primary losses more heavily than excess losses, and the split point is set by the WCIRB. In NCCI states, the mechanics differ in detail but the principle is the same: the first dollars of each claim count more than the last dollars. That means a book with many claims just under the primary threshold is paying for them in the mod more than a book with a single large claim.

An operator should be able to look at the dashboard and answer two questions. Which open claims will fall inside the experience period for the next mod calculation? And of those, which are sitting at a reserve level that, if closed lower, would materially change the mod?

That second question is where reserve review pays off. A claim reserved at a figure well above its likely settlement value, inside the primary layer, is costing the client, or the PEO, every year until it closes. ClaimsIQ flags open claims by experience-period membership and shows the reserve relative to the primary threshold so the operator knows where a reserve conference with the adjuster is worth the effort.

Reserve optimization signals, without pretending to be the adjuster

There is a line between reserve review and reserve interference, and a software vendor should be careful about where it draws that line. The adjuster owns the reserve. The PEO and the carrier have a legitimate interest in whether the reserve is reasonable, and the carrier's own claims management guidelines usually say so.

What a dashboard can do responsibly is compare each open claim to similar claims in the same book and in the claim's own history. A medical-only claim reserved at several multiples of the book's median for that injury type is worth a question. An indemnity claim where the reserve jumped sharply at one valuation with no corresponding paid activity is worth a question. A claim that has been open for years with a reserve that was set in the first ninety days and never touched is worth a question.

ClaimsIQ generates these signals and ranks them. It does not propose a reserve number. The output is a list of claims to discuss with the adjuster, with the reason each one is on the list. In our own PEO's experience, the reserve conference is where most of the value is found, and the hard part was always knowing which claims to bring to it.

Where the data comes from and why that matters

A claims dashboard is only as current as the loss runs behind it. For most PEOs that means a monthly or quarterly run from each carrier, in each carrier's own format, often across several carriers and policy years for a client that has moved programs.

ClaimsIQ is fed by the same intake pipeline as the rest of HALO IQ. A loss run arriving by email lands in InboxIQ, is classified as a loss run, matched to the client, and parsed with the deterministic parser for that carrier's template, with AI as the fallback for an unfamiliar format. Claims are aggregated by policy year across carriers, so a client with two carriers over five years shows up as one claims history rather than two disconnected files. Each valuation is stored as a snapshot, which is what makes the valuation-to-valuation comparisons possible.

For MGAs the same structure applies to a program's book across its insureds, with the operator role controlling which users see which clients.

What a claims dashboard should not show

A claims dashboard for an operator should not be a general-purpose reporting tool. The temptation is to add every field the carrier sends: claimant name, adjuster name, body part, nature of injury, cause, litigation flag, attorney, ICD codes. All of that data belongs in the claim record and should be searchable. None of it belongs on the dashboard's front page.

The front page should answer four things. What is the book's reserve exposure right now. Where is it concentrated. What moved since the last valuation. Which claims need a conversation this week. Everything else is one click away.

The claims view in a PEO's operating picture

Claims do not exist in isolation. The same client who has a frequency problem has a mod projection in ModIQ that reflects it, a renewal price in PricingIQ that should reflect it, and a safety file in SafetyIQ that should explain what is being done about it. The point of building ClaimsIQ as a module in the same tenant rather than a standalone product is that an operator can move from a flagged claim to the client's workspace in ConnectIQ, see the IIPP status, the open deals, and the renewal date, and decide what to do with the whole picture in front of them.

That is the difference between a dashboard that reports and a dashboard that is part of how the book is run. It is what we set out to build, and it is what we use ourselves.