Scope, purpose, responsibilities, and why RevOps exists
In 2025, Pearson made an organizational change that received far less attention than its investments in artificial intelligence or new products. The company brought several teams together under a dedicated Revenue Operations unit. Pearson said the change was intended to standardize sales processes, strengthen pipeline management, unify data sources, and make decision-making clearer and faster.
The decision is interesting because Pearson already had the functions one would normally associate with producing revenue. It had sales teams, marketing teams, customer-facing groups, finance professionals, technology, and management. Creating Revenue Operations therefore raises a basic organizational question: what was missing?
The answer is found in the way companies divide work.
A business usually organizes people according to expertise. Marketing attracts and develops potential customers. Sales manages commercial conversations and closes business. Finance deals with the financial consequences. Customer Success, service, implementation, or account-management teams take responsibility after the sale. Specialization makes each of these groups better at its own work.
Customers do not move through a company in the same way that boxes appear on its organization chart. Their experience passes through several of those groups, often without knowing where one department ends and another begins. A person may respond to an advertisement, speak to a salesperson, negotiate a contract, receive an invoice, begin using a service, ask for support, and eventually renew. To the customer, it is one relationship.
Inside the company, it can be six different processes.
Revenue Operations grew out of that gap.
The awkward spaces between departments
Consider something as ordinary as a new sales inquiry. Marketing has to decide when a person’s interest is strong enough to justify a salesperson’s time. Sales then needs to know who should receive the opportunity. That may depend on geography, company size, product, existing relationships, or the salesperson’s capacity.
None of this is especially difficult when a business has ten employees. People can talk to each other. Exceptions are remembered. A founder may know the history of every important account.
The same arrangements become fragile when a company has several sales teams, thousands of customers, multiple products and several information systems. One region develops a different definition of a qualified opportunity. Another keeps a spreadsheet because the central system does not quite fit its needs. Marketing believes it has produced a strong pipeline; Sales believes much of it is unusable. Both can support their position with data.
The problem continues further down the customer journey. A salesperson may agree to a special contract term without realizing how difficult it will be to administer. Information discussed during the sale may never reach the implementation team. Nobody starts work on a renewal because Sales believes Customer Success owns it and Customer Success believes the account manager owns it.
Most of these failures are unremarkable when seen individually. One lead waits too long. One field is missing. One account is assigned to the wrong person. One contract takes four additional days to approve. Over time, the accumulated cost can be substantial, and much of it sits between conventional departmental responsibilities.
Research firms have come to describe RevOps in similar terms. Gartner frames it as an end-to-end operating model spanning go-to-market functions, with shared processes and information across the revenue cycle. Forrester emphasizes the coordination of data, processes, technology, and people across the customer lifecycle.
Those definitions are useful, although they can make the subject sound more abstract than it needs to be. RevOps deals with the practical consequences of having several departments participate in the same commercial relationship.
What people in RevOps spend their time doing
The work is often surprisingly ordinary.
A RevOps team may decide how accounts are assigned to salespeople. It may define the stages in a sales process and determine what information is required before an opportunity can move from one stage to the next. It may establish rules for discounts or approvals. It can maintain the systems through which sales and customer information flows, build the process used for forecasting, or investigate why Marketing and Sales report different numbers for what appears to be the same activity.
Some teams also work on renewals, sales compensation, territories, capacity planning, pricing processes, and customer handoffs. The precise list changes considerably from one company to another.
A recent Zoom Revenue Operations role gives a sense of that range. Its responsibilities cover the path from demand generation and pipeline management through forecasting, quoting, billing, renewals, and expansion. The role also works with Sales, Marketing, Finance, IT, Legal, and customer-facing operations.
A job description should not be mistaken for a universal definition of RevOps. It does reveal why the function can be difficult to explain. Many of its activities already existed somewhere in the company before anyone used the name Revenue Operations.
Sales Operations, for instance, has long handled territories, forecasts, sales systems, quotas and sales-process design. Marketing Operations manages important parts of the marketing process and its supporting technology. Customer Success Operations performs similar work after a customer has purchased. Finance has always cared about pricing, contracts, forecasts and revenue.
RevOps changes the field of view. An issue can begin in Marketing and show up later as a Sales problem. A sales decision can create a billing problem months afterward. A weak handoff at the time of purchase may later appear in customer-retention figures. Looking at each function separately makes these connections harder to see.
This broader view is also where the boundaries of RevOps become less tidy. There is no universal organization chart that every company should copy. Some firms place Marketing Operations, Sales Operations and Customer Success Operations under one leader. Others keep those teams separate and use RevOps as a smaller coordinating group. In some businesses the function reports to the Chief Revenue Officer; elsewhere it may sit closer to Finance or the Chief Operating Officer.
The practical arrangement depends on the company’s business model and history. A recurring-revenue software business faces different operating questions from an industrial manufacturer working through distributors. The former may devote considerable attention to renewals and account expansion. The latter may care more about channel ownership, pricing, inventory commitments, or dealer relationships.
This variation is sometimes treated as evidence that RevOps lacks a clear definition. It may simply reflect the fact that operating problems differ.
Why the function tends to appear during growth
The need for RevOps often becomes noticeable after a company has already succeeded.
Early growth can be held together by people. A strong sales manager remembers exceptions. A founder resolves disputes. Finance knows which unusual contracts need attention. Employees develop informal habits that compensate for gaps in the formal process.
Headcount then increases. A second region opens. A new product line requires different expertise. One customer system is joined by another. People who designed the original process leave and their replacements inherit pieces of it without the original context.
At some point, coordination that depended on familiarity has to become explicit.
Pearson’s description of its own change is revealing here. The company placed Revenue Operations under a broader effort to create “execution synergies” and described the consolidation alongside work on operational systems and customer-centric execution. Elsewhere in the same report, Pearson says the new Revenue Operations team is intended to improve coordination between marketing, sales, and customer success operations.
There is a familiar pattern behind this. Growing organizations acquire complexity in small increments. A new approval is introduced because a previous deal went wrong. A new field is added because management wants another report. A region creates its own process because the global one does not fit a local need. Another software product is purchased to solve a problem in the existing software.
No single decision creates the complexity. A few years later, employees may need five systems and several manual workarounds to complete a task that once required an email.
Revenue Operations can provide a place to examine that accumulation. Sometimes the answer is a new process. Sometimes an old process needs to be removed. The second outcome receives less attention, although it is often more valuable.
Revenue targets eventually become operating questions
Senior management may set a goal such as increasing revenue by 15 percent. The goal itself says little about how the additional revenue will appear.
Perhaps the company needs many more new customers. Perhaps existing customers could purchase more. Perhaps customer losses are high enough that improving retention would have a larger effect than increasing new sales. The business may already have sufficient demand and lack enough sales capacity to handle it.
Once the goal reaches the operating level, it produces a series of questions. How many credible sales opportunities are required? How long does a typical deal take? Does the company have enough people to work those opportunities? Which customer segments convert well? Are current renewal rates sufficient? Where are deals slowing down? What happens to margins as discounting increases?
These questions cut across the information held by several departments. Marketing knows something about demand. Sales knows something about the active pipeline. Customer teams know something about retention and expansion. Finance has the financial view. RevOps often becomes the place where those pieces are assembled into a usable operating picture.
Forecasting provides a good example. A forecast is easy to think of as a Sales responsibility because salespeople know the deals currently under discussion. Yet future revenue in many companies also depends on renewals, new demand entering the system, available selling capacity, pricing decisions, and the reliability of the stages used to classify opportunities.
The mechanics of forecasting are therefore closely related to the mechanics of the commercial process itself. A beautifully designed forecasting model will still produce weak information when opportunities are poorly defined or updated inconsistently.
The same is true of dashboards. Management teams sometimes respond to disagreement about numbers by asking for another report. RevOps is more useful when it traces the disagreement backward. Two dashboards may differ because teams use different definitions, because systems are not synchronized, or because one part of the organization has created a parallel process. Fixing the report leaves the cause untouched.
Where RevOps can go wrong
The function has its own failure modes.
One is administrative expansion. A RevOps team adds fields, rules, approvals and required steps because each one appears reasonable in isolation. Salespeople gradually spend more time maintaining the process. Managers compensate by allowing workarounds. Data quality then worsens because employees no longer regard the official process as useful.
Another is excessive attention to technology. Revenue teams now have access to a large market of customer-management, forecasting, sales-engagement, analytics, automation and artificial-intelligence products. These tools can remove significant amounts of manual work. They can also give organizations a sophisticated way to run a badly designed process.
There is also a subtler risk. A RevOps team can become distant from the work it is organizing. A routing rule that looks efficient in a spreadsheet may create strange incentives for salespeople. A required field may appear essential to an analyst and feel meaningless to the employee expected to enter it fifty times a week. A centralized process may remove exactly the flexibility that made a particular local team effective.
Good operations requires contact with operating reality. That means sitting with the people who use the process, watching where they work around it, and being willing to discover that the formal rule is causing the problem.
This is one reason the quality of RevOps cannot be judged from the sophistication of its dashboards or the number of systems it manages.
A useful test is much more mundane. When a good customer expresses interest, does that interest reach the right person? Can the salesperson find the information needed to act? Can a sensible deal move through approvals without unnecessary delay? Does the next team know what happened before the sale? Can managers understand likely revenue without spending half the meeting reconciling spreadsheets?
These are ordinary questions. They are also close to the economic purpose of the function.
The economic case is mostly about wasted motion
Revenue growth receives attention because it is visible. Operational leakage is harder to see.
A company spends money generating interest and then responds slowly. Salespeople pursue accounts that were never a good fit. Managers spend hours preparing reports that disagree. A customer enters implementation with expectations the delivery team did not know about. An avoidable pricing exception creates months of billing work.
Every example consumes resources that have already been paid for.
The cost is distributed across departments, which makes it difficult to recognize. Marketing sees campaign spending. Sales sees seller capacity. Finance sees discounts and billing. Customer Success sees churn. The connection between them may appear only after someone follows the customer or the revenue process from beginning to end.
This explains some of the interest in RevOps among companies looking for more predictable growth. Gartner, for example, links the model with efficiency, reduced revenue leakage, and greater predictability across the customer lifecycle.
Still, expectations should remain modest. Revenue Operations cannot compensate for a weak product, an unattractive market, poor sales leadership, or customers who simply do not want to buy. Its influence is on the quality with which the commercial organization turns opportunity into revenue and manages the customer relationship afterward.
That quality matters more as the organization becomes difficult to coordinate by personal effort alone.
A working definition
The term Revenue Operations now covers enough activities that a definition can become either vague or excessively elaborate. For practical purposes, I would describe it this way:
Revenue Operations is the function that designs and improves the shared operating processes through which a company finds customers, sells to them, and manages the commercial relationship over time.
“Shared” carries much of the meaning. RevOps becomes relevant when several groups depend on the same information, when work passes from one team to another, or when a decision made in one function changes the economics or workload of another.
This also explains why Sales Operations can remain perfectly useful inside a company that has RevOps. Sales still has operating problems that belong specifically to Sales. Marketing has its own. So does Customer Success. Centralizing every operating decision would simply create a new bottleneck.
The distinctive contribution of RevOps lies in the areas where local optimization stops being enough.
There are several ways to organize that work, and companies will continue to use the title inconsistently. That is not unusual for a relatively young management function. The more useful question is whether somebody has responsibility for understanding how the pieces of the commercial process interact.
Pearson’s reorganization offers one answer. Another company may arrive at a different structure. What both are responding to is an old problem in management: specialization creates expertise, and expertise creates boundaries that then have to be coordinated.
Revenue Operations is one contemporary way of doing that coordination for revenue.
Frequently Asked Questions
What is Revenue Operations (RevOps) in simple terms?
Revenue Operations is the function that designs and improves the shared processes through which a company finds customers, sells to them, and manages the relationship afterward. It exists because a customer’s experience crosses Marketing, Sales, Customer Success, and Finance as one relationship, even though each department runs its own separate process internally.
Why would a company create a RevOps team if it already has sales, marketing, and finance?
Because those teams are organized around expertise, not around the customer’s actual journey. A lead can wait too long between Marketing and Sales, a special contract term can create billing problems Finance never anticipated, or a renewal can fall through because Sales and Customer Success each assume the other owns it. RevOps exists to manage those handoffs, not to duplicate the work each department already does well.
Is RevOps the same thing as Sales Operations?
No. Sales Operations handles problems that belong specifically to Sales, such as territories, quotas, and sales-process design. RevOps takes a broader view across Marketing, Sales, Customer Success, and often Finance, focusing on the shared processes and handoffs between those functions. Sales Operations continues to be useful even inside a company that also has RevOps.
When does a company typically need to introduce RevOps?
The need usually becomes noticeable during growth, not at launch. Early on, a small team can coordinate informally, a founder remembers exceptions and a manager resolves disputes directly. As headcount grows, new regions open, more systems get added, and that informal coordination stops working. At that point, the coordination that depended on people knowing each other has to become an explicit, designed process.
Who does RevOps typically report to?
There is no single standard. In some companies RevOps reports to the Chief Revenue Officer, in others it sits closer to Finance or the Chief Operating Officer. The right structure depends on the company’s business model, for example a recurring-revenue software business tends to focus RevOps heavily on renewals and expansion, while a company selling through distributors may focus it more on channel and pricing questions.
What are the most common ways RevOps goes wrong?
Three failure modes show up repeatedly: administrative expansion, where fields, rules, and approvals pile up until reps spend more time maintaining the process than selling; over-reliance on technology, where a sophisticated tool stack is used to run a badly designed process instead of fixing it; and distance from operating reality, where rules that look efficient on a spreadsheet create bad incentives for the people actually doing the work.
Leave a Reply