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.

1. Start-up, pre product-market fit. Fewer than roughly 30 comparable customers (practice-based threshold). Wins came from the founders' network or referrals, not from a process anyone could repeat. No segment has a measured win rate or cycle time. Retention is not tracked. The CRM, if there is one, is a contact list. Nobody carries a quota. The only question that matters: do existing customers get the outcome they were promised, and would they buy again? Run the minimum version of this skill, or do not run it.

2. Start-up, product-market fit. At least one segment with 10 or more customers won the same way (practice-based threshold). A known win rate and cycle time for that motion. Retention measured monthly. The founders still do most of the selling, with a few early reps. One person owns the CRM and can trace how recent deals moved. Run the skill for that one motion only; treat thresholds as guidance, not rules.

3. Scale-up. Sales, marketing, customer success and operations each have a named owner. The CRM holds stage history the team trusts. Reps carry quota. There is a forecast that someone is held to. Growth is a question of capacity and constraints: which function breaks first when volume doubles. Run the full skill.

4. Enterprise. Everything in situation 3, plus more than one revenue organisation: business units, regions or product lines with their own plan and their own leader. A governance layer sits above go-to-market decisions (steering committee, works council, legal or compliance gates). Finance owns the revenue target that goes to the board. The CRM may run as several instances or with many administrators. Run the full skill with the enterprise deltas named in the table: aggregation across units, governance and change management, longer decision paths.

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:

Situation	What this skill does
Start-up, pre product-market fit	Pre-product-market fit companies need data hygiene, not governance structure. Run Section 4b (Identity Resolution Gate) to prevent duplicate accounts and contacts at creation; skip field naming conventions and formal approval workflows. Focus on the minimal question: do you know the company's domain and the contact's email? Use a manual deduplication sweep against your existing accounts and contacts, then build an identity-resolution gate before any new contact or account record is created. Skip the council, maturity levels, and enrichment governance; you will add those when you have the team and a repeatable motion.
Start-up, product-market fit	Product-market fit (not yet scale-up) companies have one segment winning repeatably but still run most things by hand. Run Sections 2 (naming conventions for readability, not approval workflow), 3 (quality dimensions and detection systems), 4b (identity resolution), and 4c (outbound readiness gates). Build a simple data dictionary naming only required fields (account, contact, opportunity basics, stage, close date). Assign one person as data steward, not a council. Skip formal field-creation governance and multi-person councils; your constraint is adoption velocity, not complexity.
Scale-up	Scale-up companies run the full skill: all eight sections. Data governance is now an operating function with owned roles, a council cadence (monthly quality review, quarterly approvals), and operational prevention (validation rules, picklists, required fields). Execute the maturity progression towards Level 3 (monthly council, automated detection, standards enforcement). Integrate enrichment vendors with clear data transfer rules. Implement the identity-resolution gate and outbound readiness gates as mandatory workflows before any campaign launches.
Enterprise	Same as scale-up plus multi-instance data governance (federation across regions or business units), regulated data handling with audit trails for compliance requirements, finance-owned data standards for revenue recognition and consolidation, and cross-entity reconciliation workflows. Governance escalates to CFO or compliance office for approval on sensitive data flows.

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)

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

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

Quality scoring consumes CRM field data (entered by sales reps, marketers, and CS team; accuracy varies by field and team discipline; treat with suspicion until validated), automated scans (high reliability for exact matches, medium for fuzzy matches), enrichment vendor data (documented accuracy, but verify with sample audits), call transcripts (high reliability for fact extraction; requires human review for interpretation), and periodic audits (high reliability if the audit sample is random and large enough). Do not treat CRM text fields and enrichment data as equally reliable; use the five-dimension framework to surface confidence gaps.

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 organization. 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 = USD. 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 unrecognized"). 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 ≈ "j.smith@acme.com" 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.

## 4b. Identity Resolution Gate (Before Record Creation)

Before creating any contact or account, run an identity resolution gate. The output is one of four decisions: Link (merge into existing), Create (new record), Review (human judgment required), or Reject (insufficient identity evidence).

### The Four Decision Gate

1. **LINK**: Strong evidence that the new data belongs on an existing record. Merge or link with audit trail preserved.
2. **CREATE**: No credible existing record found after all strong keys are searched. Create new record with provenance documented.
3. **REVIEW**: Multiple candidates exist or important evidence conflicts. Escalate to human; they determine survivor and action.
4. **REJECT**: Input lacks minimum identity evidence (e.g., contact with no email AND no phone; account with no domain AND no legal entity). Do not create.

### Search Strategy

For **accounts:** search by verified domain, verified legal entity, and account relationships (parent/child, merged entities). If the domain exists in your system, you have an account. Normalise domain names and company names before comparing (remove URL protocols, standardise whitespace, strip legal suffixes for account names).

For **contacts:** search by verified email first (corporate email only; consumer domains like Gmail are not account identity). Then search by account + full name. Then by phone number. Each search runs independently so a formatting error in one field does not hide a record.

### Evidence-Based Match Rubric

Use `references/identity-resolution-rubric.md` to score each candidate. Accounts are scored on domain, legal entity, and account hierarchy. Contacts are scored on email, LinkedIn identity, name + account, and phone. Scores above a threshold (40+ for accounts; 50+ for contacts) clear for automatic linking. Scores below require review or create.

**Conflict rule:** If verified values contradict (two legal entities on the same domain, two emails for one contact on the same account), escalate to REVIEW even if the score is high. False links are costlier than false creates.

### Before Creating, Re-Resolve

