Key Takeaways:
- Workflow automation in healthcare and legal services usually fails for a reason that has nothing to do with data, security, or AI capability. It fails because the underlying process was never consistent enough to automate.
- A workflow you cannot describe the same way twice cannot be automated correctly. It can only be executed inconsistently at higher speed.
- The organizations getting real value from automation in case-based, regulated industries standardized the process first and treated the software as the second step, not the first.
By Reid Zeising, CEO & Founder, Gain Servicing
I run a company that operates at the intersection of the healthcare and legal industries. It’s an interesting cross-section to operate in because both deal with highly regulated data and information. One thing I know for sure? The longer I work across both industries concurrently, the more I notice both breaking in the same place. It all comes down to AI and automation.
I wrote recently about why I believe the legal industry’s AI problem is really a data governance problem, not a reason to slow down adoption. I see the same dynamic play out in healthcare. Where data lives, who can see it, and whether it moves through systems built to protect it matter. But what if the data generated lacks consistency in the first place?
You can govern data perfectly and still automate a broken process. Governance tells you whether the information is safe. It does not tell you whether the work behind it was performed the same way twice.
A process you cannot describe twice cannot be automated
On paper, a hospital revenue cycle and a personal injury case are apples to oranges. One involves clinicians, payers, and CPT codes. The other involves attorneys, courts, and discovery deadlines. But their foundation is the same: both have a long case lifecycle, multiple handoffs between people who do not report to each other, and a process that depends on individual judgment far more than anyone admits.
In healthcare revenue cycle, a claim moves from intake to coding to submission to adjudication, and very often, to denial and rework. The scale of that rework is hard to overstate: one widely cited estimate puts annual losses from denials across the industry at $262 billion. Most denials are not happening because the clinical work was wrong. They are happening because intake, documentation and billing were each handled slightly differently by whoever happened to be doing them that day.
In litigation, the equivalent shows up in discovery and case intake. Case teams are not usually stuck because the document review technology is weak. They are stuck because the underlying material, how it was collected, labeled, and organized, was never handled the same way twice. One industry analysis on litigation research put it plainly: the bottleneck is not the analytical tools, but whether the documents feeding them are structured enough to be useful.
Neither of those is a data governance problem. Both are process problems wearing a technology costume.
Why this gets misdiagnosed so often
I have heard a version of the same complaint from operators in both industries: “We bought the software and it did not fix the problem.” Almost every time, the issue was never the platform. It was that the process being automated was a collection of individual habits, not an actual process.
If every case manager intakes a file slightly differently, if every coder applies judgment in a slightly different place, if every paralegal organizes a case file their own way, you do not have something a system can learn to execute consistently. You have variation that happened to produce acceptable outcomes often enough that nobody questioned it. Layer automation on top of that and the system does not fix the inconsistency. It just reproduces it faster, with more confidence, and at a scale where the cost of the inconsistency compounds instead of staying contained to one case at a time.
This is also why healthcare and legal services are simultaneously the hardest industries to automate well and the ones with the most to gain from getting it right. Both involve high-stakes, document-heavy cases that move across stakeholders with different incentives. A provider wants to get paid quickly. A payer wants to control cost. An attorney wants the strongest possible case. An adjuster wants the smallest possible exposure. Nobody in that chain is rewarded for making the next person’s job easier, and that misalignment is exactly what allows inconsistent process to persist for years without anyone fixing it.
What actually has to happen before software selection
In our own operations, the work that made automation useful did not start with selecting a platform. It started with going stage by stage through the case lifecycle and asking a much less exciting question: does this step happen the same way every time, regardless of who is doing it? In most cases, the honest answer was no.
That is unglamorous work. It means sitting with a case manager and watching how they actually triage a new file, not how the process document says they should. It means comparing how three different coders handle the same ambiguous claim and discovering they reach three different conclusions. It means accepting that the org chart describes who is responsible for a step, not whether that step is performed consistently.
Once that map exists, automation has something real to act on. A system can flag a missing authorization before it becomes a denial, but only because the criteria for what complete means were defined the same way across every intake, not left to individual judgment. A system can surface a discovery document the moment it becomes relevant, but only because every document entering the case was tagged using the same structure. Legal teams that paired AI-assisted review with consistent governance and standardized intake have reported avoiding runaway review costs even on matters involving millions of documents. The technology mattered less than most people assume. The consistency underneath it mattered more.
The lesson for anyone building or buying workflow software in a regulated industry
If you operate in healthcare, legal services or anything else built around long, document-heavy, multi-party case cycles, the question to ask before evaluating any SaaS platform is not what the software can automate. It is whether the process you are about to hand it has ever actually been performed the same way twice.
Skip that question and you will buy capable software, get inconsistent results and conclude the technology was not ready. The technology is usually fine. The work it was asked to learn was never standardized enough to learn correctly.
I think this is also where the next real wave of useful SaaS innovation in regulated industries will come from. Not tools promising to automate an entire case lifecycle end to end on day one, but tools built around forcing consistency at the specific points where it tends to break down: intake, documentation, handoffs between roles. Everything layered on top of it depends on getting this part right, even though it rarely looks like innovation.