A sentence like that is a budget, not a requirement
"We want to use AI on our claims data" tells you three real things and no more: somebody senior has money and attention for this, the subject area is claims, and nobody has done the work of deciding what problem to solve. Treating it as a requirement to be clarified in a workshop wastes the first fortnight of a six-week engagement. Treating it as an unallocated budget looking for a target is more accurate and considerably more actionable, because it tells you the first deliverable is a target rather than a system.
The reframing that gets you there fastest is to stop asking what they want built and start asking what decision, made by a named person, on a known cadence, is currently made worse than it could be. Every useful version of this engagement ends up attached to a decision like that: which claims to route to a specialist handler, which of today's submissions need a human to look at the attachments, which reserves are likely to be revised upwards next month. Those are shippable in six weeks. "Use AI on claims data" is not shippable at all, because there is no state of the world in which it is finished.
Find the decision, then find what it is worth
The interview to run is not a requirements workshop, it is a shadowing exercise. Sit with the people who handle claims and watch what they do, because the expensive decisions are usually visible within an hour and almost never appear in the brief. What do they look up repeatedly? What do they wait for? Which cases get bounced between teams? Where is somebody re-typing something from one screen into another? Where is a spreadsheet doing work the system was supposed to do?
Then attach a number to the candidates, derived visibly from things the customer can confirm rather than asserted. If forty handlers each spend an hour a day gathering documents before they can assess a claim, that is forty hours daily, and halving it is a claim the sponsor can evaluate against your fee without taking your word for anything. If a misrouted claim costs a fortnight of elapsed time and one in six is misrouted, the value of better routing follows from the customer's own figures. The point of the arithmetic is not precision, it is that the sponsor and you are now looking at the same quantity and can rank three candidates by it.
Rank on two axes only: what a better decision is worth, and whether the data to support it exists today. The second is not a design question, it is a matter of fact you can settle with a day of profiling, and settling it in week one is what stops you from scoping something the estate cannot support.
Ship the narrowest slice that changes the decision
The increment should be recognisable as the whole thing to its user while being a fraction of the eventual system. Concretely, for a routing problem: one queue, one team, one category of claim, running against yesterday's data on a schedule, with the output landing in the tool the team already uses rather than in a new interface. No login, no admin screen, no retraining pipeline, no coverage of the other eleven claim types.
Ask as received: "Use AI on our claims data"
Decision found: Which incoming claims need a senior handler
Made by: the triage lead, every morning, from a spreadsheet
Current basis: claim value band, plus experience
Cost of getting it wrong: ~2 weeks of rework per claim
Week 1 increment: Profile the data. Answer one question — do we have
the outcome history to learn from at all?
Week 6 target: A ranked list of yesterday's claims for one team,
in their existing queue, with the reason shown
alongside each score.
Deliberately NOT: other claim types, real-time scoring, retraining,
a user interface, any change to their case system,
automated action without a human deciding.
The final block is the most important part of that document and the part candidates omit. Cuts that are not said out loud are not cuts, they are things you have quietly decided not to do, and the difference surfaces in the demo when somebody asks about the other claim types and discovers they were never in scope. Reading the exclusion list to the sponsor in week one is uncomfortable for ten minutes and buys you the entire engagement.
Design the increment so the answer is inspectable
There is a specific reason the "reason shown alongside each score" line is in the scope above rather than in a later phase. The first version of a system like this will be wrong for some cases, and the people using it will be experienced handlers who can tell immediately when it is wrong. If all they can see is a number, their only available response is to distrust the whole thing, and adoption stops. If they can see what drove the number, their response is to tell you the feature you are relying on is misleading for a particular kind of claim, which is the most valuable information available to you and the thing that makes version two work.
That argues for starting with the simplest model that produces an explainable output, even where you are confident something more sophisticated would score better. On a six-week engagement the constraint is rarely model quality; it is whether the users believe the output enough to act on it, and belief is built by being visibly correctable rather than by being accurate on a holdout set nobody in the business will ever see.
Have a plan for the data not supporting it
Week one exists to answer one question honestly: is there a record of what actually happened, joined to what was known at the time? A great many organisations have plenty of claims data and no usable labels — the outcome was recorded in a free-text note, or it lives only in the closed case, or the historical decisions were made by a rule everyone has since changed, so the history describes a process that no longer exists. Discovering that in week five is a failed engagement. Discovering it in week one turns it into a different one.
The pivot to have ready is a version that delivers value without learning from outcomes. Consistent surfacing of information the handler currently gathers by hand, a rules engine that encodes the triage lead's own spreadsheet logic so that it is applied uniformly, or the instrumentation needed to start capturing the labels that would make the original idea possible in six months. Any of those is a genuine result and the last one is often the most valuable thing you can leave behind, because it makes the second engagement possible.
The characteristic failure on an open-ended AI ask is to build the enabling layer. Six weeks go into a feature store, an ingestion framework, a reusable evaluation harness and a pipeline that could serve any future model, and at the end there is nothing an operator uses and nothing the sponsor can point at. Every individual decision was defensible on the grounds that the customer will need this eventually, and the aggregate is an engagement with no output.
The discipline that prevents it is to insist that something in the customer's hands changes in the first fortnight, however small, and to accept the duplication and manual steps that this implies. Hard-code the one claim type. Run it from a scheduled script. Deliver the list as a file if that is what their queue reads. You will know far more about what the platform should look like after the narrow thing is in use than you could have known before, and if the engagement ends early — which on ambiguous scopes it sometimes does — the narrow thing survives and the platform would not have.
Six weeks buys one decision, made by one named person, done measurably better. Anything scoped more broadly than that is a platform nobody asked for, and the exclusion list is the part of the scope you must read aloud.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).