How to Build a RevOps Strategy

What a RevOps strategy is, and is not

Most documents called a RevOps strategy are a list of improvements: clean the data, fix attribution, build dashboards, implement lead scoring. Every item is reasonable. Together they are not a strategy, because nothing in the list says which problem is actually binding or what order the work must happen in.

A strategy names one constraint, sequences the work that removes it, and states what you are deliberately not doing in the meantime. The test is simple: if the items could be tackled in any order, it is a backlog.

Step 1 — Diagnose the constraint

Revenue predictability fails for one of four reasons at a time. Find which one, and resist the urge to declare all four.

The third column is the important one. Each constraint is routinely misdiagnosed as its neighbour, and the misdiagnosis produces expensive work that cannot help. A conversion problem treated as a demand problem means you buy more leads to die at the same stage.

Step 2 — Agree the definitions

Before any system work, get marketing, sales, and customer success to sign one document defining a lead, an MQL, an SQL, an opportunity, each deal stage, and closed-won. It takes about a week and prevents roughly six months of rework.

This step is skipped more than any other because it produces no visible artefact and involves an uncomfortable meeting. It is also the step that determines whether everything after it is built on agreement or on three people's private assumptions.

Step 3 — Design the target architecture

The target state, written down before anything is built: object model, lifecycle stages with exit criteria, source of truth per data point, integration map, and the ownership model for each system.

Write it as a document that someone could implement without you. If it cannot be handed over, it is not an architecture — it is an intention. The Salesforce and HubSpot guides cover what this looks like on each platform.

Step 4 — Sequence by dependency

The order is not a preference. Each stage genuinely requires the previous one to hold.

1. 01
   Definitions

   Everything downstream encodes these. Building on undefined terms means rebuilding when they are eventually defined.

2. 02
   Data model

   Stages, fields, and relationships that match the definitions, with validation that enforces them.

3. 03
   Data quality

   Deduplication, normalisation, and enrichment against the new model. Doing this before the model is set means doing it twice.

4. 04
   Process enforcement

   Routing, SLAs, and stage gates in the system. This is where recovered revenue actually comes from.

5. 05
   Reporting

   Built last, on a model that holds. Reporting built earlier makes the breakage look official.

6. 06
   Cadence

   The weekly, monthly, and quarterly rhythm that turns the data into decisions and keeps the system from decaying.

Step 5 — Decide what you will not do

This is the step that makes the document usable, and almost nobody includes it. A strategy that lists only what you will do cannot be used to decline anything, which means it will not survive contact with the first senior stakeholder request.

• Name the tools you will not buy this year, and why the layer they fill is already covered.
• Name the reports you will retire, so the reporting layer shrinks rather than accumulates.
• Name the requests you will decline by category — for example, no new required fields without a stated decision that depends on them.
• Name the motions you will not instrument yet, typically anything unproven. Instrumenting an unvalidated motion is expensive and usually wasted.

Get this section signed off by the same people who signed the definitions. An exclusion nobody agreed to is an exclusion you will be overruled on.

Step 6 — Install the cadence

The weekly review has one rule that matters: run it on live CRM data, in the CRM. The moment leadership runs the number from a spreadsheet, everyone else learns that the system is optional, and adoption erodes from the top within a quarter.

Measuring whether the strategy worked

Pick the measure that corresponds to the constraint you diagnosed, and commit to it in advance so the result cannot be re-narrated afterwards.

• Demand constraint → qualified pipeline created per month, and fully loaded cost per qualified opportunity.
• Conversion constraint → stage-to-stage conversion at the failing stage, and overall win rate.
• Data integrity constraint → forecast accuracy against actuals, and time to answer a pipeline question.
• Process adherence constraint → required-field completion at stage change, and median lead response time.

One number per constraint, measured before and after, with the date you expect it to move stated up front. That single discipline separates a strategy from a plan, because it makes the work falsifiable — and it is what an agency worth hiring will insist on before quoting.