Every leader has said some version of it: "We have that capability." The programs exist, the people are trained, the technology is installed. And yet the value isn't reaching the customer. Both statements are true at the same time, and the reason they can both be true is the difference between a capability and a service.
It is the most useful distinction in operating-model work, and the most commonly skipped. Get it, and a whole class of stuck problems suddenly has a diagnosis.
Capability vs service, in one line: a capability is what an organisation can do; a service is how that capability is put to work to reach a specific customer. Ask it the other way round, service vs capability, and the answer is symmetric: the service is the delivery, the capability is what makes the delivery possible.
The what and the how
A capability is what an organisation can do: assess eligibility, settle a payment, diagnose a fault, teach a skill. It is a latent ability, an integrated system of people, process, technology, and information that could produce value.
A service is how that capability is put to work to deliver value to a specific someone. Capability is the what; service is the how. A bank has a payments capability; "pay a friend from your phone in ten seconds" is a service. A health system has a diagnostics capability; "get your scan result explained at a Tuesday clinic" is a service. The capability is the potential. The service is the potential actually reaching a person.
The formula is short enough to keep on a sticky note: develop capabilities, operationalise services. Building the ability is one job. Operationalising it as a service that reaches a customer at an agreed standard is a different job. Confuse the two, and you get exactly the paradox from the opening: an organisation certain it "has the capability" and equally certain nothing is landing. The capability exists. It was never operationalised.
The stable what, the evolving how
Here is why the distinction earns its keep. Capabilities are remarkably stable. Services are where the change happens.
Take an airline. It has needed a Passenger Check-in capability for as long as airlines have existed, and that hasn't changed. What has changed beyond recognition is how the airline operationalises it: from a staffed counter, to a self-service kiosk, to an app that issues a boarding pass from your sofa, to a face at a biometric gate. The capability held constant. The service, the how, transformed the customer's experience, the airline's cost per passenger, and the staff's working day, all at once.
The pattern is everywhere once you see it. A bank has always needed a lending capability; the service went from a branch appointment over two weeks to an instant decision in the app. A government has always needed a benefits capability; the service went from a paper form posted to an office to a self-service application that pays out in days. A library has always had a lending capability; the service went from a card catalogue and a stamp to a hold placed online and collected from a locker. In every case, nobody rebuilt the capability. They rebuilt the service on top of it.
This is the sentence to remember: the what endures, and the how is where you compete.
Why the how is where advantage lives
Because capabilities are stable and services are fluid, advantage doesn't live in the capability list. Your competitors have the same capabilities you do. It lives in how the service layer is configured: how well the capability is operationalised into something a customer actually experiences.
One honest caveat, because it matters. A new how is only an advantage until rivals copy it, and they do. Every airline has an app now; instant lending is becoming table stakes. So the edge is never simply owning a newer service. It is a service configuration competitors can't easily match, and the discipline of re-operationalising faster than they do. The advantage isn't the app. It is the ability to keep changing the how while the what stays put.
This also reframes a word that gets thrown around loosely. "Digital transformation," done properly, isn't the acquisition of new capabilities, and it's emphatically not a reorg. It is the re-operationalisation of the how of capabilities the organisation already has. Artificial intelligence is the current engine of that re-operationalisation: for most organisations it isn't a new capability so much as a dramatically better way to operationalise old ones, from claims assessment to customer support to scheduling. The capability was already there. AI changes the service on top of it.
The gap this explains
The capability-service distinction isn't academic. It names the single most common way strategy stalls: the organisation has built the capability and never operationalised it into a service that reaches the customer. The programs exist, the technology is installed, the people are trained, and somewhere between "we can do this" and "the customer experienced value," something breaks.
That gap isn't a shortage of capability, so building more capability won't close it. It is an operationalisation gap. The capability is potential energy that never becomes kinetic, and the service is the conversion. When value isn't reaching people, the missing piece is almost never another capability. It is the service that would carry the existing capability across to the person on the other end.
How to use it
The distinction earns its place because it changes your first move when something isn't landing. The reflex is to reach for capability ("we need a new system, a new team, a new competency") or for structure ("we need to reorganise"). Both are usually wrong. The better first question is: which service is failing to reach its customer, and is the problem the capability underneath it, or the way it has been operationalised?
Most of the time it's the operationalisation. The capability is fine; the service built on it's slow, fragmented, or optimised for internal convenience rather than the customer. That is good news, because re-operationalising a service is faster and cheaper than building a capability, and far more effective than moving boxes.
The practical version: keep two lists. What your organisation can do (the capabilities, which change slowly, and whose target level is a maturity question). And how each one reaches a customer (the services, which is where you improve, compete, and transform). Develop the first. Operationalise, and keep re-operationalising, the second. That is the whole of a service-oriented operating model in one habit.
Put the what and the how on one page with the free Service Operating Model Canvas, see the full argument in the operating model pillar, and read how to measure a service once you've defined it. The Closing the Strategy-Execution Gap course teaches the chain from capability to operationalised service end to end.