AI in mid-market RCM. From ambition to production.
How the Livehopper engagement applies to revenue cycle operations. Sixteen weeks. A system in production. A team that owns it.
This is a working note from Livehopper for RCM operators and their sponsors. It describes how our standard three-phase engagement applies when the operating domain is revenue cycle management. References to industry outcomes are drawn from publicly disclosed results at category-leading RCM platforms. Livehopper has no proprietary relationship with the platforms whose disclosures are referenced.
What is actually broken
Mid-market RCM operators are running 2018 operations against 2026 expectations. Clients are starting to ask about AI in their RFPs. Peers are publishing case studies. And payers are using AI to deny claims faster than offshore teams can appeal them. The asymmetry has reversed. The operator's labor base, which used to be the moat, is now the constraint.
The category leaders show what production AI looks like in this domain. Six consecutive Best in KLAS rankings. Over a hundred production AI models. Proprietary data platforms spanning thousands of terabytes of harmonized claims. The pattern is in the public record. The mid-market gap is also in the public record. Operators without an AI thesis are being repriced as commodities. Operators with one are being repriced as platforms.
The market context is consolidating quickly. TowerBrook and CD&R acquired R1 RCM for $8.9B. Blackstone acquired AGS Health for $1.1B. Waystar acquired Iodine Software for $1.25B. New Mountain Capital is executing a multi-billion-dollar RCM rollup. Every one of those transactions was priced against an AI-platform thesis.
What we would do
We sit with your team for sixteen weeks. By week sixteen, you have a knowledge layer over your claims, denials, and payer policies; AI agents running in your appeal-drafting and AR follow-up workflows; and metrics that tell the board what moved and why.
RCM is new territory for us. That matters in two ways. The engagement runs the full sixteen weeks rather than the accelerated eight, because we are validating less and discovering more. And we build the reusable template while we build your system, so the next mid-market RCM operator gets this in eight. The first operator we ship with sets the template. That is the first-mover advantage on offer.
The RCM operation end to end, with the AI agents we would build.
Upstream inputs feed patient access. Every role in the cycle is paired with the AI agent or system that would sit alongside it, each agent carrying a four-point opportunity meter from low to very high. Plain workflow systems are marked where the value is automation rather than AI. Each phase produces the artifacts the next phase consumes. The map is the architecture we would propose, sized to the operator we sit with.
Phase one. Listening week.
Weeks 1 to 2
Structured conversations with the people who actually do the work. Denial specialists. AR follow-up analysts. Coders. Eligibility specialists. Patient access supervisors. The offshore team leads and the onshore quality reviewers. No frameworks. No questionnaires. We write up what is true.
For an RCM operator the listening week typically uncovers four things. Which payers deny most, by what categories, and how the team currently triages them. Which coding errors are recurring across which client cohorts. Where the offshore team is bottlenecked and where the onshore team is over-deployed. And what the EHR integration actually looks like in practice, not what the slide deck says it looks like.
Output. Working notes and validated workflow maps, ready for the diagnostic phase.
Phase two. Operating diagnostic.
Weeks 2 to 4
A six-page brief. Board-readable. Written for the person who has to defend the investment, not for the consultant who proposed it. Specific recommendations, not themes. A concrete plan for what gets built in weeks five through sixteen.
For mid-market RCM operators the diagnostic typically lands on three to five specific recommendations. Which denial categories to attack first with gen-AI appeal drafting and what the expected appeal cycle compression is on the operator's specific payer mix. Which payer-specific scrubbing rules to encode in the knowledge layer before the appeal agent goes live. Where in patient access the voice agent goes first, if the operator wants visible client-facing wins inside the sixteen weeks. What the data foundation needs to look like to support the agents past the engagement.
Output. Six-page diagnostic brief and architecture plan. This is the document that goes to the board.
Phase three. In-production sprint.
Weeks 5 to 16
We sit with your team. The output is something running, not a deck. Three layers, the same on every Livehopper engagement, made specific to the operator we are sitting with.
- Knowledge layer Your claims, denials, payer policies, EOBs, clinical documentation, payer contracts. Indexed, access-controlled under HIPAA, queryable by every agent in the stack. Compliance guardrails enforce data classification before anything reaches the model. This is the foundation the operator owns after we leave.
- AI agents Not generic copilots. Agents shaped to your specific workflows and your specific payers. An appeal-drafting agent tuned to the denial language of the payers you actually work with. An AR follow-up agent that escalates on your aging buckets and your escalation rules. A denial triage agent that prioritizes by dollar value, appeal probability, and your staff availability. A voice agent for patient access if the diagnostic calls for it. All connected to the knowledge layer above. All constrained by your compliance requirements. They do real work.
- Metrics and measurement Not vanity dashboards. Diagnostic pairs that tell you why a number moved, not just that it did. Denial rate by payer paired with the underlying cause category. Appeal turnaround paired with the cycle stage where it slowed. First-pass collection rate paired with payer-specific scrub failure rate. Measured before, during, and after the engagement, so the value is provable to the board at week sixteen.
Output. A system in production. A team that owns it. And the reusable template Livehopper carries to the next operator.
Payers use AI to deny claims faster than the team can appeal them. We build the agents that close the gap. They do real work.
For PE sponsors
What the board sees at week sixteen. A six-page diagnostic written in week four, on file since. A production system that started running between weeks five and twelve. Measured outcomes against the baseline captured in week two. An internal team that has owned the system for at least a month before Livehopper leaves.
The valuation case is the sponsor's to make to the board. The numbers from public RCM platform comparables, 400 to 600 bps of margin expansion, a re-rating from services multiples toward platform multiples, a 2.0 to 2.5x MOIC uplift over a four-year hold, are observable in the market. They follow when the system runs. Our job is to ship the system.
What we do not do
- We do not send juniors. The people in your operating diagnostic are the same people building the agents. Senior, hands-on, named in the contract.
- We do not write reports that sit in drawers. The diagnostic is six pages because that is what the board reads. Everything past page six gets built, not written.
- We do not manage your team. We sit with them. They own the system after we leave.
- We do not sell platforms. Your knowledge layer runs on the cloud and tools you already pay for. We do not bring a stack you have to license from us.
- We do not propose 24-month transformations. The engagement is sixteen weeks. We ship the system and leave. What the operator does with it over the next two years is their program, not ours.
If you are running an RCM operation
And you would rather have AI agents running in your denial and AR workflows in four months than a strategy deck in two quarters, we should talk. The first conversation is the listening week. The sixteen weeks start the day we agree on which payers to attack first.
References to industry outcomes are drawn from publicly disclosed results at category-leading RCM platforms. Livehopper has no proprietary relationship with the platforms whose disclosures are referenced. Engagement outcomes depend on the starting state of the operation, the payer mix, and the team that owns the system after Livehopper leaves.
