Nils Wirell
A CRM can look organized while the revenue operation behind it is pulling in three directions. Marketing reports lead volume. Sales questions lead quality. Customer teams maintain account context in a separate workflow. Meanwhile, leadership cannot get a straight answer on where pipeline is slowing down.
That is why the question of centraliserad eller decentraliserad RevOps matters. It is not an org-chart preference. It determines who owns the customer data, who can change the process, how quickly teams can act on a bottleneck, and whether your growth plan survives contact with a complex sales cycle.
For B2B companies selling across multiple stakeholders, markets, and long buying windows, the wrong model creates friction that no new automation can fix.
What the decision actually controls
RevOps is often treated as the team that manages the CRM, cleans up fields, and builds reports when someone asks. That is too narrow. A functioning RevOps model connects the commercial system: how demand is captured, qualified, routed, progressed, forecasted, handed to customer teams, and measured.
The organizational question is simple on paper. In a centralized model, a dedicated RevOps function owns the operating standards, core systems, data model, reporting logic, and improvement backlog across marketing, sales, and customer success. In a decentralized model, those responsibilities sit closer to each department or business unit.
The practical difference shows up when a high-intent account enters your funnel but is not followed up for four days. Or when sales rejects a large share of marketing-qualified leads without a consistent reason code. Or when a US market expansion requires a new routing process, but every local team has built its own definitions of a qualified opportunity.
In those moments, structure becomes speed.
The case for centralized RevOps
Centralized RevOps works best when the business needs one commercial language. That usually means shared lifecycle stages, common definitions for lead quality and pipeline, clear ownership rules, and a reliable view of revenue performance.
For a Nordic B2B company expanding into the US, this consistency is especially valuable. New markets introduce new campaigns, new segments, and often new sales motions. If every team adjusts the CRM and reporting structure independently, leadership loses comparability just when it needs it most. Pipeline may increase on paper while conversion quality, sales velocity, or source attribution becomes impossible to trust.
A central team can prevent that. It sets the non-negotiables: required CRM fields, handoff service-level agreements, account ownership, data governance, automation standards, and reporting definitions. It also sees patterns that individual teams may miss. Marketing may believe the issue is conversion. Sales may believe it is targeting. A centralized RevOps view can show that the actual bottleneck is poor enrichment, slow follow-up, or a stage definition that hides stalled deals.
There is another advantage: prioritization. Commercial teams always have more requests than capacity. New dashboards, campaign workflows, lead scoring changes, AI experiments, territory adjustments, and CRM cleanup all sound urgent. A central RevOps function can assess requests against revenue impact rather than giving priority to the loudest stakeholder.
But centralization has a cost. If the team becomes a ticket queue, it slows down the business. Sales leaders start maintaining shadow spreadsheets. Marketing finds workarounds. Local teams stop bringing useful ideas because every change requires a long approval path. Central governance is valuable. Central bottlenecks are not.
When decentralized RevOps makes sense
A decentralized model gives business units or functional teams more control over their workflows, data use, and operational priorities. It can be effective when teams have meaningfully different sales motions.
Consider a company with an enterprise motion involving six-month procurement cycles and a second product sold through a high-volume partner channel. Forcing both into identical qualification rules, dashboards, and automation may create more confusion than alignment. The teams need room to operate differently.
Decentralization also works when local market knowledge genuinely changes execution. A team entering a new geography may need to test messaging, routing logic, and qualification criteria faster than a central group can reasonably support. In that case, giving the team defined autonomy can accelerate learning.
The risk is that autonomy becomes fragmentation. Separate teams create their own lifecycle stages, scoring models, campaign naming conventions, and definitions of pipeline. The CRM becomes a set of disconnected workarounds rather than a commercial system. Reporting turns into reconciliation. Leaders spend meetings debating whose numbers are correct instead of deciding what to fix.
Decentralized RevOps is not the absence of governance. It requires stronger guardrails than most companies expect. Each team needs explicit boundaries: what it can change, what it must standardize, how changes are documented, and how data remains comparable across the business.
Centralized or decentralized RevOps is usually the wrong binary
For most complex B2B organizations, the answer is neither fully centralized nor fully decentralized. The stronger model is centralized standards with decentralized execution.
This means a central RevOps owner or team governs the foundation: CRM architecture, customer and account data, lifecycle definitions, security, reporting logic, integration decisions, and performance measurement. Marketing, sales, customer success, regions, or business units retain the ability to adapt execution within that framework.
They can test campaigns, adjust enablement, refine sequences, and propose workflow changes without rebuilding the underlying operating model. The goal is not uniformity for its own sake. It is to ensure that differences are intentional, visible, and measurable.
A useful test is this: if a regional team changes a process, can leadership still understand the effect on pipeline quality, conversion, sales cycle length, and revenue? If the answer is no, the organization has decentralized too far.
Decide based on operating complexity, not headcount
Companies often assume central RevOps is for large enterprises and decentralization is for smaller businesses. That is not the right dividing line. A 100-person B2B company with several products, multiple markets, and an enterprise sales cycle can need stronger central governance than a 1,000-person company with a simple motion.
Look instead at the points where complexity enters the revenue engine. You likely need a more centralized model if your teams struggle to agree on what counts as a qualified lead or opportunity, if CRM data is inconsistent across functions, or if reporting requires manual reconciliation before leadership reviews it.
You also need central ownership when a new automation, AI tool, or campaign workflow affects multiple teams. AI does not remove the need for RevOps. It increases it. An AI assistant trained on incomplete CRM records, inconsistent opportunity stages, or weak account data will simply make poor decisions faster. The business case starts with reliable inputs and clear operating rules.
More decentralization is reasonable when a team has a distinct sales motion, clear local accountability, mature operational capability, and a measurable reason to work differently. “They prefer it” is not enough. The variation should improve an outcome you can observe.
Build the model around decisions
The most useful RevOps design work starts by mapping recurring decisions, not software. Who decides when a lead is sales-ready? Who can alter lead routing? Who owns the definition of pipeline coverage? Who approves a new CRM object, integration, or scoring model? Who is accountable when opportunity data is incomplete?
If those answers are unclear, changing the reporting structure will not solve the problem. You need decision rights, service levels, and a visible backlog tied to commercial priorities.
Start with the areas that create the most drag between marketing and sales. For many companies, that is qualification and handoff. Define the required information for a sales-ready lead, the response expectation, the acceptable rejection reasons, and the feedback loop that tells marketing what happened next. Then measure whether the agreement is actually improving conversion and speed.
From there, establish a small set of shared metrics that nobody can reinterpret. Pipeline created, pipeline conversion, sales cycle length, win rate, source quality, and follow-up speed are often more useful than an elaborate dashboard with dozens of vanity measures.
Purasu typically sees the fastest gains when the operating model is treated as a revenue constraint, not an internal administration project. The point is not to centralize control. The point is to remove the friction that keeps qualified demand from becoming revenue.
Your RevOps structure should make it easier for good teams to act, harder for bad data to spread, and possible for leadership to see where growth is actually getting stuck. Build for those outcomes, then choose the degree of centralization that supports them.