In This Article

RevOps Brief • Deep Dive • CRM Architecture

How a Series B SaaS Rebuilt Their CRM Architecture
and Reduced CAC by 31%

After 18 months of data chaos, a 90-person SaaS company undertook a full CRM data model redesign — eliminating 47% of redundant fields, unifying their contact object, and transforming how revenue data flowed across their entire stack.

June 2026 · ~18 min read · Series B SaaS • HubSpot • 90-person team · Contributor anonymous by request
31% CAC Reduction vs. 18 months prior
47% Fields Eliminated of 847 total audited
−74% Reporting Time hours per month
+29% Pipeline Velocity faster close rates
74% Attribution Coverage vs. 18% before

RevOps Brief publishes practitioner-written deep dives, frameworks, and teardowns for revenue operations professionals. No vendor sponsorship influences our editorial content. Subscribe free at www.revopsbrief.com

A note on anonymity The author of this case study is a serving VP of Revenue Operations at a Series B SaaS company. They have asked to remain anonymous, as have the company and all individuals named in the original account. All identifying details — including company name, team members, acquired entities, and external partners — have been removed or generalised at the contributor's explicit request. The data, methodology, and outcomes described are real and have been independently reviewed by the RevOps Brief editorial team prior to publication.
Foreword A Note Before We Begin

I've been doing RevOps for eleven years. I've worked at companies where the CRM was a beautiful, well-tended garden, and I've worked at companies where it had become something closer to a landfill. Before we embarked on this project, our company was firmly in the second camp.

What you're about to read isn't a polished success story with all the rough edges sanded off. It's the real version. We made mistakes. We had a moment, somewhere around month four, where the Head of Sales stood up in an all-hands and said — not entirely joking — that he trusted the data in our CRM about as much as he trusted a coin flip. That was a low point.

But we got through it, and on the other side is a revenue engine that actually works. Our CAC is down 31%. Our pipeline reporting is trusted. Marketing and Sales are finally arguing about strategy instead of arguing about whose numbers are right.

I wrote this document because I wish something like it had existed when we started. The vendor documentation tells you what the buttons do. The analyst reports tell you the market is growing. Neither of them tells you what to do when you have 847 fields in HubSpot, nobody knows who created most of them, and you have a board meeting in three weeks.

— VP of Revenue Operations, Series B SaaS Company

Part One The Diagnosis

1. The State of Things: What Broke and Why

1.1 Company Background

Let me set the scene. We're a B2B SaaS company in the workflow automation space. By January 2024, we had 87 people, a fresh $22M Series B in the bank, $8.4M ARR, and a net revenue retention rate of 108%. Those are the numbers that make a board slide look good. They are not the numbers that tell you whether your revenue organisation actually functions.

Ours didn't. Not really. The go-to-market team was performing — hitting targets, closing deals, keeping customers — but the infrastructure underneath it all was fraying. We were running HubSpot Enterprise as our primary CRM, and sitting alongside it was a Salesforce instance we'd inherited from an acquisition in late 2022. Two years on, we still hadn't fully integrated them. Contacts existed in both systems with different field schemas, different lifecycle stage definitions, and no clean mechanism to reconcile them. It was two separate realities of the same customer base, and every report we produced required someone to decide which reality to use.

Here's what that stack looked like at the time:

CategoryToolNotes
CRM (Primary)HubSpot EnterpriseOwned by Marketing & RevOps
CRM (Legacy)Salesforce ProfessionalInherited from an acquisition; partially decommissioned
Marketing AutomationHubSpot Marketing HubDeeply integrated with primary CRM
Sales EngagementOutreach.ioSyncing to HubSpot via Zapier (yes, Zapier)
Conversational IntelligenceGongPartially integrated; deal data not flowing
Data EnrichmentClearbit + ZoomInfoBoth active; overlapping coverage, no deduplication
Revenue IntelligenceClariPulling from both CRMs; producing conflicting forecasts
Customer SuccessChurnZeroConnected to HubSpot; health scores not bi-directional
Data WarehouseSnowflakePopulated via Fivetran; only 40% of GTM tools connected

1.2 The Breaking Point

The breaking point — and there's always a breaking point — came during Q3 2024 board prep. We were building the September deck and our RevOps analyst pulled CAC from three sources: HubSpot, Clari, and finance's spreadsheet. The numbers came back as $2,910, $3,180, and $3,440. A $530 spread. On the single metric the board was most likely to interrogate.

