Claim severity score: a routing input, not a reserve and not a decision
In short
A claim severity score is a number produced at intake estimating how demanding a file will be, and its only legitimate job is ordering work: which queue, which skill level, how urgently. It must not set a reserve, take a coverage position, decide liability or authorise a payment.
Key takeaways
- A severity score orders work. It does not decide anything a licensed person is accountable for.
- Split the feature list by availability: facts present at notice versus facts that only exist days later.
- Bands beat points. A 0 to 100 score implies precision the inputs at notice cannot support.
- Store the score with its inputs and model version, or you cannot answer why this file was fast-tracked.
- A score that changes routing must re-route when late facts arrive, not stay where the first guess put it.
A claim severity score is a number attached to a new claim that estimates how demanding the file will be to handle. Its purpose is ordering work: which queue the file joins, which experience level it needs, and how quickly someone should pick it up. That is the whole remit. It is a scheduling input, not a finding.
The distinction is easy to state and easy to erode, which is why it belongs in the definition rather than a policy document. Once a score is on screen, people read meaning into it. BuildspaceLabs builds triage software and is not a carrier, broker or adjuster, so read this as system design, alongside the rest of claims intake, FNOL and triage.
The score orders a queue; it does not describe a claim
A useful severity score answers one question: of the files that arrived in the last hour, which should be opened first and by whom. That framing has a consequence — the score only needs to be right in rank order, not in magnitude. A model that separates the top decile from the rest is doing its job even if every individual number is wrong.
This is also why 3 to 5 bands usually beat a 0 to 100 point score. Bands match how work is actually allocated, and they stop a handler treating 62 as meaningfully different from 58 when the underlying inputs cannot support that resolution.
Facts you have at notice, and facts that only look available
| Feature | Available at notice? | What it is really telling you |
|---|---|---|
| Injury reported, yes or no | Yes | The strongest single signal available at first contact, and often the only one that matters |
| Third party involved | Yes | Predicts correspondence volume and duration more than cost |
| Lag between date of loss and date reported | Yes, if the dates are stored separately | A long lag correlates with evidence problems, not necessarily with a large loss |
| Coded cause of loss | Sometimes | Reliable for collision and fire; frequently pending for water and theft |
| Extent of damage from photographs | Rarely | Depends on images that may be unusable or absent at the moment routing runs |
| Prior claims on the policy | Yes | A history lookup, not a prediction; it says how this insured has behaved before |
| Estimated repair cost | No | It exists after an inspection. Any value at notice is the caller's guess wearing a number |
Two rows carry most of the disappointment. The lag row only works if the record keeps date of loss, date reported and date received as separate fields; systems that store one date cannot compute it at all. And the photograph row is optimistic in almost every deployment, because first-notice images are commonly too dark, too close or missing the angle that matters at the moment the score is calculated.
Four decisions the number is never allowed to make
- Coverage. Whether the policy responds is a question about wording and facts, and a severity band contains neither. A high score on an uncovered loss is still an uncovered loss.
- Reserve amount. A reserve is an estimate of ultimate cost with accounting consequences and named accountability. A routing score has no business populating that field, even as a default a handler can overwrite.
- Liability. Fault is determined from evidence and law. Nothing about how demanding a file looks says who was at fault.
- Payment. No score should authorise, accelerate or size a payment. Approval authority belongs to people and to written limits, not to a percentile.
Being able to answer why this file went where it went
- Persist the score with the exact input values used, the model or ruleset version, and the timestamp. Recomputing later gives a different answer and proves nothing.
- Store a reason in words, generated at scoring time — the 2 or 3 inputs that moved this file into this band — rather than reconstructing an explanation on demand.
- Log the routing decision separately from the score. The score is an input; the queue assignment is the act, and they can diverge when a rule overrides.
- Re-score when a blocking fact arrives, and record both the old and new band. A file routed low because the injury question was unanswered must move when the answer lands.
- Sample 20 files a week where the handler disagreed with the band, and read them. Disagreement clusters are how you find a stale threshold before a report does.
Without that trail, two failures become unanswerable: low-severity files that keep landing in the complex queue, and the harder one, nobody being able to say why a claim was fast-tracked. Both are evidence problems, cheap to prevent and expensive to reconstruct.
Scoring is a small component inside a larger workflow, and it earns its place only when the queue design around it is right. That is the sort of build we do as internal tools and ops work within the insurance and claims practice: a bounded score, a written routing spine, and a log that survives the question asked 18 months later.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is claim severity scoring at intake?
It is the practice of attaching a number or band to a newly reported claim to estimate how demanding it will be to handle, so files can be ordered and allocated. It is a workload signal, not a valuation. The useful output is which queue and which skill level, not how much the claim will eventually cost.
Can a severity score be used to set the initial reserve?
No. A reserve is an accounting estimate of ultimate cost, owned by a person with authority to set it, and a routing score is built from a handful of facts available in the first minutes. Using one to seed the other imports a scheduling heuristic into the financial statements and makes the reserve's basis impossible to explain afterwards.
Why do severity models perform worse in production than in testing?
Usually because they were trained on facts that only exist after notice. Repair estimates, inspection findings and injury detail are present in historical data and absent at the moment routing runs, so a model that looks strong offline scores real claims on a much thinner feature set. Rebuild the training set using only what is populated at the point the decision is made.
- claims triage
- severity scoring
- routing
- model governance
Read next
- First notice of loss: the fields that turn a call into a workable fileA first notice of loss is not a claim file. It becomes one when it carries enough structure to be routed, clocked and reserved without a call back to the reporter.definition
- Cause of loss: the coded field, and why the caller's story is not itThe loss narrative and the coded cause of loss are two fields with two jobs. Conflating them gives reporting nobody trusts and routing nobody can explain.definition
- Date of loss, date reported, date received: three fields that are not the same fieldOne date decides coverage, one decides whether notice was late, and one starts your service clocks. Collapsing any two of them breaks something you will not notice for months.definition
- The damage photos come back too dark, too close, or missing the one angle the adjuster needsSplit your photo rejections by capture path and device class before redesigning anything. In-app camera and gallery upload fail for entirely different reasons and need different fixes.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation