RevOps and process mapping. The map comes before the stack.

The short answer. Map how revenue actually moves, before you touch the stack.

Gartner's May 2021 forecast predicted that 75 percent of the world's highest-growth companies would deploy a revenue operations model by 2025. Plenty of companies have taken that prediction as licence to stand up a RevOps title, buy a RevOps tool, or rename an operations role, without doing the one piece of work that actually makes RevOps function: agreeing, in writing, how a lead or opportunity really moves from first contact to renewal. Without that shared map, a RevOps hire or a new platform just automates whatever each function was already doing separately, usually three slightly different versions of the same process, now running faster and more expensively.

Process mapping in a RevOps context means something narrower than process mapping generally. It isn't documenting every task inside a single team's workflow. It's documenting the handoffs between marketing, sales, onboarding and customer success, because that's where ownership changes hands, where definitions of a "qualified lead" or a "closed-won deal" can quietly diverge, and where revenue actually leaks when nobody's watching.

How it works in practice. Three handoffs, one shared map.

Start with the handoffs, not the whole funnel. Most revenue processes have three that matter most: marketing to sales, where a lead becomes a qualified opportunity; sales to onboarding or delivery, where a closed deal becomes a live customer; and onboarding to customer success, where a new customer becomes an account someone is responsible for keeping. Map each handoff by sitting with the people on both sides of it, not their managers, and asking what actually happens the moment ownership changes. The gap between what a manager believes happens and what the team actually does is usually where the map earns its keep.

Write down, for each handoff: what triggers it, who owns the step immediately before and immediately after, what information has to travel with the lead or deal, and how long it typically sits before anything happens to it. That last point matters more than it sounds. A lead that sits for four days before a sales rep picks it up isn't a CRM configuration problem; it's a process gap the map needs to surface, because no amount of better reporting fixes a handoff nobody's actually watching.

Keep the first version of the map rough. A whiteboard photo or a simple flowchart that the people in the room agree matches reality is worth more than a polished diagram built from what the process is supposed to be. Our guide to creating a process map covers the mechanics of building one that holds up once it's finished; the discipline in a RevOps context is making sure the map covers the full revenue cycle, not just one function's slice of it.

What good looks like. One source of truth, not three tools.

A RevOps process map is working when every function can point to the same diagram and agree it's accurate, and when the CRM's stage definitions and automation rules trace directly back to steps on that map rather than existing independently of it. If marketing's definition of a qualified lead lives in a spreadsheet, sales' definition lives in CRM field logic, and nobody has reconciled the two against a shared map, that's the sign the map either doesn't exist or isn't being used.

The other marker of a healthy map is that it changes. A process map built once at a kickoff meeting and never revisited stops reflecting reality within a few months, as teams quietly adapt around whatever isn't working. Review the map against what's actually happening in the CRM every quarter, not only when something breaks visibly enough to force the conversation. Our RevOps consulting work treats the map as a living document for exactly this reason, revisited on a set cadence rather than left to drift.

Pitfalls to avoid. The map that matches the org chart, not the work.

A founder-led SaaS company I worked with had a revenue process that looked clean on paper: marketing qualifies, sales closes, customer success onboards. When we mapped the actual handoffs with the people doing the work, three undocumented manual steps turned up that nobody outside the two people doing them knew existed, including a spreadsheet one sales rep kept privately to track which leads had actually been contacted, because the CRM's own "contacted" field hadn't been trusted for months. The CRM wasn't broken. The process the CRM was supposed to reflect had drifted away from what the org chart assumed, and nobody had checked. This is an illustrative pattern I've seen across more than one client, not a single named result, but the decision rule holds broadly: never approve a CRM change, a new automation or a reporting rebuild until the current process has been mapped as it's actually run, not as the org chart assumes it runs.

A second common pitfall is mapping the process once and treating the document as finished. Growth changes a revenue process faster than most teams update their documentation for it; a handoff that worked cleanly at ten deals a month often breaks quietly at forty, because the informal communication that covered the gap stops scaling. Build a review of the map into whatever cadence you already use for pipeline review, rather than creating a separate process just to maintain the map.

A third pitfall is mapping with managers only, skipping the people actually doing the handoff. Managers tend to describe the process as designed, which is often a cleaner, more linear story than what's really happening on the ground. The real value of a mapping session comes from the moment a rep or a customer success manager says "that's not actually what I do", because that's the gap the entire exercise exists to find.

Getting started. Start with one broken handoff.

Don't try to map the entire revenue cycle in one sitting. Pick the handoff that's already causing visible friction, usually the one someone on the team complains about most often, and map just that one properly: who owns each side, what triggers the handoff, what information needs to travel with it, and how long it currently sits before anything happens. Fix what the map surfaces, then move to the next handoff. Our revenue operations work almost always starts here, with one mapped handoff, rather than a full stack rebuild on day one.

If the map turns up more gaps than your team has time to fix on its own, that's usually the point where bringing in outside RevOps support pays for itself, prioritising the handoffs by how much revenue each one is actually leaking rather than by which one is loudest in the room.