Operating Model Examples: Why the Service Model Beats the Org Chart

You've sat through the reorg. A new org chart appeared on a slide, boxes moved, reporting lines were redrawn, and senior leaders explained the design with real conviction. Six months later, the work is done the same way, by the same people, for the same stakeholders, because the chart was never the thing that was broken. The reorg is the reflex, the instinctive response an organisation reaches for when its strategy is failing to gain traction and it needs to be seen to act. It is also the change least likely to deliver the strategy. Of all the levers an operating model has, structure is the weakest, and the reorg pulls this lever first while leaving the rest untouched.

If you came in search of an operating model example, you will find five below, worked end to end across public and private sectors. But the examples only make sense once the definition is right, so let's start there.

An operating model is the practical manifestation of strategy. It is the explicit choices about how an organisation deploys people, process, technology, information, facilities, and suppliers so that the way work gets done actually produces the outcomes the strategy promised. It is the machinery between a strategic choice and a stakeholder who is measurably better off. Strategy names a destination and the operating model is the engine that gets the organisation there.

The most effective way to design that engine isn't the org chart. It is the service model: organise the operation around the services it delivers, tie each service to the outcome it exists to produce, and the machinery becomes something you can see, measure, and improve. The service carries the outcome; the org chart never does. Reach for the org chart instead, and you rearrange the boxes while the engine that actually delivers value, the service operating model, stays exactly as it was.

What an Operating Model Actually Is

The org chart rearranges boxes; the service model carries the outcome to a person. Structure is the weakest lever an operating model has.

Strip the jargon from every serious source and the same definition survives. A strategy is a set of choices about where to compete and how to win. An operating model is what makes those choices real: the arrangement of capabilities, processes, information, technology, locations, and suppliers that turns intention into running operations. The Business Architecture Guild says a version of this. So does the Bridgespan Group. So does every government target-operating-model exercise ever run. The definition isn't contested. What the field can't agree on is how to arrange the pieces, and that disagreement is where most operating-model work goes wrong.

The org chart is one small part of an operating model: the organisation-and-people domain, and the least strategic one. Reporting lines describe who answers to whom. They don't describe how a stakeholder request becomes a delivered result, which is the only thing the operating model exists to do. When leaders treat the org chart as the operating model, they mistake a single domain for the whole machine, and they reach for the lever (structure) that Bridgespan's own research flags as the one that "rarely holds the key" to delivering a strategy. The reorg feels like decisive action because it's visible and one of the few changes a leader can order alone. It changes the picture without changing the work. Decision rights and accountabilities are a different matter, and they genuinely move the needle, but in a service model they attach to the services rather than to the boxes on a chart. A better construct is available, and it has been hiding in plain sight inside the operating models that actually work.

Services Operationalise Capabilities

Two words carry the whole idea. A capability is what an organisation can do: assess eligibility, manufacture a component, resolve a dispute, teach a skill. A service is how that capability is put to work to deliver value to someone. Capability is the what; service is the how. The formula is short enough to keep: develop capabilities, operationalise services.

That distinction tells you where the two halves of the work live and why they're different jobs. Building the capability, the integrated system of people, process, technology, and information, is one discipline. Operationalising it as a service that reaches a stakeholder at an agreed standard is another. Confuse the two and you get organisations certain they "have the capability" and equally certain nothing is reaching the people they serve. The capability exists. It was never operationalised.

This is why the service model beats the org chart as the organising construct. Boxes describe structure. Services describe how capability becomes value, and they carry the outcome with them. Organise the operation around its services and you can ask, of each one, the questions that actually matter: what does this service produce, for whom, at what standard, contributing to which outcome, at what cost. The org chart can't answer any of those. The service model is built to do just that.

The Stable What, the Evolving How

The what endures, the how is where you compete: one capability, its service re-operationalised from counter to kiosk to app to biometric gate.

Here is the reason the distinction is worth the trouble. Capabilities are stable. Services are where the change happens.

Take an airline. It has always needed a Passenger Check-in capability, and that hasn't changed in fifty years. What has changed beyond recognition is how the airline operationalises it: from a manual, paper-based process at a counter, to a self-service kiosk, to an app that issues a boarding pass from the sofa the night before, to a face at a biometric gate. The capability held constant. The service, the how, transformed the customer experience, the cost structure, and the staff's working day all at once.

That is the general pattern. The what endures; the how is where you compete. Because capabilities are stable and services are fluid, advantage lives in how the service layer is configured, not in the capability list and certainly not in the org chart. One caveat. A new how is only an advantage until rivals copy it, and every airline has an app now. So the edge isn't owning a newer service. It's a configuration rivals can't easily match, and the discipline of re-operationalising faster than they do. It also reframes a word used loosely. "Digital transformation," done properly, is not 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: not a new capability so much as a dramatically better way to operationalise old ones. The reorg touches structure, the weakest lever. Real transformation touches services, the how, which is the lever that actually moves the customer experience and the cost base.