We spent two full days trying to close that gap. We couldn't — not completely. There were definitional differences buried in what each system counted as "marketing spend," attribution voids where closed deals had no traceable source, and a denominator inflated by duplicate contacts we didn't know we had. We walked into that board meeting carrying a footnote that read: "figures approximate; data reconciliation in progress."

I have been in revenue operations for eleven years. I have never felt more professionally exposed than in that meeting.

"The moment your board deck has a footnote saying your CAC is 'approximate,' you've lost something. You've lost the ability to make confident decisions about where to put your next dollar. That's not a data problem. That's a strategy problem." — VP RevOps

1.3 The Audit: What We Found

After the board meeting, we made the call to bring in an external RevOps consultant to do a full CRM audit. I want to be honest about why we chose external over internal: the internal team knew where most of the bodies were buried. The problem was that leadership needed to hear it from someone who wasn't seen as having an agenda. That's an uncomfortable truth about how organisations work, but it's true.

What the audit surfaced was worse than we'd expected — and we'd gone in expecting bad.

The Field Problem

The HubSpot Contact Object alone had 214 active properties. To be clear: active. Not archived. Not hidden. Properties that existed in live records, visible in forms, feeding workflows. Of those 214:

The Lifecycle Stage Problem

We had seven different working definitions of "MQL" operating simultaneously across the organisation — and none of them were written down anywhere. Marketing was using a scoring threshold of 40+ points. SDR leadership had their own definition based on activity cadence patterns they'd developed over time. The legacy Salesforce setup had been built around a firmographic model from the acquired company. And everyone else? They'd absorbed the definition from whoever had onboarded them, which meant the definition had been drifting and mutating for two years.

The consultant ran a query: which contacts had been marked as MQL in the last 12 months? HubSpot returned 4,817. Salesforce returned 1,241. The overlap — contacts with MQL status in both — was 847. Of those, 312 had different lifecycle stages between the two systems. Same person, same company, two different beliefs about where they sat in the funnel.

That number — 312 — is the one that hit hardest. It meant our funnel reporting was, in the most literal sense, making things up.

The Attribution Black Hole

This one is hard to write about, because it means admitting that for most of the previous year, we were making spend decisions on near-meaningless data. Only 18% of closed-won deals in the trailing twelve months had clean multi-touch attribution. Everything else resolved to "Direct" or "Organic Search" — both of which are catch-alls for "we don't actually know" — or had no attribution at all.

We were spending approximately $340,000 per quarter on pipeline generation. We had real visibility into how roughly a third of that spend was performing. The other two-thirds was running on instinct, habit, and prior-year precedent. We were renewing and expanding channels not because the data said to, but because nobody had data to say otherwise.

Marketing Attribution Coverage: Before vs. After
Figure 1 — Share of closed-won deals with attribution data
Multi-Touch Attributed
Single-Touch Only
No Attribution

The Costs Nobody Was Counting

One thing I've learned is that organisations are remarkably good at absorbing dysfunction when it's distributed across enough people that no single person feels the full weight of it. Everyone was working around the data problems. Sales reps had their own tracking spreadsheets. RevOps maintained the master Google Sheet. Marketing built a separate attribution tracker. The CRO kept a personal running total of "real" pipeline because he didn't trust the system number. When you add all of that up, it looks like this:

ActivityTime Lost / MonthEstimated $ Impact
Manual report reconciliation (all teams)117 hrs / month~$7,800 / month
Duplicate contact management28 hrs / month~$1,900 / month
Lead routing errors and re-assignment~40 deals / month affected~$120K ARR at risk / quarter
Incorrect Clari forecast requiring manual correction12 hrs / month~$2,400 / month
Sales rep time cleaning own records~3.2 hrs / rep / week~$18,200 / month (22 reps)

The audit identified approximately $30,300 in direct monthly productivity costs from data quality issues — not counting the strategic cost of decisions made on bad data. Annualised, that's over $360,000 before you start talking about misdirected marketing spend or lost deals from routing errors.

Part Two The Design

2. Designing the New Architecture

2.1 First Principles: What We Decided Before Writing a Single Field

Before the consultant started rebuilding anything, three weeks were spent on alignment. This part is the part most RevOps teams skip, and it's also the part most responsible for failed CRM redesigns. You cannot build a good data model until you have agreement on what the data needs to do.

