revops-data-governance

name	revops-data-governance
aliases	["revops-data-governance"]
description	Revenue data governance: the operational discipline every other RevOps skill depends on. Use when the user mentions data governance, data quality, data model, data architecture, field governance, property naming conventions, data hygiene, deduplication, integration data flows, system of record, sync rules, data enrichment, data definitions, one vision of truth, data spine, data quality scoring, validation rules, GDPR, field deprecation, or data audit. Also trigger when someone says "our reports don't match," "our CRM is a mess," "we have too many fields," or describes duplicate accounts, conflicting numbers, stale data. Fix data governance before building metrics or scaling. BOUNDARY: Covers data MODEL, QUALITY, and GOVERNANCE. For HubSpot setup, see revops-hubspot. For metrics, see revops-metrics.
status	stable

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.

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)

ORGANISATION 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)

UNIQUENESS:    No duplicates?
               Recommended target: 99%+ (Measure: duplicate contacts per account,
               duplicate accounts per domain; duplicates are high-risk)

Starting point: if your organisation is below 85% on any dimension, prioritise completeness and consistency before accuracy or timeliness.

Data Quality Score

Recommended starting weights (practice-based):

DQ Score = (Completeness × 0.25) + (Accuracy × 0.25) + (Consistency × 0.25)
         + (Timeliness × 0.15) + (Uniqueness × 0.10)

Rationale: completeness, accuracy, and consistency carry equal weight because all three are prerequisite for trustworthy reporting. Timeliness and uniqueness prevent stale or duplicate data from corrupting decisions but require less weight since periodic refresh and deduplication can address them. Adjust weights to your business; if revenue accuracy depends heavily on timeliness (e.g., real-time deal velocity), increase timeliness weight.

Track monthly. Recommended target: 85%+ across organisation. Starting point assumes B2B SaaS (€15M-150M ARR); mature data governance may sustain 90%+.

### Prevention-First Approach

Don't plan to fix bad data. Prevent it:

VALIDATION RULES: Email format. Phone country format. Dates can't be in past (except close_date). Stage only moves forward without approval.

REQUIRED FIELDS: On Contact: email, first_name, last_name, account_id On Opportunity: account_id, name, stage, close_date Keep to minimum; too many kills adoption.

PICKLISTS > TEXT: For ANY categorical data (stage, industry, deal_type). Free text proliferates bad data.

DEFAULT VALUES: Currency = EUR. Stage = Prospect. Country = from account. Reduce manual entry wherever possible.

### Detection Systems

AUTOMATED SCANS (weekly): Duplicate accounts (fuzzy match on name + domain) Null required fields | Stage anomalies (backwards movement, stuck >180 days) Data drift (values changed without user action, e.g., stage changed but no activity log)

ANOMALY ALERTS (real-time): Close date in the past | Contact on 5+ accounts | ARR > €10M on single opportunity Stage change without activity in 30 days | Deal velocity anomaly (closed in <3 days or >365 days)

LLM-BASED QUALITY MONITORING (emerging, 2026): Pattern detection: LLM identifies suspicious records based on field patterns (e.g., "contact name contains only one letter", "title has 47 words", "industry unrecognised"). Technique: fine-tune on your clean records, flag outliers for review. Accuracy: 75% precision on data quality detection (practice-based; emerging in vendor research 2026). Use case: catch unusual entries before they propagate. Not a replacement for rules.

PREDICTIVE QUALITY SCORING (emerging): Score each record's propensity for future data issues based on historical patterns (e.g., records created by User X without manager review have 40% incompleteness rate). Direct QA effort to riskiest records. Reduces data quality audit workload.

PERIODIC AUDITS (quarterly): Sample 5% of closed opportunities (really closed, or marked closed in error?) Sample 5% of churned accounts (really churned, or erroneously moved?) Sample 5% of enrichment data (vendor data still accurate after 6 months?) Calculate dimension scores: completeness, accuracy, consistency, timeliness, uniqueness (see Five Dimensions section). Compare month-over-month.

### The Data Quality Tax

DQ Tax = (Hours wasted × Hourly cost) + (Revenue impact of decisions on wrong data)