After planning the create action, re-search immediately. Another workflow may have created the record while you were planning. If a new candidate appears after re-search, invalidate the create decision and resolve again. This prevents race-condition duplicates.

### What Gets Logged

Every identity decision (link, create, review, reject) gets logged with: the search keys used, search population (active records? archived? merged entities?), candidates found, matching evidence, and the decision. For CREATE decisions: log provenance (source system, date, who initiated). For LINK/REJECT decisions: log the reasoning. Enable lookup: "Why did we create this record?" or "Why did we link these two?"

---

## 4c. Outbound Readiness Gate (Before Launching a Campaign)

Before launching outbound from CRM segments, run a five-gate readiness check. Any hard conflict stops the affected record.

### The Five Gates

1. **Identity:** Account domains resolve without material duplicate risk. Contacts tie to a single account.
2. **Ownership:** Every target has one accountable owner or a routing rule exists.
3. **Reachability:** Email, phone, or LinkedIn details are verified enough for the planned action.
4. **Context:** Customers, active deals, recent touches, and legal suppressions are visible and respected.
5. **Fit:** Every target traces to the campaign's ICP and inclusion reason.

### Execution Sequence

**Step 1: Materialize the audience.** Run the exact CRM segment filters. Don't substitute an overall CRM health score; inspect the actual slice. Count: accounts, contacts, contacts per account, contacts with email, ownerless records, duplicates, suppressed records, active opportunities, customers.

**Step 2: Run the five gates.** For each gate:
- Define the check (e.g., "Identity = no account has 2+ contacts with the same email domain").
- Run the check on the audience segment.
- Flag failures and count them by severity.

**Step 3: Remediate in dependency order.**
- **Identity first:** Resolve account duplicates before targeting contacts, because duplicates split activity and ownership.
- **Ownership second:** Assign owners before drafting so replies and tasks have a destination.
- **Reachability third:** Refresh contact details after the target population is stable.
- **Suppress:** Apply active customers, active opportunities, and legal suppressions.
- **Fit:** Audit a sample that the ICP inclusion reason is real (not just "not disqualified").

**Step 4: Rebuild and approve.** After remediation, regenerate the audience from source filters (not editing the export). Re-run all five gates. Reconcile why records entered or left. Require an explicit launch decision.

### Worked Cleanup Sequencing Example

Account "Acme Corp" has two records: Acme_ID_001 (created 2024-03-15, 12 contacts) and Acme_ID_002 (created 2024-07-20, 2 contacts). Both active, no parent/subsidiary relationship documented.

**Step 1: Resolve identity**
- Search by domain (acme.com): both point to it. Duplicate detected.
- Link: Survivor = Acme_ID_001 (older, more complete contact base).
- Merge Acme_ID_002 into Acme_ID_001. Preserve all contacts and activities from Acme_ID_002.
- Log: "Merged Acme_ID_002 into Acme_ID_001 on 2026-09-01; 2 orphan contacts relinked."

**Step 2: Resolve ownership**
- Acme_ID_001 has no owner assigned. Check activities: last touch was from AE Sarah Chen on 2026-08-28.
- Route: Assign Sarah as owner. Log: "Assigned Sarah Chen as owner; last active 2026-08-28."

**Step 3: Refresh reachability**
- 12 contacts, but 3 have no email. Enrichment lookup: 2 of 3 have emails in vendor database.
- Fill blanks: add emails from enrichment. 1 contact (founder, no email published) remains blank; flag for manual entry or skip.
- Log: "Enriched emails for 2/3 missing contacts; 1 remains blank."

**Step 4: Apply suppressions**
- Acme_ID_001 = current customer (closed-won deal 2024-06-01, active subscription).
- Suppress: Remove from outbound campaign. Note: "Active customer; route to CSM for expansion motion."

**Result:** Acme is clean (1 account, 1 owner, reachable contacts), but ineligible for the cold outbound campaign because they are already a customer. Route to expansion instead. No record is wasted; it's just routed correctly.

---

## 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 organizations 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. Prioritize 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; operationalize 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: OPTIMIZED 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.

---

## Framework Additions

### Data Foundation for AI Readiness

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

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, behavioral 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. The thesis: the martech stack doesn't sit on top of data; it is data.

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

By 2026, 61% of RevOps teams use AI in at least one workflow (Skaled, 2026); governance must address agent behavior, 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 defense.

**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 behavior 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 organization:
- Standardized 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 on contradictory assumptions.

**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 emergency data audit, see **revops-crisis**.

The skill produces four deliverables for the leadership and operations team: a data dictionary (one document per object, defining fields, data types, owners, and use cases; updated quarterly), a field-governance process (defined approval workflow and SLA for new fields; documented deprecation timeline), a quality scorecard (monthly DQ score across five dimensions with baseline and 12-month targets), and an outbound readiness checklist (five-gate audit applied before every campaign launch). Frame the final scorecard and targets without reference to maturity levels or framework names.

## When Not to Use This Skill

This skill assumes you have a functional CRM. If you are still using spreadsheets, email, and manual record-keeping with no CRM in place, call revops-tech-stack to establish a CRM first. If your CRM is fundamentally broken (inoperable, vendor sunset, or incompatible with your workflow), see revops-crisis before attempting data governance. Governance on the wrong tool wastes the effort.

## What good looks like

- One documented system of record per object, and reports built on it agree with each other.
- Every active field has an owner and a use case; fields without either are deprecated on a schedule.
- Data quality is scored on completeness, accuracy, consistency and timeliness, with quarterly targets.
- New fields go through a create workflow instead of appearing ad hoc.

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