> ## Content Index > Fetch the complete content index at: https://www.missionviewpoint.com/llms.txt > Use this file to discover other available public pages before exploring further. # When a Workflow Becomes a Product - URL: https://www.missionviewpoint.com/when-a-workflow-becomes-a-product/ - Published: 2026-09-11T11:21:00.000Z - Updated: 2026-09-11T18:25:15.000Z - Author: Scott Dickson - Tags: Topic: Care Organizations at Scale, ABA Stack ***Part One of MissionViewpoint's series: The Unbundling of Work*** For most of the history of ABA practice management technology, the division of labor was straightforward. **Providers hired people to do the work. Software helped them do it.** Employees handled intake, verified benefits, managed authorizations, built schedules, worked denials. The practice management platform — **and eventually a growing collection of other applications** — gave them tools to perform those jobs. **The provider still owned the work.** > That boundary is beginning to move. Increasingly, providers **aren't being offered another tool** for their intake team. They're being offered **intake** itself. Not software that helps someone verify benefits, but **eligibility verification as a finished capability**. Not another dashboard for finding documentation problems, but something that identifies the problems, resolves what it can, and **routes the exceptions** that need human judgment. Behind that capability **might be** conventional software. It **might be** AI. It **might be** offshore labor, or specialized domestic staff. Increasingly, it **will be** some combination of all four — and from the provider's perspective, that distinction may eventually matter less than we think. Because the thing they're buying is changing. For twenty years, we mostly unbundled software. **Now we're beginning to unbundle work.** ### Software Used to Stop at the Work Think about what happened when a provider bought an authorization management application. The software **could organize** authorizations, **track** units, **flag** expiration dates, maybe **automate** pieces of the workflow. But when something actually needed to happen, **someone at the provider still had to do it**. **Someone** gathered the documentation. **Someone** called the payor. **Someone** investigated the exception, followed up when the request stalled, and figured out why the system didn't match what the payor had on file. The software made that employee **more productive**. It **didn't replace** the provider's responsibility for completing the work. **That distinction shaped the healthcare software industry**. We bought tools for people who did jobs — a CRM for the intake team, an RCM system for the billers. Even when the software automated individual tasks, **the organizational boundary held.** The application supported the work. **The provider performed it**. ### That Boundary Is Starting to Disappear AI is part of what's changing this, but it isn't the whole story. Software has gotten **better at executing tasks** rather than just organizing information about them. APIs make it easier for specialized systems to reach into a provider's **existing technology**. AI can interpret unstructured information, make decisions inside defined boundaries, and handle interactions that used to require a person. **And companies can pair those technologies with specialized labor to catch the cases automation can't.** > The result is something different from traditional software. Take **eligibility verification**. Under the old model, a provider that wanted to do it better bought better software, and **employees used it** to check coverage, interpret results, resolve discrepancies, document findings, and escalate the unusual cases. Now a provider can instead **buy (or build) a capability** that receives the patient information, performs the verification, clears the routine discrepancies, handles the follow-up, and **returns the answer to the provider's workflow**. At that point, asking whether the vendor is a software company or a services company stops being useful. The provider isn't really buying either one. **It's buying completed work.** ### Look at Intake Intake makes the shift **easy to see**, because intake was never really one thing. Picture the intake coordinator at a mid-sized provider. A referral lands on her desk. Before she can make the one call that actually requires her judgment — whether this family fits what the provider does well, and how urgently they need to be seen — **she has to get through everything wrapped around that judgment**. She's **on hold** with a payor confirming coverage. She's **emailing** a family for the third time about a missing form. She's **re-keying** referral details the sending office already typed into a system somewhere. The judgment takes a few minutes. **The work around it takes her day.** For years, we described the CRM as the technology supporting intake. But the **CRM was never the capability**. The capability was everything required to turn a referral into a patient **ready for service** — and much of it is the mechanical work filling that coordinator's day, **not the minutes of judgment** at the center of it. That surrounding work is exactly what's becoming purchasable as completed output. Coverage confirmed, documents collected, routine follow-up handled, the referral kept moving. What's left — **the judgment about whether this family fits, the relationship the provider may not want to hand to anyone** — is the part that's harder to buy, and the part worth being deliberate about keeping. The workflow hasn't disappeared. **The question is who, or what, performs each part of it.** And once that question can be asked of intake, it can be asked of **almost anything**: credentialing, documentation QA, claims follow-up, pieces of scheduling. Each was historically some combination of employees, process, institutional knowledge, and software. **Each can now be decomposed** — some tasks automated, some handled by AI, some left to specialized people, some still depending on employees who understand the provider, the patient, the payor, or the local market. The interesting development isn't that AI replaces all those people. It won't. It's that **a vendor can now draw a boundary around a piece of operational work** and say: you don't have to assemble this yourself anymore. **You can buy it.** That's a **fundamentally different proposition** from selling another application. ### Part of the Organization Moves Outside the Organization For years, one of the defining questions in ABA technology has been whether the practice management platform should do more, or whether providers should assemble best-of-breed applications around it. That's still a real question. **But it assumes the things surrounding the core platform are applications.** Increasingly, they won't be. A provider's operating stack may still include a practice management platform, a CRM, an HR system, a clinical data system. But sitting alongside them may be capabilities that **don't fit the traditional software stack** at all. One looks like software to the user but has a service operation behind it. Another **looks like a managed service** but has AI doing most of the work. A third has employees **touching only the exceptions** while software handles the rest. On an architecture diagram, these are boxes connected to other boxes. Operationally, something more consequential has happened. **Part of the provider's organization has moved outside the organization.** The technology stack and the operating model are starting to converge. What software you run and what work your organization actually performs **used to be largely separate questions**. Increasingly, decisions about one determine the other. ### When Work Becomes Purchasable, a Different Question Appears None of this means providers should unbundle every workflow they can. There are good reasons to **own some capabilities internally**. Some hold institutional knowledge that **creates advantage**. Some depend on relationships a provider **shouldn't surrender**. Some require judgment that's hard to specify in a contract. And some external capabilities will simply **cost more or perform worse** than the internal operation they're meant to replace. The point isn't that unbundling is better. It's that the option increasingly exists — and **that changes the strategic question**. For years, providers asked whether a piece of software belonged inside the practice management platform or outside it. Increasingly, they'll have to ask something more fundamental: **Does this work need to live inside our organization at all?** That's a much bigger decision than choosing software. Because once workflows become products, providers aren't just deciding what technology to buy. **They're deciding which capabilities the organization itself needs to own.** --- **Coming next: Software, AI, or People?** In Part Two, I'll look at how providers should decide which capabilities to keep inside the organization, which to buy, and why the technology underneath the work may matter less than the economics, control, and strategic value of the capability itself.