Building a RevOps team from scratch: Lessons from three and a half years in the trenches

Editor's note: This article was based on a talk given by Cheryl Pederzoli, Executive Director, RevOps & Enablement, AGS Health at the time of this article, at our Revenue Operations Summit, Boston, 2026.

When our Salesforce admin quit and gave her two weeks' notice, I was on the marketing team doing enablement work. I had a little Salesforce admin experience, a marketing ops background, and just enough time to say, "Yeah, I'll help out for a couple of weeks until we hire someone."

That was three and a half years ago.

What I found when I got into that Salesforce instance was exactly what you'd expect. A mess. No documentation, no training links, reporting that didn't tell us much of anything useful.

So I did what any reasonable person would do: I went to HubSpot Academy over the weekend and knocked out the RevOps certification course. Then I went back to my boss and said we had a much bigger opportunity here than just replacing a Salesforce admin.

That's how our revenue operations function got started. Two people, 46 users, and a whole lot of cleaning to do.

You're probably not as alone as you think

Before I get into the how, I want to address something that trips up a lot of people early on: the feeling that your team is too small to do this properly.

When I started, there were two of us. I felt the weight of that constantly. But look around at any RevOps gathering, and you'll quickly realize that more than half of revenue operations organizations are six people or fewer.

Teams of two are completely normal. The pressure you feel isn't a sign that something's wrong with your setup. It's just the reality of this function at most companies.

Knowing that helped me stop comparing and start building.

How we evolved, year by year

Year one was almost entirely fixing and cleaning. We built documentation, got training in place, and started making sense of technology that other teams had bought without us.

Year two, once we'd found our rhythm, we could actually start improving things. We standardized processes and built custom object development that matched what our sales and customer success teams genuinely needed.

Year three, I added a third person, a technology enablement specialist focused specifically on training and rep-facing support. That hire changed everything. It freed our Salesforce admin to stop fielding quick questions all day, and it gave me the space to focus on process improvement.

Year four, we now support around 150 users across sales, customer success, legal, finance, operations, and marketing. AI is a big part of what we're figuring out this year.

Getting your priorities straight

When you're a small team, and everybody wants everything, you need a clear framework for deciding what actually gets your attention. We ask four questions.

Does it impact revenue? Anything that affects revenue flow gets prioritized, whether the impact is positive or negative. Customer attribution issues, for example, can quietly drain revenue if you're not watching them.

What's the impact if we don't do it? Some requests are genuinely low-stakes. If the answer is "not much," that matters.

Can we fix it with better training? A surprising number of requests are really just training gaps in disguise. Before you build something new, ask whether the system already does it and people just don't know.

How long will it take to implement? Anything beyond a week needs to be planned properly. It affects what else you can do.

From there, we sort everything into three buckets: fix now, fix next, or not yet.

Fix now covers anything that impacts revenue flow, usability, or security. When a BDR leaves and all your MQL routing runs through them, you stop what you're doing and fix it immediately.