RevOps and your CRM. The system that either enforces the process or lets it drift.

I'm Lauren Pearson, and most of the RevOps engagements I run start with the same quiet admission: the team has a strategy document, a set of pipeline stages someone wrote down eighteen months ago, and a CRM that no longer matches either. This piece is about why that gap opens up, and what actually closes it.

The short answer. The CRM is where RevOps either wins or quietly loses.

RevOps needs a single source of truth for revenue data, and in practice that source is the CRM, not a strategy deck or a shared drive full of process documents. Sales, marketing and customer success each touch a lead or an account at different points in its life, and the CRM is the one system built to hold all three views of the same record without one team's version overwriting another's. When that is missing, teams do not stop tracking their numbers, they just track them somewhere else: a spreadsheet, a second tool, a dashboard someone built once and nobody maintains.

The reason this matters more than most RevOps writing admits is that process only holds where the system enforces it. A rule written in a playbook is a suggestion. The same rule built as a required field, a validation rule or a stage-gate in the CRM is a fact the deal has to satisfy before it can move forward. RevOps as a function spends a surprising amount of its time translating agreed process into exactly that kind of CRM configuration, because that is the only place the process actually survives a busy quarter.

How it works in practice. Data model, enforcement, and where the line gets drawn.

Start with the data model, because everything else sits on top of it. A CRM built for RevOps needs one shared definition of a lead, an opportunity and an account across every team that touches revenue, with the same required fields and the same meaning attached to each pipeline stage regardless of who is looking at it. This sounds obvious until you look at what actually happens as a US company scales past its first fifty people: sales adds a custom field for its own reporting, marketing builds a parallel campaign object that only loosely maps to the same leads, and customer success starts tracking renewal risk in a spreadsheet because the CRM's account object was never built with their workflow in mind. None of these decisions is unreasonable on its own. Together, they leave three teams working from three versions of what should be one record, and nobody notices until a forecast meeting where sales, marketing and finance each bring a different number to the same table.

Once the data model is genuinely shared, the CRM becomes the place RevOps enforces process rather than just describing it. A marketing-to-sales handoff rule, a lead only passes to sales once it has a verified email and a stated budget range, means nothing as a line in a playbook if the CRM will happily let a lead move stage without either field filled in. Build the same rule as a required field with a validation check, and the process holds on its own, whether or not anyone remembers the playbook exists. This is the part of RevOps that rarely gets written about, because it is unglamorous field-level configuration work rather than strategy, but it is the actual mechanism by which a RevOps framework turns from a document into something a business runs on.

A US-based SaaS company I worked with recently had exactly this problem in miniature, and it is a useful illustration of how the enforcement question actually gets settled in practice, not just in theory. The team had a perfectly sound lead-to-cash process mapped out on paper. Sales, though, still logged deals in a spreadsheet for the first two weeks of every quarter, because the CRM's mandatory fields at that stage felt like friction when reps were racing to hit a number. My rule in that situation is consistent: I do not relax the required field to make the workaround easier, because that just moves the enforcement gap somewhere else. I go back to why the field feels like friction in the first place, usually because it is asking for information too early in the deal for a rep to reasonably have it yet, and move the requirement to the stage where that information genuinely exists. The process held once the field sat where the data was actually available, not because anyone got stricter about following the rule.

Tool sprawl is the other place this breaks down, and it is largely a symptom of the same underlying issue: teams building workarounds because the CRM was not configured to hold what they needed. RevOps Co-op's 2025 State of RevOps report, based on responses from 200 RevOps professionals, found that around a third of the average tech stack, 33 percent, sits unused as shelfware: tools bought, connected once, and never fully adopted. That figure lines up with what I see in most audits. A point solution gets added to solve one team's problem in isolation, it never gets a clean two-way sync back to the CRM, and within a year it is either quietly abandoned or, worse, still limping along as a second source of truth nobody has the authority to shut down.