Example: Sales ops 2hrs/week on dupes (€1,500/mo) + 20 reps × 0.5hr/week (€3,200/mo) = €4,700/month = €56,400/year. Show this to the CFO. Governance gets budget.

## 4. Deduplication & Record Management

### Duplicate Detection

EXACT MATCH (high confidence): Email address | Account domain + size | Phone number FUZZY MATCH (review required): "Acme Corp" ≈ "ACME CORPORATION" ≈ "Acme" "John Smith" + @acme.com ≈ "[e-mail]" VENDOR MATCH: Enrichment vendors flag duplicates in their systems

### Merge Protocol

CONTACT MERGE: Surviving record = most complete + recent activity. Preserve all activities and relationships from deleted record. Keep audit trail (which record deleted, when, who).

ACCOUNT MERGE: Surviving record = older record (usually). Move all contacts, opportunities, subscriptions from deleted. Never merge parent into subsidiary. Log everything.

### Prevention at Creation

On contact creation: form triggers lookup by email. If exists, "This contact already exists." On account creation: fuzzy match on name + country. Show potential matches. Override option logged and audited.

### Account Hierarchy

Parent = ultimate legal entity. Child = subsidiary/division. On M&A: create new parent, move old to child. On acquisition: don't delete; create parent relationship instead. Every contact maps to exactly one primary account.

## 5. Integration Data Flows

### System of Record Decisions

For each data point, one system owns it. Others read it:

Account name: CRM (authoritative) Annual revenue: Enrichment vendor → CRM (weekly sync) Sales stage: CRM (only sales updates) Subscription dates: Finance system → CRM (don't edit in CRM) Lead source: CRM (integration reads, doesn't change)

Rule: if you don't explicitly define system of record, conflicts emerge.

### Sync Direction Rules

ONE-WAY (most common): Master → Reader. Example: Finance → CRM for subscription data. BIDIRECTIONAL (dangerous): System A ↔ B. Use rarely. Requires detailed conflict resolution.

CONFLICT RESOLUTION: Define per field: which system wins? Timestamp-based? Manual review? SLA: investigate conflicts within 24 hours.

### Architecture Patterns

POINT-TO-POINT: Simple, 2-3 systems. Breaks down at 5+.

HUB-AND-SPOKE: CRM as central hub. All systems speak to CRM. Recommended for €15-80M. Risk: CRM becomes bottleneck; sync latency compounds.

iPaaS: Integration platform (Zapier, Make, n8n). For 5+ systems with complex transforms. Operational burden: monitoring, error handling.

EVENT-DRIVEN: Real-time event streams (data warehouse streams, message queues). Emerging pattern for €100M+ or high-frequency sync requirements. Each system publishes events; consumers subscribe independently. Benefit: decoupling, lower latency, easier to add new systems. Operational burden: event schema governance, consumer failure handling.

DATA FABRIC: Composable CDP or modern data platform (Hightouch, Census, CDP). Zero-copy replication from warehouse to destination systems. Benefit: single source of truth, no ETL reimplementation. For 2026: emerging as standard for €50M+ with data warehouse.

COMPOSABLE CDP: Modern CDPs (Attio, Clay, etc.) with multi-destination reverse ETL. Warehouse-native with no-code sync. Hybrid human+AI enrichment.

**2026 standard:** Size €50M+ or 5+ integrated systems with complex data flows? Evaluate data fabric or event-driven. Smaller organisations can sustain hub-and-spoke through €80M if iPaaS handles integration complexity.

### Integration Monitoring

Sync failure alerts (3 failures → alert within 4 hours). Data drift detection (weekly record count comparison). Latency monitoring (alert if >2 hours). Don't trust syncs just because you set them up.

## 6. Enrichment Strategy

### What, When, How

WHAT: Firmographics (revenue, size, industry) | Technographics (tools they use) Intent signals (job postings, keyword research) | News (funding, M&A, leadership)

WHEN: On creation (initial fill) | On stage transition (targeted enrichment) Quarterly refresh for active accounts | Event-driven (trigger-based)

