How to Build a RevOps Function From Scratch

Days 1–14: diagnose, build nothing

The strongest temptation in a new RevOps function is to start fixing things immediately, because the problems are visible and fixing them feels like progress. Resist it for two weeks.

A function that begins by configuring has no diagnosis to point at when it later needs to say no to a senior stakeholder. Two weeks of structured investigation buys the mandate for everything afterwards, and it is the cheapest political capital available.

1. 01
   Interview the frontline before leadership

   A rep, an SDR, a marketer, a CS manager. Ask how the process actually works, not how it is supposed to. The gap between their account and leadership's is your real diagnosis.

2. 02
   Inventory every system and integration

   What exists, who owns it, what it costs, when it renews. Most companies discover two integrations silently failing and one tool nobody has opened in a year.

3. 03
   Measure the obvious things

   Field population rates, duplicate count, leads never routed last quarter, opportunities with past close dates, median lead response time. Five numbers, all countable in a day.

4. 04
   Find the shadow spreadsheets

   Every business-critical spreadsheet outside the CRM is a system telling you what it fails to do. Ask each function what they rebuild manually every week.

5. 05
   Write it down and circulate it

   A short document with counts, not adjectives. This becomes the reference you point at every time someone asks why you are not doing their request first.

Days 15–30: definitions and one visible win

Two things run in parallel here, and both matter.

The first is the definitions workshop: get marketing, sales, and customer success to sign one document defining a lead, MQL, SQL, opportunity, each deal stage, and closed-won. It is contentious, it takes about a week of calendar time, and it prevents roughly six months of rework because every system decision downstream encodes one of these definitions.

The second is shipping something visible. A new function needs evidence that it produces outcomes before it asks for a quarter of rebuild time. The best candidates are fast, uncontroversial, and immediately felt.

Days 31–60: rebuild and enforce

Now the structural work, in dependency order. Each step assumes the previous one holds.

• Object model to match the definitions. Stages with exit criteria, required fields only where a decision depends on them, one source of truth per fact.
• Validation that enforces the criteria at the point of stage change. This is what turns definitions from a document into a system.
• Data quality as recurring jobs, not a cleanup — dedupe, normalisation, and daily reconciliation between systems.
• Routing, SLAs, and handoffs automated, with fallbacks and manager escalation.
• Retire what the new design makes redundant. Deletion is part of the build, and it is the part that gets deferred forever if not scheduled.

Days 61–90: instrument and install cadence

Reporting comes last deliberately. Dashboards built on a broken data model make the breakage look official, and rebuilding them after the model changes is wasted work.

Build the small working set — pipeline coverage, stage conversion, velocity, CAC payback, response time — then install the rhythm that turns those numbers into decisions: a weekly pipeline review run in the CRM, a monthly metrics review, and a quarterly system review. Without the cadence the whole build decays within two quarters, which is covered in the RevOps operating cadence.

Who to hire, and when

The first-hire row is where most companies go wrong, scoping the role as an analyst to fit a budget and then expecting architecture. The full sequencing is in how to structure a RevOps team.

The two traps

Building reporting first. It is the most requested thing and the most visible, and doing it before the data model is fixed produces dashboards everyone will stop trusting within a quarter — at which point you have spent your credibility on work you must redo.

Accepting the request queue as the job. Inbound requests will expand to fill all available capacity. Ring-fence 30% for roadmap work from week one and report on it monthly. Retrofitting that protection after the function has been purely reactive for two quarters is considerably harder than establishing it at the start, because by then the expectation is set.

A function that survives its first year has a diagnosis it can point at, one visible win in the first month, a signed definitions document, and protected capacity. Those four things matter more than any tooling decision made in the same period — and the maturity path afterwards is in the RevOps maturity model.