Five Operating Model Examples

The lens applied to all five examples: capability → service → valued output and service level → outcome → a stakeholder measurably better off.

Operating models are easier to see in the concrete than the abstract. Here are five, across public and private sectors, each read through the same service-oriented lens: the capability (the what), the service that operationalises it (the how), the valued output and its service level, and the outcome it contributes to. The lens is universal; the sectors aren't the point.

1. Government human services: a childcare subsidy

John is a parent. He has just relocated for a job that starts immediately, has two pre-school children, and can't cover childcare this month. He needs a subsidy fast, with no barriers.

• Capability (the what): eligibility determination, enrolment, benefit administration.
• Service (the how): provide the subsidy through self-service. John opens an account online, enters his details, and the service does the rest. He never experiences the capabilities; he experiences a service.
• Output and service level: an authorised subsidy paid monthly to his daycare. Efficiency lands on a real number. The same output costs the agency under a dollar to process when he self-serves online, against roughly thirty dollars in person. Quality is the rest of the service level: a timely decision, accurate, available around the clock, completed unassisted.
• Outcome: John takes the job; once his income is steady, his family is off assistance.

He gets it approved in time to take the job, and his family makes rent this month. The reflexive fix for "this department is too program-centric" is a reorg: move the subsidy team under a new division. That changes the boxes and nothing John experiences. The service model redesigned his experience (self-service, under a dollar, timely, off assistance once income is steady) without touching the org chart.

2. An airline: passenger check-in

• Capability: Passenger Check-in, unchanged for decades.
• Service: passenger check-in, one service, its how re-operationalised across four generations of channel and process: counter, kiosk, mobile app, biometric gate.
• Output and service level: a boarding pass and an assigned seat. Efficiency: cost per check-in collapses as the channel moves from staffed counter to phone. Quality: seconds instead of minutes, available a day ahead from anywhere.
• Outcome: the passenger boards on time, and counter staff shift from processing everyone to handling the exceptions.

This is the Stable What, Evolving How made literal. Nobody rebuilt the capability. They rebuilt the service on top of it, repeatedly, and that's where every gain came from.

3. A retail bank: lending

• Capability: credit assessment and loan origination.
• Service: loan origination, one service, re-operationalised from a branch appointment to an online application to an in-app instant decision.
• Output and service level: an approved, funded loan. Efficiency: cost to originate falls sharply off the branch channel. Quality: a decision in minutes rather than days, at equal or better accuracy of the risk call, available whenever the customer is ready.
• Outcome: the customer is funded when they need it, and the bank grows its book at a lower cost to serve.

One capability, one lending service, three channels of increasing immediacy. The competitive difference isn't the capability, which every bank has. It's how the service is configured and delivered.

4. A hospital: chronic disease management

• Capability: care coordination and diagnostics.
• Service: a nurse-led or pharmacist-led titration service that adjusts medication between physician visits, rather than waiting for the next appointment.
• Output and service level: an adjusted, on-target treatment plan. Efficiency: the cost of a titration touch between visits, set against the avoidable admission it prevents. Quality: time from a flagged reading to an intervention; accuracy of the adjustment.
• Outcome: the patient's blood pressure is controlled, and avoidable admissions fall.

An org-chart response would create a "chronic disease division." The service response designs the service that actually reaches the drifting patient between visits. (This is the operating-model side of the OKR hypertension example: the Key Result names the outcome, the service is what delivers it.)

5. A polytechnic: learner enrolment

• Capability: admissions and learner assessment.
• Service: an integrated apply-and-enrol service, re-operationalised from paper forms and in-person appointments to an online application with real-time eligibility and placement.
• Output and service level: an enrolled learner in the right program. Efficiency: cost per enrolment as the service shifts off in-person processing. Quality: time from application to offer; accuracy of placement so the learner starts where they will succeed.
• Outcome: the learner completes and is employable; the institution improves retention.

Five sectors, one construct. In every case the capability is stable, the service is where the value is created or lost, and the outcome is what the service is finally accountable for. The rule holds across all five: the service carries the outcome, and the org chart never does. That is why the service model beats the org chart, and why the same lens reads a hospital, a bank, and a benefits office without changing shape.

Where the Operating Model Sits

The examples share a structure, and it has a precise home. In the Design4 governance cycle, an organisation moves through four phases: Discover (purpose), Define (strategy), Develop (capability), and Deliver (operations). The operating model is the machinery of the bottom two. Develop builds the capabilities, the what. Deliver operationalises them as services, the how. The operating model is precisely the conversion of capabilities into services, run as live operations.