Four working sessions were run with cross-functional stakeholders: CRO, VP Marketing, Head of Sales, Head of Customer Success, CFO, and CRM admins from both HubSpot and legacy Salesforce. The goal was to answer five questions before designing anything:

  1. What is the primary job of each CRM object? (Contact, Company, Deal — what is it for, and what is it NOT for?)
  2. What are the 10 most critical decisions the GTM team makes, and what data does each one require?
  3. Where does the data driving those decisions come from, and who is responsible for its accuracy?
  4. What does the ideal buyer journey look like in data terms, and which system owns each stage?
  5. What are the non-negotiable reporting requirements for the board, and what exact data points feed each one?

Pro tip: Do not let "we'll sort that out during implementation" be an acceptable answer in your design sessions. Every unresolved definitional question becomes a field naming inconsistency, which becomes a reporting discrepancy, which becomes someone in a board meeting saying "depends how you define it." Kill these ambiguities in the design phase.

2.2 The New Object Model

The core principle we settled on was what the consultant called the "Source of Truth Stack." Every data point would have exactly one system of record. Any other system that needed that data would pull from it — not store its own version. Sounds obvious. It was not how we'd been operating.

Contact Object: The Unified Person Record

We scrapped the existing Contact object design entirely and rebuilt it around a single question: what does a revenue team member actually need to know about a person to have an effective conversation and route them correctly? Not "what might be useful someday." Not "what did we import from the old system." What do you need, right now, to do your job?

The answer was 53 fields. Down from 214. The 161 we removed weren't deleted on day one — they were archived, with a 90-day sunset window. Only three people came back asking for a field we'd removed. That tells you something about how many of those 161 were actually being used.

Field CategoryBeforeAfter
Identity & Demographics3412
Company / Firmographic Context288 (via Company object)
Lead Source & Attribution195 (with strict definitions)
Lifecycle & Status144
Engagement & Scoring227
Sales Rep Notes / Custom310 (moved to Activity)
Enrichment Data (Clearbit/ZoomInfo)4711 (consolidated)
Campaign / Marketing Fields196
Total21453
Overall CRM Field Audit Results
Figure 2 — Distribution of 847 fields audited across all objects
Eliminated (Redundant/Orphaned) — 47%
Retained (Validated) — 31%
Redesigned or New — 22%

The Lifecycle Stage Framework

We killed all seven MQL definitions and replaced them with six stages, written in plain English, with explicit entry and exit criteria. Every single stage owner signed off on the definitions in writing. That last part was the consultant's insistence, not mine — and she was right. The act of signing something changes how seriously people take it. We had the same conversation about MQL many times in the previous two years. It never produced this level of clarity because it never had stakes attached to it.

StageOwnerEntry CriteriaExit Criteria
SubscriberMarketingAny form fill, content download, or webinar registrationReaches ICP threshold + activity score
MQLMarketingICP-matched account + score ≥50 + at least 2 engagement signalsSDR accepts or rejects within 4 business hours
SALSales DevSDR accepts the MQL; has validated contact infoFirst discovery call booked and held
SQLSales DevDiscovery call completed; BANT partially qualifiedAE accepts and creates opportunity
OpportunityAEAE-created deal with defined close date and ARRClosed Won or Closed Lost
CustomerCSContract signed; CS owner assignedChurned or Expanded (tracked separately)

2.3 The Attribution Architecture

Of all the pieces of this redesign, fixing attribution had the most direct downstream effect on CAC — because it was the piece that changed what we spent money on. If you can't see where your customers actually came from, you make budget decisions based on whatever narrative is most convincing in the room. Usually the person who shouts loudest about their channel wins. We'd been operating that way for two years.

We moved to a W-shaped multi-touch framework as our primary model — first touch, lead creation, and opportunity creation each weighted more heavily, with remaining touches distributed across the path. We explicitly decided against linear attribution as the primary model. Treating a brand awareness touchpoint the same as a demo request isn't just analytically weak, it actively rewards top-of-funnel vanity metrics at the expense of understanding what actually converts.

The harder change was operational. We rebuilt every UTM parameter across every campaign, every form, every outbound sequence. HubSpot was configured to route any inbound lead missing source data to a review queue instead of auto-creating it. For six weeks, that review queue filled up every day. We manually classified every one. It was painful. It was also what made the attribution data trustworthy.

The hard truth about attribution is that "better attribution" does not come from a tool. It comes from operational discipline applied before the data ever hits your CRM. No attribution model can fix a campaign that launched without UTMs. No BI tool can reconstruct a touchpoint that was never recorded. The fix is process-level, not technology-level.

2.4 The Tech Stack Rationalisation

