Most diligence on a third-party administrator gets done from the outside: customer references, a platform demo, a management presentation, and a retention number. All of that is real, and none of it tells you whether the operation can absorb the growth in the model. I have run TPA claims and operations for the better part of twenty years. This is what I would look at if I were the one writing the check.
What does the auto-adjudication rate actually measure?
It measures the share of claims that pass through the system without a person touching them. That is all. It does not tell you whether those claims paid correctly, and it is one of the easiest numbers in the building to improve. Loosen a few edits, raise a dollar threshold, and the rate goes up while the plan sponsor quietly pays for it.
Ask for the rate with its companions: the pended-claims inventory and how long claims sit in it, the top ten reasons claims pend, and the post-payment adjustment rate. A high auto-adjudication rate with a rising adjustment rate is a TPA that moved its work from before payment to after it. A high rate with a large pend queue means the rate is being calculated on the claims that were easy.
Where does the manual work live?
Every TPA has a layer of work that never shows up in the platform demo. Somebody reconciles the eligibility files. Somebody builds the plan for the group whose design does not fit the standard template. Somebody re-keys the repricing result when the cost-containment vendor's file fails. Somebody works the pend queue.
That layer always exists. The diligence question is how big it is relative to the claims volume, whether it scales with headcount or with clients, and who owns it. If the answer to "who handles eligibility exceptions" is a name rather than a team, you have found the constraint on growth.
How do I read the eligibility process?
Eligibility is where TPAs bleed. A claim paid for a terminated member, or denied for an active one, is a plan-sponsor complaint, a stop-loss dispute, and often a refund the TPA eats. Ask for eligibility file error rates by client and by source (carrier feed, ben-admin platform, manual). Ask what the reconciliation cadence is and whether it is a report someone reads or a process someone runs. Ask how many clients send files that require manual clean-up before load. That number is a proxy for how much of the client base is being administered by hand.
What is the platform, and what has been built on top of it?
Most TPAs license a core adjudication system and then build around it: custom plan-build logic, integrations to network and PBM and stop-loss partners, reporting layers, portals. Get a plain inventory of what is configured within the vendor's product and what was custom-developed in house. Custom code is where the key-person risk and the upgrade risk both live. If the platform vendor releases a major version and the TPA cannot take it, that is a cost that has not been booked yet.
Then ask which client would break if it moved. Every TPA has one or two groups whose plan design was built with workarounds. Those groups are the test of whether the operation is as configurable as the demo suggests.
How should I read retention?
A retention figure without a termed-client list is a marketing number. Ask for every group that left in the last three years, the reason recorded at the time, and where they went. Groups that left because the employer was acquired are noise. Groups that left for a competing TPA after a service failure are signal, and three of them in the same twelve months usually point to the same root cause inside the operation.
Separately, ask about account manager turnover. In this business the plan sponsor's relationship is with a person, and when that person leaves, the institutional knowledge of how that plan is supposed to work often leaves with them.
Who matters on the org chart?
Two things to look for. First, whether the subject-matter experts behind claims, eligibility, and compliance are real people with tenure, or titles that were filled last quarter. Second, whether the escalation path from a plan sponsor complaint to someone who can fix it is short. A TPA where every escalation lands on the president has a president who cannot do anything else.
What should be in the data room?
Twelve months of claims turnaround by claim type, clean and pended, with the pend inventory and aging.
Post-payment adjustment and overpayment rates, and the refund recovery process.
Eligibility file error rates by client and source, and the count of clients requiring manual file clean-up.
A configured-versus-custom inventory for the platform, with the current release version and upgrade status.
Termed clients for three years with the reason recorded at the time and the destination.
The org chart with tenure, and account manager turnover for the last two years.
The plan-build backlog: groups sold but not yet live, and the time from signature to first claim paid.
None of this is exotic. A well-run TPA produces all of it for its own management every month. If it takes three weeks to assemble, that is a finding on its own.