That placement isn't downstream of strategy. It is part of it. The Strategic Choice Cascade (Lafley and Martin, Playing to Win) has five choices, and the last two are capabilities required and management systems. Both are operating-model choices. So the cascade doesn't stop at strategy and hand off; it reaches into the operating model at its bottom two rungs. An operating model built on an "assumed" strategy has skipped choices that were the strategist's to make.

Each Design4 phase carries a governance question, the Four Ares. Applied to the operating model, they line up cleanly:

Read the right-hand column top to bottom and it's a design for an operating model you can govern, not just draw.

The Measurement Layer: Outputs, Service Levels, Outcomes

Go back to John for a moment, because everything in this section is already in his example. It only needs naming.

His subsidy service does a bundle of things he never sees. It checks his eligibility, enrols him, authorises the money. Then it hands him the one thing he actually came for: a subsidy, approved and paid to his daycare. That is the valued output. Every service has one. The training service hands over a trained person, the lending service a funded loan, John's service a paid benefit.

That output is also where the promise lives. John was promised a decision that's quick, correct, and available whenever he can get to a screen. If you write that promise down it has a name, the service-level agreement, and it's the point where you measure whether the service kept it.

Services also connect. John's approved subsidy becomes the input to the payment service that pays his daycare, and the daycare's own enrolment service picks up from there. The work runs across these services, one output feeding the next, and that chain is the operating model. It isn't a stack of boxes reporting upward. It's a line of connected services that point toward John, and that's the deepest reason the org chart is the wrong picture. Work flows across services, never up and down reporting lines.

