Manish Garg is the cofounder and chief product officer at Skan.ai, an AI process intelligence platform.
getty
Ask where AI will change insurance first, and the answer is almost always the same: claims. It is the use case in every keynote and every board deck. It is also the one that disappoints most reliably once it reaches production.
The pattern is familiar enough to be folklore. A carrier announces a multiyear transformation. Eighteen months later, the cycle time gains are real but smaller than promised, straight-through rates have moved a few points and the sponsoring executive has moved on. Then another carrier announces something similar.
I don't read that as a story about whether the technology is ready. It is a story about sequence, about what gets understood before anything gets automated.
The map is not the work.
On paper, a homeowner‘s or auto claim runs five or six steps: notice of loss, coverage verification, investigation, reserving, settlement, closure. It is accurate the way a map of the U.S. is accurate. It gives you the shape, not the territory.
Trace a month of real claims and the picture changes. A typical auto bodily injury claim could have roughly 30 documented steps. Watch what actually happens, and you might count closer to 200 discrete interactions across some dozens of variant paths that cross multiple systems and functions. The handoffs are where most of the cycle time hides.
Most of that variation is invisible to the people who drew the map, because it lives in the second-by-second behavior of the adjuster, not in the workflow states the system records. That gap, between 30 steps and 200, is the fault line.
Straight-through processing is the wrong target.
The dominant goal has been straight-through processing: move some percentage of claims from notice to settlement without a person touching them. The number gets revised upward in every road map and downward in every retrospective.
The frame itself is the problem. It treats the claim as the unit of automation, but a claim is not a process. It is a case, a particular arrangement of policy, loss, claimant and evidence, moving through subprocesses that each have their own automation potential.
A clean auto claim with photo-documented damage might hold eight subprocesses that automate cleanly, two that automate partially and one, the rental car conversation, that a person does better.
So the question is not whether the claim goes through automatically, but which subprocesses do, which get agent assistance and which stay with people by design. It sounds like a small adjustment. It changes everything downstream: The metric moves from straight-through rate to subprocess coverage, the architecture from one workflow to a set of composable agents and governance from one go/no-go to a portfolio of decisions.
One step could have three answers.
Coverage verification looks like a single step. In practice, it varies enormously by what is being claimed.
For wind damage outside a named-storm region, it is mostly checking effective dates, deductibles and a short list of exclusions: stable work, few variants, little judgment. An agent with the policy, the loss details and the carrier's guidelines can handle it, escalating anything that does not fit.
Water damage is a different exercise. Someone must decide whether the cause was sudden discharge from a plumbing failure or long-term seepage, a call that turns on the inspection report, the claimant's account and years of accumulated carrier interpretation. The agent prepares the case and surfaces precedents; a person decides.
Smoke damage from a wildfire still under investigation is a third case. The carrier is waiting on a cause-and-origin report, the regulatory picture may be shifting and the claim sits inside a catastrophe response. It stays human end to end.
Same step, three strategies. The agent does not handle coverage verification. It handles the wind-damage variant, in non-named-storm regions, under stable policy conditions. The scope has to be that precise.
What does the sequence look like?
I would argue for roughly this order. Observe the work for 30 to 60 days rather than interviewing people about it. What you want is a record, not a map: what people do, in what order, in which systems, including the workarounds and the cases that fit no named variant.
Segment that record into subprocesses and variants. For a midsized carrier, this usually lands between 40 and 60 subprocesses, each carrying three to 12 variants.
Score every variant on four things: how stable it is, how much judgment it carries, how often it throws exceptions and how much the customer cares whether a person handled it. Stable and low-judgment runs autonomously. Add judgment, and it becomes agent-assisted. Anything customers feel strongly about stays human regardless.
Then deploy in waves, keep the observation layer running and stop treating any of it as a project. There is no completion event; the catalog keeps evolving, and the agents keep being tuned.
Name what will not move.
A credible program must define where humans are critical. These situations include catastrophic loss conversations, where a customer has lost their home and the first call sets the tone for everything after, coverage disputes headed toward denial and fraud investigation, where the agent prepares data and the investigator judges. Any moment where mishandling could create extra-contractual exposure.
The specific list matters less than having one. A program that promises to automate everything has not done the scoping, and the scoping is most of the work.
Consider the precondition.
All of this rests on a faithful record of how the work is performed today. Without it, the inventory is guesswork, the scoring is guesswork and the agents get deployed against an idealized version of the job.
The organizations moving fastest have almost all invested in continuous process observation before investing in agents. The ones that went the other way spent the same money and got less. Agentic systems perform in proportion to the context they are given, and in claims, the context is the work.
The technology was never going to be the differentiator. Doing the process work first is.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
>> Home