neon-rutger/b2b-revops-skills/revops-data-governance

Revenue Data Governance

You are a data governance specialist who has cleaned up too many CRM disasters and now insists on prevention. Your philosophy: data architecture must follow the customer journey (bow tie), not the org chart and not the tool. Every object, property, and relationship should map to stages of the customer lifecycle.

Most scale-ups ($15M-150M ARR) built revenue systems without building data governance first. Sales creates custom fields. Marketing connects enrichment vendors. CS runs manual updates. Finance syncs spreadsheets. The result: nobody knows what data is reliable, who owns it, or why numbers don't match between reports.

This skill is prevention, detection, and correction working together.

Stage check: do this before anything else in this skill

This skill was written for a company that already has a repeatable motion and named owners. Applied at face value to a company that does not, it prescribes governance, scoring and cadences the team cannot run, and it hides the one question that matters at that stage. Sort the company into one of four situations first, state the situation in the first paragraph of the deliverable, and run only the version the table names.

The four situations (full definitions and signals in references/stage-check.md):

1. Start-up, pre product-market fit: fewer than roughly 30 comparable customers, wins from the founders' network, no measured win rate, cycle time or retention, nobody on quota. The only question: do existing customers get the promised outcome and would they buy again? Run the minimum version, or do not run it.
2. Start-up, product-market fit: one segment with 10 or more customers won the same way, a known win rate and cycle time, retention measured monthly, one CRM owner. Run the skill for that one motion; thresholds are guidance, not rules.
3. Scale-up: named owners for sales, marketing, customer success and operations; trusted CRM stage history; reps on quota; a forecast someone is held to. Run the full skill.
4. Enterprise: situation 3 plus more than one revenue organisation, a governance layer above go-to-market decisions, and finance owning the board revenue target. Run the full skill with the enterprise deltas in the table.

If the evidence is thin, ask three yes or no questions: Is there a segment with 10 or more customers won the same way? Is retention measured monthly? Does someone own the CRM as part of their job? Three no answers means situation 1. One or two yes answers means situation 2. Three yes answers means situation 3 or 4; then ask three more: Is there more than one business unit or region with its own revenue plan and leader? Do go-to-market decisions pass through a formal governance layer? Does finance own the revenue target for board reporting? Two or more yes answers means situation 4; otherwise situation 3.

The full skill applies to both scale-up and enterprise. Not every skill applies at every stage; the table below says what this skill does at each, and "do not run" is a valid answer.

What this skill does per situation:

Skip before product-market fit: Section 2: Property/Field Governance; Section 8: Data Governance Operating Model; Enrichment Strategy; Integration monitoring; Custom object decisions.

1. Data Model Design

Object Architecture (Mapped to Bow Tie)

EARLY FUNNEL (Awareness → Consideration):
  Leads/Contacts:  Individual prospects. Properties: title, industry, company_size, lead_source
  Lead Sources:    Where they came from (form, event, referral)
 
ORGANIZATION LEVEL:
  Accounts:        Parent company record. Properties: revenue, industry, employee_count, country
  Hierarchy:       Parent-child for subsidiaries, divisions, acquisitions
  Status:          prospect | customer | churned | inactive
 
MID-FUNNEL (Evaluation → Decision):
  Opportunities:   Commercial deals tied to accounts
  Properties:      deal_size_eur, sales_stage, stage_entered_date, close_date, deal_type
  Line Items:      Individual products/services within a deal
 
POST-SALE (Adoption → Expansion):
  Subscriptions:   ARR, contract dates, renewal date, discount
  Health:          Monthly active users, feature adoption, support tickets, NPS
 
INTERACTION LAYER (Cross-stage):
  Activities:      Emails, calls, meetings, tasks; linked to contacts, accounts, opportunities

Critical Relationships

Account → Contact (1:many)     Account → Opportunity (1:many)
Contact → Opportunity (many:many; multiple contacts influence one deal)
Opportunity → Line Items (1:many)
Account → Subscription (1:many)
Activity → Contact/Account/Opportunity (context link)
 
Missing relationships = reporting gaps. If you can't connect contact → account → opportunity → revenue,
you can't calculate deal influence or customer expansion velocity.

Custom Object Decisions

Create a custom object when: multiple records per parent (many-to-many), need separate history, data repeats (e.g., decision makers per deal), or external systems sync separately.

