Building a RevOps Layer on Top of a HubSpot You Didn't Set Up

Diagnosing what's actually there, before touching anything

Before changing a single workflow, map what exists: every pipeline and its stages, every custom property and whether it's actually used, every active workflow and what it triggers. This takes a day, not a week, and it prevents the single most common mistake — deleting or 'fixing' something that a different part of the business quietly depends on.

The 80/20 of RevOps fixes

• Lifecycle stage hygiene — decide what 'lead,' 'MQL,' 'SQL,' and 'customer' actually mean in your business, and fix the records that don't match
• One source of truth for pipeline stages — if sales reports pipeline differently than what's in HubSpot, the CRM has already lost, fix the gap in one direction
• Kill dead automations — workflows nobody remembers building, firing on old logic, quietly sending the wrong emails to the wrong people
• Reporting that matches how the business actually talks about revenue — not HubSpot's default reports, the specific numbers your leadership team already reviews

What to leave alone vs. what to rebuild

Not everything inherited is broken. Custom properties that are actually populated and used should stay. Integrations that work should stay. The instinct to rebuild everything from scratch usually comes from not trusting what's there rather than from evidence it's actually failing — the audit step exists specifically to tell the difference.

Signs the RevOps layer is working

Sales and leadership are looking at the same pipeline number in the same meeting without a reconciliation conversation first. Lifecycle stage changes happen automatically instead of being manually updated (or not updated) by whoever remembers to. And the CRM stops being 'the thing sales complains about' and starts being the thing that answers questions faster than asking a person would.

A practical audit checklist

• Pipelines: list every pipeline and stage, and note which stages deals actually move through and which are skipped
• Deal properties: for each custom property, check what share of recent deals have it filled in
• Contact and company properties: same check, and flag duplicates that hold the same information under different names
• Workflows: list every active workflow, its trigger, its last run and what it changes or sends
• Lifecycle stages: compare how records are distributed across stages with how the sales team describes the funnel
• Integrations: list every connected app and what data it writes into the CRM
• Users and permissions: check who has access, and remove former employees

Defining lifecycle stages your team will actually use

Write one sentence for each stage that describes an observable event, not a feeling. For example: a lead becomes a marketing qualified lead when they match the target customer profile and have taken a defined action such as booking a call or requesting a quote; they become a sales qualified lead when a salesperson has spoken to them and confirmed a real need and budget.

Then agree who moves a record between stages, and whether that happens automatically or manually. Ambiguity here is the root of most reporting arguments. If marketing and sales count “qualified” differently, no dashboard will settle the disagreement.

Reporting that leadership will trust

Start with the three or four numbers leadership already asks about in meetings, such as new pipeline created this month, deals closed, average deal size and how long deals take to close. Build those reports first, check them against what the sales team believes, and resolve every difference before adding anything else. One trusted report is worth more than a dashboard full of numbers nobody believes.

Common traps when cleaning up an inherited CRM

• Deleting properties before checking whether a workflow, report or integration depends on them
• Changing pipeline stages mid-quarter, which breaks comparisons with previous periods
• Fixing data once without fixing the process that created the bad data, so it returns within weeks
• Building complex automation before the team agrees on the basic definitions

Who owns the CRM after the cleanup

Name one person as the owner of the CRM's structure: the only person who creates new properties, pipelines or workflows, or who approves them. Others can use the system freely, but structural changes go through one owner. That single rule does more to prevent the next mess than any amount of cleanup.

Related reading