We also used this redesign to make some stack decisions we'd been avoiding. Running HubSpot and Salesforce in parallel for two years wasn't a strategy — it was procrastination dressed up as caution. Once the acquisition integration was complete enough, we made the call: Salesforce gets decommissioned by Q1 2025. That conversation had been had before and shelved. This time, with the audit data sitting in front of everyone showing exactly what the dual-CRM setup was costing, it stuck.

We also cut ZoomInfo. Running both Clearbit and ZoomInfo for enrichment had seemed like redundancy-as-insurance, but in practice it was creating conflicting data with no tiebreaker logic. We ran a proper coverage analysis across 12,000 contacts from our ICP — mid-market SaaS and tech, 50–500 employees — and Clearbit won clearly. Cutting ZoomInfo saved $34,000 annually and immediately simplified a mess of enrichment fields that had been causing scoring anomalies for months.

The last tactical change was replacing the Outreach-to-HubSpot sync via Zapier with the native integration. The Zapier sync had been dropping data for at least a year — we just hadn't known, because nobody was monitoring it. With the native integration live, AE activity in Outreach finally started appearing correctly in HubSpot's contact timelines, which in turn fixed a gap in our engagement scoring that we'd been trying to patch with manual overrides.

Part Three The Implementation

3. Executing the Migration

3.1 The Implementation Roadmap

The implementation ran across six months, from November 2024 through April 2025, in four structured phases. We did not attempt a big-bang cutover. I want to be emphatic about this: anyone advocating for a big-bang CRM migration has never been responsible for the fallout of one. You will lose data. You will break workflows. You will spend six months explaining to sales leadership why their pipeline numbers look different. Phase by phase is slower. It is the only viable approach.

PhaseTimeframeKey ActivitiesStatus
Phase 0Oct 2024Audit, design sessions, stakeholder alignment, documentation freeze✓ Complete
Phase 1Nov–Dec 2024New field schema build, lifecycle stage overhaul, naming convention enforcement, Salesforce export and archive✓ Complete
Phase 2Jan–Feb 2025Contact object migration, deduplication, attribution rebuild, Zapier-to-native Outreach migration✓ Complete
Phase 3Mar 2025Salesforce decommission, Snowflake pipeline rebuild, Clari reconnection and validation✓ Complete
Phase 4Apr 2025Reporting rebuild, dashboard rollout, team training, governance framework launch✓ Complete

3.2 The Deduplication Project

I want to give the deduplication project its own section because it deserves one. It was not a feature of the migration — it was a parallel workstream that could have derailed the whole thing if we'd tried to fold it in.

We started with 84,312 contact records across HubSpot and the Salesforce archive. We ended with 51,847 unique contacts. That means 39% of our database was noise — duplicates, test records, email-bounce auto-creates, ghost contacts from import errors years old. Nearly four in ten records were, in some meaningful sense, fictitious.

We used Dedupely for the automated pass. It handled the clear-cut cases — same email, same domain, obvious duplicates. What it couldn't handle was the manual review queue: 4,200 contacts that matched on some signals but not others, where a human had to make a judgment call. We ran that as a dedicated four-week sprint with two analysts. It was not glamorous. One of them described it as "being paid to stare at slightly different versions of the same person for eight hours a day." But buried in that queue were 312 key accounts with fragmented contact records spread across duplicate company objects. Finding and consolidating those was worth the entire effort on its own.

Deduplication Lessons Learned
  1. Start with email as your primary match key — it has the fewest false positive matches. Phone numbers are surprisingly unreliable (people share phones, use reception numbers, etc).
  2. Do not try to deduplicate and migrate simultaneously. Deduplicate in your old system first, then migrate the clean data. Trying to do both at once is how you lose records.
  3. Build a "golden record" rule set before you start. When two records conflict, which one wins? Document this before running any deduplication tool. (Most recent activity date + most complete field population + original create date as tiebreakers, in that order.)
  4. Archive, do not delete. Archive every merged/deleted contact in a Snowflake table with a full field snapshot. This has saved the team twice already.

3.3 Rebuilding the Reporting Layer

I have to tell you about the Google Sheet. Our RevOps analyst had been maintaining a master reporting tracker for two-and-a-half years. It had 74 tabs. When I first opened it I assumed something had gone wrong with the file. It hadn't. It was 74 tabs of manually reconciled data, each one solving for a gap between what the CRMs couldn't produce and what the business actually needed to see. It was, in its own way, an impressive piece of work. It was also a single point of failure — one person, one file, one version of truth that lived nowhere official and was trusted by everyone because there was nothing better.