The practical test for where to draw the integration line is simple, and I use it on every stack audit: does this tool need to write back to the CRM, or does it only need to read from it. A tool that enriches a record, adds firmographic data, scores intent, verifies an email, earns its place if it writes the result straight back into the CRM automatically. A tool that only needs to pull a report from the CRM for its own dashboard is lower risk either way, because it cannot create a second version of the truth even if it drifts out of sync. The tools that cause real damage are the ones in between: they hold data that matters, sales or customer success has started relying on what is inside them, but nothing forces that data back into the system everyone else is actually looking at.

What good looks like. One record, one definition, one place the answer lives.

A working RevOps CRM setup has a simple tell: ask where the answer to a specific question lives, "what is our current pipeline coverage for this quarter" or "which accounts are at risk of churning in the next sixty days", and everyone in the room points to the same screen. Not the same rough figure reconstructed three different ways. The same screen, built from the same underlying records, that sales, marketing and customer success all feed and all trust.

The second sign is quieter and shows up in how disagreements get resolved. In a business where the CRM is genuinely the system of record, a dispute over a number gets settled by opening the record and checking the field. In a business where it is not, the same dispute turns into a meeting, because everyone half-trusts the CRM and half-trusts their own private tracking, and neither is treated as final. That second pattern is expensive in a way that rarely shows up on a single invoice: it is the accumulated hours of every team quietly re-verifying numbers the system was supposed to already hold with confidence.

The third sign is what happens when a new tool gets proposed. A mature RevOps CRM setup treats "does this write back automatically" as a genuine gating question before a new subscription gets approved, not an afterthought handled after the contract is signed. That single habit, asked consistently, is most of what keeps a stack from drifting back into the shelfware pattern the RevOps Co-op data describes.

Pitfalls to avoid. Where the CRM stops being the source of truth without anyone deciding it should.

The first pitfall is treating the CRM as a place to log activity after the fact rather than the system the team actually works inside all day. If reps do their real work in email and a personal spreadsheet, then update the CRM once a week as an administrative chore, the CRM cannot be a source of truth, because it was never the source in the first place. It is a summary, written from memory, of a truth that lives somewhere else entirely.

The second is letting each department own its own slice of the CRM without a shared owner across all three. Sales customises fields for sales, marketing builds its own campaign structure, customer success bolts on a health-score field nobody else understands, and within a year the CRM is technically one system holding three barely-related data models under one roof. This is exactly the tool sprawl problem, just moved inside a single platform instead of across several, and it is often harder to spot because there is no separate invoice flagging it.

The third is confusing a CRM migration with actually fixing the underlying process. Moving from one platform to another without first agreeing the shared data model, the stage definitions and the enforcement rules simply rebuilds the same disagreements inside a newer, more expensive interface. The system changes. The behaviour underneath it, three teams quietly keeping their own version of the numbers, does not, unless the migration is used as the moment to fix that properly.

The fourth, and the one that catches growing US teams most often, is adding integrations faster than anyone is reviewing them. A Series A company might start with a lean stack and a clean CRM, then add a new tool every time a team hits friction, sales engagement here, an enrichment provider there, a separate forecasting tool because the CRM's native reporting feels thin. Eighteen months later nobody can say with confidence which tool is authoritative for which piece of data, and the RevOps function spends more time reconciling exports than doing the process work it was hired for. The fix is not refusing new tools. It is reviewing the stack on a fixed cadence, quarterly is usually enough, and asking the same question every time: does this still write back cleanly, and is anyone actually using it. Our revenue operations work with growing teams starts with exactly that audit, because it is faster and cheaper to catch sprawl at a quarterly review than to unpick it after a year of silent drift, and where a full CRM rebuild is the right call rather than a lighter audit, that is the scope our RevOps consulting engagements are built to cover.

None of this is complicated in principle. It just requires treating the CRM as infrastructure the whole revenue function depends on, not a database sales happens to use. Everything else in a RevOps framework, the shared definitions, the forecast, the cadence, only holds because the CRM underneath it is actually enforcing what the team agreed to. Get that one piece right and the rest of the operating model has something solid to stand on.