8 min read
Ask five companies what their revenue operations team does and you will get five answers. One runs the forecast. Another administers the CRM. A third builds lead routing and lives in the automation editor. A fourth produces a weekly dashboard that three people open. The title has spread faster than any agreement about the job, which is how so many teams end up hiring for it and then wondering what they bought.
Revenue operations, usually shortened to RevOps, is the function that owns the systems and processes revenue moves through, from first touch to renewal. It treats marketing, sales, and customer success as one motion rather than three, and it holds the data, the metric definitions, and the handoffs that connect them. Where sales operations makes the sales team more effective and marketing operations makes the marketing team more effective, revenue operations is accountable for the whole path a customer travels across all of them.
That is the definition. The part most companies miss is what kind of work it is. Revenue operations is a design discipline. Its deliverable is not a report. Its deliverable is the set of decisions your systems encode about how your company sells: what counts as an account, when a deal becomes real, which rep sees which inbound lead, and what happens in the ten minutes after someone signs.
Those decisions get made whether or not anyone is assigned to make them. Someone picked the pipeline stages. Someone decided the required fields. Someone chose to store partner-sourced deals in a spreadsheet because the object model had no room for them. Every company already runs on a pile of answers to these questions. In most, the answers were made independently, by different people, in different quarters, for reasons nobody wrote down. Revenue operations is the function that makes them on purpose, in one place, and then makes the systems hold them.
The disagreements that look like reporting problems
The classic symptom is two teams walking into a meeting with two pipeline numbers. That reads as a reporting failure, and it gets treated as one: someone is asked to build a better dashboard. The cause is usually further upstream. Marketing counts an opportunity from the moment a demo is booked. Sales counts it once discovery is complete. Both numbers are correct against their own definition, so no amount of charting reconciles them. The meeting becomes an argument about whose spreadsheet is right instead of which deals will close.
Multiply that by every metric a company steers on and you get the condition revenue operations exists to fix. Not missing data, but competing versions of the same data, each defensible, none authoritative. Fixing it is unglamorous work: agreeing what a qualified lead is, writing it down, encoding it once, and deleting the other three places it was defined. This is the part that produces compounding returns, and it is the part that gets skipped in favor of buying something.
Why the function emerged
Revenue operations grew out of a structural fact about B2B buying: the customer's path stopped matching the org chart. A buyer researches alone, engages sales somewhere in the middle, gets handed to onboarding, expands through a customer success manager, and renews through someone else entirely. Each of those teams optimized its own stretch of that path with its own tools, its own definitions, and its own targets.
Optimizing every department separately produces a company that performs worse than the sum of its parts, because the losses land in the seams. The inbound lead that ages out during routing. The deal forecast twice under two names. The usage drop that signaled churn six weeks before anyone read it as churn. None of those failures belong to a department, so in a departmental structure none of them have an owner. Revenue operations is the answer to the ownership question.
Where the function sits decides what it can do
Three org models cover most companies.
Embedded in sales is the most common. It gets the function close to the number, which helps, but it quietly re-creates sales operations under a broader title. Marketing and customer success requests join the back of a queue set by quarterly quota pressure.
Reporting to finance produces strong forecast rigor and weak execution. The definitions become clean and the pipeline hygiene improves, while the automations, routing, and enablement work that shapes daily behavior gets less attention than it needs.
Standalone, reporting to a chief revenue officer, a COO, or the CEO, is the model that matches the job description. The function serves all three teams and answers to none of them individually.
The variable that decides the outcome is narrower than the reporting line, though: authority to refuse. A revenue operations function that cannot decline a new required field, a fourth pipeline stage, or a tool a director already promised their team is a service desk with an ambitious name. Design authority means the power to say no to entropy, and companies that hire the role without granting that power get dashboards, which is exactly what they then complain about.
What the function owns also depends on how the company sells. A business where most revenue arrives through self-serve signup needs product usage treated as first-class data and lifecycle automation that runs without a human trigger. A business closing six-figure contracts through outbound needs territory design, routing rules, and deal inspection instead. The difference between a product-led and a sales-led motion (link slug: product-led-vs-sales-led-growth) reshapes the function before anyone writes the job description. And the function sits downstream of the strategy you have chosen for reaching your market (link slug: gtm-strategy), which it can execute far better than it can substitute for.
What good design refuses to ask for
Process for its own sake kills this function, and it does the killing while looking like diligence.
Revenue operations exists to get everyone working from the same picture, and if the way it does that is too complicated, it produces the opposite. Every required field is a tax paid by the person filling it in. Charge enough of them and people route around the system: they invent values to clear a validation rule, they keep the deals they care about in a personal spreadsheet, they log the call three days later from memory. The system that was built to hold a shared picture starts holding a fictional one, and the reports built on top of it get more confident and less true.
Nobody wants to enter data into a CRM. Everybody wants the data to be there. That tension is the real constraint on the design, and it resolves in one direction only: the system has to earn each thing it asks a human for, and capture everything else by itself. Email and calendar activity, call recordings and transcripts, product events, billing status, support history. Most of the record can assemble itself from things that already happened. What remains for a person to supply should be the judgment a machine cannot reach: whether the champion has real budget, whether the timeline is honest, what the buyer said off-script.
Agents inherit your data model
Capable agents raise the stakes on every one of those design decisions.
A human seller compensates for a badly designed system constantly. They remember that the "Enterprise" tier in the picklist means something different for deals signed before last March. They know that the account owner field is stale and go ask a colleague instead. Judgment papers over structural mess, quietly, at a cost nobody measures.
An agent does no such thing. It reads what is in the system and treats it as the world. Give it a schema that fits your business and a context layer that is current, and it can research an account, score a deal against your qualification framework from the call transcripts alone, draft the follow-up, and flag the deal that has gone quiet. Give it two definitions of pipeline and a required email field stuffed with generated addresses, and it will reason fluently from nonsense and write the results back at speed.
Which means the quality of your operational design is now the ceiling on how much intelligence you can point at your revenue. Data model, definitions, and integration coverage used to be plumbing beneath the strategy. They are the thing that determines how much of the work can be done for you. The unglamorous decisions revenue operations makes about what an account is and where the truth lives are the same decisions that determine what your agents are capable of.
This is why we build Attio as an agentic CRM. Our data model bends to how your business works instead of asking you to describe it in someone else's objects, so the structure a revenue operations team designs is the structure the system runs. Every signal your teams generate lands in one shared context layer, so people and agents work from the same live picture of the customer. And a real API, an MCP server, and deep integrations mean that context is reachable from wherever the work happens, rather than trapped behind a UI. Teams get to build the go-to-market system they want, at the speed and scale the work now demands.
Where to start
If you are standing up this function, or trying to work out why the one you have is underdelivering, the first move is not a tool evaluation. Take the five metrics your leadership genuinely steers on. Write down the definition each team is using today, in their words. Then find every place in your systems where those definitions are encoded, and count the disagreements.
Working that list down is the job. Do it and the forecast starts to hold. Skip it and every tool you buy inherits the confusion, as does every agent you point at it.