We replaced it with a three-tier reporting architecture:

Monthly Reporting Hours by Team
Figure 3 — Hours per month spent on reporting and reconciliation, before vs. after
Before Redesign
After Redesign

3.4 Change Management: The Part Nobody Wants to Talk About

Here's the thing I got wrong: I thought we'd built enough credibility through the audit and the design process that the rollout would be relatively smooth. I underestimated how much people had adapted to the old, broken system — and how much of their identity and routine was tied to the workarounds they'd built around it. Changing the CRM felt, to some people, like we were deleting the tools they'd invented to survive.

The resistance came from three directions, each requiring a different approach:

Sales Rep Resistance

Reps didn't resist because they didn't understand the value. They resisted because the new system required more discipline upfront — structured dropdowns instead of free-text, mandatory fields that didn't used to be mandatory, activity logging that was now actually being looked at. One senior AE told me, with complete sincerity, that he'd been "fine without this stuff for seven years." Which was true. He'd also been maintaining a personal spreadsheet for seven years to compensate for what the CRM couldn't do. What worked was embedding three of our highest performers into the design process from Phase 1 as "field advisors." When their peers heard "I helped build this and it's better," the conversation changed completely.

Marketing Ops Resistance

The campaign naming convention was the specific flashpoint. Our Marketing Ops lead had spent three years building a taxonomy that worked for them — imperfectly, but it worked. The new convention wasn't fundamentally different, but it required retroactive retagging and a team-wide behavioural change. Rather than mandate the switch, we ran a six-week parallel window. Both naming conventions were accepted. But during those six weeks, we surfaced the attribution data in real time and let people watch "unknown source" appear on leads that had slipped through without the new tags. Seeing your own campaign show up as "unknown" in the attribution report is a more effective behaviour-change intervention than any policy document.

Leadership Reporting Anxiety

This one surprised me most. The CRO and VP Sales had been using the same report views for two years. Even knowing the data was bad, they'd calibrated their intuition to those numbers. The new reports, even though they were more accurate, didn't feel right yet — the patterns were different, the absolute numbers were different, and familiarity had been doing a lot of the trust-building that the data couldn't. We ran a four-week parallel period where every board-facing metric was published with both old and new methodology side by side, each with an explicit confidence rating. By week three, the conversation had shifted from "which number is right?" to "why does the old number look so different?" That's the question you want them asking.

Part Four The Results

4. What Changed: The Results

4.1 The CAC Story

The headline number is 31%. CAC fell from a peak of $3,420 in November 2024 to $2,360 in the trailing twelve months to May 2026. I want to be careful about how I present this, because I've seen too many case studies attribute everything to the project being written about and nothing to context. So let me break this into three honest components.

CAC Trend: 18-Month Journey
Figure 4 — Customer Acquisition Cost across the full redesign period
Pre-Redesign Period
Post-Redesign Period

Component 1: Marketing Spend Optimisation (This One We Own)

With real attribution data for the first time, we ran a full channel audit in Q1 2025. The results were genuinely uncomfortable to sit with. Google Ads at ~$45,000/month was producing about 12% of attributed pipeline. Our content syndication program at $22,000/month was producing 4% — that's roughly $5,500 of attributed pipeline per $22,000 spent. Meanwhile, LinkedIn outbound from the Sales Dev team — largely human-powered, significantly lower direct cost — was producing 31% of pipeline.

We reallocated approximately $38,000/month away from the underperforming paid channels and reinvested into scaling what was working: LinkedIn prospecting infrastructure, webinar programming (which showed the highest multi-touch influence scores of any channel), and organic content. Marketing spend dropped. Pipeline held. CAC fell. That sequence is only achievable if you actually know what you're doing with the budget.

Component 2: Pipeline Velocity

Better qualification at the top of the funnel meant fewer bad-fit deals making it through to late stage and stalling there. Our average sales cycle dropped from 71 days to 57 — a 20% compression. The effect compounds through the math: a shorter cycle means less pipeline outstanding at any given time, which means less spend required to maintain coverage ratio. The velocity improvement also fed Clari's deal scoring in ways that made weekly forecast calls genuinely useful, rather than the ceremonial guessing exercise they'd been before.

Pipeline Velocity: Average Days Per Stage
Figure 5 — Stage-by-stage velocity comparison
Before
After

Component 3: Market Conditions (Being Honest)

