RPA for claims processing has a reputation problem it partly deserves and partly does not.
The technology does exactly what it says. A software robot logs into your systems, reads a screen, types into a field, clicks a button, and moves on. Robotic process automation exists because enterprise systems are bad at talking to each other and rewriting them is expensive. It is a bridge, and bridges are useful.
The reputation problem comes from what happens when you point that bridge at claims. Six months in, the bots are running, the dashboard looks healthy, and the exception queue is larger than the backlog you started with. Nobody quite knows when that happened.
It happened at the beginning, in an assumption nobody wrote down.
The assumption RPA makes
Every RPA workflow assumes the data already exists in a form the bot can act on. That is not a criticism. It is the design. A bot is a very fast, very literal clerk: give it a value and a destination and it will move the value to the destination forever without complaint.
What it cannot do is look at a photograph of a damaged vehicle and tell you the plate. It cannot read a handwritten loss notice. It cannot open a workshop quote on unfamiliar letterhead and work out which number is the labour total. It cannot notice that an endorsement issued in March changed the coverage the base policy describes.
In a claims operation those are not edge cases. They are the intake.
So the bot is fed by something, and in most implementations that something is either a human doing data entry into a staging form, or a template-based capture tool that works beautifully on the two document types you standardised and hands everything else to a queue.
Both of those are the original problem wearing a new interface.
Why the exception queue grows instead of shrinking
The failure mode is specific and worth naming, because it is predictable enough to plan around.
Automation raises throughput on the easy cases first. Straightforward files clear faster, which is real value. The residue is the hard files, and they now arrive in a queue at the rate the automation clears the easy ones. The queue composition shifts to entirely difficult work.
Exception handling is slower than the original process. A person handling a file end to end builds context as they go. A person handling an exception inherits a partially processed file, has to work out what the automation did, decide whether to trust it, and finish the job. That is frequently more work than starting clean.
Nobody owns the exception rate. The automation programme is measured on cases automated. The claims team is measured on cycle time. The exception queue sits between the two and belongs to neither.
Bots are brittle in two directions. They break when a system's interface changes, which teams expect and plan for. They also degrade quietly when input quality drifts, which teams rarely instrument at all. The second one is worse because it produces wrong answers rather than stopped runs.
The honest summary: RPA moves the bottleneck rather than removing it, unless something underneath it can read.
Three layers, and which one owns what
The confusion in most claims automation programmes is that three genuinely different jobs get bought as one thing. Separating them makes the sequencing obvious.
| Layer | The question it answers | What it is good at | Where it fails |
|---|---|---|---|
| Document intelligence | What does this file actually say? | Turning handwritten, scanned, photographed and unfamiliar documents into structured, checkable values | It has no opinion about what the values mean for your policy |
| Decision rules | Given what it says, what should happen? | Applying the same gates and scoring to every case, in the same order, with reasons recorded | It is only as good as the data handed to it |
| Process automation | Where does the result need to go? | Moving outcomes between systems that do not integrate natively | It cannot interpret anything; it executes |
Read the failure column downward. The order it implies is the order the build should follow: reading first, rules second, movement last. Most programmes run it backwards, because movement is the easiest to demonstrate in a steering committee.
This is also why "RPA versus AI" is the wrong framing. They are not competing for the same job. RPA is a transport layer. The reading and the deciding are separate problems that have to be solved before transport is worth anything.
What reading properly actually involves
"Extraction" undersells it. On a claims file the useful work is as much validation as capture.
- Classification before extraction. Knowing that page four is a police report and pages five to nine are a medical summary, in a single PDF someone scanned in whatever order the papers were on the desk.
- Recalculation, not transcription. Reading a quote's line items and confirming they sum to the stated total. Reading a statement and replaying every transaction against the running balance. If the arithmetic does not hold, that is a finding, not a rounding issue.
- Cross-document consistency. The plate on the photograph against the plate on the policy. The loss date on the notification against the invoice date on the repair quote. The name on the identity document against the name on the claim.
- Refusing to guess. This one is a design stance rather than a feature. Some tools will quietly adjust a value so a document balances, which produces a clean-looking file and a wrong one. We surface the discrepancy and let a person decide. A silent correction is the most expensive kind of automation there is.
- Coverage gaps. Noticing that pages are missing from a statement or a report, which is where inconvenient information tends to go.
A bot handed the output of that work has something worth transporting. A bot handed the output of zonal OCR on a phone photograph has a plausible-looking mistake.
Test the reading layer before you scope the automation. Start free trial and put a real claim pack through it, or book a demo and we will run yours in the session.
What changes when the rules run
Once the file is readable, the second question is who decides what happens to it.
In a manual operation, policy exists as a written manual plus whatever each assessor internalised. Consistency is a function of training, tenure and how late in the day the file arrives. Nobody designs it that way; it is what happens when judgement is the mechanism.
The alternative is that the rules your team wrote are the rules that run, on every case, in the same order. Two things make that credible rather than a slogan.
Gates and scoring stay separate. A hard gate stops a case regardless of how well it scores elsewhere: coverage lapsed at the date of loss, claimed amount above the sum insured, a required document absent. Scoring is the graded part that routes towards settlement, referral or investigation. Blending the two is how a strong score quietly carries a case past a condition that should have stopped it.
Changes are tested before they run. A rule change can be replayed against your historical book, with its real outcomes, before it goes anywhere near a live case. That turns "we think this tightens things appropriately" into a number. Every version is retained, so a case decided last year is still explainable under the policy version that actually ran it.
One boundary, stated rather than glossed. Determinism belongs to the rules layer: the same inputs and the same policy version produce the same outcome, every time, and the record is replayable. The reading layer is a different kind of system and we do not claim bit-identical extraction from it. What we do claim is that the source document sits alongside what we read from it, so your team can verify rather than believe. The architecture is described in more detail in what a decisioning engine is.
Sequencing a build that holds up
The programme structure that survives contact with production looks like this.
Start with the intake mix, not the process map. Pull a hundred real files from last month at random. Not curated. Categorise them by what actually arrived: typed PDF, clean scan, poor scan, phone photo, handwritten, mixed-language, incomplete. That distribution is your project, and it is usually worse than anyone expects.
Prove the reading layer against that distribution. Not against a sample pack. The measure is how many files come out complete enough to act on without a person opening the original.
Write the rules explicitly, and find the disagreements. This step is uncomfortable and valuable. Getting two senior assessors to write down the same policy usually surfaces places where the operation has been running on two policies. Better to find that now.
Back-test before you go live. Run the drafted policy against decided cases and compare. Where it disagrees with what your team did, one of the two was wrong and you want to know which.
Then automate the movement. With verified data and a policy that runs identically, transport is genuinely the easy part, and whether you do it with RPA, APIs or a mix becomes an implementation detail rather than a strategy.
Supervisory expectations point the same way. The governance and control standards set out in the IAIS Insurance Core Principles assume you can explain how a case was handled, which requires the record to exist at the point of decision rather than being reconstructed afterwards.
What we can and cannot tell you here
Floowed is the decision platform: Document Intelligence reads the file, the Decision Engine runs your rules on it. We are not an RPA vendor and we are not a claims management system. We return the decision and the record; we never move money.
Every customer we have came off manual process rather than off a competing platform, and our deepest proof is in lending, because lending is where we have been longest. Concretely: 180 or more officer hours returned weekly at one lender, credit memo preparation from roughly 15 hours to about three minutes, six times the volume through the same team, three times as much statement fraud caught as manual review was finding, and a 54% cut in review time on clean cases.
Those are lending figures, labelled as lending figures. Our non-lending decision streams are opening shortly, and we are not going to dress them up as a shipped insurance track record. What transfers is the part that is genuinely general: we read documents of any quality, and we run the rules a team writes on what we read, the same way every time.
Frequently asked questions
Does this mean we should not buy RPA?
No. It means RPA should be sequenced last rather than first. If you have systems that need to exchange data and no API between them, a bot is a reasonable answer to that specific problem. The mistake is expecting it to solve an intake problem it was never designed to touch.
We already have RPA in production. Is that work wasted?
Usually not. The transport workflows generally survive; what changes is what feeds them. If your bots currently start from a human-keyed staging form, replacing that form with verified extracted data is an upgrade to the same pipeline rather than a rebuild of it.
What percentage of claims can run without a person?
It depends almost entirely on your intake mix and how tolerant your policy is, and any vendor quoting a single number without seeing your files is quoting someone else's operation. The useful version of this question is answerable in an afternoon: run a random hundred files and count. That is your number.
Who writes the rules, and how hard is it to change one?
Your credit, risk or claims team, directly. Changing a threshold is a change to the policy, versioned and back-testable, not a ticket to engineering. That matters more than it sounds: if only an engineer can change a rule, every policy change carries a queue, and over two years the queue costs more than the licence.
How does this handle documents in poor condition?
That is the part we are strongest at. Handwritten, photographed, skewed, badly scanned, stamped over, multi-language. It is best-in-class globally on non-standard documents, and it is the reason we exist rather than a feature we added later. See the intelligent document processing guide for how the reading layer is built.
What about audit and data protection?
Every decision retains the exact documents and values that drove it, re-inspectable years later, with role-based access and who-did-what logging. We are PDPA-compliant; the specifics of processing and retention are on the security page.
See it on your own documents
Automation strategy arguments resolve quickly once a real file is on screen. Book a demo and we will run your messiest claim pack, show the analysed output next to the source, and walk through how your rules would run on it. To try it yourself first, start free trial.
Last updated 2026-08-04 by Kira.