Skill detail

crm-data-governance

Designs CRM field-level governance: field ownership, system-of-record maps, freshness SLAs, enforcement plans, and governance cadence.

Why we recommend it: CRM field governance applies to HubSpot data hygiene, though it is CRM-agnostic.

MatchPossibleRecommended for HubSpot
Sourcembfinotti/​revops-skillsExternal source
Reported installs6,713Popularity signal only

Inspect before use

Read the source instructions and check the requirements before you install this skill.

Saved source preview

SKILL.md

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: crm-data-governance
description: Design and operate CRM field-level governance - who owns each CRM field, which system is authoritative for it, how often it must be refreshed, and how the rules are enforced. Produces a field dictionary, per-field ownership, a system-of-record map with write-precedence and conflict rules, freshness SLAs, an enforcement plan, a field lifecycle, and a governance cadence. Use whenever the user mentions field ownership, single source of truth, system of record per field, data dictionary, stale CRM data, custom field sprawl, "which system wins", or "our CRM fields contradict each other" - even if they never say "governance". Covers B2B and B2C. Do NOT use for org-wide, object-level source-of-truth policy - use mbfinotti/revops-skills@revenue-data-governance-strategy instead.
license: MIT
metadata:
  author: Maya-Beth Finotti
  version: "1.3.1"
---

# CRM Data Governance

Build and run field-level governance for a CRM. The deliverable is a living rulebook plus a meeting rhythm - "governance dies from lack of a meeting, not lack of a document" (ORM Tech) - built from:

- A governed-field catalog with one named owner per field.
- A per-field system-of-record map with write-precedence and conflict rules.
- Refresh and staleness SLAs.
- An enforcement plan ranked by value per unit of effort.
- A field request-approval-deprecation lifecycle.
- The recurring cadence that keeps all of it alive.

## Ground Rules

- Govern revenue-critical fields, not every field - this is the first scoping decision. A CRM carries hundreds of fields; governing all of them is impossible and counterproductive (practitioner consensus). Start from the sourced field lists in [references/field-ownership-and-dictionary.md](references/field-ownership-and-dictionary.md) and expand only through intake.
- One named human owner per field - "Not a team. A person." (RevBlack). Assign each field to the function that consumes it, not the one that populates it.
- Designate the system of record per field, never per system or object. Every other copy is explicitly derived. Blank never overwrites populated, whatever the timestamps say.
- Reps are never the enforcement mechanism of last resort. "Sales reps cannot be responsible for data entry... their compensation, goals, and psychological incentives all push them toward selling, not data stewardship" (Jared Barol). Prefer automation, integration writes, enrichment, and defaults over required-field pressure.
- Design and operate a standing system. A cleanup without an ownership map, a lifecycle, and a scheduled cadence is not governance; decay resumes the day the cleanup ends.
- Label every threshold with its provenance: published company practice, practitioner consensus, or derived from the user's own data. Warn off the circulating statistics - "30% of CRM data decays per year" and "CRM data is only 40-60% accurate" circulate unattributed and must never be stated as fact. Cite the mechanism instead: reality changes underneath stored values (people change jobs, companies grow and rename), and multi-writer syncs without per-field authority silently overwrite each other. Never present a vendor-coined proprietary composite score as an industry standard.
- Scope boundary: record deduplication and merge mechanics are out of scope here. Recurring hygiene sweeps, stage exit criteria, forecast reliability, and routing logic belong to the sibling skills in Reference - this skill writes the field rules those jobs consume.

## B2B and B2C

**Divergent:**

- **B2B** runs on sparse, slow data: long cycles, account hierarchies, buying committees, and a rep-entry layer to treat as unreliable by default ("you should never assume that someone within your sales team is going to help you in adding data" - Stefano Mazzalai). Governance coordinates several functions writing to one account.
- **B2C** runs on high-volume, real-time behavioral data written by systems with no rep layer. Consent/preference field
Read the full source on GitHub (opens external page)
Context

Related work