Say your pipeline report shows $2.4M and your finance team will only stand behind $1.1M of it. Your VP of Sales is "confident" about next quarter, but marketing is blaming sales for not following up on MQLs, and customer success is wondering why nobody told them about the upsell conversation that apparently happened three weeks ago.
If this sounds familiar, congratulations. You are running a normal B2B company with siloed operations. And you are probably about six months away from either a painful miss or an expensive replatforming project.
I have seen this exact scenario play out across more than 30 engagements over the last seven years. The fix is not another dashboard or another weekly alignment meeting. The fix is revenue operations.
Revenue operations is one team, one data model and one set of definitions across marketing, sales and customer success.
RevOps replaces three separate ops functions with a single team that owns the whole customer journey, from first website visit to renewal, in one CRM with one definition of a lead, a pipeline stage and a customer. It is worth investing in once you have distinct marketing, sales and CS teams that disagree about the numbers, which for most B2B companies happens somewhere between 50 and 100 employees. Below 30 employees, a well-configured CRM and one named owner for operations is usually enough.
Most of what you will read about RevOps online is recycled consulting jargon. This guide is different. I am going to explain what revenue operations actually is, what it looks like inside a real company, and when it makes sense to invest in it, based on what I have seen work (and fail) across B2B companies from 20 to 2,000 employees.
What is revenue operations, really?
Revenue operations is the practice of unifying your sales, marketing, and customer success teams under a single operational function. That is the textbook answer. Here is what it actually means.
Right now, your company probably has three separate operational worlds:
- Marketing ops manages your email platform, runs campaigns, and tracks MQLs. They own HubSpot Marketing Hub (or Marketo, or whatever you are using).
- Sales ops manages your CRM pipeline, builds reports for the VP of Sales, and fights with Salesforce configuration.
- Customer success ops (if you even have this) manages renewal tracking, health scores, and onboarding workflows. They own Gainsight or a spreadsheet.
Each team has its own tools, data definitions, and reporting. Marketing counts a "qualified lead" differently than sales does. Sales marks a deal as "committed" while finance calls it "best case." Customer success tracks churn in a spreadsheet that has not been updated since last quarter.
Revenue operations removes these silos. Instead of three ops functions reporting to three VPs, you create one ops team that reports to a single revenue leader (usually a CRO, COO, or CEO). This team owns the entire customer journey from first website visit to renewal.
The result? One definition of "qualified lead." One pipeline methodology. One source of truth for revenue data. One team responsible for making the handoffs between marketing, sales, and customer success actually work.
Sounds obvious when you read it. The execution is where most companies get stuck.
Revenue operations vs sales operations: key differences
This is the question I hear most often from founders, so let me be direct about it.
Sales operations is a subset of revenue operations. Sales ops focuses on making the sales team more effective: CRM configuration, territory planning, quota setting, compensation models, deal desk, and sales reporting.
Revenue operations does all of that, but also covers marketing operations and customer success operations. More importantly, RevOps owns the connective tissue between these functions.
Here is the pattern in its most common form. Sales runs HubSpot, marketing stands up its own instance of HubSpot Marketing Hub, and customer success tracks everything in Notion. Three systems. Three sources of truth. Three different answers to the question "how many customers do we have?"
Sales ops would have fixed the CRM configuration. RevOps fixed the entire data architecture, connected all three systems through HubSpot Operations Hub, built a unified customer lifecycle model, and created a single reporting layer that everyone trusted. Sales ops is plumbing for the sales team. RevOps is plumbing for the entire revenue engine.
Another way to think about it: sales ops asks "how do we close more deals?" RevOps asks "how do we generate, close, and retain more revenue?" The scope is different. The mandate is different. The organizational placement is different.
If you are running a company under 30 people, sales ops is probably enough. Once you pass 50 employees and start feeling the friction between marketing and sales (and especially once customer success becomes a real function), that is when the shift to RevOps pays off.
The revenue operations framework: how it is structured
A lot of people talk about RevOps frameworks in the abstract. Let me show you what one actually looks like. This is based on the framework we use at Ziel Lab when we build RevOps functions.
Process layer
This is where you define how revenue is generated. You document every stage of the customer journey, from anonymous website visitor to closed-won customer to renewal.
In practice, this means:
- Lead scoring criteria that marketing and sales agree on (not marketing's version of lead scoring that sales ignores)
- A pipeline methodology with clear stage definitions and exit criteria
- Handoff protocols between marketing and sales (when exactly does an MQL become an SQL?)
- Customer onboarding workflows that pull data from the sales process
- Renewal and expansion playbooks that customer success actually follows
The version of this we see most often is a company with several different definitions of "pipeline" running at once. The CEO sees one number in the board deck. The VP of Sales sees another in HubSpot. The SDR manager has a third in a spreadsheet. That is not a reporting problem. That is a process problem.
Data layer: the single source of truth for RevOps
The data layer is where most RevOps implementations fail or succeed. This is your single source of truth: one CRM, one data model, one set of definitions.
For most B2B companies in the 50-200 employee range, this means:
- HubSpot as your core CRM (or Salesforce, depending on your situation)
- Segment or a similar CDP for collecting product usage and website data
- Clay for data enrichment and prospecting intelligence
- A clean data model with standardized properties, lifecycle stages, and attribution
The biggest mistake I see? Companies that try to solve data problems with dashboards. If your underlying data is dirty, no amount of Looker wizardry will save you. RevOps starts with cleaning the data, standardizing the definitions, and building integrations that keep everything in sync.
Everything else builds on top of it. Dashboards built on bad data just hide the problem more efficiently. At Ziel Lab this is where we spend the majority of our time during a CRM implementation.
Technology layer
Here is where it gets fun for the nerds (myself included). The RevOps tech stack for a modern B2B company typically looks like this:
Core CRM: HubSpot is our default recommendation for companies in the 50-500 employee range. It handles marketing, sales, and service in one platform, which eliminates a huge category of integration headaches. We have written extensively about why HubSpot works for growth-stage companies.
Data enrichment: Clay is the best tool I have used for enriching and maintaining CRM data, for one reason: waterfall enrichment. Instead of relying on a single data provider, Clay queries providers in sequence and stops at the first valid match, and you pay only for the matches it finds (Clay's waterfall documentation). Clay says it connects to more than 150 databases. In practice that means far fewer empty fields than any single provider returns, and empty fields are the whole CRM data problem. It also integrates directly with HubSpot. We use Clay to keep CRM data fresh, score accounts, and power outbound prospecting workflows.
Automation: n8n handles the workflow automation that sits between your tools. Things like "when a deal closes in HubSpot, trigger an onboarding sequence in customer success, update the billing system, and notify the account team." You can self-host n8n or use their cloud version (n8n documentation). Either way, it replaces the duct tape of Zapier with something you can actually maintain, for three reasons. A workflow is one object you can export, version and review, rather than a chain of separate zaps. A Code node lets an engineer write JavaScript or Python inside a step when the visual logic runs out. And an error workflow tells a human when something fails, instead of failing silently. We build these automation workflows regularly.
Analytics: HubSpot's native reporting covers most of what you need. For the rest, a BI tool like Looker or Metabase connected to your data warehouse gives you the custom analysis.
Product data: Segment collects product usage events and routes them to your CRM, analytics tools, and data warehouse. If you are running a product-led growth motion alongside sales, this is non-negotiable, because in PLG the buying signal is product usage, not a form fill. Sales needs activation, feature adoption and seat growth on the contact and company record to know who to call, and Segment's HubSpot destination sends those events into HubSpot as custom behavioural events and contact or company updates (Segment documentation).
The mistake most companies make is buying too many tools too early. Start with HubSpot and Clay. Add n8n when you have workflows that need automating. Add Segment when you need product data in your CRM. You do not need 15 tools on day one.
Most teams buy tools before they have problems. Add n8n when workflows actually need automating. Add Segment when you need product data in the CRM. Not before.
People layer
RevOps needs at least one dedicated person. At the 50-100 employee stage, that is usually a RevOps manager who reports to the COO or CRO. At 100-200 employees, you probably need 2-3 people covering CRM administration, data analysis, and process design.
The first RevOps hire should be someone who understands both data and process. Technical enough to configure HubSpot workflows and write SQL. Strategic enough to sit in a revenue meeting and ask the right questions about pipeline conversion rates. This person is rare, which is why many companies outsource RevOps to a specialist firm while they build the internal muscle.
Before and after: what RevOps actually changes
Across more than 30 engagements over the last seven years the starting picture is remarkably similar, so here it is as a pattern rather than as one company's story. The shape is what matters.
The shape we see before
- Marketing reports a large MQL number, sales accepts a fraction of it, and the rest sits in a queue nobody owns. Both teams are right, because they are working from different definitions of "qualified" in different systems.
- Lead response time is measured in days, if it is measured at all, because routing is a person forwarding emails.
- The forecast is a spreadsheet three people update on Friday. The CEO has stopped trusting it and is deciding on gut feel.
- Churn has a number but no explanation, because customer data is spread across the CRM, the billing tool, the support desk, and a sheet CS keeps for upsells.
- In the worse cases there is more than one CRM: sales on one, marketing on another, partnerships on a third, and nobody can say what a customer costs to acquire because attribution never crosses the system boundary.
What changes in the first two quarters
- Lead scoring is rebuilt with both marketing and sales in the room. MQL volume drops, acceptance rises, and the argument stops.
- Routing moves into HubSpot workflows or the equivalent, with an owner and a response-time SLA written down. Response time goes from days to hours because nobody is forwarding anything.
- Pipeline stages get written criteria, so a deal in "Proposal" means the same thing for every rep, and the forecast becomes a report instead of a ritual.
- Customer data lands in one place, usually HubSpot with custom objects for anything the default objects do not cover. Churn analysis becomes possible for the first time, and the usual finding is that the churned accounts share a visible early signal, most often incomplete onboarding.
- Manual CRM entry is replaced by enrichment through Clay and syncing through n8n, so reps stop spending their Mondays pasting notes and LinkedIn URLs into records.
- Expansion revenue gets tracked next to new business, and it is routinely a larger share of total revenue than anyone had assumed.
The measurable result is specific to each company and depends entirely on where they started, which is why no before-and-after figures are quoted here. What is consistent is the order: definitions first, then routing, then the data model, then automation. Teams that start with automation on top of unclear definitions automate the disagreement.
When to hire vs outsource RevOps
This is where I am going to be self-serving but also honest.
Hire internally when:
- You have a clear RevOps strategy and just need someone to execute it
- You are past 150 employees and need full-time, embedded ops support
- Your tech stack is stable and you mainly need optimization
- You have the budget for a $120K-180K hire (the going rate for a good RevOps manager in 2026)
Outsource when:
- You need to stand up RevOps from scratch and lack internal expertise
- You are going through a CRM migration or major tech stack change
- You need specialized skills (HubSpot architecture, Clay implementation, automation engineering) for a defined project
- You want to move fast. An experienced consultancy can do in 8 weeks what takes most internal hires 6 months.
At Ziel Lab, most of our work falls into the second category. A company comes to us with a mess of tools and data, we build the RevOps foundation (CRM architecture, data model, integrations, automation), and then hand it off to an internal hire who maintains it.
The worst approach? Hiring a junior ops person and asking them to "figure out RevOps." I have seen this fail repeatedly. Architecture decisions made in the first 90 days shape everything after. Getting those decisions wrong means rebuilding in 18 months.
When to invest in revenue operations
The trigger is friction between teams that each own a piece of the revenue number, more than any headcount threshold. The signals that it is time:
- Marketing and sales report different lead counts for the same month, and the meeting to reconcile them is now a standing one.
- The board deck pipeline number and the CRM pipeline number are produced by different people and do not match.
- Lead follow-up time is unknown, because nobody owns the handoff.
- Customer success finds out about upsells and renewals from the customer rather than from the system.
- A CRM migration or a second product line is on the roadmap, and the current data model will not survive it.
Two or more of those and the cost of waiting is already higher than the cost of the function. One of them, and a well-configured CRM with a named owner is still enough.
The honest case against RevOps
I should be transparent about when RevOps is not the right move.
If you are under 30 employees, you probably do not need a formal RevOps function. Your CEO or COO can own the ops work, and a well-configured HubSpot instance is enough infrastructure.
If your product-market fit is not established, investing in RevOps is premature. Fix the product first. Operations optimization on top of a broken product just helps you measure failure more precisely.
If your teams are not experiencing friction between marketing, sales, and customer success, do not create a problem to solve. Some companies run fine with separate ops functions until they hit 300+ employees.
RevOps is an investment. It requires budget (either for a hire or an external partner), executive sponsorship, and organizational willingness to change. If you do not have all three, wait until you do.
How to get started with RevOps: the first 30 days
If you are convinced RevOps is the right move, here is what the first month looks like.
If that sounds like a lot, it is. That is why many companies bring in a RevOps partner like Ziel Lab to accelerate the process.
What measurable looks like at the end of week four is narrow on purpose: one handoff with a written definition on both sides, a workflow that enforces it, and a report that shows the before and after for that one handoff. Lead response time is the usual candidate because it is easy to measure and everyone already agrees it matters. Anyone promising a transformed revenue engine in four weeks is describing a slide.
How to design an SLA between marketing and sales
The marketing and sales SLA is the single most useful RevOps artefact, because it turns "marketing sends bad leads" and "sales ignores our leads" into two numbers that can be checked. Five steps.
- Define the stages in writing. Use the CRM's lifecycle model so the definitions live where the data lives. HubSpot's default stages run Subscriber, Lead, MQL, SQL, Opportunity, Customer, and it defines an MQL as a contact marketing has qualified as ready for sales and an SQL as one sales has qualified as a potential customer (HubSpot lifecycle stage documentation). Write the entry criteria for MQL and SQL as properties a workflow can test.
- Marketing commits to volume and quality. A number of MQLs per month that meet the written criteria, with the criteria enforced by the scoring model rather than by opinion.
- Sales commits to response and disposition. A maximum time to first touch for each MQL, and a required outcome: accepted as SQL, recycled to nurture with a reason, or rejected with a reason. The reason field is what makes the loop improvable.
- Enforce it with workflows. A timer that reassigns or escalates a lead that breaches the response SLA, a required reason on rejection, and a weekly report of commitments against actuals on both sides.
- Review monthly and adjust the criteria. If rejection reasons cluster, the MQL definition is what needs changing.
Our sales and marketing alignment guide goes deeper on the negotiation itself.
How to structure deal stages so pipeline velocity does not stall
Most stalled pipelines are a stage design problem. Deals sit in a stage because nothing defines when they should leave it. The rules we apply:
- Every stage has an exit criterion the buyer performs. A demo held, a champion confirmed, a proposal sent, a legal review started. If the exit criterion is something the rep does, the stage will be gamed.
- Set the probability per stage and keep won and lost as real stages. HubSpot requires a probability for each stage and uses it for weighted pipeline, and it requires both a Closed won and a Closed lost stage for reporting to work (HubSpot pipeline documentation).
- Require the properties that matter at the stage where they become knowable. HubSpot lets you make properties required when a deal moves into a stage. Use it for close date, amount and next step, and nowhere else, or reps will stop moving deals.
- No parking stages. "On hold" and "nurture" stages are where pipeline goes to die. Close the deal as lost with a reason and reopen it later.
- Report stage age as well as stage count. The number that predicts a stall is how long a deal has been in its current stage against the median for that stage.
Our HubSpot deal stages guide has a worked example of a pipeline built this way.
A RevOps audit checklist
This is the list we run through in the first week. It is deliberately short, because the point is to find the two or three things that explain most of the mess.
- One system of record for contacts, companies and deals, or several? If several, which one does finance trust?
- Written definitions for lead, MQL, SQL, opportunity and customer, and do the CRM properties match them?
- Duplicate rate on contacts and companies, measured rather than guessed.
- Lead response time, measured from form submission to first human touch.
- Deal stages with written exit criteria, and the median age of deals in each stage.
- Attribution: can you say which channel produced last quarter's closed-won revenue without a spreadsheet?
- Integrations: a list of every tool that writes to the CRM, who owns each one, and what happens when it fails.
- Reporting: does the board deck number come straight from the CRM, or is it assembled by hand?
- Handoffs: is the sales-to-customer-success handoff a workflow or a Slack message?
- Ownership: is there one named person accountable for the data model?
How to scale revenue operations without adding headcount
The honest answer is automation first, and only in a specific order. The work that eats a RevOps person's week is repetitive and rule-based: routing, enrichment, deduplication, stage hygiene, handoff notifications. Each of those is a workflow, and once it is a workflow it costs nothing to run the thousandth time. Start with lead routing and response-time enforcement, because they touch revenue fastest. Then enrichment on create, so reps stop researching by hand. Then deduplication as a background process rather than a quarterly project. Then the sales-to-CS handoff. Our n8n automation guide walks through each of those builds.
For the work that is not repetitive, the architecture decisions, the data model, the migration, the engagement model matters more than the headcount. Three models exist: a defined project with an external partner, an ongoing fractional arrangement where a partner owns the stack for a set number of days a month, and a full-time hire. The project model fits a migration or a build from scratch. The fractional model fits a company that needs senior judgment a few days a month but cannot justify a senior salary. The hire fits once the stack is stable and the work is daily execution. Most companies move through them in that order.
Need a RevOps audit?
We will map your broken systems, show you what to fix first, and give you a plan you can actually execute.
Book a callFAQ
What does a revenue operations team actually do day to day?
A RevOps team manages CRM configuration, builds reports and dashboards, designs workflow automations, manages data quality, and runs cross-functional process improvements. A typical week might include fixing a broken lead routing rule, building a board-level pipeline report, and working with marketing to improve lead scoring. It is part analyst, part systems administrator, part process consultant.
How is RevOps different from just having a good sales ops person?
Sales ops focuses on the sales team. RevOps covers the full revenue cycle from marketing through customer success. The big difference is ownership of the handoff points. Sales ops optimizes within sales. RevOps optimizes across all revenue functions. The practical impact is that a RevOps person can fix the problem of "marketing sends leads that sales ignores" because they own both sides of that handoff.
What is the right time for a B2B startup to invest in RevOps?
Most companies feel the pain between 50 and 100 employees, or around Series A to Series B. The trigger is usually when you have distinct marketing, sales, and customer success teams that are starting to step on each other. If your board is asking questions about pipeline accuracy, if your CRO cannot get a straight answer on conversion rates, or if your teams are spending more time arguing about data than acting on it, you are ready.
Can you do RevOps without expensive tools?
Yes. You can start with HubSpot's free CRM, Google Sheets for reporting, and manual processes for handoffs. It is not about the tools. It is about the alignment, the data model, and the processes. That said, once you pass 50 employees, the manual approach breaks down fast. The cost of a proper tech stack (HubSpot, Clay, n8n) is usually less than the cost of the revenue you are losing to bad data and slow processes.
Should RevOps report to the CRO, COO, or CEO?
At companies under 100 employees, RevOps usually reports to the CEO or COO. This gives them authority to make changes across all revenue functions without getting stuck in political battles. At 100+ employees, a CRO is typically the right home, but only if the CRO genuinely owns marketing, sales, and customer success. If your CRO only owns sales, COO is the better reporting line. The principle: RevOps needs to report to someone with authority across all revenue teams, not just one.
Revenue operations is not a magic fix. It will not solve bad product-market fit, weak sales hiring, or a market that is not buying. What it will do is remove the friction between your revenue teams, give you data you can trust, and make it possible to execute the strategies you are building.
If you are running separate ops silos and feeling the pain of misaligned data and unreliable forecasts, let's talk about how to fix it. We have built RevOps functions for companies from seed stage to Series C, and we can help you figure out whether you need a full overhaul or just a few targeted fixes.