The business model says how you make money; the operating model is how you actually run the business to make that money. Miss that distinction and you get a strategy deck everyone applauds and an organisation that cannot deliver on it. The business model answers "how do we create and capture value?" The operating model answers "how do we run ourselves to deliver that value, every day?" Get the second one wrong and the first one is just fiction.
Two checks tell you where you stand right now:
- Ownership: who owns the revenue model, and is that the same person who owns end-to-end delivery? If not, who bridges them?
- Delivery reality: if you traced a customer order or service request from start to finish today, would it follow the structure you designed, or a workaround someone built to survive it?
Key Takeaways
Aligning your operating model to your business model requires mapping both honestly, prioritising the handful of cross-boundary decisions that matter, and treating the redesign as a continuous discipline rather than a one-off project.
| Point | Details |
|---|---|
| Define both models separately | The business model answers how you create value; the operating model answers how you deliver it day to day. |
| Map current state before redesigning | Document structure, decision rights, and processes as they actually work, not as the org chart claims. |
| Prioritise the critical few | Focus redesign on the four or five cross-boundary decision processes, not exhaustive low-level detail. |
| Watch for pivot failure points | Business model shifts like recurring revenue demand matching changes to incentives, support, and systems. |
| Use a live platform to track drift | Oak & Nine gives managing directors and operations leaders a real-time map that flags bottlenecks before they escalate. |
Table of Contents
- Operating model vs business model: what each one is actually for
- What is an operating model, and how do you map it?
- Where the confusion between the two costs you the most
- How to align your operating model to your business model
- When to redesign, and the roadmap that actually works
- Closing the gap between the plan and the day-to-day
- Short examples that make the difference concrete
- Why leaders keep mixing these two up, and what it costs
- How digital transformation is reshaping both models
- Case studies: how the gap plays out across industries
- A short note on the mistake leaders keep repeating
- How Oak & Nine helps you close the gap between plan and delivery
- Frequently asked questions
- Sources
Operating model vs business model: what each one is actually for
A business model is the blueprint for how you create, deliver, and capture value. It answers three core questions: what value are you offering, to whom, and how does money flow back to you for it? Get this wrong and no amount of operational excellence saves you.
Map these elements to test whether yours is coherent:
- Value proposition — what problem you solve and why a customer pays for your solution over the alternative.
- Customer segments — who buys, and whether you are serving one coherent group or three incompatible ones under one price list.
- Revenue streams — subscription, transaction, licence, or a blend, and which one actually carries the margin.
- Channels and partners — how the offer reaches the customer and who else touches that journey.
- Cost structure — where money actually goes, and whether that lines up with what you claim to prioritise.
This is close to the logic behind the business model canvas, still the fastest way to get these elements onto one page.
Pro Tip: Run the unit economics before you touch anything else. If you cannot state, in one sentence, what it costs you to acquire and serve one customer against what that customer pays you over their lifetime, your business model isn't defined yet, it's an aspiration.
What is an operating model, and how do you map it?
An operating model is the internal machinery that delivers the business model: how the organisation is structured, who decides what, and which processes actually move work through the business. It answers "how do we run day to day to deliver on our promise?" rather than "what is our promise?"
Five components deserve a map each:
- Structure and roles — who reports to whom, and where accountability actually sits versus where the org chart claims it sits.
- Decision rights and governance — who can approve pricing exceptions, hiring, or a product change without waiting three weeks for a committee.
- End-to-end processes — how work genuinely flows from request to delivery, not the version in the process manual nobody reads.
- Technology and data — the systems and information that either support the model or quietly fight it, a point MIT CISR has researched extensively in how operating model choices shape IT investment.
- Metrics and operating rhythm — the cadence of reviews and the numbers that actually get discussed in them.
Document the current state honestly before designing the target one. Organisation maps, decision matrices, and capability maps give you a shared, factual starting point rather than a debate about impressions.
Pro Tip: Draw your current-state process map with the people who do the work, not the people who designed it five years ago. The gap between the two is usually where your operating model is bleeding.
Where the confusion between the two costs you the most
The clearest practical difference: the business model looks outward and plays on a medium to long timeframe, while the operating model looks inward and plays out over shorter operating cycles, often quarter to quarter. One asks whether the market wants what you sell; the other asks whether you can deliver it without heroics.
That difference shows up hard in ownership too. A business model tends to live with strategy, product, and commercial leadership, expressed in a canvas or a strategic plan. An operating model lives with COOs, operations directors, and HR, expressed in org charts, RACI matrices, and process maps. When nobody owns the seam between the two, misalignment festers quietly until it becomes visible in customer complaints or margin erosion.
Consider the practical fallout: a company launches a subscription pricing model (a business model shift) but keeps a transactional sales team and a support function built for one-off purchases. Churn climbs, not because the pricing was wrong, but because the operating model never moved with it, a failure mode the Shopify operating model guide flags directly.
Run this check now:
- Does your incentive structure reward the behaviour your business model needs, or the one your old operating model was built for?
- When a customer escalation crosses two departments, does anyone actually own resolving it, or does it just bounce?
- Has anyone redesigned a core process since the last time the business model changed?
If you hesitated on any of those, you have found your misalignment.
How to align your operating model to your business model
Alignment is a sequence, not a workshop. Run it in this order and resist skipping steps because they feel obvious.
- Map the business model and agree the measures. Get the value proposition, segments, and revenue streams on paper, and agree what "working" looks like in numbers.
- Map the current operating model. Structure, decision rights, processes, systems, as they actually function, not as the org chart claims.
- Identify the gaps and prioritise four or five cross-boundary decision processes. These are the handoffs between departments where friction actually happens, and practitioner guidance consistently points to focusing effort here rather than exhaustively redesigning every low-level task.
- Design the target operating model. Decide the structure, governance, and systems needed to close the gaps you found, using a decision rights matrix to make ownership explicit rather than implied.
- Pilot, measure, and scale. Test the redesign on one function or region before rolling it out everywhere.
Produce three living artefacts along the way: a decision-rights matrix, a capability map, and a process value chain. Govern the change with named owners, a fixed review rhythm, and two or three lead metrics you actually track, not twenty you collect and ignore.
Pro Tip: Assign an owner to the seam itself, the point where the business model and operating model meet, not just to each side separately. Seams without owners are where transformation projects quietly die.
When to redesign, and the roadmap that actually works
Four triggers usually mean it is time to redesign: a business-model change (new pricing, new channel), a scale jump that outgrows your current structure, persistent cross-functional failures nobody has fixed, or new technology and regulation that force a rethink.
A sound project runs through five phases: diagnose, design, pilot, scale, embed. Skip a phase and you pay for it later, usually at the worst moment.
Three pitfalls recur constantly:
- Over-design, trying to specify every micro-process from the top instead of the handful that genuinely cross boundaries.
- Skipping governance, redesigning structure without redesigning who decides what.
- Wrong sequencing, piloting before you have agreed how you will measure success.
The target operating model guide from Oak & Nine walks through this sequencing in more depth for teams planning their first structured redesign.
Closing the gap between the plan and the day-to-day
Most organisations do not fail because their business model was wrong. They fail because nobody kept the operating model honest as conditions changed. A live organisational map that updates as roles, processes, and systems shift, rather than a static diagram redrawn once a year, closes that gap far faster than another strategy offsite.
Preemptive alerts that flag a process bottleneck before it stalls a delivery, or a resourcing gap before it becomes a missed deadline, turn operating model management from an annual audit into a continuous discipline. A managing director scaling from one site to three, or an operations leader piloting a new service line, gets to see where the model is straining before customers do.
This is the kind of proof point Oak & Nine's own operations leadership resources are built around, and it is worth returning to as your organisation grows past the size where informal coordination still works.
Short examples that make the difference concrete
A software company's business model might be simple: charge a monthly subscription for access to a tool. Its operating model is everything underneath that promise, the onboarding flow, the support tiers, the release cadence, the billing system that has to handle upgrades and downgrades without breaking. Two companies can share an identical business model and run completely different operating models, one lean and automated, one bloated with manual handoffs, and only one of them will scale profitably.
A manufacturing firm offers a clearer contrast. Its business model might centre on premium, made-to-order products at a high margin. Its operating model has to match: flexible production lines, a skilled workforce empowered to make judgement calls, and a supply chain that tolerates variability. Force that same firm into a mass-production operating model, rigid lines, standardised routines, and the business model collapses even though nothing about the value proposition changed.
A retailer moving from physical stores to e-commerce shows the seam most starkly. The business model shift (channel change) looks simple on a slide. The operating model shift is not: warehousing replaces shop-floor stock, delivery logistics replace till operators, and customer service moves from face-to-face to ticketing systems. Companies that treat this as "just a website" rather than a full operating model redesign are the ones that stall six months in, buried under fulfilment problems nobody planned for.
Why leaders keep mixing these two up, and what it costs
The most common mistake is treating "operating model" as a synonym for "org chart" and "business model" as a synonym for "strategy," then wondering why alignment discussions go nowhere. Both models have real, distinct content, and conflating them means nobody actually owns the translation between what you promise and how you deliver it, a confusion Milen Vasilev's analysis of the strategy, business model, and operating model stack addresses directly.
A second pitfall is designing the operating model once and treating it as finished. Markets move, customer expectations shift, and a structure built for a ten-person team run by consensus does not survive contact with a hundred people and three business lines. Organisations that revisit their operating model only during a crisis are always designing under pressure, which produces worse decisions than designing on a planned cycle.
A third, subtler challenge: business model change frequently gets approved at board level with far less scrutiny of what it requires operationally. A pivot to recurring revenue sounds attractive in a strategy meeting, but it quietly demands new incentive structures, a different finance system for recognising revenue, a support model built for renewal conversations instead of one-off transactions, and a release cadence that matches ongoing customer expectations rather than annual launches. Skip that operational redesign and the pivot fails, not because the business model was flawed, but because nothing underneath it changed to support it.
Finally, cross-functional politics gets mistaken for operating model design. Redrawing boxes on an org chart to resolve a personality conflict is not the same as fixing a genuine decision-rights gap, and leaders who confuse the two waste redesign cycles solving the wrong problem entirely.
How digital transformation is reshaping both models
Digital transformation rarely touches only the business model or only the operating model. It usually forces both to move at once, and that is exactly where most transformation budgets get spent inefficiently.
On the business model side, digital channels create entirely new revenue streams, usage-based pricing, marketplace commissions, data monetisation, that did not exist in the original blueprint. On the operating model side, those new revenue streams demand new decision rights (who can approve a dynamic price change in real time?), new metrics (usage data replaces simple sales counts), and new technology choices about how much to integrate systems versus let them run independently, precisely the kind of trade-off MIT CISR's research on integration and standardisation is built to help leaders navigate.
Automation compounds this. Routine tasks that used to require a person checking a spreadsheet now run through software, which frees capacity but also removes the informal checks that used to catch errors. That gap has to be filled deliberately, through better monitoring and clearer escalation paths, or it becomes a silent operational risk. Leaders who treat automation purely as a cost-cutting exercise, rather than an operating model redesign in its own right, tend to discover the gaps only after something breaks.
The organisations getting real value from digital transformation are the ones treating their operating model as a living structure that adapts continuously alongside the business model, not a static chart revisited once every few years.
Case studies: how the gap plays out across industries
A financial services firm expanding into a new regulatory market illustrates the operating model side sharply. The business model, lending or advisory services, barely changes. What changes entirely is the operating model: new compliance decision rights, new reporting processes, sometimes an entirely separate governance layer to satisfy a regulator. Firms that underestimate this treat market entry as a sales exercise and get blindsided by compliance failures within months.
A healthcare provider moving from in-person consultations to a hybrid telehealth model shows the reverse pattern: the operating model (clinical staff, scheduling systems, care processes) has to be redesigned almost entirely, while the underlying business model, fee for consultation, stays largely intact. The organisations that struggled were the ones that bolted a video call tool onto an unchanged operating model instead of redesigning triage, scheduling, and clinical handoffs around the new channel.
A logistics company adopting a platform-based business model, connecting independent drivers to shippers rather than owning a fleet, needed an operating model built almost from scratch: dynamic matching algorithms, a decentralised workforce with different governance needs, and performance metrics that track network reliability rather than fleet utilisation. Here, the business model change was the whole story, and the operating model had no legacy version to adapt; it had to be designed fresh, which is arguably easier than retrofitting one built for a different era.
Across all three, the pattern holds: the size of the required operating model change rarely tracks the size of the business model announcement. Sometimes a small pricing tweak demands a complete process rebuild; sometimes a dramatic new channel needs only modest internal adjustment.
A short note on the mistake leaders keep repeating
The most common failure isn't picking the wrong operating model, it's designing every process from the top instead of just the four or five that genuinely cross boundaries. Set those, then let local teams own the rest.
How Oak & Nine helps you close the gap between plan and delivery
Oak & Nine gives you what a slide deck never can: a live, connected view of how your business model is actually running, updated in real time rather than redrawn once a year. Managing directors get a single view across departments instead of five disconnected reports; operations leaders and HR get the same map, so decision rights and process handoffs stop living only in someone's head.
The platform surfaces where a process is bottlenecking, where resourcing is stretched thin, and where a decision is quietly stuck between two departments, before it turns into a missed deadline or a customer complaint. It also automates the routine tracking work that normally eats a manager's week, freeing that time for the decisions that actually move the business. If you are leading a team through a business model change, a scale jump, or simply want to see whether your current operating model is holding up, start with Oak & Nine's resource for managing directors and request a walkthrough of what a live organisational map would show for your business.
Frequently asked questions
Is an operating model the same as a process model? No. A process model documents a single workflow step by step. An operating model is broader, it covers structure, decision rights, technology, and metrics across the whole organisation, of which processes are only one component.
Which comes first, the business model or the operating model? The business model comes first in principle, since it defines what value you are creating and how you capture it. In practice, the two evolve together, and a mature organisation reviews both on a regular cycle rather than treating either as fixed.
Can two companies have the same business model but different operating models? Yes, and this happens constantly. Two subscription software companies can charge the same way and target the same customers while running entirely different internal structures, one lean and automated, one manual and slow, with very different margins as a result.
What is a target operating model? It is the future-state design for how an organisation will run, built by comparing the current operating model against what the business model actually requires, then closing the gaps through a phased project.
How often should a company revisit its operating model? There is no fixed interval, but a change to the business model, a significant scale jump, or repeated cross-functional failures are all reliable signals that a review is overdue.