CRM & data governance

A board slide once showed net-new ARR $900K higher than the number Finance had. Both were pulled from the same Salesforce org. The gap was one mis-stamped close date on a large deal that landed it in the wrong quarter, and it took me two days to find. The two days were not the cost. The cost was that leadership stopped trusting the dashboard for a month, and every number I shipped after that got a second look before anyone acted on it. That is what ungoverned data actually costs. Not the error, the erosion of trust in everything downstream.

Gartner puts the average annual cost of poor data quality near $15M, and most of that is invisible until a slide contradicts a slide in front of the board. The number I care about is the one under it: 55% of organizations say bad data undermines confidence in their own analytics (Experian 2024). Once a team stops trusting the dashboard, they rebuild it in a spreadsheet, and now you govern nothing.

Govern five things, not four hundred

You cannot govern 400 fields, and trying is how governance dies as a project nobody finishes. I split the work into five areas and treat each as an ongoing loop rather than a cleanup sprint. Ownership follows the workflow, not the system: marketing ops owns inbound capture, sales ops owns territory and hierarchy, and RevOps owns cross-system policy. Assigning an area to “the CRM admin” is how every area ends up unowned.

Definitions ends the most arguments. If two dashboards disagree, I resolve it against the published definition, not the loudest voice in the room. When teams debate which value is right, ownership is missing, and the fix is a documented owner, not a longer meeting. This is the same principle that makes handoffs hold: a number nobody owns is a number everybody fights over. I lay out the field-level version of that contract in the data contract for GTM.

	What it governs	The mechanism I ship
Definitions	One canonical meaning per critical field	Published field dictionary; 'Segment' means one thing everywhere
Creation & dedup	How records enter the system	Entry-time validation and dedup, so bad records never reach the forecast
Lifecycle & ownership	Who owns each field, and when	A named role per field, not a system or a committee
Enrichment & validation	Keeping data current	Scheduled append and format checks, because data decays 30% a year
Access & audit	Who can change a value	Field history and permission sets, so you can trace how a wrong value got in

Validate at entry, because cleanup is the expensive path

The $900K slide error would have been caught by a required-field validation on stage change that cost the rep 10 seconds. Instead it flowed into the forecast, into comp, and onto a board deck, and cost hours of reconciliation plus the credibility hit that lingered for a month. That ratio holds everywhere: catching a bad record at entry is nearly free, and catching it after it has propagated is expensive and public.

So I enforce with automation, not reminders. A reminder posted in a Slack channel is a governance program that has already given up, because it depends on the same humans who created the gap to remember to close it. The gate goes on the field, at the moment of entry.

Validation rule on Opportunity (fires on stage change to any Closed stage):
  AND(
    ISCHANGED(StageName),
    ISPICKVAL(StageName, "Closed Won"),
    OR(
      ISBLANK(CloseDate),
      Amount == null,
      ISBLANK(TEXT(Segment__c))
    )
  )
  → "Close date, amount, and segment are required before closing.
     These feed the forecast and the board deck."

Gate the critical few, not the field list. A rule that demands twenty fields at close teaches reps to type garbage or work the deal in a spreadsheet, and then you govern nothing at all. The engineering counterpart to this discipline is idempotent enforcement, which I cover in the required-fields tax: the automation should be safe to run twice and should never fight the rep on a field that does not touch money.

Here is the query I run before writing any dedup rule, so the fix targets the real fracture rather than a guess about it:

-- Fuzzy duplicate accounts by normalized domain: where dedup pays back first
SELECT Website_Domain__c, COUNT(Id) dupes, SUM(Open_Pipeline__c) pipe_at_risk
FROM Account
WHERE Website_Domain__c != null
  AND Type = 'Prospect'
GROUP BY Website_Domain__c
HAVING COUNT(Id) > 1
ORDER BY SUM(Open_Pipeline__c) DESC

The pipe_at_risk column ranks the duplicates by the pipeline sitting on top of them. You fix the fractures carrying real money first, not the ones that are alphabetically convenient.

Enrichment is continuous or it is decoration

