Hiring RevOps? Stop Screening for the CRM Logo

Emily Goh · 2026-11-14

The job post says "5+ years of Salesforce required." Forty applicants come in. The recruiter filters out everyone whose resume says HubSpot, and the hiring manager interviews the six who are left. Every one of them can build a report. Nobody asks them what they would do when Sales and Finance bring two different revenue numbers to the same meeting. Three months after the hire, that is the exact problem landing on their desk.

So, how do you hire for RevOps skills? Screen for the work, not the logo. The CRM can be learned in weeks. What takes years is the judgment underneath it: getting teams to agree on what a number means, writing it down, checking whether the data follows it, and deciding what is worth fixing. Ask candidates to show you how they have done those things, in any tool. Then give them a short, realistic exercise and watch how they think.

Why the CRM logo is a weak filter

Requiring a specific CRM feels safe. It sounds like less ramp time. But it filters for the part of the job that is easiest to learn, and says nothing about the part that is hardest.

Think about what a RevOps lead actually spends the first 90 days doing. Learning where the buttons are takes a few weeks. The rest is figuring out what "Qualified" means to Sales versus Marketing, why the forecast drifts every quarter, which backlog items matter and who owns each number. None of that is in the vendor certification.

There is a second problem. Your definitions do not live in the tool. A candidate who knows Salesforce well still has to learn what Closed Won means at your company. We wrote about this when looking at CRM migrations: the records move, the meaning does not. The same is true for people. Their tool knowledge travels. Your definitions have to be learned either way.

The skills that travel between CRMs

Here is what a strong RevOps hire brings with them, whatever system they used last:

• Definition discipline. They ask "what does this number mean?" before they build anything. They write the answer down and get an owner to sign off.
• Tracing. When a number looks wrong, they can walk back from the dashboard to the records and find the cause.
• Prioritization. They can look at a long backlog and say what to rebuild, what to work around and what to leave alone.
• Getting agreement without blame. They can sit between Sales, Marketing and Finance and turn "your number is wrong" into "we are counting different things, let's pick one."
• Process thinking. They fix the form, the stage rule or the handoff, not just the bad records.

Notice that none of these mention a vendor. A person who has done all five in HubSpot will do them in Salesforce. A person who has done none of them in Salesforce will not suddenly start because they know the menus.

Interview questions that reveal real skill

Swap "How many years of Salesforce?" for questions about the work. A few that tend to separate strong candidates:

1. "Tell me about a time two teams reported different numbers for the same metric. What did you do?" Listen for whether they found the definition gap, or just picked a winner.
2. "How would you find out what Closed Won means at a company you just joined?" Good answers involve asking owners, reading the stage rules and checking real records.
3. "You inherit a backlog of 60 requests. What do you do in week one?" Listen for a way to sort, not a promise to do everything. Our post on what to fix first as a new head of RevOps covers this.
4. "A forecast number dropped overnight. Walk me through how you would find out why." Listen for steps that go from report to records to cause.
5. "Tell me about a fix you made that stopped a problem from coming back." Listen for process changes, not one-off cleanups.

Follow up every answer with "How did you know it worked?" Strong candidates can point to evidence. Weaker ones describe effort.

A 45-minute exercise that beats a tool test

Tool tests check whether someone can find a setting. A better exercise checks judgment.

Give the candidate a small, made-up spreadsheet. Say 40 deals, with stage, amount, close date and owner. Add two short definitions: one for Commit and one for Closed Won. Plant a few problems: deals in Commit with no close date, a Closed Won deal with no contract date, a duplicate.

Then ask three things:

1. Which records do not meet the definitions, and why?
2. What would the corrected Commit number be?
3. What would you change so these errors stop happening?

You will learn more in 45 minutes than in an hour of "show me how you build a report." You will see whether they read the definition first, whether they check the rows, and whether they think about the process behind the mess. You will also see how they explain it, which matters, because they will be explaining it to your CFO.

What you can do this week

You do not need to rewrite your whole hiring process. Start here:

1. Edit the job post. Change "5+ years of Salesforce required" to "experience running a CRM (we use Salesforce)." Move the tool to nice-to-have.
2. Add two skill questions from the list above to your interview guide.
3. Build the exercise. One spreadsheet, two definitions, a few planted errors. It takes an hour to make and you can reuse it.
4. Write down your own definitions before the new person starts. If you cannot hand them a one-page list of what your key numbers mean, that is their first project, and you should know that going in. Our plain-English guide to business data accountability is a good starting point.

Where Gohvio fits

A new RevOps hire spends their first months learning your definitions and finding where the data breaks them. Gohvio helps shorten that. You upload your own guardrails, the definitions your teams actually use, as a document. A person approves them, and each change is recorded with who changed it and when. Gohvio checks your CRM data against those guardrails and shows what is broken, what it does to pipeline and forecast, and the rows behind every finding. It is read-only, so it reads your CRM and does not change it.

That means your new hire starts with written definitions and a clear list of what is broken, instead of a blank page.

Stop debating your data. Start making evidence-based decisions.