GOVERNANCE RULES: AUTO-OVERWRITE: Only for immutable data (founding year, domain) FILL-EMPTY-ONLY: For data where manual entry is authoritative SUGGEST (review): For data that might conflict (company size, title); default.

Cost varies by vendor type and enrichment depth. Evaluate vendors on accuracy (measured by sample audit against real data), coverage (percentage of your target market addressable), and integration quality. Request sample enrichment of 100 test accounts before commit. Document vendor's data sources to confirm GDPR compliance.

### Privacy & Data Transfer Compliance (Global)

**GDPR (EU, UK, EEA):**
Verify vendor data sources (scraped data may violate GDPR). Document legitimate interest for B2B outreach (requires documented three-part balancing test; post-October-2024 CJEU rulings). Article 14: notify enriched contacts within one month of collection. Article 21: unconditional right to object to direct marketing; processing must stop immediately. Implement DND/Do-Not-Contact flag + automated cessation workflow + audit log (Schrems II requirement).

**US Transfer Safeguards (Schrems II 2020, updated 2024):**
Standard Contractual Clauses (SCCs) alone are insufficient. Require supplementary safeguards: transfer-risk assessment for each vendor, encryption in transit/at rest (where applicable), vendor's compliance with US surveillance law, and clause permitting escalation to data protection authorities if US law compels disclosure. If transfer risk is unjustifiable, route data to EU-based vendor or keep processing in EU (common for enrichment).

**CCPA/CPRA (California, US):**
Consumer right to know, delete, correct, and opt-out of sale/sharing. For B2B: exempt if data relates to business role, but boundaries unclear for personal emails. Implement request intake process. Deletion SLA: 45 days. Requires privacy policy and opt-out link.

**LGPD (Brazil):**
Broadly similar to GDPR. Requires Data Protection Impact Assessment (DPIA) for high-risk processing. Right to deletion and correction. No adequacy decisions; SCCs required for Brazil-to-US transfers.

**UK DPA 2018 (Post-Brexit):**
UK retained most GDPR provisions but added transparency duty (inform subjects of data uses). UK-US transfers require adequacy decision (November 2023) or SCCs plus supplementary safeguards.

**Consent & Do-Not-Contact Management:**
Use consent management platforms (CMPs) for EU contacts to track consent basis per channel (email, phone, SMS). Consent is required for direct marketing in Germany, Austria (UWG s.7); cold email to corporate accounts is permitted in Netherlands (Telecommunications Act art. 11.7) and France under conditions. Implement immediate cessation workflow for Article 21 objections (no delay).

**Enrichment Vendor Assessment:**
Before engagement: ask vendor for DPA, SCCs, audit report (SOC2/ISO27001), data sources, and transfer mechanisms. Prioritise EU-based vendors for EU data. Document assessments in vendor risk register.

## 7. Definitions & Taxonomy

### The Shared Definitions Problem

Sales says €2M pipeline. Marketing says 50 leads. Finance forecasts €1.8M. Nobody agrees what "pipeline," "lead," or "qualified" means.

### Definition Governance

1. PROPOSE: Owner documents definition with specific, measurable criteria
2. REVIEW: Marketing, Sales, Finance all review (can you identify this? Is it useful? Can you forecast?)
3. APPROVE: Revenue leader signs off. Definition locked. Version controlled.
4. COMMUNICATE: Published centrally. Training delivered. Enforcement begins.
5. REVIEW: Quarterly: still working? Annual: comprehensive update.

### Stage Definitions Tied to Data

Each stage requires specific data to exist; operationalise this:

