By Camela Thompson, Head of Marketing, RevOps Co-op
I’ve been on both sides of the RevOps consulting table: hiring outside help and being the outside help. I wish I could tell you that every engagement starts with a clear scope, aligned stakeholders, and strong data governance—but let’s be real. Most of the time, you call a consultant because something is broken, and you don’t have the bandwidth or expertise to fix it.
Unfortunately, that’s also when the wrong kind of consultant can make a bad situation worse.
This article is for two audiences:
Let’s break down the biggest red flags I see—and what “green flag” behavior looks like instead.
There is no such thing as a one-size-fits-all RevOps solution.
If a consultant shows up ready to drop their “proven” lifecycle stage model, deal pipeline, or required field structure without interviewing your team, start running—fast.
Real example:
A client once hired a consulting firm that “specialized” in HubSpot. Their first move? Delete several pipeline stages and roll out required fields on the deal object—without ever talking to sales. Predictably, chaos followed. Deals stopped getting updated, adoption cratered, and both sales and marketing blamed each other for “breaking” the system.
How to fix it:
In this case, the sales team had abandoned the CRM because every deal stage was overloaded with required fields. It was a small organization without a standardized sales methodology or forecasting requirements.
We stripped the system back to the essentials—deal stages, minimal required fields, and shared definitions—then retrained the team.
For consultants: Always meet your client where they are. Focus first on the reports the business needs to function (like a reliable forecast) and architect toward that goal. Don’t build for a “five-year vision” unless sales leadership is actively investing in training and coaching to support it.
If a consultant wants to start by “fixing” data without talking to your stakeholders, they’re about to break something important.
Real example:
A client had thousands of duplicates in their CRM. Most consultants would dedupe by domain—standard SaaS practice. But this company sold into healthcare, where multiple hospitals shared the same domain.
If we’d followed the CRM’s “best practice” (in this case, HubSpot’s domain-centric logic), we would’ve merged separate locations, nuked critical data, and made reporting useless.
The fix:
We talked to users, confirmed how they used account data, and built a custom deduplication waterfall using both domain and location fields. The result: no data loss, no panic attacks.
For consultants: Every weird quirk exists for a reason. Before you “fix” data or redesign a workflow, find out why it’s set up that way. Don’t assume the person who created the system didn’t know what they were doing—even in the messiest instances.
Let’s normalize this:
No consultant can accurately scope a project without looking under the hood.
End users usually know something’s wrong, but they can’t diagnose everything that’s wrong. That’s literally why you’re hiring help. So when a consultant says, “We’ll start with discovery before quoting the final scope,” that’s not a sales tactic—it’s honesty.
Real example:
A client couldn’t figure out why their UTM parameters weren’t syncing from Pardot. On the surface, that sounds like a small fix. But once I got access, it turned out their campaign hierarchy and form setup were duplicating campaign members per form submission. The whole data model needed rework.
No one could have known that without seeing it.
Moral of the story: A consultant who insists on a pre-scope login and NDA isn’t being difficult—they’re being responsible.
Here’s what separates the consultants who fix from the ones who break:
RevOps consulting isn’t about proving you’re the smartest person in the room. It’s about listening first, diagnosing with empathy, and designing systems people will actually use.
If you’re hiring a consultant, look for curiosity and humility.
If you are a consultant, remember: your first job isn’t to fix—it’s to understand.