> ## 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.

# You Can Outsource the Work. Can You Keep the Advantage?
- URL: https://www.missionviewpoint.com/you-can-outsource-the-work-can-you-keep-the-advantage/
- Published: 2026-09-10T22:46:00.000Z
- Updated: 2026-09-11T18:24:33.000Z
- Author: Scott Dickson
- Tags: Category: Automation and Integration, Topic: Care Organizations at Scale

*Part Two of MissionViewpoint's series: The Unbundling of Work*

I ended the first article in this series with a question: **Does this work need to live inside our organization at all?**

For a lot of the mechanical work surrounding ABA operations, the answer may **become increasingly easy**. If someone else can verify eligibility or collect documentation **more cheaply and reliably**, there may be **little strategic value** in employing people to perform those tasks simply because that's how they've historically been done.

The harder question begins where Part One left the intake coordinator: with the thin slice of the workflow the provider **might actually care about owning**. The judgment. The relationship. The parts that might make one provider **meaningfully different** from another.

Traditional management thinking had a reasonably straightforward answer for those: **outsource commodity work** and **keep differentiating capabilities inside**.

I'm not sure the second half of that rule **holds anymore** (apologies to my Biz School Strategy professors!). Increasingly, a provider may not need to **perform** a differentiating capability internally in order to **own** the differentiation.

## What If the Vendor Wants the Relationship Too?

Go back to the intake coordinator from Part One. It is relatively easy to imagine moving the mechanical majority of her day elsewhere **while retaining the few minutes of consequential judgment** at its center.

**But the market doesn't have to stop there.**

There are now capabilities that can take on much more of the **intake front end**: forms, prospect communication, document collection, follow-up, scheduling activity, and eligibility verification. They aren't necessarily deciding whether a family is clinically appropriate for the provider or how urgently that family should be seen. **That judgment can remain with the provider.**

But something else has moved: **the family relationship.**

Now imagine two providers evaluating that same capability. For the *first*, intake is primarily an **administrative process**. Move an appropriate family through it accurately and quickly, and the **process has done its job**.

For the *second*, speed to care and family engagement are part of the strategy. Leadership has **deliberately designed how quickly** families hear back, how they are **guided** through the process, and how **friction is removed** between referral and care. For that provider, the vendor is offering to perform work through which the organization **expresses its differentiation**.

The old rule says don't outsource it.

But that's only necessary if owning the differentiation requires owning all of its execution.

**It increasingly may not.**

## Own the Difference, Not Necessarily Every Step

The second provider could still decide that initial family communication is **too important to move** outside. That's a perfectly rational answer. But it could also decide that someone else can perform much of that communication—as long as the provider remains **explicit about what makes its intake experience different**.

How **quickly** should a family hear back? What should happen when the normal **process breaks down**? Which interactions **can be standardized** and which should **reach someone** inside the organization? What outcomes tell leadership that the experience it designed is **actually being delivered?**

Those are different questions from who sends the text message or follows up on the missing form.

The same distinction can apply elsewhere. A provider that **differentiates on clinician experience** might decide that unusually fast, low-friction credentialing **contributes** to that experience without concluding that its own employees must perform **every credentialing step**.

And at the far end of that spectrum is a provider that decides a capability matters enough to **build it.** AI has made that plausible for organizations that could never have considered it before — the scheduling logic, intake trackers, and credentialing dashboards that **used to require an engineering bench are now within reach** of a motivated operations lead and a coding assistant. 

For genuinely strategic work, building can be the right answer: it's the most complete way to own not just the differentiation but the execution and the software underneath it.

But building doesn't escape the question the rest of this series is asking. **It relocates it**. A capability a provider builds still has to connect to the record, know when work needs to happen, and return its result to the systems people use — except now the **provider supplies all of that plumbing itself**, with no vendor carrying any of the integration or security load. 

**And the obligations don't shrink because building got cheaper**: a system that touches protected health information carries the same compliance and maintenance weight whether it was licensed or written in-house. 

More software you own is **more software that demands attention**. Build where the capability is truly strategic and where you can own it without becoming the sole keeper of connective tissue that then constrains every future move — **not simply because building has become easy**.

What makes a capability strategic isn't necessarily the labor used to produce it. It's understanding how that **capability creates advantage** and **retaining control** over the things that make the advantage **real.**

A provider can potentially buy substantial portions of execution while retaining the design, judgment, measurement, and accountability that **make the capability distinctive.**

## Someone Has to Own the Difference

There is a **catch**. Externalizing execution **doesn't eliminate management responsibility**. In some ways, it makes that responsibility more important.

Suppose our second provider hands much of its intake front end to an external partner. At implementation, leadership **carefully defines the experience** it wants. Six months later, **an exception is simplified**. Then a workflow is **standardized**. A response-time expectation **slips**.

Nothing dramatic happens. Families still get through intake. The vendor may still be meeting its contractual obligations. But gradually, the provider's distinctive operating model **begins converging toward the vendor's standard one**.