PROSPECT: account_name + contact_email + lead_source (can't advance without these) QUALIFICATION: + title + company_size + budget_range + expected_close_quarter PROPOSAL: + deal_size_eur + decision_maker_identified NEGOTIATION: + close_date + deal_terms_documented + risks_identified

This enforces data quality by stage. You can't lie about stage if the data isn't there.

### One Vision of Truth

NOT one database. Agreed definitions and shared views:

Marketing owns lead definition (CRM = system of record) Sales owns opportunity definition (CRM = system of record) Finance owns ARR definition (synced from subscription system, displayed in CRM) CS owns health score (calculated in CS platform, synced to CRM for visibility)

Shared vision = published definitions + agreed metrics + shared dashboards Not: everything in one tool. Tools are separate. Definitions are shared.

## 8. Data Governance Operating Model

### Roles

DATA OWNER (executive): VP Sales owns stage accuracy. VP CS owns health scores. Authority: mandate corrections, approve fields, set standards.

DATA STEWARD (operational): RevOps/SalesOps. Day-to-day enforcement, audits, dedup. Authority: execute corrections, delete bad data, enforce process.

DATA CONSUMER (end user): Reps, CSMs, marketers. Follow standards. Measured on data quality.

DATA GOVERNANCE COUNCIL: VP Sales + VP Marketing + VP Finance + VP CS + RevOps Lead Monthly: quality scorecard, incident review, process changes Quarterly: field approvals, definition updates, tool decisions Annual: maturity assessment, multi-year roadmap

### Data Governance Maturity

LEVEL 1: CHAOS No standards, no ownership. 500+ fields, many duplicates. "We don't trust our reports." Fix: 3-6 months dedicated effort.

LEVEL 2: REACTIVE Some naming conventions. Occasional cleanup projects. Ad hoc ownership. Quality scoring begins. "We keep finding new problems." Fix: 6-12 months with council.

LEVEL 3: PROACTIVE Council meets monthly. Prevention enforced (validation, picklists). Quality scoring automated. Standards documented. Dedup prevention built in. "We know what good data looks like." Fix: 12-18 months for Level 4.

LEVEL 4: OPTIMISED Automated enforcement. Self-healing data. Culture of ownership. Real-time monitoring. Predictive quality. "Data quality is our competitive advantage."

TARGET: Level 3 within 12 months. Level 4 requires data engineering resource.

---

## Norton Framework Additions (Source: Kyle Norton, Revenue Leadership Podcast, Jan 2026)

### Data Foundation for AI Readiness (Norton Model)

AI is only as good as the data underpinning it. Most companies trying to bolt AI onto broken infrastructure are installing a turbocharger on a car with a cracked engine block.

**Prerequisites for AI-Ready Data:**
1. **Single source of truth**: Snowflake (or equivalent) as system of record for intelligence, CRM as operational layer.
2. **Data synthesis**: Sales, marketing, product, and third-party data coherently joined.
3. **Quality thresholds**: Defined minimums for completeness, accuracy, and freshness before AI models can be trained.
4. **Definition convergence**: Consistent stage definitions, field meanings, and scoring criteria across all teams.

**The Code Red Principle:**
If your data foundation isn't ready for AI, call a code red at the exec level. Get the resources to fix it.
> "If you argue for your limitations, you get to keep them."

**Composability Data Requirements:**
Multiple integrated tools (composability) require stricter governance because sync failures cascade across more systems. For every new tool added:
- Define the system of record for each data entity
- Document sync direction and conflict resolution rules
- Test data flow end-to-end before go-live



### The Five Data Classes (Brinker/Databricks, March 2026)

When designing data governance, think beyond CRM hygiene. Modern data governance covers five interrelated classes of data:

| Class | What it covers | Governance implications |
|---|---|---|
| **Customer Data** | Profiles, transactions, behavioural signals, support tickets, enrichment data | Identity resolution, consent management, decay monitoring |
| **Company Data** | Operational data across departments: financials, pipeline, inventory, logistics | Cross-functional access policies, department data ownership |
| **Content Data** | Creative assets with metadata: what it is, where it can be used, who approved it, how it performs | Content governance, brand compliance, performance tracking |
| **Code Data** | AI models, prompts, agent configurations, automation rules; "software is data" | Version control, prompt governance, agent audit trails, agentic compliance |
| **Control Data** | Semantic layer definitions, business rules, governance policies, AI guardrails | Meta-governance: the rules that govern the rules |

**Why this matters:** When everything is data (including the AI agents themselves and the governance rules they follow), data governance becomes the foundation of the entire operating system, not just a hygiene exercise. Brinker's thesis: "The martech stack doesn't sit on top of data. It is data."

### Code Data Governance: Operationalising AI Agents (2026 Standard)

By 2026, 61% of RevOps teams use AI in at least one workflow (Skaled, 2026); governance must address agent behaviour, not just model training. Key runtime controls:

**Agent Audit Trails (Mandatory):**
Every agent action must be logged: what data it read, what decision it made, what it wrote, timestamp, confidence score (if available). Log writes to immutable ledger (append-only). Enable 72-hour recall: "What did Agent X do on this record last week?" Required for: regulatory compliance (Article 21 objections, GDPR audit), incident investigation (data corruption), and audit defence.

**Prompt Versioning & Control:**
Treat prompts as code. Version control: prompt text, input validation rules, output validation rules, agent access boundaries. On prompt change: test against 100-record sample before go-live. Document: what changed and why. Escalation: if agent behaviour changes meaningfully, notify VP RevOps before rolling out.

**LLM Output Validation (OWASP Agent Top 10, 2025):**
AI agents can hallucinate (invent data), confabulate (misunderstand), or take unintended actions. Guardrails per OWASP Agent Governance Toolkit (Microsoft, 2026):
- No agent writes to immutable fields (account_name, created_date, revenue_closed_won)
- All writes to mutable fields (stage, notes, scores) must pass validation: "Is this value in the allowed range?" / "Is this a typo?" / "Did something break upstream?"
- Cost anomaly detection: if agent writes ARR > €10M on single deal, hold and escalate (48-hour review SLA)
- Contact/account merges: agent cannot merge without human approval; only surfaces candidates

**Escalation Rules:**
If agent confidence <65% on any critical decision (stage change, data write, contact merge candidate), escalate to human for review. Track escalation rate per agent; >15% escalation signals poor prompt or broken upstream data.

**Agent Lifecycle:**
Before deployment to production, agent must: pass compliance test (writes only to approved fields), achieve >90% accuracy on 50-record validation sample, and have audit trail integrated. After deployment: weekly logs review (sample 5% of actions), quarterly prompt audit (still appropriate for the data it sees?). Disable agents that exceed escalation threshold; post-mortem before redeployment.

**Singapore Model AI Governance Framework (IDA, 2024) alignment:**
AI agents for revenue operations are not yet classified as "high-risk" by EU AI Act, but operational controls above reflect emerging best practice in insurance, finance, and government sectors (where AI audit trails and escalation are mandatory). Implementing now prevents regulatory surprise and reduces revenue leakage from agent errors.

### The Semantic Layer as Governance Foundation

A semantic layer provides consistent, business-friendly vocabulary across the organisation:
- Standardised metric definitions (what "MQL," "pipeline," "customer" mean)
- Translation between technical schemas and business concepts
- Shared calculations that every report, dashboard, and AI agent uses

**Without a semantic layer:** "Every agent becomes its own island of interpretation, which is how you get three different dashboards showing three different pipeline numbers, or worse, three different agents taking three different actions based on contradictory assumptions." (Brinker, 2026)

**Practical implication for revenue dashboard:** The breach rules and tile definitions in the revenue dashboard ARE the semantic layer for revenue operations. They enforce shared meaning. When building the revenue dashboard, you're building the semantic layer.

## How to Use This Skill

**"Our CRM is a mess":** Start with the data quality audit; score the five dimensions. Calculate the data quality tax. Show leadership the cost. Then build prevention (validation rules, required fields, picklists) before correction (cleanup projects).

**"Reports don't match across teams":** This is a definitions problem. Get in a room. Define MQL, pipeline, revenue, customer. Write it down. Publish it. Enforce it.

**"We have too many fields":** Run field audit: which fields haven't been touched in 3 months? Deprecate aggressively. Install field creation governance to prevent recurrence.

**"Integrations keep breaking":** Map system of record for every data point. Define sync direction. Set up monitoring. Most integration failures come from undefined ownership.

**Cross-references:** For CRM property implementation, see **revops-hubspot**. For tech stack integration decisions, see **revops-tech-stack**. For data spine quality scoring, see **revops-four-capability-maturity-assessment**. For emergency data audit, see **revops-crisis**.

> Built by [Neon Triforce](https://neontriforce.com)