Q3 and Q4 2025 saw improving conditions across our segment. Buyer confidence returned. Deal cycles compressed industry-wide, and some of that shows in our numbers whether we deserve credit for it or not. My honest estimate is that macro tailwinds account for 5–7 percentage points of the 31% reduction. The remaining 24–26 points I'm comfortable defending as ours. At our acquisition volume, that represents roughly $260–280 saved per customer acquired. It adds up fast.

4.2 Data Quality Scores

We implemented a data quality scoring framework in March 2025 — something we should have had from day one. Each contact, company, and deal is scored daily on weighted criteria: completeness, accuracy, freshness, and source integrity. The improvement since implementation has been significant across every category, but the one that matters most operationally is lead routing accuracy. Getting that from 71% to 97% alone is worth the entire project cost in recovered deal flow.

Data Quality Scores by Category
Figure 6 — Quality scores across key CRM data domains, before vs. after
Before Redesign
After Redesign

4.3 Operational Efficiency Gains

The time savings are real, but I want to frame them correctly. The point of reclaiming 92 hours per month of reporting time across the GTM team isn't to reduce headcount. It's to redirect that capacity toward work that actually moves the business. Our RevOps analyst went from spending three days a week maintaining the 74-tab spreadsheet to spending three days a week building new analyses, identifying pipeline risks early, and designing the next layer of automation. That's the version of RevOps we wanted to be running. We just couldn't get there while the data janitor work was consuming everything.

MetricBeforeAfterChange
Monthly reporting hours (all teams)117 hrs25 hrs−79%
Lead routing accuracy71%97%+37%
Average time to MQL acceptance/rejection18.2 hrs3.4 hrs−81%
Contact database duplicates~39%<3%−92%
CRM fields with documentation28%100%+257%
Attribution coverage (multi-touch)18%74%+311%
Clari forecast accuracy (vs. actuals)±28%±8%+71%
Sales rep data entry time (hrs/week)3.2 hrs1.1 hrs−66%

The metric I track most personally is the Clari forecast accuracy shift — from ±28% variance to ±8%. That's not just a data quality win. It means every conversation we have about pipeline coverage, hiring plans, and capacity is now based on a number that actually predicts what's going to happen. The downstream decisions that flow from a trustworthy forecast are worth more than any single line item in the table above.

Part Five The Governance Model

5. Keeping It Clean: The Governance Framework

There is a specific kind of failure mode in CRM redesigns that I've watched happen twice at companies I've talked to since we did this work. The project launches cleanly. The data is good. People trust the reports for a while. Then, six months later, someone creates a field without a documentation entry. Then two more people do. Then a new hire builds a sequence off an unreviewed field. Then finance notices the CAC number looks different again. The re-degradation is slow enough that nobody triggers an alarm, and fast enough that by the 18-month mark you're mostly back where you started. The antidote is governance, and governance has to be designed before it's needed — not installed as a patch after things start sliding.

5.1 The CRM Constitution

Every field in the new HubSpot environment has a corresponding entry in what we call the "CRM Constitution" — a live Notion document that serves as the single reference for every property across every object. For each field, it records: the internal name, the display label, the owning role, the data source, how often it should be updated, a plain-English definition, and every downstream system, report, or workflow that reads from it.

The rule is non-negotiable: no new field exists in HubSpot without a Constitution entry. This is technically enforced — regular users don't have field creation permissions. The first time someone asked me why, I explained it the same way I'd explain a building permit: you can build whatever you want, but it has to be on record so the next person who comes along knows what's load-bearing.

5.2 The Field Request Process

New field requests come through a Notion form, reviewed by RevOps weekly. Three questions govern every decision: Does something for this already exist? Is the use case tied to a real decision or reporting need? Could an existing field with a different picklist value serve the same purpose?

In the first six months after launch: 34 requests received, 11 approved. Of the 23 rejected, 14 were resolved by showing the requester what already existed in the Constitution. This is the single most revealing data point from the whole project. Most CRM field sprawl isn't caused by genuine new business requirements. It's caused by people who don't know the tool they're working in. Invest in discovery before you invest in creation.

5.3 The Data Quality Review Cadence

CadenceOwnerScopeOutput
WeeklyRevOps AnalystNewly created contacts: completeness, routing accuracy, duplicate detectionException report to RevOps lead; reps notified of data gaps
MonthlyRevOps LeadFull data quality score review, field population rates, attribution coverageData quality scorecard shared with GTM leadership
QuarterlyVP RevOps + ConsultantFull CRM Constitution review, unused field audit, integration health check, Snowflake pipeline validationQuarterly housekeeping sprint; approved deletions processed

