Revenue operations team structure, and the order to hire in.

The short answer. One function, not three silos.

A revenue operations team structure works when sales operations, marketing operations and customer success operations sit inside a single function with one leader, rather than three separate teams each reporting to their own VP. That leader answers to the CEO in an early-stage business, or to a CRO or COO once the company has grown enough to appoint one. Routing the function through the CFO is a common mistake: finance is built to optimise for cost control and forecast accuracy, while revenue operations exists to remove friction across the whole revenue engine, which is a growth mandate rather than a cost one.

Gartner made the scale of this shift explicit in a May 2021 press release, predicting that 75% of the highest-growth companies in the world would run a unified revenue operations model by 2025, up from a small minority at the time. The underlying logic still holds for any founder-led team today: when sales, marketing and customer success each keep their own version of the pipeline, the lead and the numbers, arguments about whose data is right eat time that should go into fixing the actual funnel.

How it works in practice. The three functions inside one team.

Underneath the single reporting line, revenue operations still does three distinct jobs, and each one keeps its own day-to-day focus even though the team shares one data model and one system of record.

• Sales operations. Pipeline hygiene, CRM administration, quota and territory design, deal desk support and forecasting cadence. This is usually the first slice of the function a founder-led team builds, because it is where the messiest data problems show up first.
• Marketing operations. Lead scoring, campaign systems, attribution and the handoff rules that decide when a marketing lead becomes a sales opportunity. Left unowned, this is where a business loses the clearest read on which channels actually produce revenue.
• Customer success operations. Renewal and expansion workflows, health scoring, and the reporting that tells a leadership team whether retention is improving or quietly eroding. Founder-led teams tend to build this slice last, usually once churn or expansion revenue starts to matter as much as new logos.

The structure that scales is one where these three functions report into the same person and share the same CRM, the same pipeline stage definitions and the same reporting layer, rather than each function building its own dashboard and its own version of what a "qualified lead" means. The team's size grows with the business, but the shape, one leader across all three functions, tends to stay the same from a 30-person company through several hundred.

Shared ownership matters more than shared headcount at first. A single generalist can run all three functions for a founder-led team of under fifty people, provided they have the authority to set the definitions everyone else works from: what stage a deal moves to on a demo booked, what score qualifies a marketing lead for handoff, what health signal triggers a customer success outreach. Those three definitions are where most of the argument between departments actually lives, and putting one person, or one small team, in charge of writing them down and enforcing them is what the structure is really buying a business, well before it is big enough to need three specialists.

The tooling question follows the structure, not the other way round. A single CRM acting as the system of record for sales, marketing and customer success data, rather than three separate tools stitched together with exports and spreadsheets, is what makes a one-team structure workable in practice. Businesses that keep marketing automation, the CRM and a separate customer success platform fully siloed tend to rebuild the three-function structure informally anyway, because nobody can actually see the whole funnel from one screen, and the reporting layer becomes the place arguments move to instead of being resolved.

What good looks like. Hiring in the right order.

The sequence that avoids the most rework is generalist first, specialists later. A first revenue operations hire needs to be comfortable touching CRM configuration, building a pipeline report a founder can actually trust, and redesigning a lead handoff process, all without a team behind them. Hiring a narrow specialist, a reporting analyst who cannot touch the CRM, or a systems administrator who cannot design process, before that generalist foundation exists usually means the specialist spends their first six months waiting on decisions nobody else in the business has made yet.

A 40-person SaaS company we worked with built its revenue operations function in exactly this order over eighteen months. The first hire was a generalist who spent their opening quarter rebuilding pipeline stage definitions that sales, marketing and the founder had each been interpreting differently. Once that was stable, the same hire added lead-scoring rules that halved the number of unqualified leads reaching sales reps. Only at month nine, once reporting requests were taking more than a day a week to service by hand, did the company add a dedicated data analyst. A systems administrator followed at month fourteen, once the CRM had grown enough integrations that configuration work alone justified a full role. The company never split sales ops, marketing ops and CS ops into separate teams; all three still report to the same RevOps lead today.

Good structure also means giving the function real authority, not just a dashboard. A revenue operations hire who can report on a broken handoff process but cannot change it becomes a report writer rather than an operator, and the underlying problem stays unfixed while the reporting simply documents it more precisely each quarter.

Timing the specialist hires matters as much as the order. Adding a data analyst before the CRM and pipeline stages are stable usually means their first months go into reconciling data quality problems rather than building anything new, which is a poor use of a specialist salary. Adding a systems administrator before the integrations and workflow rules are documented tends to produce a role that spends its time firefighting rather than improving the stack. The generalist-first sequence exists precisely to have that documentation and stability in place before a specialist's time becomes worth ring-fencing for deeper, narrower work.

Pitfalls to avoid. Where team structures actually break.

The most common structural mistake is recreating the silos revenue operations was meant to remove: splitting sales ops, marketing ops and CS ops under three different VPs, each with their own budget and their own priorities. This produces exactly the disagreement over whose pipeline numbers are correct that the unified structure exists to prevent, and it tends to happen when a company grows quickly and each function head asks for their own dedicated support rather than sharing one.

A second pitfall is scaling headcount before documenting the stack and the process. Adding a second or third RevOps hire before the first one has written down how the CRM is configured, what each pipeline stage means, and which reports actually get used, usually produces two or three people quietly rebuilding overlapping versions of the same report rather than covering more ground.

A third, quieter pitfall is putting revenue operations under finance by default, simply because it looks like an "operations" cost centre on an org chart. Finance-led revenue operations tends to optimise for forecast accuracy and headcount efficiency ahead of the process fixes that actually grow pipeline, which is a reasonable priority for finance and the wrong one for this function. Keeping the reporting line with the CEO or CRO, and treating the CFO as a close partner rather than the owner, keeps the incentives pointed at growth rather than cost control.

A fourth pitfall shows up once the team has grown past its first few hires: letting the title "revenue operations" drift onto anyone doing generalist administrative work, regardless of whether they have the systems access or process authority the role needs. A wide, loosely defined team with an inconsistent mandate is often harder to fix than no dedicated team at all, because it looks on the org chart as though the function is already covered. Reviewing what each person on the team can actually change, not just what they can report on, once a year keeps the structure honest as headcount grows past the point where one founder can track it from memory.

Whichever stage a business is at, the test is simple: can one person, or one team with one leader, see and act on the full funnel from first marketing touch through renewal, without waiting on three separate reports to agree on the numbers first. If the answer is no, the structure needs fixing before the next hire gets made. For the underlying operating model this structure supports, see our revenue operations work with founder-led teams, and if you are weighing whether to build this in-house or bring in outside support to get the foundation right first, our RevOps consulting engagements start with exactly the audit described above.

Once the reporting line and hiring order are settled, the next decision is usually which framework to build the function around. That is covered in full in our revenue operations framework guide, alongside the RevOps strategy guide for turning the structure into a working operating rhythm.