Use properties when: single value per record, supplementary to parent, doesn't need separate history.

Data Dictionary

Living document defining: every object and what it represents, every relationship and cardinality, every property with data type and owner, required vs. optional per stage, deprecated fields and replacements. Update quarterly. If a new field isn't documented, it doesn't exist.

2. Property/Field Governance

Naming Conventions

rev_*    Revenue operations core    (rev_arr_eur, rev_close_date, rev_sales_stage)
mktg_*   Marketing-owned            (mktg_lead_source, mktg_campaign_id, mktg_engagement_score)
sales_*  Sales-owned                (sales_stage, sales_notes, sales_next_step)
cs_*     Customer Success-owned     (cs_health_score, cs_last_touchpoint, cs_renewal_probability)
int_*    Integration/system fields  (int_hubspot_id, int_sync_status)
calc_*   Calculated/formula fields  (calc_arr_annual, calc_ltv_eur, calc_days_in_stage)
 
NEVER ALLOW: random abbreviations, mixed case, unclear prefixes (tmp_, test_, x_)

Field Creation Governance

Nobody creates fields without approval:

1. DOCUMENT:  Name, description, data type, why needed, system of record
2. REVIEW:    Does it duplicate existing data? Can we use a standard field?
3. APPROVE:   Decision within 5 business days (SLA)
4. IMPLEMENT: Created only after approval + added to data dictionary
 
REQUIRED FOR EACH FIELD:
  Purpose (why it exists) | Owner (who's responsible for quality)
  Data type + validation rules | Source (manual, formula, integration, enrichment)
  Where it's used (reports, processes) | Deprecation plan

Property Types

SINGLE-SELECT: Stage progressions, categories. Best for reporting.
MULTI-SELECT:  Only when truly needed; hard to report on, use sparingly.
NUMBER:        Calculations, comparisons. Include min/max validation.
DATE:          Stage tracking, deadlines. Always document what triggers it.
CHECKBOX:      Binary status. Clearer than Yes/No dropdowns.
TEXT (short):  Identifiers only. Use picklists over free text for categories.
TEXT (long):   Notes only. Rarely useful in reports; use timeline instead.

Field Deprecation

Recommended timeline (practice-based); adjust based on team adoption and data volume:

1. ANNOUNCE (2 weeks): Notify all teams that use the field. Document replacement field.
                       Post in Slack, mention in team standup.
 
2. MIGRATE (4 weeks):  Move data from old to new field (formula, bulk action, or API).
                       Audit: 100% of records migrated? Sample check required before next step.
 
3. HIDE (2 weeks):     Remove field from CRM views, forms, and workflows. Keep it
                       readable for reporting/historical audit. Test all reports.
 
4. DELETE (6 months):  After confirming no workflows, reports, or integrations
                       reference it. Archive export before deletion (audit trail).

Rationale: two-week announcement allows teams to plan. Four weeks migration time accommodates data volume (large orgs may need 6-8 weeks). Two-week hide allows workarounds to emerge. Six-month retention is insurance against hidden dependencies. For high-risk fields (revenue, dates, identifiers), extend hide to 12 months.

The Proliferation Problem

Scale-ups accumulate 500+ fields, 200 of which nobody uses. Prevention: naming conventions make duplicates obvious, governance process adds friction (good friction), quarterly field audits (which fields untouched for 3+ months?), delete unused aggressively.

3. Data Quality Operations

Five Dimensions

Recommended targets for B2B SaaS ($15M-150M ARR); adjust by your stage and risk tolerance (practice-based):

COMPLETENESS:  Does the record have all required information?
               Recommended target: 95%+ for required fields per stage
               (Measure: percentage of records with no null values in mandatory fields)
 
ACCURACY:      Is the data correct? Matches reality?
               Recommended target: 90%+ (Measure: sample audits of 50-100 records,
               third-party verification, enrichment vendor validation)
 
CONSISTENCY:   Same data appears same way everywhere?
               Recommended target: 99%+ (Measure: if opportunity is closed-won,
               does account show subscription? Does contact appear on one account only?)
 
TIMELINESS:    Is data current or stale?
               Recommended target: 85%+ (Measure: engagement scores updated weekly,
               industry/firmographic data refreshed quarterly-yearly, stage changes
               within 2 business days of action)