A third-party administrator wins a new block of business: forty thousand additional claims a year, at a per-claim fee negotiated eighteen months ago. Finance models the revenue and it reads as growth. Operations models the work and sees something different, because every one of those claims still moves through people, and people are the one cost the fee already assumed away. By the time the block is signed, the margin has started to leak, and nobody has mapped where.
Why a TPA’s claims economics punish manual work harder
The economics of an administrator are not the economics of a carrier, and that difference decides what automation is worth. A carrier collects premium and pays claims, so examiner labor sits inside the loss and expense ratio, one funded cost among many. A TPA is paid a fee to run someone else’s claims, and that fee is fixed in advance, per claim or per member per month. The examiner hours behind each file are not overhead against a premium pool but the largest variable cost the business carries, sitting directly beneath a price that cannot move until the contract renews.
| Carrier | Third-party administrator | |
|---|---|---|
| Revenue | Premium, with investment float | Fixed fee, per claim or per member |
| Where claims labor sits | Inside the loss and expense ratio | Directly beneath a fixed price |
| Repricing | At the next annual renewal | Locked to the quote until the contract renews |
| What automation does to margin | Trims one cost among many | Converts saved minutes straight into margin |
This is where the Manual Wall shows up in its sharpest form. We use that term at Digital Forms for the point where a growing operation can only produce more output by adding more people, and for a TPA the wall arrives early because the price is contractually locked. Regulation makes it heavier still: the NAIC’s Unfair Claims Settlement Practices Act, the 1990 model most states have since adopted in some form, requires whoever handles a claim to acknowledge it within roughly fifteen days and to keep it moving on defined timeframes after that. Every one of those obligations is another clock to watch and another manual touch on a file whose fee was fixed long before the obligation ever applied.
The exact fee structure varies, whether it is priced per claim or on a per-member-per-month basis, but the direction is identical: revenue per unit of work is agreed up front, and the labor to deliver it is booked afterward. That gap between a fixed price and a variable, people-heavy cost is where an administrator’s margin is won or lost, and it is why the same automation a carrier treats as optional is, for a TPA, a direct lever on the number that keeps the business solvent. That pressure does not start with the administrator either, because carriers have little underwriting margin to pass down: AM Best put the US property and casualty industry’s 2024 combined ratio at 98.9, barely inside an underwriting profit, so cost discipline flows downhill to whoever administers the claims.
So the administrator absorbs three kinds of pressure against one frozen number: rising work per claim, rising volume as blocks are won, and rising regulatory documentation. A carrier can reprice at the next renewal, whereas a TPA lives with the quote until its contract renews, and in the meantime the only lever that looks available is headcount.
Why hiring examiners stops working sooner than you expect
The instinctive response to a full claims queue is a hiring plan, and for a while it works. Then the math turns, because a new examiner does not arrive productive. In our experience a claims hire takes several months to reach full speed, and during that ramp an experienced examiner loses hours to training and quality review, so the team’s effective capacity dips before it climbs. On a fixed fee, those ramp months are pure margin erosion.
There is a further problem specific to administrators, and it is the reason adding examiners rarely clears a TPA backlog for long. Each examiner you add has to learn not one system but the full set your clients require: the carrier’s platform for one book, a self-funded employer’s portal for another, your own administration system underneath, and the spreadsheets that bridge whatever those systems will not pass between them. The training load scales with the number of client environments, not with the number of claims, so every new client contract quietly raises the cost of every future hire.
That is the multi-client version of what we call the Human API problem, where skilled people spend their day carrying data by hand between systems that were never connected. In a carrier it is expensive. In a TPA it compounds, because the administrator is bridging its own systems and each client’s systems at the same time, and the person doing the bridging is the same person whose time the fixed fee is trying to minimise.
What your client SLAs turn a backlog into
A carrier that falls behind on claims annoys its own policyholders. A TPA that falls behind breaches a contract, because the service levels are written into the client agreement, from acknowledgement and payment turnaround times to the accuracy threshold measured on audit. Those SLAs are the product a TPA actually sells, so a processing backlog stops being an operational irritation and becomes a commercial liability with penalties and renewal risk attached to it.
Manual processing and SLAs coexist quietly until volume moves, and volume moves more than it used to. The Swiss Re Institute put global insured natural catastrophe losses at around USD 137 billion in 2024, one of a run of years above USD 100 billion, and each of those events arrives as a wave of claims that has to be administered on fees agreed long before the storm. When a surge like that coincides with a new block going live, the queue a manual team could just about hold starts missing the clock. The usual response is overtime and temporary staff, which protects the SLA at the direct expense of the margin the SLA was meant to earn, so the administrator ends up buying its way out of a penalty using the very labor cost the fixed fee was supposed to contain.
Automation changes the shape of that risk, not only its cost. When the high-frequency transfers run without a person in the loop, capacity stops tracking headcount one for one, so a volume spike no longer forces a choice between a breached SLA and a blown margin. In our experience this is the argument that lands hardest with a TPA’s executive team, because it reframes the spend as protection for the contracts the business already holds, with a lower cost per claim as the side effect rather than the headline.
Where the manual work actually hides in TPA claims
Ask a claims director where the hours go and the answer is usually “the complex files,” but measure it and the picture turns out more mundane. The heaviest manual load tends to sit in the movements between steps rather than in adjudication itself: re-keying first notice of loss from a client intake form into the administration system, copying reserve figures into a carrier’s portal, assembling correspondence packets, updating a compliance tracker so the audit trail survives an examiner leaving. None of these require adjudicator judgement, and all of them recur on nearly every file.
The reason they persist is not laziness or bad hiring but the fact that no single client relationship ever justified redesigning the workflow. A block of twelve thousand claims did not warrant a systems project, so the examiners absorbed the gaps with manual effort, and the pattern set like concrete. Then the next client arrived with its own portal and its own format, and the manual layer thickened again. The work looks like adjudication on the org chart, but a large share of it is data logistics that a system should be doing.
Naming which movements pay to automate is the whole game, and it is worth being precise about the difference between the tools involved. Rules-based automation handles the deterministic transfers well, the same-every-time re-keying between two systems. The genuinely variable work, reading an unstructured loss report or an adjuster’s narrative, is where document AI earns its place, and confusing the two is how automation budgets get wasted. We wrote a fuller comparison of where RPA fits versus where AI actually adds value in claims, and the same logic applies to a TPA with one amplifier: because your fee is fixed, the payback on automating a high-frequency transfer is faster than a carrier would ever see on the identical step.
What to automate first, and what to leave alone
The sequencing question matters more than the technology question, and it has a cheap wrong answer, which is to buy a platform and hope the workflow reshapes around it. The better order starts from the fee. Find the transfers that happen on the most files, cost the most examiner minutes, and require the least judgement, then automate those first, because that is where a fixed price converts saved minutes straight into recovered margin.
This is what we call ROI-ordered sequencing at Digital Forms: every candidate automation is ranked by the recoverable cost it frees, and the biggest wins ship first rather than the ones that are technically interesting. The practical test is frequency times manual minutes, so a thirty-second re-key that happens on every one of eighty thousand claims a year outranks a complex reconciliation that happens twice a month, even though the reconciliation feels harder. On a TPA’s economics that ranking pays for itself fast, because every reclaimed examiner hour is a measurable line you can point a client or an owner to. If you want the underlying arithmetic before committing anyone’s time, the Manual Wall Calculator puts a number on what the current manual load is costing.
What to leave alone matters just as much. Judgement-heavy adjudication, coverage decisions, anything a regulator audits for human accountability: these are not the first targets, and forcing them into a brittle rules engine creates exposure rather than savings. The point of claims automation done in the right order is to take the mechanical load off examiners so their judgement goes where it is actually needed, not to replace the judgement.
What this looks like in a real TPA operation
Picture a mid-market administrator running roughly two hundred staff across several client blocks, processing somewhere in the region of half a million claims a year. The complaint that reaches the executive team is a staffing one: the queue is growing and SLAs are under threat during seasonal spikes, so the obvious fix looks like another dozen examiners against margins that are already thin.
Map the actual work and a different story usually emerges. A large share of examiner time, commonly a third or more in the operations we have seen, goes to moving data between the administration system and the various client portals rather than to deciding claims. The same first-notice details are typed two or three times into different systems. A compliance tracker is updated by hand hundreds of times a day so the audit trail holds. None of that is adjudication, and almost all of it is a candidate for automation that pays back inside a single busy season because the fee behind those claims never changed.
Clearing that load does not primarily shrink the team; it lets the same team take on the next client block without the margin leak the opening scene described, and hold SLAs through a surge without the emergency hiring that quietly erases the fee. New business can then be priced on a cost-to-serve that reflects systems rather than overtime. For an administrator, that is what insurance claims automation actually buys: the ability to grow the book without growing headcount at the same rate.
What to do about it
The first move is not a software purchase, and it is deliberately small. Before committing anyone to a build, it pays to know exactly which transfers cost the most and in what order to tackle them, which is what we built our Profit Leak Diagnostic to surface: a ranked, costed list of where the margin is leaking across your claims operation, with a number attached to each item. For a TPA that output doubles as a pricing and renewal artifact, because it quantifies cost-to-serve per block.
From there the discipline is to ship one thing and measure it against your own cost per claim rather than a vendor’s slide, which is the shape of an Operations Sprint: a fixed-scope build that puts a single high-frequency automation live in weeks, so the first result is proven before the second is scoped. When you are ready to treat it as a programme rather than a project, our claims automation service for P&C insurers and TPAs runs the whole path, from diagnosis through the builds that hold cycle times without adding examiners or replacing your core platform.
Closing
The queue will keep growing either way, so that is not the number to chase. What to put on the table this quarter is the real cost of moving a single claim from intake to closure, and how much of that cost is a person doing work the fee already priced out. Answer that honestly for one client block, and the case for automating stops being an IT argument and becomes the plainest margin math a TPA runs.
—