B2B contact data decays around 30% a year, roughly 2 to 3% a month (ZoomInfo). Titles change, people leave, companies merge and rebrand. A one-shot enrichment looks great the week it runs and is stale before the quarter closes, which means a “clean” database is a moving target, not a finish line. So enrichment runs on a schedule, and I measure it with operating metrics rather than vibes: duplicate rate, completeness on money-decision fields, validity, time-to-correct, and the percentage of records routed within SLA. Those five go in the monthly review so leadership treats data quality as a managed KPI instead of a surprise on a board slide.

One-time passMonthly refresh

View as table

Point	Value
Enriched	100%
Q1	93%
Q2	85%
Q3	78%
Q4	70%

The operating metrics need targets, or “data quality is improving” stays an opinion. These are the ones I put on the dashboard and the bands I hold them to:

Operating metric	Definition	Target band	Why it matters
Duplicate rate	Duplicate accounts ÷ total accounts	Under 2%	Above 4% routing and reporting both break
Completeness	% of records with all money-decision fields filled	95%+ on Opps	Blank close date or amount corrupts the forecast
Validity	% passing format and range checks	98%+	Bad email or a future-dated close date is silent poison
Time-to-correct	Median days from flag to fix	Under 3 days	A slow correction loop means the dashboard is stale by review day
Routed within SLA	% of new records routed inside the SLA window	95%+	The seam where governance meets handoffs

The completeness figure only counts money-decision fields on purpose. Completeness across every field on the object is a vanity number that punishes you for leaving a harmless notes field blank. Measure the fields that feed a decision and ignore the rest.

The two governance regimes, side by side

	Governance that decays	Governance that holds
Enforcement	Slack reminders to 'please clean up'	Entry-time validation on the critical few fields
Ownership	'The CRM admin owns data quality'	A named role per critical field
Enrichment	One annual bulk append	Scheduled monthly refresh, measured for coverage
Dedup	Quarterly cleanup script	Entry-time dedup plus a ranked-by-pipeline sweep
Reporting	Discovered when a board slide contradicts Finance	Five operating metrics in the monthly review
Scope	40-page standard covering every object	One object, one workflow, one metric set, then extend

Start with one object, one workflow, one metric

The way governance programs fail is scope. Someone tries to govern every object at once, produces a 40-page standards doc, and nothing changes because nobody can operate it. I start narrow. One object, say Opportunity. One workflow, say the stage-change gate. One metric set, say completeness on close date and amount. Prove the loop works there, show the reconciliation time drop in the monthly review, then extend to the next object. A working loop on one object beats a perfect standard on all of them, because a standard nobody enforces is a document, not a control.

Here’s how I’d build it: the governance loop

This is the loop I run on every critical object, in order. It is a maturity ladder, not a one-time project: each rung produces an artifact that keeps running after I leave.

1. 1

   1. Pick the critical few fields

   The ones that feed money decisions and exec metrics: stage, amount, close date, segment, owner, source. Assign each a named role owner. Everything else can wait.

2. 2

   2. Write entry-time validation

   Required-field and picklist logic on those fields, enforced by automation at the moment of entry. Never a reminder, because the humans who created the gap will not remember to close it.

3. 3

   3. Build a data-health dashboard

   Duplicate rate, completeness, validity, time-to-correct, routed-within-SLA. The five operating metrics, each with a target band, not a vibe check.

4. 4

   4. Route exceptions with a due date

   To the owning role, not a broadcast. Unowned data rots, and a fix with no deadline is a fix that never happens.

5. 5

   5. Schedule enrichment and dedup

   Continuous, because a one-time pass slips below 80% by Q3 and toward 70% by year-end. Rank the dedup sweep by pipeline at risk so the fix hits the money first.

6. 6

   6. Report quality monthly

   So leadership manages data quality as a KPI and funds the fix before it becomes a board-slide surprise. The monthly report is the reason the loop survives.

Pick one object, write one validation rule, build one dashboard tile, and let the drop in reconciliation time fund the next object. Governance is not a project you finish. It is a loop you keep running, and the first turn of it fits in an afternoon.