5.4 The Owner Accountability Model

Every data domain has an owner who is accountable for quality — not responsible for entry. This distinction matters more than it sounds. The AE enters deal data. The AE Manager is accountable for the quality of their team's deal data. Accountability without data entry responsibility means managers have to care about the norms they set for their teams, not just their own hygiene.

We built this into the GTM manager performance framework — one of the five metrics in every QBR is the data quality score for that manager's records. It doesn't have to be perfect. But it has to be trending in the right direction, and outliers get a conversation. The effect was immediate: within two months of QBR integration, the number of records failing completeness thresholds dropped by 61% in the teams whose managers knew it was being tracked.

Part Six Lessons & Playbook

6. What We Would Do Differently

6.1 Governance in Phase 4 Was a Mistake

We built the governance framework in Phase 4 — the last phase, after everything was already live. The reasoning at the time was that we wanted to get the architecture right before layering rules on top of it. In retrospect, that's backwards. Governance isn't a layer you add on top of an architecture. It's a constraint that shapes the architecture. If we'd built the Constitution template and the field request process in Phase 0, we would have made design decisions differently — fields would have come with owners baked in from the first day they were written, not assigned retroactively after the fact. We also would have avoided three weeks of post-launch catch-up work documenting fields we'd already built.

6.2 Four Weeks of Parallel Reporting Wasn't Enough

We ran four weeks of parallel reporting — old and new metrics side by side. I pushed for six, got overruled on the basis that the team was burned out from the implementation and needed to move forward. In month one post-parallel, three separate stakeholders independently went back to the old report views "just to double-check something." That is what trust debt looks like. It doesn't break loudly; it erodes quietly. Those three check-ins became informal precedents, and we spent another three weeks reinforcing the new system before it fully took hold. The extra two weeks of parallel reporting would have been less painful than that.

6.3 Enrichment Vendor Consolidation Takes Twice As Long As You Think

Cutting ZoomInfo and consolidating to Clearbit seemed like a clean decision. We had the data to support it and the cost case was obvious. What we hadn't mapped was the blast radius. ZoomInfo data had been written into scoring rules, sequence enrollment criteria, workflow triggers, lead assignment logic, and five different report filters — almost none of which were documented. Tracking down every reference took six additional weeks we hadn't planned for. If you're consolidating enrichment vendors, spend a full week upstream doing a dependency audit before you sign the cancellation notice. You will find things you didn't know existed.

6.4 The External Consultant Wasn't There For Their Knowledge

This one is uncomfortable to admit, but it's important. Our internal team had identified virtually every problem that the external consultant surfaced in the audit. We'd been flagging most of them for over a year. The reason we hired an external party wasn't because we needed their expertise — it was because we needed their credibility. A VP of RevOps saying "our data model is broken and we need to rebuild it" is politics. An external consultant with no stake in the outcome saying the same thing is a finding. That's a dysfunction of how organisations work, not a reflection on the internal team. But if you're trying to get buy-in for a project of this scale, an external voice often unlocks the room in a way that internal advocacy can't. Budget for it accordingly.

7. The Practical Playbook: If You Are Starting This Today

These are the specific steps, in order, that we would execute if starting this project from scratch today. I'm not framing these as best practices I read somewhere. These are decisions we made, including some we made wrong the first time. The sequencing matters — don't reorder them because your situation seems different. It probably isn't as different as you think.

Phase 0 Diagnosis (4–6 weeks)
  1. Pull a complete field inventory from your CRM. Assign an analyst three days to document every field: object, creator, creation date, population rate, last populated date.
  2. Run a lifecycle stage consistency audit. Pull all contacts at each stage from all connected systems and compare. Document every gap or contradiction.
  3. Quantify the operational cost. Calculate hours spent monthly on manual reconciliation, duplicate management, and report rebuilding. Put a dollar figure on it. This is your business case.
  4. Identify your five most critical reporting metrics. Trace each metric back to its data source and document every dependency.
  5. Conduct stakeholder alignment sessions. Do not begin designing anything until key stakeholders have agreed in writing on: MQL, SQL, Lead Source taxonomy, CAC methodology, ARR definition.
