When a Digital Service Still Needs a Human

The Layers of a Digital Service describes the Interface layer as the concrete, consumable surface through which a service’s capability is reached — a web UI, an API, a CLI, a self-service portal. Most of the time that technical interface is enough, and documentation, in-product guidance, and chat assistants carry the rest.

But not always, and when a human does get involved, that does not automatically mean the interface failed or that the service has stopped being digital. It usually means one of three different things, each with its own implication for cost and pricing:

Human involvement does not automatically make a digital service less digital. That distinction matters because the rest of this post is mostly about the middle row — that is where the interesting design and pricing decisions sit — but the other two are worth naming precisely so they don’t get mistaken for it.

Where the Interface Should Absorb It — and Where It Can’t

The first row is not primarily a packaging or pricing question — though a documentation gap is still design feedback worth acting on. If a service breaks or its documentation has a real gap, fixing that for a customer is just the service doing what it already promised — not an extension of anything, and not something to price separately. In enterprises this is extremely common, and it is a real pain point: incidents, support tickets, and documentation gaps that should have been prevented become a recurring source of friction and unplanned cost, often absorbed by whichever team is closest to the customer rather than priced or budgeted for anywhere.

The cost is not only the provider’s, either. The customer pays too — in time lost, workarounds, and their own people pulled into chasing a fix — and that cost is often invisible to the provider precisely because it never shows up as a support ticket. When the customer’s accumulated cost becomes large enough, it can exceed the service fee itself, and that imbalance is exactly when they start looking for another service instead of tolerating the promise going unmet.

The second row is different, and this is where the earlier, simpler framing — “a human means the interface fell short” — needs to be narrowed. When a human is repeatedly explaining something the interface should make routine, that dependency should be reduced over time: better documentation, better defaults, better self-service tooling. But when the work requires customer-specific judgment — a nontrivial integration, an architectural decision about how to consume the service correctly, a genuinely novel edge case — that is not a deficiency to be engineered away. It can be a legitimate part of a high-value proposition, providing contextual judgment, discovery, assurance, or relationship management that no purely technical interface could deliver to every customer.

Whether It Is Worth Offering At All

Covering that second kind of need with a human does not scale the way the underlying digital service does — one more customer on a SaaS platform has a relatively low marginal cost; one more customer who needs a person to walk them through an integration costs an actual hour of someone’s time. Whether offering that human extension is economically feasible depends heavily on what the digital service actually delivers and to whom.

A Customer-Facing service selling to a large volume of small customers at a low price point usually cannot afford to put a person behind every one of them — the honest answer for that segment may simply be that some customers rely on community support, partners, or pooled support channels instead of a dedicated person. The same service sold to a small number of large enterprise customers, or a Platform service whose few consumers each represent significant recurring value, can usually afford it. Type and scale, not good intentions, decide whether this is viable.

When Human Help Becomes a Separate Offering

Occasional human support can sit inside the service without changing anything about it. But once that support has its own defined promise, scope, price, and contract, it has become something else: a companion service offering, adjacent to the digital one rather than part of its interface. The economics are why — the digital service is priced assuming a relatively low marginal delivery cost, and human time is the opposite of that, so it rarely stays folded into the base price once it becomes a real cost center. It is either sold separately — a paid implementation package, a professional services engagement — or recovered through a higher-priced tier, the way named customer-success contacts and enterprise support often are.

Either way, the result is a service offering that is, in the end, dependent on human delivery — sold, scoped, and delivered like one — sitting alongside a digital service whose Offering and Interface layers remain unchanged. What has been added is a distinct companion offering with its own economics and its own promise.

Not Every Enterprise Capability Is Digital

It is worth being precise about what this is not. A companion service that helps a customer consume a digital service is still anchored to it — it exists because of a specific need for a specific customer. That is different again from the third row: enterprise capabilities that were never digital services to begin with. This row gets less treatment in pricing terms than the first two, and that is deliberate rather than an oversight. It still requires funding — staffing, budget, opportunity cost, some measure of return — but it is not priced in the same sense, because it does not sit on top of a digital service’s Offering and Interface at all.

A Center of Excellence, a community of practice, an embedded coaching function — some of these can have a catalog of offerings, an intake channel, and repeatable engagements, so having an interface isn’t what sets them apart. The real distinction is that their outcomes are delivered primarily through organizational relationships, judgment, and capability transfer, not through a predominantly technical, repeatable interface. That resembles what Team Topologies calls enablement: helping other teams acquire a capability rather than operating a system on their behalf. The enabling function itself may be long-lived — Team Topologies is explicit that treating enabling teams as necessarily short-lived is a misunderstanding — but its engagement with any particular team should be temporary, aimed at that team’s growing autonomy rather than an open-ended dependency.

An enterprise’s real portfolio, then, is not only the digital services these types describe. It is those services, the companion services that sometimes extend them, and a layer of purely organizational capability that was never meant to be digital at all — three different things, funded and managed differently, that get flattened together far too often. Digital service is itself just one type in that portfolio, not a category apart from it — The Types of Enterprise Service works through the other four in the same detail this post’s table only sketches.

This is also where the scope of the DSLC Model deliberately stops. It manages the digital service — Offering and Interface included — through its life cycle, but it is not intended to govern a companion implementation offering or a Center of Excellence, because neither one is a digital service. That responsibility sits with the DEHSO Model, whose scope is the enterprise’s operation as a whole rather than any one digital service inside it. Getting this right matters in practice, not just in theory: fund a companion offering like a feature of the platform and its economics disappear into the platform’s; run a Center of Excellence like it owes uptime and support tickets and it will be measured against a promise it was never designed to keep.