WHAT REVOPS MEANS
AT 5, 25, OR 60.

RevOps has become one of those words that means everything and nothing. Most companies aren't at scale. They're at 5 people, or 25, or 60. At every one of those stages, RevOps means something different.

At 5 people: RevOps is a set of decisions

You don't need a RevOps hire at 5 people. You need a founder who makes three decisions and writes them down.

Decision 1: What's your source of truth for each key number? Revenue lives in Stripe. Pipeline lives in HubSpot. Customer status lives in the product. Pick one system per metric.

Decision 2: What does your pipeline actually mean? Define your stages. "Discovery" means the first call happened. "Proposal sent" means a pricing document was delivered. If your stages aren't defined, your pipeline is a to-do list, not a forecast.

Decision 3: What happens after someone signs? The handoff from sales to onboarding to CS is where most early-stage companies leak. A deal closes, and then what?

At this stage, the "ops" work takes maybe two hours a week. It's not a role. It's a discipline. But if you skip it, you're building debt that gets exponentially harder to fix later.

At 25 people: RevOps is a part-time job becoming full-time

This is the stage where things start to fray. You now have a marketing person running campaigns, an SDR or two booking meetings, a couple of AEs closing deals, and someone doing CS. Everyone is in HubSpot. Everyone is building things. Nobody is coordinating.

Owning the CRM architecture. Someone needs to decide where data lives, enforce naming conventions, and prevent the contact object from becoming a junk drawer.

Building the first real workflows. Lead assignment, deal stage automation, renewal reminders, onboarding triggers. Not because automation is exciting, but because manual handoffs are already dropping things.

Bridging the teams. Marketing is generating leads. Sales is working them. CS is managing accounts. But are they using the same lifecycle stages? The same definitions of "qualified"?

Protecting data quality. Running regular audits. Cleaning stale contacts. Closing dead deals. Archiving unused properties. The least glamorous part of the job and the most important.

The trap at this stage is giving this person responsibility without authority. They can see every problem, but if leadership doesn't back their decisions, the system degrades faster than one person can maintain it.

At 60 people: RevOps is a function, not a person

At 60 people, you likely have distinct marketing, sales, and CS teams with their own managers and their own goals. The integrations are multiplying. The workflows are complex. And the consequences of bad data are real.

A dedicated team with cross-functional authority. Not embedded in sales. Not reporting to marketing. Sitting across all revenue teams with the mandate to build and enforce shared systems.

A documented architecture. What lives where, what each property means, who owns which system, how data flows between tools. If this doesn't exist in writing, you're one departure away from nobody understanding how anything works.

Integration governance. Every tool talks to every other tool. But who decided the sync direction? What happens when Stripe and HubSpot disagree? At 60 people, these aren't edge cases. They're weekly occurrences.

Process standardization across teams. Lead scoring means the same thing in marketing and sales. Pipeline stages have shared definitions. Renewal is a process, not a calendar reminder.

Reporting that leadership trusts. This is the ultimate test. If the CEO asks "what's our net revenue retention?" and gets one clear answer within five minutes, RevOps is working.

The thread that runs through all three

Whether you're 5 people or 60, RevOps is the same question: are the teams responsible for revenue working from the same reality?

At 5, that's a founder writing down three decisions. At 25, it's an ops person holding the system together and asking for the authority to enforce standards. At 60, it's a function with the mandate to build the infrastructure that makes revenue predictable.

The mistake most companies make is treating RevOps as something you "add" once you're big enough. By then, you've already built three separate realities, and merging them is ten times harder than building one from the start.

That's what we help companies figure out at Sequolia, whether you're making your first CRM decisions or untangling years of accumulated ones.