Reserves get set in the first week and never move until the file closes

Reserves stop moving because nothing in the file ever asks the question a second time. The first-week figure is set when the adjuster has the least information they will ever have about the claim, and unless some specific event forces a review, that figure survives every development on the file until closure quietly replaces it with the payment total.

This is a software problem with a hard boundary drawn around it. A system can watch a file for the events that change expected exposure, put the question in front of the person who holds authority, attach the documents that caused it, and record what was decided. It cannot propose the number. BuildspaceLabs builds claims tooling and integrations; we are not a licensed carrier, adjuster or actuary, and nothing here is reserving advice.

Count the reserve entries before anyone argues about adequacy

The complaint usually arrives as a feeling: reserves are stale, the actuaries are unhappy, development is worse than it should be. None of that identifies a fixable thing. The confirming check is a distribution. For every file closed in the last 12 months, count the rows in the reserve history, then cut that count by file age at closure and by the adjuster who held it.

The count alone proves nothing. It becomes diagnostic when you put the events beside it. For each file with one reserve entry and more than 90 days of life, list what arrived in between: documents received, a representation letter, a coverage position, a repair supplement, medical records, a recovery identified. A file that ran 9 months and took in 14 documents while its reserve stood still is not a stable claim.

Cut the same distribution by adjuster before anyone concludes this is a system problem. Where two adjusters carry a comparable mix of loss types and one shows a median of 3 reserve entries per file while the other shows 1, the gap is behavioural and no trigger will close it on its own. Where every adjuster looks the same, the gap is in the software, and it is worth building.

Four reasons a first-week number survives to closure

1. Nothing is wired from the event to the reserve. The system records that a demand letter arrived, indexes it and files it. That path never touches the reserve record, so the single most exposure-changing document on the file produces no prompt anywhere.
2. The prompt exists and arrives as diary noise. A reserve review generated as an ordinary diary entry lands in the same undifferentiated list as a callback and a photograph chase, sorted by date and styled identically. Adjusters clear that list by triage, and a task with no visible consequence loses every time to one with a claimant waiting on the other end — the same queue behaviour that leaves files in the middle of a caseload sitting untouched.
3. The approval step costs more than the correction is worth. Where every change routes to a supervisor with a written justification, a small downward adjustment is rationally skipped. The adjuster is not being lazy; the gate is priced wrong for the size of the decision.
4. Late documents land somewhere that is not the reserve question. The estimate, the medical narrative, the repair supplement arrive in a document queue, get classified and attached, and never reach the person who would move the number. Worse, evidence that arrives unreadable produces no signal at all — the failure traced in damage photos that arrive unusable from the loss report.

The file events that have to ask the question again

A trigger set is a short, defensible list of events that change what a file is likely to cost, each one bound to a prompt that carries its own evidence. Keep it short. A trigger on every document type reproduces the diary noise you are trying to escape.

A referral to a special investigation unit belongs on the same list, because it changes expected expense and often the resolution timeline; what that referral has to contain to be worth sending is set out in assembling a referral packet an investigator will use.

Making the prompt something other than diary noise

• Give it its own queue. A reserve review is a decision with a record, not a chore. Put it where decisions live, count it separately, and report on it separately.
• Attach the evidence, not a reference to it. Render the triggering document beside the current figures so the decision takes under a minute instead of 4 minutes of navigating to find out why the prompt exists.
• Make reviewed, no change a first-class outcome with a reason code. Without it, the only way to clear a prompt is to move a number, and the honest answer disappears from your data entirely.
• Escalate on age, not on volume. A prompt untouched for 10 days goes to the supervisor who holds that file, with the file attached — not into a nightly digest of 60 prompts that nobody opens.
• Retire superseded prompts automatically. If a reserve moved for any reason after the trigger fired, close the prompt with that link recorded, so the queue reflects outstanding questions rather than historical ones.

The approval gate that prices small corrections out of existence

If every reserve movement needs a signature, adjusters batch changes until they are large enough to justify the paperwork, and the batching is exactly what produces the flat line you are investigating. The workable shape is banded: movement within a defined band on a file the adjuster already holds is recorded with a reason and no second signature; movement that crosses the band, changes the reserve category, or lands on a file already flagged goes up.

That is the same design argument the payment side has already had, and it resolves the same way — a tier that handles the ordinary case and named exceptions that override it, laid out in authority levels or exception rules for claim payments. Reserve changes are usually the easier half, because a reserve is not money leaving the building.

Stair-stepping is the same report read backwards

The mirror-image failure is a file whose reserve rises in a long series of small increments, each one sized to stay under the threshold that would trigger a review or a supervisor conversation. It produces a file with plenty of reserve entries and just as little thinking behind them, and it damages development reporting in a way that a flat reserve does not.

1. Order every reserve change on a file by date and record the delta, the direction and the reason code attached to it.
2. Flag files where 4 or more consecutive changes run in the same direction with no intervening file event from the trigger list — movement with no cause recorded against it.
3. Flag separately any change that lands within a narrow margin below an authority band or review threshold, and count those by adjuster. One or two are coincidence; a pattern is a gate being routed around.

A reserve that never moves and a reserve that moves in twelve identical steps are the same failure wearing different clothes: nobody was asked a question they had to answer.

What a trigger set will not fix

Triggers make the question unavoidable. They do not improve the answer. An inadequate initial reserve stays inadequate until someone with better information changes it, and a prompt on day 40 does not retroactively fix day 3. Nor will any of this settle the reserving philosophy underneath — whether a file is reserved to the most likely outcome or to a probable worst case is a carrier policy decision, and a system that has not been told which one is in force will produce prompts that feel wrong to half the desk.

One prerequisite is not optional. If reserve changes are stored as an overwritten current value rather than an append-only history with a user, a timestamp and a reason on every row, none of these checks can be run at all, and no audit of them will hold. That storage change is usually the first piece of the work, and it is ordinary product build engineering rather than anything clever. This page sits in claims handling, fraud flags and recovery, part of our insurance and claims software practice.

• claims reserving
• claims handling
• workflow triggers
• claims software