From 4 Hours to 2 Minutes: How an RCM Company Rebuilt Its Analytics
A revenue cycle management company cut per-client analysis from four hours to two minutes and 90% of analytics cost using Supaboard's AI-native BI.
The client review was twenty minutes in when the question landed: why did our denial rate jump last month?
It was a fair question. It was also, until recently, the kind of question that ended a meeting instead of getting answered in one. Someone on the Jindal Healthcare team would write it down, promise to circle back, and open a ticket. A senior analyst would pick it up, write the SQL, pull the claims, pull the remittances, reconcile the two against systems that were never built to agree with each other, and roughly four hours later there would be an answer. By then the meeting was a memory and the client had moved on.
This is the quiet tax on a revenue cycle management business. Jindal Healthcare runs RCM for a roster of healthcare clients, which is to say it lives in one of the most data-heavy corners of the industry. Every client arrives as its own world: its own claims data, its own payer mix, its own denial patterns, its own idea of what a good report looks like. Multiply that by a client list and the analytics workload stops being a task and becomes its own operations problem.
A revenue cycle management company, Jindal Healthcare, cut per-client analysis from four hours to two minutes and reduced analytics cost by 90 percent using Supaboard's AI-native BI.
At a glance
Company | Jindal Healthcare, a revenue cycle management (RCM) provider serving a roster of healthcare clients |
|---|---|
Industry | Healthcare, revenue cycle management |
Before | One client analysis took about four hours of senior-analyst time, spread across multiple SQL queries and manual reconciliation between disconnected systems |
After | The same analysis takes about two minutes, run on demand by any operator, with analytics cost down 90 percent |
What they use it for | Client reviews, denial root-cause analysis, and performance benchmarking, all run from one source of truth across every client |
Data and compliance | Jindal masks all PHI before it leaves its environment. Supaboard cleans the masked data into a warehouse and never touches PHI or the EHR |
When answering a question costs as much as the work
Before Supaboard, an answer at Jindal had a price, and the price was a person.
Not just any person. The questions that mattered most, denial root cause, AR aging by payer, why one client's collections slipped, all needed someone who could write, run, and reconcile SQL across systems that did not share a definition of anything. The clearinghouse spoke in claim files and remittance codes. The practice management and EHR systems each client billed from spoke in their own schemas. The payer portals, where denials and adjustments actually surface, spoke in yet another dialect. Stitching those into a single trustworthy number was skilled work, and skilled work is slow and scarce.
So the team did what every team does when answers are expensive. They rationed them. A deep look was reserved for problems everyone already agreed were problems. Hunches went uninvestigated, because a hunch was not worth four hours of the one analyst who could chase it. As the operations team put it:
"The cost of answering questions had started to rival the cost of the work the answers were meant to inform."
That is the sentence that makes a company go looking for something new. Not a software complaint. A math problem. When the meter on a question runs as high as the meter on the work itself, your analytics function has quietly become a second business you did not mean to start, and it is competing with the first one for the same people.
One source of truth, trained on the actual domain
The fix was not a faster way to write the same SQL. It was removing the SQL from the critical path entirely, and doing it without letting protected health information anywhere near the analytics layer.
The pipeline was built with a hard boundary. Jindal collated the raw data from across its sources, the clearinghouse claim and remittance feeds (the 837s going out and the 835 ERAs coming back), the practice management and EHR systems each client billed from, and the payer remittance and denial data, and masked every piece of PHI into a single database before any of it moved. Supaboard never connected to an EHR and never saw a patient. Using one of its 600+ connectors, it pulled from that masked database, cleaned the data, and moved it into a data warehouse that became the one source of truth the agent ran on. The compliance line and the analytics line were the same line, and PHI stayed behind it.
Moving the data was the easy half. The harder half was teaching the tool what the data meant. RCM is full of numbers that look identical and mean opposite things. Aging is the classic trap: a claim sitting at sixty days can be a process failure your team needs to fix, or it can be nothing at all, just the unremarkable rhythm of a payer who always pays on that cadence. A naive dashboard flags both as red. An analyst who knows the account knows the difference. Jindal trained Supaboard's trainable agent on exactly that kind of judgment: claim lifecycles, denial categories, and the behavior of specific payers, including when aging signals a problem and when it is just how a payer pays.
Once the agent understood the domain, the question stopped routing through a person. Anyone on the team could ask a question in plain language and get an answer back in the shape of the work, not in the shape of a SQL result set waiting to be interpreted.
The part nobody expected
Here is the moment the team still talks about.
It was a client review, the same kind of meeting that used to end with a promise to follow up. The client asked why denials had moved on a particular payer. The person who answered was not the senior analyst. It was an operations associate, someone whose job had never included writing a line of SQL, who in the old world would have been the one taking notes and opening the ticket.
Instead she typed the question into Supaboard, in front of everyone, and asked for the denial rate by payer and reason code for the prior month against the trailing baseline. The answer came back in about two minutes, while the meeting was still happening. It separated the genuine process problem from the payer that simply pays slowly, the exact distinction that used to require an analyst's trained eye. She read it out, and the conversation kept going, because for the first time the answer arrived inside the same meeting as the question.
The shape of what she pulled looked like this:
Payer | Denials, prior month | vs. 6-mo baseline | Top reason code | Read |
|---|---|---|---|---|
Payer A | up | well above | medical necessity | Process problem, fixable, worth a workflow change |
Payer B | up | in range | timely filing | Mostly payer cadence, not a fire |
Payer C | flat | in range | none material | No action |
(Representative view. The point is the structure of the answer, not a specific month.)
Nobody had planned for that. The pitch had been about speed, about turning four-hour analyses into two-minute ones. What actually changed was who got to ask. An analysis that had been gated behind the most senior, most scarce person on the team became something an operator could do live, with a client watching, and get right. The bottleneck was never the data. It was the translator standing between a normal person and the data, and that translator was now built into the tool. As the operations team described the shift:
"Analyses that required a senior analyst to write, run, and reconcile became conversations any operator could have with the data directly."
The number, and what it freed up
The headline outcome is clean, and it is the kind of thing worth repeating because it is the whole argument in two figures. Per-client analysis at Jindal went from about four hours to about two minutes, and analytics cost across RCM operations dropped by 90 percent.
Before Supaboard | After Supaboard | |
|---|---|---|
Time per client analysis | ~4 hours | ~2 minutes |
Who could run it | Senior analyst only | Any operator |
Path to an answer | Ticket, queue, SQL, reconcile | One question, plain language |
Analytics cost | Baseline | Down 90 percent |
Data | Scattered across systems | One source of truth, every client |
But the figure that the team felt was not really the 90 percent. It was the second-order effect. When a deep look cost four hours, you only spent it on problems you already knew about. When it costs two minutes, you can chase a hunch. Denial root-cause work, client reviews, and benchmarking stopped waiting in the analytics queue and started running on curiosity. The operations team's own framing captures it better than a metric can:
"When a deep look costs four hours, you save it for problems you already know are problems. When it costs two minutes, you can chase a hunch."
That is the difference between an analytics function that defends the business and one that explores it. The first only ever confirms what you suspected. The second finds the thing you did not know to look for.
What this means if you run analytics for more than one client
The Jindal pattern travels, and not only in healthcare. If you run reporting for a portfolio of clients, agency, services firm, RCM, anything where every account is its own dataset with its own definitions, the same trap is probably set in your operation right now.
It usually does not look like a tooling problem. It looks like a staffing problem. You feel it as "we need to hire another analyst," because the queue is long and the one person who can answer the hard questions is always busy. But the queue is long because every answer is expensive, and every answer is expensive because it routes through SQL and reconciliation and a single scarce expert. Adding a person widens the bottleneck by one. It does not remove it.
What Jindal removed was the translation layer between a question and the data. The lesson is not that AI replaced their analysts. The senior analyst at Jindal did not stop mattering. What changed is that the analyst stopped being a toll booth on the road to every routine answer, which freed that expertise for the genuinely hard questions where it belongs. And the rest of the team, the operators closest to the clients and the actual denials, got to ask their own questions at the speed they actually occur to them.
When the cost of a question falls far enough, people do not just ask the same questions faster. They start asking better ones. That is the part you cannot put in the pricing table, and it is the part Jindal would tell you mattered most.
Want the structured version with the dashboards and metrics? Read the full Jindal Healthcare case study.
