The oldest and newest files move; the ones in the middle of a caseload stop

Files in the middle of a caseload stop moving because nothing is pushing them. A new loss has a service clock, a first-contact standard and a supervisor watching the new-loss report. A very old file has an escalation, a complaint, a suit or an audit behind it. The band in between has no forcing function at all, so it accumulates — and it accumulates fastest on the desks that look busiest.

The pattern is measurable before it is fixable, and the measurement is not the one most claims systems ship. Pending inventory by age tells you how much is open, not how much is moving. What you need is the gap since something a person actually did.

Plot the touch gap against file age and look for the trough

Take every open file, compute days since the last substantive touch, and bucket that by how long the file has been open. If the shape is real, the median touch gap will be low at both ends of the age range and rise sharply somewhere in the middle. That trough is the population, and it is usually narrower and older than anyone guesses — commonly the band between roughly 45 and 180 days.

What counts as a touch, and what is the system talking to itself

This measurement lives or dies on the exclusion list. Most claim systems write notes constantly — a document indexed, a payment posted by a batch job, a status synchronised from a policy system, an automatic acknowledgement letter, a diary entry created by a rule. Count those and every dormant file reports as touched last night.

• Counts as substantive. A note authored by a named user, a logged outbound contact attempt, a document reviewed and dispositioned by a person, a reserve change, a payment approved by a human, a status change with a reason code attached.
• Does not count. Anything with a system or integration user id, auto-generated correspondence, document intake and classification, nightly synchronisation writes, and diary entries the system created rather than a person.
• The awkward middle. An adjuster opening the file without writing anything is genuine attention that leaves no artefact. If your system logs views, keep them in a separate column rather than folding them into the touch date — a file that was looked at 9 times and never worked is its own finding.

Four reasons the middle of a caseload is the part that stops

1. The work queue sorts on one dimension. Whatever that dimension is — oldest diary date, newest assignment, highest reserve — the queue produces a stranded band on every dimension it does not sort by. A single sort key is not a prioritisation scheme; it is a guarantee about what will be ignored.
2. Diary dates collide. Entries set in bulk at intake, or at a common event plus 30 days, land on the same handful of dates. The adjuster clears the top of that day's list, the remainder rolls forward, and it collides with the next day's cluster. Files that lose two or three roll-forwards in a row do not resurface on their own.
3. Reassignment resets the age that anyone can see. Many queue views show days since assignment, not days since notice. Move a 200-day file between desks twice and it presents as a 12-day file to the person now holding it, with none of the urgency its real age deserves.
4. There is no blocked state. A file waiting on an appraisal, a police report, medical records or another carrier's response is not workable today, so the adjuster skips it — correctly. Nothing in the record distinguishes skipped because blocked from skipped because forgotten, and no clock is running on the party that owes the answer.

Duplicates deserve a separate line in this report. A second claim number opened against one loss is a file with no real owner, and it will sit in the trough indefinitely because nobody is waiting on it — the detection and merge problem covered in one loss that opens two claim numbers. Exclude confirmed duplicates from the touch report before drawing conclusions, or they will dominate it.

Diary collisions and the roll-forward nobody counts

The diary is the only forcing mechanism most files have, and it fails in a specific, countable way. Count entries due per adjuster per working day for the next 60 days. If the distribution has spikes of 3 to 5 times the median, the roll-forward is doing the scheduling, not the adjuster.

1. Count diary entries per adjuster per day, then count how many were completed on their due date versus rolled.
2. For rolled entries, count consecutive rolls per entry. Anything past 3 has stopped functioning as a reminder and should escalate rather than roll again.
3. Spread new entries deterministically: when a rule sets a date, jitter it across the surrounding few working days against that adjuster's existing load rather than posting every one at plus 30.
4. Give recurring reviews a band rather than a date — due within this week — so the queue can level itself without every entry looking late.

Blocked needs to be a state with a clock on the other party

The single highest-value change in this whole diagnosis is usually the cheapest: give the file an explicit waiting-on state that records who owes the answer, what was requested, when it was requested and when it was promised. That turns an invisible skip into a tracked obligation with a chase schedule, and it removes the blocked population from the untouched report so the genuinely forgotten files stand out.

• Waiting on an estimate or a supplement is the most common block, and it is also where the review work sits once the document lands — the mechanics of that check are in how estimate review finds line items that do not belong.
• Waiting on an investigation is a legitimate block only if the referral was complete when it was sent; a packet an investigator has to rebuild adds weeks to the block, which is the argument in assembling a referral packet an investigator will use.
• Waiting on a third party does not pause the clocks that matter outside the file. A stranded file still burns the recovery window, and screening it late is exactly the failure described in finding recovery potential before the limitation runs.
• A block with no promised-by date is not a block. If the request has no expected return date, the file is not waiting on anyone; it is parked.

Pending inventory tells you how much is open. Only the touch gap tells you how much is moving, and the two reports rarely point at the same desks.

The cut that surfaces a stranded file before a complaint does

Run one daily report, not a dashboard. It lists files where the touch gap exceeds the threshold for that age band, excludes anything in a blocked state with a live promised-by date, excludes confirmed duplicates, and sorts by age band rather than by adjuster. Route it to the supervisor who holds the desk, capped at a length someone will read — 20 files is a working list and 200 is wallpaper.

Two secondary cuts are worth having beside it. First, files where the reserve has not moved despite documents arriving, since a stranded file and a reserve set once and never moved are usually the same file. Second, open outbound requests past their promised-by date grouped by the party that owes them, which turns a scatter of individual chases into one conversation with a vendor.

What this diagnosis does not tell you

The touch report identifies where inventory is stalling. It does not establish that the desk is over capacity, and reading it as a capacity signal is the most common misuse. A trough appears at very ordinary caseload sizes whenever the queue has one sort key and no blocked state, and adding an adjuster to that arrangement produces two people with a trough each. Fix the ordering and the state model first, then measure again before anyone argues about headcount.

It also says nothing about whether a file was worked well. A file touched every 6 days by a note that reads chased again is not progressing, and no gap-based measure will catch that. Building the report, the exclusion list and the blocked state is internal tools and ops work that usually sits alongside an existing claims system rather than replacing it. This page belongs to claims handling, fraud flags and recovery, part of our insurance and claims software practice.

• claims handling
• adjuster workload
• queue design
• claims aging