(For the architects: the end-to-end flow of work that honours each service is the value stream. Service and value stream are complementary, not rivals. Lead with the service, because that's what John experiences and what carries the service level, and let the value stream describe how the work flows behind it. How to measure a service goes deeper.)

Outputs aren't the end of the story, and confusing them with the end is its own failure mode. An output contributes to an outcome: the change in the stakeholder's world the output was for. A subsidy paid is an output; a family off assistance is the outcome. Two measurement points, and the discipline is to hold both, because a service can hit every output target while the outcome never moves. (That is the operating-model face of Measurement Theatre: service levels green, nobody better off.)

There are only three things worth measuring about John's service, and you already know all three from his story.

The first is what it cost to serve him: under a dollar online against thirty at a counter. Call that efficiency.

The second is whether it kept its promise to him: decided quickly, decided correctly, open at the hour he was free. Call that quality. Efficiency and quality together are the service level, and they answer the Deliver question, are we getting it done well? The useful part is that these repeat. Any service of the same type is measured in a similar way, so the pattern hands them to you.

The third is the one that actually mattered to John: did his family get off assistance? That's effectiveness, and it's the only one the pattern can't hand you, because it comes from what this particular program was for. A service can be cheap and fast and correct, every light green, and John's family can still be no better off. That's why you hold all three. Effectiveness is the one that answers the Discover question, are we getting the benefits?

Target Operating Model (TOM)

A target operating model is the future-state design of an operating model. It's a blueprint of the capabilities and services the strategy requires, usually with a roadmap for building them. Where the operating model describes how the organisation runs today, the TOM describes how it intends to run once the strategy is delivered.

Picture the agency serving John designing the version of itself that would serve him well. That design is a small, connected set of models, not a binder:

• a context model: who the operating model serves and interacts with (stakeholders, suppliers, partners);
• a service model: the services it delivers, their outputs, and how they connect into value chains;
• a capability model underneath: the what each service operationalises, and the target maturity of each (this is where the capability maturity contour gets set);
• clear accountabilities: who owns each service and holds its service level.

The trap is a TOM that's a new org chart with a date on it. A target operating model example worth the name changes the service model, then lets structure follow, rather than redrawing boxes and calling it transformation. It is anchored in explicit design parameters from the strategy, tested against real stakeholder scenarios, and instrumented with the metrics that will show whether it's working.

Free template: The Service Operating Model Canvas maps any operating model or TOM on one page: capabilities, the services that operationalise them, their outputs and service levels, and the outcomes they contribute to. Use it to pressure-test a redesign before anyone touches the org chart.

The Field, and Why This Cuts Through

Operating models attract a lot of thinking and little agreement. It is worth naming the camps, because the service-oriented model is defined partly by what it refuses.

The service-oriented model doesn't add a sixth acronym to the seating-plan argument. It gives the operating model the three things the field keeps missing, and you can see all three in John. A spine: a capability became a service that produced the subsidy that got his family off assistance. A measurement layer: cost and quality told the agency the service ran well, effectiveness told them John was actually better off. And a direction: the whole chain points at a person at the end of it, not at a set of domains to argue over. Every element traces to something you can stand in front of, which is the difference between an operating model you can govern and a diagram you file.

Two honest concessions keep that from being a caricature. The domain frameworks aren't wrong, and Campbell's Operating Model Canvas is a useful completeness check. The service-oriented model doesn't discard the domains; it puts them to work beneath the services. And it has a price: a measured service model demands honest service definition and real outcome data, harder than redrawing boxes and slower than a reorg. The trade is deliberate, more work up front for an operating model you can run and correct rather than one you admire and file.

The Business Architect Belongs at the Strategy Table

There is a common assumption, stated plainly in the establishment literature, that the strategy will be defined by a strategy team and handed to the operating-model work as a settled input. The business architect, in that account, is a member of the strategy team at best and a recipient of its output at worst. That is too passive for what the operating model actually is.

If the operating model is the bottom two rungs of the strategic cascade, then the design parameters that translate "our strategy is X" into "the operating model must enable Y" are strategic choices, and they're conceptual-design work. Translating a strategy into the parameters an operating model must satisfy is precisely what business architecture does: it produces blueprints and roadmaps. So the architect doesn't wait downstream to receive the parameters. Look at what John needed: the subsidy fast, and no barriers. That isn't a wish, it's a design parameter, the thing that turns "help families back to work" into an operating model someone can actually build. Get that parameter right and the service falls into line behind it. Get it wrong, or let someone write it who has never met John, and every downstream choice inherits the error. That's why the architect belongs at the table while the parameter is being written, not downstream once it's set. It's a design job, not an analysis job. Leave the architect out of that room and the strategy writes cheques the operating model can't cash, commitments made with no honest account of what the machine can actually deliver.

This is what it means to treat business architecture as a strategic management discipline rather than downstream documentation. The credibility problem the field complains about, that "architecture" sounds like technical paperwork and gets shunted to IT, dissolves the moment the work is visibly this: a straight line from a strategic choice to John off assistance, drawn in language a board can act on. It isn't a better diagram but a running, measured, strategy-linked service model, with a practitioner in the room where the choices that shape it get made.

A Quick Diagnostic

Five questions will tell you whether your operating model is doing its job or is an org chart with ambitions. Run them in under ten minutes.

1. Can you name the design parameters the operating model was built to satisfy, or did the last redesign start from a chart?
2. Did the last operating-model change move any lever other than structure: process, information, decision rights, capability?
3. Can you trace a line from a stakeholder outcome back through a service to a capability, or does the model deliver outputs with nobody accountable for whether anyone is better off?
4. Are the handful of must-deliver capabilities identified, and is the model built to get those right rather than everything "good enough"?
5. Who owns the decisions? Are decision rights and accountabilities explicit, or does the structure complicate them?

Three or more weak answers, and what you have is a structure, not an operating model. The strategy-to-execution diagnostic traces the same break across the whole chain from purpose to outcomes.

The Operating Model Is the Engine

Strategy doesn't fail because people stop trying. It fails because the machinery that would turn a choice into an outcome was never built, or was built for a strategy no one confirmed, or was mistaken for the org chart and rearranged instead of designed. The operating model is that machinery. It is the engine the strategy assumes, and of everything an organisation reaches for when execution stalls, it covers the most of the chain: all of Develop and Deliver, capability turned into delivered value.

Build it as a service model and it becomes something you can actually run: capabilities operationalised as services, services producing valued outputs at an agreed standard, outputs contributing to outcomes that close the loop back to purpose. Build it as a new org chart and you have moved the boxes and changed nothing the stakeholder will ever feel. The choice between those two is available every time a strategy isn't landing, and it's the difference between being seen to act and actually operationalising the strategy you already have. On the other end of the machine is John, who needed the subsidy in time to take the job. Build the service model and he gets it. Redraw the org chart and he's still on hold three offices deep, explaining his situation for the fourth time, while the new boxes look tidy on the slide and nothing reaches him.

Frequently Asked Questions

Continue Learning

Pillar pages

• Strategy to Execution: How to Close the Gap: the four points where the chain from purpose to outcomes breaks, and what closes each one
• What Is Business Architecture?: the discipline, the models, and how it connects purpose to delivery
• Business Architecture Framework: The Design4 Approach: the four-phase governance cycle the operating model lives in
• OKRs Are Not a Strategy: the dashboard that assumes the operating-model engine is already built
• Capability Maturity: where target maturity is set for the capabilities an operating model operationalises

Tools and going deeper (cluster)

• The Service Operating Model Canvas: map any operating model or TOM on one page (free template)
• The Reorg Reflex: why structure is the weakest lever, and what to reach for instead
• Services Operationalise Capabilities: the stable what and the evolving how, in full
• How to Measure a Service: efficiency, quality, and effectiveness, and which question each answers
• Outputs Are Not Outcomes: the service side of benefits, and how to avoid Measurement Theatre
• Design Parameters: The Hinge From Strategy to Operations: how a strategic choice becomes something an operating model can be built to satisfy