Revenue Cycle Orchestration: Why No Single Payer Channel Is Enough

Getting information from payers is one of the most basic tasks in revenue cycle work, and one of the hardest to do well. A claim status request might start with an EDI transaction, move to a payer portal, and end with a phone call that takes far longer than anyone planned. When each of those channels belongs to a different team or system, the work gets slow, expensive, and hard to manage.

That was the central argument SuperDial Co-Founder and CEO Sam Schwager made on the Becker's CFO + Revenue Cycle Podcast in an episode titled "The Connected Revenue Cycle: Why the Future of RCM Is Orchestration, Not a Single Channel." Speaking with host Lukas Voss in the October 28, 2026 episode, he made the case that the future of revenue cycle management is orchestration, not any single channel.

Revenue cycle orchestration means coordinating teams, systems of record, and payer channels (EDI, portals, APIs, and phone calls) so each task takes the path most likely to return a complete, actionable answer. Here is what that means for revenue cycle leaders evaluating AI for payer operations.

What a connected revenue cycle looks like

Schwager described the revenue cycle in three stages. The front runs from scheduling until the patient receives care, the middle covers the period after care and before the claim, and the back runs from claim submission until payment. In a large provider organization, some of those stages are usually outsourced, some are handled in-house, and different systems of record may be involved at each step.

Layered on top of that are the ways teams reach payers: EDI, payer portals, payer APIs, and phone calls. In Schwager's view, when these teams, systems, and channels operate in silos, the outcome is worse for both the provider organization and the patient. A connected revenue cycle, as he defined it, is one where they coordinate to deliver the fastest time to payment, the fastest time to care, and the best financial result. What makes that achievable now, he argued, is that large language models and AI agents can reason across many sources and large volumes of unstructured data, connecting pieces of the revenue cycle that have historically stayed separate.

Why no single payer channel gives you the whole answer

Electronic data interchange (EDI) is the standardized, transaction-based way providers and payers exchange data such as eligibility, claim status, and remittance. Schwager called EDI the "tried and true" rail: it delivers much of the core data revenue cycle work needs, quickly and at low cost. The problem is that the work requires more than EDI returns.

Claim status is a clear example. The 276/277 transaction pair (a claim status inquiry and the payer's response) can provide useful information, but often not enough. If a claim has been sitting for 60 days or more without an 835 electronic remittance advice, Schwager said, the 277 response may be incomplete and not actionable. At that point, a phone call is often what it takes to learn the next best action.

Part of the reason, he explained, sits on the payer side. Answering a provider's question can require reconciling several internal data sources, and those sources sometimes conflict. That is why teams still rely on portals and on calls to a payer representative who is looking across multiple screens and reasoning toward an answer. Schwager described phone calls as by far the costliest way to get information from an insurer, and said a single call can run upward of an hour.

The practical point is that no one-size-fits-all approach works across payers. Whether the task is verifying benefits, securing a prior authorization, or following up on a claim, Schwager framed the goal the same way: get the information that moves the account to the next stage, with payment as the final one.

Start by writing down which channels work for which payers

Schwager's most practical recommendation was also the least technical. Teams usually know which payers answer through EDI, which require a portal, and which only resolve certain questions by phone. But that knowledge, he said, often lives in people's heads rather than on paper. The first step is to document it and align on which channels to use for which payers and use cases. Format matters less than getting it recorded. "The more that gets written down, the better. Even if it's unstructured, it's always better to write it down than not," Schwager said.

Documentation makes channel decisions consistent and shows where the repetitive, tedious work sits. Those are the tasks Schwager believes are best offloaded to AI agents working out of the same systems as the team.

Let agents carry the routine work so people can focus on judgment

Schwager described how this works at SuperDial. A customer specifies the information it needs, for example 20 data elements about a claim it has not heard back on. SuperDial then works across the available channels. It might try EDI first and collect some of the data, go to the payer portal for more, and place a call to get the remainder before returning the full set to the customer.

The goal is not to remove people from the revenue cycle. Schwager called the information-gathering payer call necessary, but said it is not the highest and best use of a revenue cycle expert's time. The model he described is humans working alongside AI agents that take on repetitive administrative work, so experienced staff can spend more time on work that requires judgment, such as resolving a complex claim denial or building a strong appeal.

How to tell whether orchestration is working

For finance and revenue cycle leaders, Schwager pointed first to the fundamentals: how much the organization collects, how quickly it collects (days in accounts receivable, or AR), how quickly patients get access to care, and how satisfied patients are with both their care and their financial experience. He described these as lagging indicators and suggested that if they are not improving after an orchestration effort, something is not working.

His reasoning is that well-implemented automation should change these numbers directly. "You should see days in AR going down," he said. He also expects collections to rise because AI agents can work claims that would otherwise go untouched due to capacity limits, and expects patients to get care sooner as benefits verification speeds up and prior authorization timelines shorten. These are his expectations for a successful rollout, not guaranteed outcomes.

For payer data specifically, Schwager recommended tracking a few operational measures:

• First-touch resolution: how often a request gets a complete answer on the first attempt.
• ‍Touches per claim: how many interactions a claim requires across its life cycle.‍
• Manual versus AI touches: what share of those interactions are handled by staff and what share by AI agents.

That last measure is the one he emphasized most. "There better be a good reason if you have team members picking up the phone to make phone calls to payers," he said. In his view, a strong signal that orchestration is working is when staff report they are calling payers only for genuine edge cases, while standard, scripted calls are handled by agents.