Crm Data Governance

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 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 fields and retention schedules become first-class governed fields (consent policy owned by marketing, sync reliability by platform ops; consent logic stays centralized even when page creative is federated).
• Identity resolution has no B2B equivalent for B2C's cross-channel matching (deterministic exact-identifier vs probabilistic). B2B resolves identity at the account level via domain matching instead.

Identical across both: per-field system-of-record designation, blank-never-overwrites-populated, enrichment risk tiering, and last-verified-as-distinct-from-last-modified. That equivalence is reasoned synthesis from generically-phrased sources, not a published claim - say so in the deliverable.

Interview

Ask before designing anything. One question per message; multiple-choice where possible; skip anything already answered.

• Which CRM, and which other systems write to it: marketing automation, billing, product database, enrichment providers, support desk, data warehouse?
• Can you export (or let me query) the field list for the objects in scope? Roughly how many custom fields per core object?
• Which fields feed forecasting, routing, compensation, or executive reporting today? (This seeds the governed set.)
• Symptoms driving this: fields contradicting across systems, values mysteriously reverting, stale data, field sprawl, nobody knows who owns what?
• Who does data operations today: dedicated RevOps, a CRM admin, IT, nobody?
• Does any field documentation or dictionary exist, and where does it live?
• Which enrichment providers write into the CRM, and into which fields?
• B2B, B2C, or both? Any consent/data-protection obligations in scope?
• Is there an existing governance forum? Who approves new fields right now?
• Typical sales cycle length and record volumes? (Calibrates SLAs and thresholds.)
• By what date must this be in place - an audit, a board reporting cycle, a CRM migration, or a forecast nobody trusts right now?
• Do you want a one-off correction of the fields that are wrong today, or a compounding governance system that keeps holding as fields are added?
• What is the effort ceiling: admin hours this quarter, any integration engineering capacity at all, and how much friction the sales org will absorb before it routes around you?

The last three set the option ordering in Workflow steps 4 and 6, so ask them before designing anything:

• A hard date promotes the config-only rungs (restricted picklists, defaults, scheduled pull, augment-only enrichment) and schedules conditional validation and real-time push for the next cycle rather than dropping them.
• A compounding mandate promotes per-role permissions, conditional required-at-stage, and the lifecycle and cadence themselves, and demotes default values, which patch a symptom without creating a rule.
• No integration engineering capacity deletes real-time push outright.
• A sales org already hostile to required fields deletes hard required for rep-entered fields.

Record every deletion in the spec - a ruled-out option parked at the bottom of a list reappears as scope at the next escalation.

Workflow

1. Run the Interview; confirm the scope boundary (field rules - not dedup, not hygiene sweeps, not stage design).
2. Scope the governed set: start from the revenue-critical lists in references/field-ownership-and-dictionary.md, add every field feeding forecasting/routing/comp/reporting, and cap it deliberately.
3. Assign ownership per field: consumer-ownership principle, one named person, RACI-by-function as the default split (same reference).
4. Build the per-field system-of-record map: authoritative system, write precedence, replication pattern, enrichment write strategy with risk tier, and conflict-resolution tier for each governed field - references/system-of-record-rules.md. Two ranked choices sit inside this step, and both are made here rather than in the reference:

• replication, efficiency: scheduled pull > reconciliation-only > real-time push. Default every governed field to scheduled pull on the cadence its freshness SLA demands; move a field up to real-time push only when one stale sync cycle changes an action rather than a report. Real-time push is what this order starves - best freshness, worst ratio - so name it in the spec when demoting it, and flip the order where an event bus or iPaaS is already running and the marginal field costs nothing.
• enrichment, efficiency: augment > append > overwrite. Default the whole governed set to augment; move to overwrite only where the provider is definitionally authoritative and the stored value carries no verification stamp. Overwrite is starved here for the same reason, and it is the only mode that can correct a value that is already wrong.