Phase 1 Design (3–4 weeks)
  1. Draft the new object schema. Start with Contact, then Company, then Deal. Work backward from decisions, not forward from existing data.
  2. Write the lifecycle stage definitions. Get each stage signed off by the function that owns it and the function that receives leads at that stage.
  3. Design the attribution framework. Decide on your primary model. Build the UTM taxonomy. Define what a "source" is and what it is not.
  4. Draft the CRM Constitution template. Having it ready means fields get documented as they are built, not as an afterthought.
  5. Define your golden record rules for deduplication before running a single dedup job.
Phase 2 Build (6–8 weeks)
  1. Build the new schema in your CRM in a staging environment or using a systematic naming convention that allows parallel operation.
  2. Run deduplication on your contact database before migrating anything. Deduplicate first. Migrate second. Non-negotiable.
  3. Rebuild your integrations. Every integration should be re-validated against the new schema.
  4. Build the data quality scoring model. Even a simple version gives you a baseline to measure against.
Phase 3 Migrate & Validate (4–6 weeks)
  1. Run parallel reporting for a minimum of six weeks. Publish both old and new metrics simultaneously.
  2. Establish the weekly exception reporting workflow before go-live so it is operational from day one.
  3. Conduct live team training for each team (Sales, Marketing, CS) with time for Q&A.
Phase 4 Govern (Ongoing)
  1. Enforce the field request process from day one. The first time someone creates an unauthorised field and nothing happens, the norm is broken.
  2. Build data quality into manager scorecards. Accountability without consequence is just a suggestion.
  3. Run the quarterly housekeeping sprint. Schedule it now, for every quarter, for the next two years.
  4. Review the CRM Constitution at every major tool addition or GTM process change. Catch implications proactively.
Conclusion Data Infrastructure Is Strategy

There is a version of the RevOps function that is reactive — fixing things when they break, reconciling numbers when people ask, maintaining systems designed by somebody else for a company that no longer exists.

There is another version that is proactive — designing revenue infrastructure that enables good decision-making, building data models that reflect how the business actually works, and governing those models with enough discipline that they stay reliable over time.

The difference between these two versions of RevOps is not really about skill or tools. It is about whether the organisation treats data infrastructure as strategy or as plumbing. Plumbing gets maintained. Strategy gets invested in.

What was built here is not unique or especially clever. It is the application of basic data engineering principles to a go-to-market context, executed with stakeholder buy-in and maintained with discipline. The 31% CAC reduction happened not because anyone found a secret lever. It happened because the revenue team was given accurate information and trusted to make good decisions with it.

"Your CRM is not a system of record. It is a system of beliefs. Every field, every lifecycle stage, every attribution model represents a belief about how your business works and how your customers make decisions. When those beliefs are muddled, contradictory, or just wrong, they produce muddled, contradictory, and wrong decisions.

Clean up the beliefs. The results will follow."

— VP of Revenue Operations, Series B SaaS Company (anonymised at contributor's request)
Enjoyed this deep dive?

RevOps Brief publishes practitioner-written deep dives, frameworks, and teardowns for revenue operations professionals. No vendor influence. No fluff.

Subscribe Free →
Appendices Templates, Tools & Resources

Appendix A: CRM Constitution Template

Use this template in Notion (or any wiki) for every field in your HubSpot instance. The template is the governance, not just documentation.

AttributeDetails / Description
Field Name (Internal)The exact API name as it appears in HubSpot
Field Label (Display)What users see in the UI
ObjectContact / Company / Deal / Ticket
Owner (Role)Which role is accountable for data quality in this field
Data SourceManual entry / Enrichment / Workflow / Integration / Calculated
DefinitionPlain English: what does this field measure or represent?
Allowed ValuesIf dropdown: list all values with exact definitions. If free text: describe the expected format.
Population Rate TargetWhat % of records should have this field populated?
Update FrequencyReal-time / Daily / Weekly / On deal stage change / etc.
Downstream DependenciesEvery report, workflow, integration, or scoring model that reads from this field
Date CreatedWhen was this field created?
Created ByRole/name of whoever created it
Last ReviewedDate of last quarterly review
Retirement CriteriaUnder what circumstances should this field be deprecated?

Appendix B: The 12-Question CRM Health Assessment

Answer these twelve questions honestly. More than four "No" answers indicates a structural data model problem that requires intervention beyond routine maintenance. This is an interactive checklist — click to mark your answers.

0/12
Click the checkboxes below to assess your CRM health

Appendix C: Recommended Resources & Tooling

CRM & Data Model Design

Deduplication Tools (2026 Landscape)

Attribution

Community & Peer Learning