Operated function · claims intake
Almost no claim arrives with everything needed to assess it. What determines how long it takes is not the assessment — it is how many separate times somebody has to go back to a claimant for one more document, and how long each of those round trips takes.
The claim arrives — a call, a form, a broker, an app — and it is incomplete, because the person making it was describing an event rather than completing a file. They do not know which of the forty things you need are the eight that apply to them.
It sits in a queue until somebody opens it. That person reads it, works out what is missing, and sends a request. The request lists what they noticed. Three days later the documents come back and a second thing is missing, either because it was not obvious the first time or because the first document revealed a new requirement.
Each of those round trips is days, and the days are asymmetric: a request goes out instantly and comes back at the speed of somebody who is dealing with a flood, a funeral, or a car they no longer have. Chasing them feels wrong, so it happens late.
The claimant experiences this as being asked repeatedly for things they thought they had already provided, at the worst possible time. That experience is what generates complaints, and the complaint is almost never about the outcome — it is about the number of times they were asked.
And the reporting is cycle time, which blends assessment work with waiting on a claimant and waiting for a third party. Three completely different problems in one number, and the only one anybody can act on directly is the smallest.
What is required to assess a claim depends on the claim, and completeness is established incrementally as a human reads the file — so each read produces one more request, and each request costs a multi-day round trip.
Collapsing that is the whole operation. If the full requirement set for a specific claim type and circumstance can be established at first notice, the claimant is asked once, comprehensively, at the moment they are already engaged — which is both faster and considerably kinder than three requests over two weeks.
That is bounded, rules-driven work: given this claim type, this policy, these circumstances, which items are required and which are conditional on something else being present. It is precisely the kind of thing that is tedious for a person to do exhaustively and easy to do partially, which is why it is done partially.
The second move is making the waiting visible and separate. Time spent assessing, time waiting on a claimant, and time waiting on a third party are three different problems, and only the first is capacity. Reporting them as one cycle-time number is why claims operations reliably invest in the wrong one.
And the recurrence data is the permanent fix. When the same item is missing on most claims of a type, the form or the first-notice script is wrong, and correcting it removes the round trip for everybody rather than chasing it per claim.
What does not move is the decision. Whether a claim is covered, what it is worth, and whether it is declined are determinations with contractual and regulatory weight, and they stay with your assessors under your authority.
Round trips per claim — measured by separate information requests sent per claim, against your own baseline — the number that most directly drives both cycle time and complaints.
Time from first notice to a complete file — measured by elapsed days to completeness, separately from time to decision.
How cycle time actually divides — measured by assessing, waiting on claimant and waiting on a third party, split rather than blended.
Complaints about process rather than outcome — measured by complaints citing repeated requests, against your own prior period.
Items missing most often — measured by frequency by required item and claim type, which points at the form rather than at the claim.
Assessor time spent assessing — measured by assessor hours on complete files versus on chasing, sampled the same way before and after.
any coverage determination, valuation, settlement or decline, and no assessment of whether a document is genuine or a claim is valid. Nothing here decides anything about a claim. It establishes what is required and whether it has arrived — and a system that started judging validity would be making regulated decisions without the authority to make them.
Claims stay in your claims system and documents land in your document store. Nothing migrates, no second claim record is created, and no file exists outside the system your assessors and auditors work from.
The requirement rules are yours: written by your claims leadership, versioned, and owned — because they encode your policy wordings and your regulatory position, and a requirement set that lives only inside a vendor is a compliance dependency rather than an asset.
Where a third party is in the loop — a repairer, a medical provider, an adjuster — their part of the waiting is tracked as its own class rather than folded into claimant delay, because they are chased differently and by different people.
The tone is not decoration here. Every message is written and approved by your claims leadership, in plain language, and it explains why each item is needed rather than listing references. A claimant who understands why is a claimant who sends the right thing once.
Vulnerability is a routing class rather than an afterthought. Where a claim carries indicators your policy defines — bereavement, serious injury, distress expressed at notice — it routes to your people rather than into a request sequence, and that rule is written before anything is sent.
Every contact and every document carries a receipt: what was asked, when, what arrived, and what was still outstanding. In a regulated claims operation that record is the answer to a complaint and to a regulator.
Operational access is not permission to train. Claims data — which includes health information, financial circumstances and sometimes the details of a death — does not become material improving anything serving another organisation.
Compliance will want the boundary in writing: what is established versus what is decided, and the explicit statement that no determination happens here. That distinction is the whole basis on which a regulated claims operation can delegate anything at all.
Whoever owns your vulnerable-customer policy owns the routing indicators. Those cannot be vendor defaults — they are specific to your book, your regulator and your obligations.
Where an obligation attaches through your regulator, your policy wordings or a data class, it is marked applicability-gated rather than presented as standing.
A single claim type over one trailing period — read-only, nothing sent — counting information requests per claim and splitting elapsed time into assessing, waiting on claimant and waiting on a third party.
The observation phase contacts nobody and produces the two numbers that matter: how many separate times a claimant was asked for something, and how cycle time actually divides. Most claims operations report one blended figure and have never seen either.
The recurrence breakdown comes with it — which required item is missing most often on this claim type. Where one or two items dominate, the correct fix is the first-notice form or script, which removes the round trip for every future claim and requires no operated intake at all.
If you continue, the first delegation is establishing the requirement set and sending a single comprehensive request on one claim type, with vulnerability routing live before anything is sent.
The decisions are not delegated and the page says so in several places, because it is the only basis on which any of this is appropriate. What is delegated is establishing which items a claim requires and whether they have arrived — mechanical completeness, not validity and not coverage. If your regulator or your own compliance position holds that even completeness-checking is a regulated act in your line, then the honest scope is the observation phase alone, and it is still worth doing.
For some of them it is, which is why vulnerability indicators are a routing class written by you and live before anything sends, and why those claims go to your people rather than into a sequence. The argument for the rest is that the current experience — three separate requests over two weeks — is the thing generating complaints. Being asked once, clearly, with an explanation of why each item is needed, is the kinder version.
Every claim is different in its facts and highly patterned in its requirements, which is why the rules are conditional rather than a fixed list: this claim type, this wording, these circumstances, therefore these items and these conditional ones. Where the rules cannot determine a requirement, the claim goes to an assessor to establish it rather than receiving a partial request. The observation phase measures how much of your book the rules can actually cover, and if that share is low this is the wrong operation.
Then the split will show it, and it costs a read-only period to find out. The more common finding is that cycle time looks acceptable in aggregate while the round-trip count is high — which does not show up in cycle time at all but does show up in complaints. If your complaints are about outcomes rather than about being asked repeatedly, your constraint is elsewhere and this will not help.