Operating Model Design: Build a Business to Scale
Learn how to design, build, and run a scalable operating model. Align your people, processes, systems, and RevOps data to eliminate execution bottlenecks.
An operating model defines how an enterprise’s capabilities, processes, applications, and data architecture interact to realize business outcomes.
At its core, the model establishes formal boundaries for integration and standardization, governing cross-functional handoffs, data ownership, decision rights, and performance instrumentation.
In revenue-generating functions, Revenue Operations (RevOps) serves as the operational glue that aligns marketing, sales, and customer success across this underlying architecture.
As organisations scale, ad-hoc workflows inevitably introduce technical debt, operational friction, and data fragmentation.
Adopting a structured Design–Build–Run (DBR) lifecycle provides a systematic framework for re-architecting these operational domains, eliminating structural bottlenecks, and continuously refining capabilities.
What Is an Operating Model?
An operating model is the blueprint for how an organization delivers value to its target customers and stakeholders.
While often confused with concepts like an operating system or Revenue Operations (RevOps), it serves a distinct function:
Operating model: How your business organises people, processes, systems and data to deliver its strategy.
Operating system: The management framework used to set priorities, monitor progress and run the business, such as EOS.
RevOps: The function that aligns marketing, sales and customer success across the revenue process.
MIT's Center for Information Systems Research (CISR) helped formalise the modern operating model concept through its work on enterprise architecture.
Its research defines an operating model in terms of the integration and standardisation required across a company's core processes.
The 2006 book Enterprise Architecture as Strategy, by Jeanne W. Ross, Peter Weill and David C. Robertson, connected the model to the systems and processes required for business execution.
This framing helps leaders decide where the business needs standard processes and shared data, and where teams need autonomy.
Too much standardisation creates rigidity. Too little creates fragmentation.
What Are the Components of a Modern Operating Model?
A modern operating model brings people, processes, systems and data together around the value the business promises to deliver.
Governance and performance management keep those components aligned as conditions change.
Area | What it covers |
Strategy and value | Target customers, desired outcomes, and the capabilities that give the business an advantage |
People and structure | Roles, responsibilities, skills, capacity, and reporting relationships |
Process | How work moves from its initial trigger to completion, including hand-offs and exceptions |
Systems | The platforms, integrations, and automation used to support the work |
Data | Definitions, ownership, access, quality standards, and reporting |
Governance | Decision rights, controls, escalation routes, and review ca |
Performance | Measures, incentives, and feedback used to assess and improve results |
These areas are interconnected. For instance, hand-off failures can appear to be process issues, but the underlying cause might be unclear ownership or missing CRM data.
Reviewing the full operating model helps you address the cause rather than adding another workaround.
MIT CISR's work on digital operating models also notes that digital offerings increase the need for speed and agility, not only efficiency. Modern models must therefore balance shared capabilities and data with enough flexibility to adapt.
When Should You Redesign Your Operating Model?
An operating model redesign is triggered when your operational infrastructure can no longer absorb increased organizational complexity, scale, or strategic change without generating technical debt and execution bottlenecks.
Common triggers include:
Rapid growth. Processes that worked for a smaller team begin to create bottlenecks as headcount, customer volume or revenue increases. Too much work may still depend on individual knowledge and manual coordination.
A new market or product. Entering a new market or adding a product may require different sales processes, pricing, service capabilities or compliance controls that the current model does not support.
Mergers and acquisitions. The combined business may inherit duplicate systems, conflicting processes and different definitions of the same data. A redesign can establish shared standards and clarify ownership.
Margin pressure. Rising costs, duplicated work and frequent rework may show that the business is no longer operating efficiently. Redesigning workflows can remove unnecessary steps and make better use of capacity.
Customer friction. Delays, inconsistent communication or dropped hand-offs often mean that no one owns the complete customer journey. The operating model may need clearer accountability across teams.
Technology transformation. Replacing a CRM, ERP or other core platform is an opportunity to improve the processes it supports. Roles, workflows and data requirements should be defined before the new system is configured.
AI adoption. AI agents and automation need defined triggers, reliable data, clear permissions and escalation routes. An AI-first operating model starts with the work and its controls so the technology can scale safely.
How Do You Design, Build and Run an Operating Model?
Operating model transformation works best as a Design-Build-Run (DBR) cycle. The three phases connect the target model to implementation and continuous improvement.
1. Design the Target Operating Model
Start with the strategy, customers and outcomes in scope. Map how work moves today, who makes decisions, which systems hold the data and where exceptions occur. ‘
Use cycle times, conversion rates, customer feedback and rework to identify structural problems.
Next, establish explicit design choices to guide the target state:
Which processes need to be standard across the business?
Which teams require local or specialist autonomy?
Who owns each end-to-end outcome?
Which decisions should be centralised, delegated or automated?
What data must be shared?
Which controls are required?
The resulting target operating model, or TOM, should define future capabilities, accountability, workflows, technology, data and governance. It should also state what is outside the project's scope.
2. Build the Required Capabilities
The build phase turns the design into working operations.
Prioritise the changes that remove the largest constraints. This may involve redefining roles, simplifying approvals, documenting processes, integrating systems, cleaning data and creating dashboards.
Sequence matters. Do not automate a process before its rules and exceptions are understood.
Do not migrate inconsistent data without deciding which definitions will govern the new environment.
GTM systems integration should follow the target process and data model rather than preserve every historical workaround.
Use manageable releases where possible. A pilot can test the new roles, workflows and controls while revealing exceptions missed during design.
3. Run and Improve the Model
During the run phase, teams measure performance, resolve issues and adapt the model based on findings.
Track a small set of measures tied to the redesign's objectives, such as lead response time, forecast accuracy, customer retention, cost-to-serve or manual rework.
You should also establish a regular governance cadence and name owners for processes, systems and data:
Teams should know which changes they can make locally and which require cross-functional approval.
Use the feedback from this process to guide your next design cycle.
What Are the Most Common Operating Model Design Failures?
Even with a strong target design, operating model transformations often fail during execution due to predictable organizational antipatterns.
The table below outlines the most common design failures, how to spot them in practice, and the strategic adjustments required to fix them.
Failure | What it looks like | Revised approach |
Treating technology as the model | A new platform is expected to solve unclear ownership or inconsistent processes | Define the process, decisions and data before configuring the system |
Designing in silos | Each department optimises its own activity while cross-functional hand-offs fail to improve | Map complete value streams and assign outcome ownership |
Copying another organization | The model reflects an “ideal” structure that doesn’t actually fit your organization’s strategy or needs | Make design choices based on your customers, economics, capabilities and unique goals |
Misaligned incentives | Teams are expected to collaborate, but their targets reward different priorities | Align measures and rewards with shared outcomes |
Overcomplicating the future state | The plan becomes so detailed or ambitious that teams struggle to implement it, morale sinks and resources suffer | Focus on the most important changes, test them in practice and then move forward |
Treating the organisation chart as the operating model | Leaders change reporting lines without fixing broken workflows or decision bottlenecks | Design around customer value, capabilities and end-to-end work |
Treating implementation as the finish line | Ownership fades after launch and old workarounds return | Assign ongoing ownership and regularly review performance |
How Do You Start Designing an Operating Model?
To design an operating model, begin by targeting a single strategic outcome and mapping the end-to-end value stream required to deliver it.
Follow this structured framework to move from current-state analysis to target-state execution:
Clarify the business outcome. Define what must improve, for whom and by how much.
Set the scope. Choose the customer journey, value stream, business unit or capability involved.
Map the current state. Document roles, hand-offs, decisions, systems, data and exceptions.
Identify root constraints. Look at capacity, capability, process, ownership, technology, data and incentives.
Define design principles. Agree on the rules that will guide trade-offs and resolve competing priorities.
Design and prioritise the target state. Rank changes by value, dependency, effort and risk.
Build, test and govern it. Implement in releases, measure results and assign permanent ownership.
For revenue-facing work, a structured revenue operations strategy can connect commercial objectives to the processes, systems and data supporting the customer lifecycle.
Executives must also agree on priorities, accept trade-offs and reinforce the new accountabilities. Otherwise, teams tend to preserve the current model.
Natalie Furness
FAQs
What is a target operating model?
A target operating model describes how an organisation intends to work in the future. It translates strategy into required capabilities, roles, processes, systems, data, governance and performance measures. It should provide enough detail to guide implementation without attempting to predict every future task or exception.
What is an operating model framework?
An operating model framework is a structured approach to assessing and designing how a business operates. Most frameworks cover people, process, technology and data, with additional consideration for governance, capabilities, customer value and performance. The framework provides consistent categories, but the resulting operating model should be specific to the organisation's strategy.
Who owns the operating model?
The executive team generally owns the enterprise operating model because it involves cross-functional choices and trade-offs. Individual leaders may own parts of it, such as a value stream, process, system or data domain. A transformation office, strategy team or RevOps function may coordinate the design, but it should not make major operating decisions without accountable business leaders.
How often should an operating model be reviewed?
Review performance regularly and reassess the overall model when strategy, scale or market conditions materially change. Quarterly operating reviews can identify emerging issues, while a deeper annual review can confirm whether capabilities and accountabilities still support the strategy. Events such as an acquisition, new market entry or major technology change may require an earlier redesign.
Can AI improve an operating model?
Yes. AI can reduce manual work, support decisions and make processes more responsive. It works best when the operating model already provides clear process rules, reliable data, defined permissions, and human accountability. AI should be built into the work with appropriate oversight, rather than added as a separate tool after the process is set up.
Book a Revenue Flow Discovery Session
See how we can uplift your revenue next