The vendor doesn't have to do anything wrong for this to happen. Standardization is often exactly how a specialized operating company **creates efficiency**.

If the capability matters strategically, somebody inside the provider therefore has to **know what isn't supposed to become standard.** They need enough operating knowledge to recognize **drift**, enough visibility to measure whether the capability is still producing the intended **result**, and enough authority to **correct** it when it isn't.

And drift isn't the only risk. A capability can change abruptly too. If, for example, the company performing it is **acquired by an organization** whose interests no longer align with yours. I'll come back to that problem in the final article.

For now, the principle is simpler:

**You can externalize execution. You can't externalize accountability for differentiation.**

## The Exceptions Tell You What You Bought

The distinction becomes especially visible when a workflow leaves the **happy path**. A vendor may perform the predictable 80 or 90 percent of a process extremely well.

**ABA operations live heavily in the remainder.**

A family's coverage information is contradictory. A payor has an unusual requirement. The family's circumstances don't fit the normal intake sequence. Something appears during the process that **requires judgment** rather than another follow-up.

What happens next tells the provider a great deal about what it actually bought. Does the vendor **resolve** the exception? Does it **escalate it with enough context** for someone else to act? Does it simply **return the work** to the provider?

And, for strategically important workflows, does the exception **teach the organization anything?** If the same unusual situation happens twenty times, does someone get better at recognizing and responding to it? Does the provider? Does the external capability? **Do both?**

For commodity work, the answer may not matter very much. For something the provider believes differentiates it, **it matters considerably**.

## Compare Outcomes, Not Subscriptions

There is another way buying work changes the decision: the economics are different.

If a company sells completed eligibility verification, **comparing its price with an eligibility software subscription isn't particularly useful**. The internal alternative includes the software, employee labor, management, training, turnover, quality control, capacity constraints, and the downstream cost of mistakes.

The useful denominator changes. What does a correctly completed eligibility verification **cost** us? What does it **cost** to move an appropriate referral successfully through intake? What does it **cost** to resolve a denial?

Once providers buy work rather than tools, they need to **compare the cost and performance of outputs**, not subscriptions.

But even that calculation has **limits**. Our second provider could discover that an external intake capability produces a lower cost per completed intake and still **rationally decide against it**. If the cheaper model weakens the family experience the provider deliberately uses to differentiate, unit economics capture the cost of the work without capturing all of the **value of the capability**.

That's why the decision can't be reduced to **outsourcing economics**.

## Differentiation Has a Half-Life

There's another problem with the old rule to keep differentiating capabilities inside: **capabilities don't remain differentiating forever**.

Suppose our provider really does have an unusually effective intake operation today. It responds faster, keeps families engaged, and gets appropriate patients into care more efficiently than its competitors. **That's an advantage.**

Then competitors improve. Technology spreads. Specialized companies encode more of the workflow into capabilities other providers can simply buy. What once required unusual organizational expertise **becomes broadly available**.

**Yesterday's differentiator becomes today's table stakes.**

At that point, continuing to perform the work internally because it was historically strategic can become **its own form of inertia**. So leadership shouldn't ask only whether a capability differentiates the organization. It should periodically ask whether it **still** does.

A provider might rationally develop deep internal expertise while a capability creates **meaningful advantage**, externalize more of its execution as the market **catches up**, and redirect scarce management attention toward whatever creates the **next advantage**.

The boundary of the organization doesn't have to be permanent.

## Buy the Work. Own the Differentiation.

This is why *Software, AI, or People?* is ultimately **the wrong question**.

Providers should understand how an external capability works. AI, automation, offshore labor, domestic specialists, and conventional software create different risks and economics. But those are implementation questions.

The strategic question is **what the organization needs to own.**

For some work, the answer may be almost nothing beyond the outcome: verify the eligibility accurately, resolve the denial, complete the credentialing file, do it reliably, and handle exceptions appropriately.

For a **differentiating capability**, the provider needs to retain much more: a **clear understanding** of what makes it different, how that difference should be **expressed**, how it will be **measured**, and who remains **accountable** for **protecting** it. That doesn't necessarily mean retaining every person who executes every step.

The old rule was to keep your differentiating capabilities inside the organization.

The emerging rule may be more **precise**:

> **You don't have to own all the work that creates your advantage. You have to own the advantage.**

That requires knowing what makes the **capability different** in the first place, noticing when external execution begins to **dilute that difference**, and recognizing when the **market has caught up** and what once differentiated you has become **table stakes**.

The unbundling of work therefore isn't primarily an outsourcing decision. **It's a strategy decision**.

As more operating capabilities become purchasable, providers have an opportunity to become much more deliberate about where they spend organizational attention and **what they actually need to be exceptional at.**

That still leaves a **practical problem**. If some work belongs in the provider's core systems, some belongs inside the organization, and some can increasingly be purchased as specialized capabilities, **the operating environment has to accommodate all three**. Those boundaries also need to be able to move as the answers change.

That's where I'll turn in the final article of this series.