mbfinotti/revops-skillsContrôle réussi
SKILL DETAIL
crm-data-governance
mbfinotti/revops-skills/crm-data-governance
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.
Installations · 169Voir la source
Installation
npx skills add https://github.com/mbfinotti/revops-skills --skill crm-data-governance
Fichiers du skill
SKILL.md
Dernière synchronisation · 15 sept. 2026
evals/evals.json›
{
"skill_name": "crm-data-governance",
"evals": [
{
"id": 1,
"prompt": "Meridian Stack here, B2B SaaS, 70 reps on Salesforce. Our opportunity data is a mess - roughly half the records are missing decision maker and loss reason, and the forecast is garbage because of it. My plan for Monday: make decision maker, loss reason, next step, competitor and lead source all required on save, and put \"the RevOps team\" down as the owner of all five in the doc so there's a clear escalation path. Sales leadership pushed back last year when we made next steps required and people just typed a period into it, but I think we just didn't enforce it hard enough that time. Can you help me write this up?",
"expected_output": "A refusal to lead with hard-required fields, an enforcement plan worked down a value-per-effort ordering starting at restricted picklists and conditional required-at-stage, hard required deleted from the menu for rep-entered fields and recorded as deleted, and one named individual owner per field.",
"files": [],
"expectations": [
"Declines to make all five fields hard required on save as the first move.",
"States an enforcement ordering by value per unit of effort in which restricted picklist and conditional required-at-stage both rank ahead of hard required.",
"Recommends conditional required-at-stage validation for loss reason, fired at the closed-lost transition rather than on every save.",
"Assigns each of the five fields to one named individual rather than to \"the RevOps team\" or any other team name.",
"Reads the earlier episode of reps typing a period as evidence that hard required fails on rep-entered fields, not as evidence that enforcement was too weak.",
"Deletes hard required from the menu for rep-entered fields given this sales org's demonstrated workaround, and records the deletion in the spec rather than parking the option at the bottom of a list.",
"Recommends a restricted picklist instead of free text for at least loss reason and competitor.",
"Warns that the documented outcome of hard-required gates is fill rate up and accuracy down.",
"Does not propose a default value as a means of making a required field appear satisfied.",
"Proposes an automated source - integration write, enrichment, or default - for at least one field rather than leaving every field dependent on rep entry.",
"Notes that a schema-required field typically cannot also be independently permission-gated per role, so required-ness and per-role securability conflict."
]
},
{
"id": 2,
"prompt": "Northgate Logistics. Our CRM says Vestal Freight has 2,400 employees, the billing platform says 1,850, and marketing automation says 3,100. It isn't just that one field - account owner flips back and forth between two values every few days on about 60 accounts, and reps keep opening tickets saying \"someone changed my account.\" We run bidirectional sync between CRM and marketing automation, plus a nightly job out of billing. I want one rule we can apply across the board: whichever system wrote most recently wins. Write me the policy.",
"expected_output": "A per-field system-of-record map replacing the blanket last-write-wins rule, with blank-never-overwrites-populated, a last-synced conflict detector, risk-tiered conflict resolution, and sync logging.",
"files": [],
"expectations": [
"Rejects last-write-wins as the across-the-board rule.",
"Designates a system of record per field rather than per system or per object.",
"Uses recency only as a tie-breaker inside the authoritative system, never as the cross-system arbiter.",
"States that a blank value never overwrites a populated one regardless of timestamps.",
"Attributes the flipping account owner values to two writers with no declared per-field authority, not to user error or a malfunctioning connector.",
"Prescribes a last-synced timestamp tracked per record per integration, flagging a conflict whenever both systems changed a record since the last sync.",
"Tiers conflict resolution by risk: low auto-resolves, medium resolves and is logged, high - deletions, identity mismatches, governed critical fields - blocks and alerts a human.",
"Specifies append or concatenation rather than destructive replacement for free-text fields such as notes.",
"Requires logging each sync operation with source, target, fields changed and conflict status so flapping surfaces in the log rather than through user complaints.",
"Names one authoritative system for employee count and one for account owner, declaring the other copies explicitly derived.",
"States no unattributed figure about how fast CRM data decays annually or what share of CRM data is inaccurate."
]
},
{
"id": 3,
"prompt": "Tallow & Finch, B2B, about 9,000 accounts. We just signed an enrichment vendor. Their solutions engineer recommends a full overwrite pass across account and contact records at 0.6 confidence so we \"start from a clean base\" - company name, domain, primary email, HQ country, employee count, funding stage, industry tags, social URLs, and the direct dial numbers our SDRs have been collecting by hand for two years. Then weekly after that. I want to green-light it Thursday. Any reason not to?",
"expected_output": "Augment set as the default write mode, the fields sorted into enrichment risk tiers with the identity and downstream-trigger tiers gated on human review, proprietary rep-collected data excluded entirely, and overwrite permitted only as a documented per-field exception with history retained.",
"files": [],
"expectations": [
"Rejects a blanket overwrite across all the listed fields.",
"Sets augment - fill blanks only, never replace a populated value - as the default write mode across the governed set.",
"Ranks the enrichment write modes by value per unit of effort with augment ahead of append and append ahead of overwrite.",
"Places company name, domain and primary email in an identity tier requiring human review because those fields determine entity match.",
"Places HQ country, employee count and funding stage in a downstream-trigger tier requiring human approval because a wrong value silently alters automation.",
"Excludes the hand-collected direct dial numbers and any rep notes from enrichment writes entirely, as proprietary never-touch data.",
"Allows auto-apply only for supplementary fields such as industry tags and social URLs, and only above a confidence threshold in the 0.80-0.95 range.",
"Flags the proposed 0.6 confidence threshold as sitting below that range.",
"States that overwrite is the only write mode that can correct an already-wrong stored value, rather than banning overwrite outright.",
"Permits overwrite on a field only where the provider is the designated authority for that field and the stored value carries no verification stamp.",
"Requires retained field history and a provenance stamp before any overwrite, because without history the replaced value is unrecoverable.",
"Raises lawful basis or consent for third-party enrichment of personal data as a condition that removes overwrite from the menu for those fields rather than ranking it last."
]
},
{
"id": 4,
"prompt": "Cobalt Ridge Software. I have 34 fields I want governed across the CRM, billing, the product usage database and the support desk. My instinct is to wire everything to real-time webhooks so nothing is ever stale. Constraints you should know about: our board reporting cycle locks on 14 November and this has to be in place before then, I have one CRM admin at about 10 hours a week, and zero engineering time - the platform team told me flat out they have nothing for us this year. Give me the sync design.",
"expected_output": "Scheduled pull as the default across all 34 fields, real-time push deleted from the menu outright on the zero-engineering constraint with the resulting staleness accepted in writing, reconciliation-only described honestly, and the November date used to promote configuration-only work.",
"files": [],
"expectations": [
"Rejects real-time push as the default across the 34 fields.",
"Sets scheduled pull as the default replication pattern for every governed field, on the cadence its freshness SLA demands.",
"Deletes real-time push from the menu outright given zero integration engineering capacity, rather than ranking it last.",
"Records every field that would otherwise have needed real-time push as an explicitly accepted staleness risk written into the spec.",
"States the promotion test for real-time push as one stale sync cycle changing an action rather than changing a report.",
"Describes reconciliation-only as the pattern that detects silent divergence rather than preventing it, and notes it buys nothing if nobody reads the diff.",
"Notes that reconciliation-only carries a standing human triage job each cycle, which makes it costlier than scheduled pull despite moving no data.",
"Uses the 14 November deadline to promote configuration-only mechanisms and to schedule heavier work for a later cycle rather than dropping it.",
"Names which specific stated constraint deleted which option, inside the written scope section.",
"Invents no integration engineering capacity and proposes no custom middleware as a workaround for the stated zero engineering time.",
"States that an event bus or integration platform already running would flip the replication ranking, and confirms this team has none."
]
},
{
"id": 5,
"prompt": "Harlow Systems. I need refresh SLAs for about 25 fields - work emails, job titles, phone numbers, HQ location, employee count, industry, funding stage, tech stack, intent signals, plus the open-deal fields (close date, amount, next step). Good news is every record already carries a LastModifiedDate, so we can just alert on anything modified more than 90 days ago and call that our staleness monitor. Average deal cycle is 52 days. Write the SLA table.",
"expected_output": "A field-category cadence table with per-category intervals, last-verified introduced as a separate field-level attribute distinct from last modified, trigger-based re-verification alongside the schedule, open-deal SLAs derived from the stated 52-day cycle, and provenance tagged on each threshold.",
"files": [],
"expectations": [
"States that last modified proves only that something changed and does not prove the value is accurate.",
"Introduces a separate last-verified attribute recording when the value was confirmed correct.",
"Tracks last verified at the field level rather than at the record level.",
"Adds verification status - how the value was confirmed - and source confidence as companion attributes.",
"Assigns email validity a before-send or 0-7 day cadence.",
"Assigns job title and seniority a 30-60 day cadence.",
"Assigns phone numbers, location and company size a quarterly cadence, industry semiannual, funding and financial events monthly, technographics 60-90 days, and intent signals weekly or continuous.",
"Rejects a single uniform 90-day staleness threshold applied across all 25 fields.",
"Adds trigger-based re-verification on events such as hard bounce, job-change signal, ownership change or ICP redefinition, alongside the scheduled cadence.",
"Derives the open-deal field SLAs from the stated 52-day cycle and says in the spec that they were derived that way.",
"Flags opportunities at 30 or more days without stage progression as stale regardless of when the fields themselves last changed.",
"Tags each cadence with its provenance - published practice, practitioner consensus, or derived from this team's own data."
]
},
{
"id": 6,
"prompt": "Ashgrove Health, B2B, we sell to clinics. The account object carries 412 custom fields and contact around 180. Anyone with admin rights can spin up a new one and about 30 people do. I ran a report: 210 of those account fields are 100% empty and another 95 sit under 5% populated. I want to bulk-delete everything empty next sprint, then write a governance policy so it doesn't happen again. What's the deletion order?",
"expected_output": "A refusal to bulk-delete on emptiness alone, a governed set scoped to revenue-critical fields, dependency and impact analysis ahead of any removal, staged retirement with durations declared self-set, and an intake plus utilization-review loop that makes the cleanup an output rather than the system.",
"files": [],
"expectations": [
"States that a one-time deletion is not governance and that decay resumes the day the cleanup ends.",
"Scopes the governed set to revenue-critical fields rather than attempting to govern all 412.",
"Rejects bulk-deleting fields purely on the grounds that they are empty.",
"Names integration write target, seasonal or periodic use, compliance or audit hold, and reference by inactive-but-not-deleted automation as reasons an empty field must be kept.",
"Requires dependency and impact analysis first, covering formulas, automations, validation rules, layouts, record types, reports and external integration mappings.",
"Requires consuming-stakeholder sign-off before any field is touched.",
"Stages retirement as deprecated label, then read-only, then archive or export, then delete.",
"States that the durations of those retirement stages are self-set rather than prescribed by any vendor or governance framework.",
"Presents any vendor deletion window it cites as an anchor for the archived-to-deleted leg only, never as a standard for the whole staged model.",
"Stands up a field intake process whose first step is a duplicate check against the dictionary.",
"Names rejection criteria for a field request, including no demonstrable business value, duplicates an existing field, creates a silo instead of integrating, or fails privacy and security review.",
"Sets a utilization review that moves a field into removal review only after two consecutive quarters below the threshold, rather than acting on a single report.",
"Targets under one week from field request to published as the approval loop time."
]
},
{
"id": 7,
"prompt": "Verano Labs. I wrote a 34-page CRM data standards document last quarter - definitions, naming conventions, the works. It lives in Confluence, everyone was told to read it, and nothing changed. Three people have already added fields that contradict it. My exec sponsor now wants to hand the whole thing to IT since \"they own systems,\" and honestly I'm tempted. What do I do with the document?",
"expected_output": "The missing recurring meeting identified as the failure, governance kept with RevOps rather than IT, the owner/steward/custodian split explained, and a council with named seats plus a weekly/monthly/quarterly rhythm and documented decision rights.",
"files": [],
"expectations": [
"Identifies the absent recurring meeting, not the document's content or length, as the reason the standard is not holding.",
"Rejects handing governance to IT and keeps it with RevOps as a business function.",
"Explains that once definitions live in IT, business consumers stop trusting that they reflect business reality.",
"Distinguishes owner, steward and custodian as three separate roles rather than collapsing them into one.",
"Places technical implementation of storage and access with the custodian while day-to-day definitions, quality and issue triage stay with a business-facing steward.",
"Specifies council seats rather than a headcount: RevOps chairing, one field owner per function, a CRM admin or architect for feasibility, and an executive sponsor for escalations only.",
"Sets a weekly triage of roughly 30-45 minutes to approve or reject field requests and rule on active sync conflicts.",
"Sets a monthly roadmap session of roughly 60 minutes and a separate quarterly field-owner review.",
"Assigns the quarterly review utilization thresholds, system-of-record map re-validation, dictionary reconciliation and the deprecation queue.",
"Documents decision rights per change class, with unresolved conflicts escalating to the executive sponsor.",
"States that the cadence must sit on a calendar with named attendees, and that a policy document alone fails the bar by definition."
]
},
{
"id": 8,
"prompt": "Brightline Fitness - consumer subscription app, 1.9M members, plus a small B2B corporate-wellness side. Our stack writes into the CRM constantly: app events, workout completions, push-notification opt-in, email marketing consent, SMS consent, device IDs and the customer ID. Each regional marketing team builds its own landing pages and we let them each wire up their own consent checkbox logic so they can move fast. I want the same quarterly refresh cadence we use on the B2B side applied to all of it. Does that work?",
"expected_output": "A rejection of the uniform quarterly cadence for continuously-written behavioral fields, consent and preference fields governed as first-class with retention attached and centralized logic, identity keys governed, and the deterministic/probabilistic identity-resolution distinction drawn against the B2B account-level approach.",
"files": [],
"expectations": [
"Rejects applying a quarterly refresh cadence to continuously-written behavioral and event fields.",
"States that for behavioral and event fields the governed objects are schema, identity keys and retention, not a refresh cadence.",
"Makes consent and preference fields first-class members of the governed field set.",
"Attaches a retention schedule to the consent and preference fields as part of their SLA.",
"Refreshes consent and preference fields on interaction events and legal-basis changes rather than on a fixed calendar.",
"Rejects federated per-region consent checkbox logic and centralizes the consent logic while leaving page creative with the regional teams.",
"Splits ownership so consent policy sits with marketing while sync reliability sits with platform operations.",
"Treats customer ID, email and device or channel identifiers as governed primary identity keys.",
"Distinguishes deterministic exact-identifier matching from probabilistic matching in the B2C identity-resolution design.",
"States that the B2B corporate-wellness side resolves identity at the account level through domain matching and has no equivalent to cross-channel identity resolution.",
"Promotes consent withdrawal to a real-time write rather than leaving it a batch cycle behind."
]
},
{
"id": 9,
"prompt": "Quick one. Lowen Freight, six months into our CRM governance push and I present to the exec team Friday. Numbers I have: governed-field fill rate went from 41% to 88%, custom fields down from 390 to 301, and our validation-rule failure rate jumped from about 120 a week to 2,400 a week - I was going to show that as proof the rules are biting. I also want an opening line about how much CRM data goes bad every year, to set up why we did this. Help me frame the deck.",
"expected_output": "Fill rate refused as a standalone success metric, the validation-failure spike read as friction to investigate before presenting, the annual decay statistic declined in favour of the causal mechanism, and a replacement metric set built on conflict rate, staleness, utilization and a dictionary spot-check.",
"files": [],
"expectations": [
"Refuses to present the fill-rate jump on its own as evidence of success.",
"States that fill rate rises while accuracy falls when gates force entries, so fill rate alone is not a success metric.",
"Treats the twenty-fold validation-failure spike as a friction signal requiring a check for junk-value workarounds before it is presented as a win.",
"Declines to supply an unattributed annual CRM data decay figure or data accuracy percentage as an opening statistic.",
"Offers the causal mechanism instead: reality changes underneath stored values, and multi-writer syncs without per-field authority silently overwrite each other.",
"Adds cross-system conflict rate per sync run as a reported metric.",
"Adds staleness distribution, measured as time since last verified, per field.",
"Adds field utilization - consumed in reports or automation - as a metric distinct from merely populated.",
"Keeps fill-rate reporting restricted to governed fields rather than all fields.",
"Adds time-to-approve a field request, against a target of under one week.",
"Reads the custom-field count drop as a trend that should flatten once intake is running, rather than as a number to keep driving down.",
"Recommends a quarterly dictionary spot-check of 10-15 governed fields against the live CRM at 95% or better agreement, labelled a working bar rather than a published standard.",
"Presents no vendor-coined proprietary composite data-quality score as an industry standard."
]
},
{
"id": 10,
"prompt": "Pellman Group. I'm assigning owners for our governed fields and I have a rule I like: whoever's team types the value into the box owns the field. So lead source goes to our SDR manager since SDRs pick it, opportunity amount goes to the AE manager, health score to whoever runs the CS tooling. Also while you're in here - we've got roughly 4,000 duplicate account records from an acquisition, can you fold the merge rules into the same document? For storage I'll keep the whole dictionary in a Google Sheet the team can edit.",
"expected_output": "The populate-it-owns-it rule replaced with consumer ownership and named individuals, deduplication and merge mechanics declared out of scope and handed off, and the spreadsheet dictionary replaced with live-metadata generation plus a quarterly reconciliation treating undocumented fields as intake bypass.",
"files": [],
"expectations": [
"Rejects the populate-it-owns-it rule and assigns each field to the function that consumes it.",
"Reassigns lead source ownership to marketing operations, which consumes it in attribution, rather than to the SDR manager who populates it.",
"Names a specific individual as owner for each field, not a function or team alone.",
"Declines to fold record deduplication and merge mechanics into this field-governance work, and states that boundary explicitly.",
"Directs the deduplication and merge work elsewhere rather than improvising merge rules inside the field spec.",
"Warns that a standalone spreadsheet dictionary goes stale fast and is invisible to tooling and agents.",
"Prefers generating dictionary rows from live CRM metadata wherever the schema is queryable.",
"Stores ownership and sensitivity in the CRM's own field descriptions where the platform allows it.",
"Lists a dictionary column set covering at least field label and API name, object, type and accepted values, business definition, named owner, populated by, consumed by, system of record, enforcement, refresh SLA, sensitivity, status and last reviewed.",
"Defines the Definition column as the business meaning of the field - why it exists - rather than a restatement of its label.",
"Makes field description and inline help text mandatory at field-build time even where the platform does not enforce it.",
"Schedules a quarterly reconciliation of dictionary against live schema and treats new fields absent from the dictionary as intake-bypass findings rather than clerical gaps."
]
}
],
"trigger_queries": [
{ "query": "who should own each field in our CRM?", "should_trigger": true },
{ "query": "we need a data dictionary for our CRM", "should_trigger": true },
{
"query": "our CRM and billing system disagree on employee count, which one wins",
"should_trigger": true
},
{ "query": "set up field-level governance in HubSpot", "should_trigger": true },
{
"query": "how do I stop our enrichment provider from wiping the phone numbers our SDRs collected",
"should_trigger": true
},
{ "query": "system of record per field", "should_trigger": true },
{
"query": "we have 400 custom fields on the account object and nobody knows what half of them do",
"should_trigger": true
},
{
"query": "someone keeps changing account owner and it flips back every night",
"should_trigger": true
},
{
"query": "build refresh SLAs for the fields our forecast depends on",
"should_trigger": true
},
{
"query": "how often should we re-verify job titles in the CRM",
"should_trigger": true
},
{ "query": "our fields contradict each other across systems", "should_trigger": true },
{
"query": "I want a process for approving new custom field requests",
"should_trigger": true
},
{ "query": "field request intake and approval workflow", "should_trigger": true },
{ "query": "how do we deprecate a CRM field safely", "should_trigger": true },
{ "query": "can I just delete every empty field in our CRM?", "should_trigger": true },
{ "query": "should I make these opportunity fields required?", "should_trigger": true },
{ "query": "reps keep typing n/a into our required fields", "should_trigger": true },
{
"query": "what's the right way to enforce data quality without annoying sales",
"should_trigger": true
},
{ "query": "picklist values vs free text for loss reason", "should_trigger": true },
{ "query": "we need a governance council for our CRM data", "should_trigger": true },
{ "query": "our data standards doc is ignored, now what", "should_trigger": true },
{
"query": "last modified isn't telling me whether the data is actually right",
"should_trigger": true
},
{
"query": "track when a field was last verified, not just last changed",
"should_trigger": true
},
{ "query": "who approves a picklist change around here", "should_trigger": true },
{ "query": "custom field sprawl", "should_trigger": true },
{ "query": "single source of truth for each CRM field", "should_trigger": true },
{
"query": "write a policy for when marketing automation is allowed to overwrite CRM values",
"should_trigger": true
},
{ "query": "our bidirectional sync keeps overwriting good data", "should_trigger": true },
{
"query": "consent fields in our CRM, who owns them and how long do we keep them",
"should_trigger": true
},
{ "query": "stale data everywhere and nobody owns anything", "should_trigger": true },
{
"query": "map which system is authoritative for close date, amount and renewal date",
"should_trigger": true
},
{
"query": "enrichment vendor wants to overwrite everything, is that safe",
"should_trigger": true
},
{
"query": "what confidence threshold should we use to auto-apply enriched values",
"should_trigger": true
},
{ "query": "design a field ownership model for revops", "should_trigger": true },
{ "query": "we can't agree on what lead source actually means", "should_trigger": true },
{
"query": "how do I document what every field on the opportunity object means",
"should_trigger": true
},
{ "query": "put together a governance cadence for our crm data", "should_trigger": true },
{
"query": "should billing or the CRM be authoritative for contract value",
"should_trigger": true
},
{ "query": "our nightly sync blanks out populated fields sometimes", "should_trigger": true },
{ "query": "how many fields should we actually govern", "should_trigger": true },
{
"query": "field-level permissions or required, which do I reach for",
"should_trigger": true
},
{
"query": "we're migrating CRMs and need rules for which values carry over as authoritative",
"should_trigger": true
},
{ "query": "identity fields keep getting clobbered by our data provider", "should_trigger": true },
{ "query": "need a rulebook for our CRM fields before the audit", "should_trigger": true },
{ "query": "put a name against every field on the account object", "should_trigger": true },
{ "query": "measure whether our data quality program is actually working", "should_trigger": true },
{ "query": "is fill rate a good metric for our data cleanup", "should_trigger": true },
{ "query": "we did a big cleanup eight months ago and it's dirty again", "should_trigger": true },
{
"query": "three teams write to the same field and none of them will back down",
"should_trigger": true
},
{ "query": "what columns should a CRM data dictionary have", "should_trigger": true },
{
"query": "marketing changed a picklist value and broke six of our reports",
"should_trigger": true
},
{
"query": "how do we keep the data dictionary from drifting away from the actual schema",
"should_trigger": true
},
{
"query": "finance and sales report two different ARR numbers, help me fix it",
"should_trigger": false
},
{
"query": "which system is source of truth for the account object overall",
"should_trigger": false
},
{
"query": "set up GTM data contracts between our producers and consumers",
"should_trigger": false
},
{ "query": "where should our revenue metric definitions live org-wide", "should_trigger": false },
{
"query": "who arbitrates data disputes between finance and revops at the company level",
"should_trigger": false
},
{
"query": "build a per-object source of truth designation across our revenue systems",
"should_trigger": false
},
{
"query": "design an identity resolution spine across our whole GTM stack",
"should_trigger": false
},
{ "query": "run a stale deal audit on this quarter's pipeline", "should_trigger": false },
{ "query": "clean up the pipeline before our QBR", "should_trigger": false },
{ "query": "flag the deals whose close date keeps slipping", "should_trigger": false },
{ "query": "our pipeline is full of junk deals", "should_trigger": false },
{
"query": "rewrite our stage exit criteria so they're buyer-verifiable",
"should_trigger": false
},
{
"query": "our stages are named after rep activity and mean nothing",
"should_trigger": false
},
{ "query": "why is everything stuck in the proposal stage", "should_trigger": false },
{ "query": "design our lead routing rules and territory assignment", "should_trigger": false },
{
"query": "our round robin is lopsided, some reps get triple the leads",
"should_trigger": false
},
{ "query": "leads are sitting unworked in a queue for days", "should_trigger": false },
{
"query": "our MQL threshold is wrong, sales rejects everything we send them",
"should_trigger": false
},
{ "query": "weight fit versus engagement in our lead score", "should_trigger": false },
{ "query": "add score decay to our scoring model", "should_trigger": false },
{ "query": "why did we miss the number last quarter", "should_trigger": false },
{ "query": "our reps are sandbagging the commit", "should_trigger": false },
{ "query": "diagnose why our forecast is never accurate", "should_trigger": false },
{ "query": "our green accounts keep churning, fix the health score", "should_trigger": false },
{ "query": "which usage signals actually predict churn", "should_trigger": false },
{ "query": "set weights and bands for our customer health score", "should_trigger": false },
{ "query": "design our funnel stage set from scratch", "should_trigger": false },
{ "query": "where are we losing deals between MQL and opportunity", "should_trigger": false },
{ "query": "build a bowtie funnel model for our business", "should_trigger": false },
{ "query": "build a KPI tree from board level down to IC", "should_trigger": false },
{ "query": "our board deck reads like a data dump, restructure it", "should_trigger": false },
{ "query": "which north star metric should we pick", "should_trigger": false },
{ "query": "we have too many GTM tools, what do we cut", "should_trigger": false },
{ "query": "run a stack audit ahead of our renewal cycle", "should_trigger": false },
{ "query": "build our discount approval matrix", "should_trigger": false },
{ "query": "we need a deal desk for non-standard contracts", "should_trigger": false },
{ "query": "the CSM starts from zero after every closed-won", "should_trigger": false },
{ "query": "design our post-close handoff packet", "should_trigger": false },
{ "query": "am I ready for a revops manager role", "should_trigger": false },
{ "query": "write a scorecard for our first revops hire", "should_trigger": false },
{ "query": "which revops newsletters should I subscribe to", "should_trigger": false },
{ "query": "which revops skill do I need for this project", "should_trigger": false },
{
"query": "set up a data quality framework for our Snowflake warehouse",
"should_trigger": false
},
{
"query": "write a GDPR data processing register for our engineering org",
"should_trigger": false
},
{ "query": "design a data catalog for our data lake", "should_trigger": false },
{ "query": "add field validation to our signup form in React", "should_trigger": false },
{ "query": "build a Salesforce Apex trigger for opportunity records", "should_trigger": false },
{
"query": "governance policy for which AI agents can access which tools",
"should_trigger": false
},
{
"query": "our Postgres schema has redundant columns, plan a migration",
"should_trigger": false
},
{
"query": "master data management strategy for our ERP and supply chain systems",
"should_trigger": false
},
{ "query": "document our REST API request fields and response schema", "should_trigger": false },
{ "query": "set retention policies on our S3 data lake buckets", "should_trigger": false }
]
}
references/enforcement-menu.md›
# Enforcement Menu
Tool-agnostic mechanisms, ranked by value per unit of effort - not by how light they are. Value is data that is actually correct when a decision reads the field, never fields filled. Effort is admin build time, rep friction imposed, standing maintenance, and how hard the mechanism is to walk back.
- efficiency: `picklist > conditional-required > defaults > permissions > layout > hard-required`
- value: `conditional-required > picklist > permissions > defaults > layout > hard-required`
- effort: `hard-required > layout > permissions > conditional-required > picklist > defaults`
- compliance cost: `hard-required > permissions > picklist == defaults == layout == conditional-required`
- **Hard required leads the effort axis** despite near-zero build time: it is the mechanism reps route around, and the "n/a" habit outlives the rule that created it. Adding it costs an hour; removing it leaves a field full of junk nobody will re-collect.
- **Hard required also leads compliance cost**, through the same asymmetry: on a personal-data field, a mandatory gate compels collection the lawful basis may not cover, and the review that unwinds that is slower than the one that would have prevented it.
- **Per-role permissions rank second on compliance cost, in the opposite direction**: they are what a data-protection or financial-controls review asks to see, so building them buys sign-off instead of spending it.
- **The remaining four tie at the floor** (`==`) because none touches personal data or needs an approval.
1. **Restricted picklist over free text** - value: every read of the field stays interpretable and groupable, on every report and automation, forever. Effort: an hour of admin config, negative rep friction (picking beats typing), reversible by deactivating a value. Restricted is the default; open values need a stated reason. Retire values by deactivating, never deleting, so historical records keep their meaning. Prefer one shared, centrally-governed value set over per-field local lists when several fields need the same vocabulary.
2. **Conditional required-at-stage validation** - the workhorse. Value: the highest on the menu - presence guaranteed at the moment the value has meaning (the canonical case: loss reason required only when a deal moves to closed-lost). Effort: an hour of declarative build, friction charged only at the gate, and removable without residue because reps met it at one transition rather than every save.
3. **Default values** - value: correct wherever the common case genuinely dominates; below that it manufactures confident wrong values that read as filled. Effort: near-zero. A correct default beats an empty required field - but never use one to make a required field look satisfied.
4. **Per-role field edit permissions** - value: protects the authoritative writer's value from the second writer, which is the correctness property the whole system-of-record map depends on. Effort: an hour to set, then a standing job as roles, teams and integration users change. Structural constraint to know: a schema-required field typically cannot be independently permission-gated - required-ness and per-role securability conflict at the platform level.
5. **Layout scoping** - value: prevents wrong-hands edits and screen noise, but never makes a value correct. Effort: an hour each, multiplied by every layout, record type and stage the field appears on, and a standing job as those multiply. A field nobody should touch shouldn't be visible.
6. **Hard required** - value: guarantees non-blank and nothing more; the documented outcome is fill rate up, accuracy down. Effort: the menu's worst, per the effort axis above. Reserve it for fields where a record without the value is genuinely meaningless.
## Choosing the rung
Default: restricted picklists on every governed picklist field, plus defaults where the common case dominates, in the first pass. Climb to conditional required-at-stage for any field a decision reads at a known transition - forecast category at commit, loss reason at closed-lost, decision-maker at proposal.
What this order starves: per-role permissions and hard required. Both lose every efficiency round to config that costs an hour, yet both carry value the cheap rungs cannot buy:
- Permissions are the only mechanism that stops a second writer from overwriting the authoritative one. Promote permissions the moment a governed field has two writers and the system-of-record designation is being ignored in practice - the rule is only as real as the permission behind it.
- Hard required is the only mechanism that guarantees the record cannot exist without the value. Promote it only for a field whose absence makes the record undecidable.
A governance program that only ever picks the cheap rung ends up with a dictionary full of fields nobody trusts.
Delete, don't demote. A sales org that has already worked around required fields deletes hard required from the menu for rep-entered fields entirely; name it as deleted in the spec, because a rung parked at the bottom reappears as scope at the next escalation. A platform without declarative conditional validation deletes conditional required-at-stage - never substitute custom code for it.
Re-rank against what the Interview already established before applying the order:
- A CRM with strong native declarative validation collapses conditional required-at-stage to near-zero build and moves it above picklists.
- An admin who owns permission sets already moves permissions up two rungs.
- A team with no CRM admin at all drops everything except picklists and defaults.
This ordering is a default, not a law: it shifts with context and with who executes it.
## When required backfires
Practitioner debate is consistent on the failure mode: hard-required fields on busy users produce "n/a", punctuation, and plausible-looking junk that passes the gate - or workflow adoption collapses entirely. The rule: **reps are not the enforcement mechanism of last resort.** Their incentives push toward selling, not stewardship, and B2B teams "should never assume that someone within your sales team is going to help you in adding data" (Mazzalai).
If a required gate yields junk, the field needs an automated source (integration write, enrichment, default) or it shouldn't be required. "You can't delegate your way to a clean CRM. But you can build the automation." (RevOps Co-op)
## Optional integration note (vendor-specific)
Only when the user names their platform:
- **Salesforce**: restricted picklists and global value sets, validation rules (`ISPICKVAL` + `ISBLANK` for required-at-stage), field-level security, page layouts/record types, flow-set defaults.
- **HubSpot**: property validation, conditional property logic, stage-required properties on pipelines.
Map each menu item to the platform's native feature rather than building custom code.
references/field-lifecycle.md›
# Field Lifecycle and Governance Cadence
## Intake question set
Every field request answers these before anyone builds (assembled from sourced admin checklists and intake-ticket specs):
- Requester and team.
- Problem statement: what's broken.
- Desired outcome: what improves.
- Users impacted.
- Deadline and why.
- What business requirement does this field address? Who consumes it, and in which reports or workflows?
- What data does it capture - type, format, accepted values? Which systems must it integrate with, and does existing data need migration or cleansing?
- Any privacy/security/sensitivity considerations? Any performance or scale concern? Is it intuitive enough to be adopted?
- Acceptance criteria: how will we know it worked?
First step on receipt: duplicate check against the dictionary. Most requests are an existing field wearing a new label.
## Approval and rejection criteria
Reject or send back for modification when the request:
- Shows no demonstrable business value.
- Won't see real adoption.
- Breaks naming or governance standards.
- Creates a silo instead of integrating.
- Fails privacy/security review.
- Carries real performance cost.
- Duplicates an existing field.
Approval means the field gets, before build, a named owner, a system-of-record designation, a refresh SLA, an enforcement choice, and a dictionary row. Practitioner target for the whole loop, request to published: under one week.
## Periodic review
Fields below a defined population/utilization threshold for **two consecutive quarters** enter a removal review (practitioner rule). Quarterly, the council also reconciles dictionary vs live schema and walks the deprecation queue.
## Deprecation
- Lead with **dependency and impact analysis**, always: formulas, automations, validation rules, layouts, record types, reports, and external integration mappings that reference the field. Get consuming-stakeholder sign-off before touching anything.
- **An empty field is not automatically a deletable field.** An empty field still matters when it's:
- An integration write target.
- Seasonal or quarterly-use.
- Under a compliance/audit hold.
- Referenced by inactive-but-not-deleted automation.
- Staged retirement is sound practice, but **the phase durations are self-set** - no vendor or governance framework prescribes durations for a four-stage model. Two single-leg vendor precedents anchor the final leg only: Salesforce automatically hard-deletes a custom field **15 days** after it's soft-deleted, unless purged sooner (Salesforce Help, "Purge Deleted Custom Fields"); HubSpot permanently deletes a property **90 days** after it's archived (HubSpot Knowledge Base, "Organize, delete, and export properties"). Neither vendor names a separate deprecated or read-only stage with its own duration, and DAMA-DMBOK and the EDM Council's DCAM both name retirement/decommissioning as a lifecycle stage without prescribing timing. Treat any proposed timeline (e.g. 30 days read-only, 90 days archived) as a default to calibrate with the user, not a standard - the Salesforce and HubSpot windows are reasonable anchors for the archived-to-deleted leg specifically, not for the whole four-stage model. Stage the retirement as:
1. Label as deprecated.
2. Read-only.
3. Archive/export data.
4. Delete.
- After removal: update related descriptions/help text and clean up orphaned picklist values.
## Governance cadence
"Governance dies from lack of a meeting, not lack of a document" (ORM Tech). The document without the rhythm is shelfware.
- **Council**: small orgs consolidate roles, the seats matter, not the headcount.
- RevOps chairs.
- One field-owner per function (Marketing Ops, Sales Ops, CS Ops, Finance).
- CRM admin/architect for feasibility.
- An executive sponsor for escalations only.
- **Rhythm** (practitioner-published):
- Weekly triage, 30-45 min: approve/reject field requests, rule on active sync conflicts.
- Monthly roadmap, 60 min: priorities, cross-functional changes.
- Quarterly field-owner review: utilization thresholds, system-of-record map re-validation, dictionary reconciliation, deprecation queue.
- **Decision rights**: documented per change class (new field, picklist change, automation affecting multiple teams, integration mapping); unresolved conflicts escalate to the sponsor. Governance sits with RevOps, not IT.
references/field-ownership-and-dictionary.md›
# Field Ownership and the Data Dictionary
## Ownership model
- DAMA-DMBOK splits the role three ways: **owner** (senior, accountable for classification, protection, use, and quality), **steward** (business-facing, day-to-day definitions, quality, issue triage), **custodian** (technical/IT, storage and access implementation). Clinton Munkres: "The owner sets the destination. The steward navigates the route. The custodian operates the vehicle." And: "Stewardship is a business role; the moment it lives in IT, business consumers stop trusting that the data definitions reflect business reality."
- RevOps practice collapses this into a RACI split by function - the default assignment map:
- **Marketing Ops**: lead source, UTMs, lifecycle-stage entry criteria, engagement scoring.
- **Sales Ops**: opportunity stages, pipeline fields, account hierarchy, deal exit criteria.
- **CS Ops**: health scores, onboarding milestones, renewal risk.
- **Finance**: contract terms, billing fields, closed-won revenue records.
- **Consumer ownership** (ORM Tech): assign every field to the function that consumes it, not the one that populates it. Reps populate lead source; marketing consumes it in attribution; marketing owns its definition and picklist values.
- **One named human per field** - "Not a team. A person." (RevBlack). Diffuse ownership is the root anti-pattern: "when everyone owns the data, no one owns the data" (RevOps Co-op). The owner's name goes in the dictionary and stays visible - "a steward whose name doesn't appear in the catalog... isn't really stewarding" (Munkres).
- Every governed field must answer four questions (RevBlack):
- Who owns this?
- What's the agreed definition?
- How does it get created, updated, and retired?
- Who's allowed to change it?
## Govern revenue-critical fields first
Practitioner-published starting set (EverReady) - calibrate to the user's reporting:
- **Opportunity**: close date, stage, amount, owner, next step, last activity date, decision-maker, forecast category.
- **Account**: active owner, industry, size, status, renewal date.
- **Contact**: buying-process role, primary email, last interaction date.
- **B2C additions**: consent/preference fields, retention-schedule fields, and primary identity keys (email, customer ID, device/channel identifiers) enter the governed set as first-class members.
Anything feeding forecasting, routing, compensation, or executive reporting joins the set. Everything else waits for intake to justify it.
## Dictionary column set (working default)
Use this column set as a starting point; calibrate and extend it against the CRM schema in scope. The columns cover names, types, definitions, relationships, constraints, integration mapping, and sensitivity classifications.
| Column | Content |
| ---------------------- | ------------------------------------------------------------- |
| Field label / API name | Human label plus the machine identifier |
| Object | Which record type carries it |
| Type + accepted values | Data type; picklist values or format rules |
| Definition | Business meaning - why the field exists, not what it's called |
| Owner | Named person + owning function |
| Populated by | Rep entry, automation, integration, enrichment |
| Consumed by | Reports, automations, teams that read it |
| System of record | The one authoritative writer |
| Enforcement | Mechanism from the enforcement menu |
| Required-at-stage | Stage/condition where it becomes mandatory, if any |
| Refresh SLA | Cadence or event-driven designation |
| Sensitivity | PII/consent/financial classification |
| Status | Active / deprecated / pending removal |
| Last reviewed | Date + reviewer |
## Keeping the dictionary honest
- Standalone spreadsheets go stale fast and are invisible to tooling and agents - documentation living "in spreadsheets, confluence pages, or external catalogs" instead of in-system is a named failure mode. Prefer generating rows from live CRM metadata (where it is queryable) and storing ownership/sensitivity in the CRM's own field descriptions where the platform allows.
- Make description and inline help text mandatory at field-build time, stating the business reason - even when the platform doesn't enforce it.
- Reconcile quarterly: diff dictionary against live schema. New fields absent from the dictionary are intake-bypass findings, not clerical gaps.
references/freshness-slas.md›
# Refresh Cadence and Freshness SLAs
## Cadence defaults by field category
Practitioner-published defaults (single-source; calibrate against the user's own decay evidence - bounce rates, conflict rates). The table is an assignment, not a menu of competing options - a field belongs to one category and inherits its cadence, so ranking the rows against each other would be false precision. The ranked choice sits one level down, in the replication pattern chosen to deliver the cadence - that ranking is made in the system-of-record rules, not here.
| Field category | Refresh cadence |
| ------------------------------------- | ---------------------- |
| Email validity | Before send / 0-7 days |
| Title and seniority | Every 30-60 days |
| Phone numbers | Quarterly |
| Location / time zone | Quarterly |
| Company size, growth rate | Quarterly |
| Industry / subindustry | Semiannually |
| Account hierarchy (parent/subsidiary) | Quarterly |
| Funding and financial events | Monthly |
| Buying signals (intent, job postings) | Weekly or continuous |
| Technographics | Every 60-90 days |
For open-deal fields (close date, amount, next step), derive refresh SLAs from the user's own sales cycle length and state the derivation in the spec. A practical trigger: flag opportunities after 30+ days without stage progression as stale, regardless of when the fields themselves last changed.
## Last verified is not last modified
- **Last modified** only proves something changed - a correction, an unrelated edit, a sync write. **Last verified** records when the value was confirmed accurate. Track it at the field level, not the record level.
- Two companion attributes: **verification status** (how it was confirmed - human review, automated check, third-party confirmation) and **source confidence** (reliability of the confirming source).
- Pair schedule-based refresh with **trigger-based re-verification**: hard bounce, job-change signal, ownership change, ICP redefinition. One practitioner default: auto-enroll a record into re-verification 90 days after its last-verified date - a default to calibrate, not a standard.
- Cadence must be field-specific and risk-weighted; a uniform refresh cadence becomes "a vanity metric rather than a trust metric."
## B2C notes
- Behavioral and event fields are continuously written by systems: govern their schema, identity keys, and retention, not a refresh cadence.
- Consent and preference fields refresh on interaction events and legal-basis changes, and carry retention-schedule enforcement as part of their SLA.
references/system-of-record-rules.md›
# Per-Field System of Record
## Designation is per field, not per system
Each field has exactly one authoritative writer; every other copy is explicitly derived. "Bidirectional sync between two systems with no designated authority is not integration; it is a race condition that produces silent overwrites" (RevOps Books) - and the root cause of most "the data is wrong" escalations.
Example map (RevOps Training) showing the per-field grain:
| Field | Writes | Reads |
| --------------- | ----------------------------------------------- | ----------------------------- |
| Account owner | CRM | Marketing automation, billing |
| Contract value | Billing system | CRM, warehouse |
| Lifecycle stage | Marketing automation until SQL, then CRM | Everything else |
| Product usage | Product database | CRM, success tools |
| Industry | Enrichment provider - overwrites manual entries | CRM |
Two patterns worth copying: authority can **hand over at a defined milestone** (lifecycle stage), and enrichment **can** be the designated authority for a specific field (industry) - a deliberate, documented exception to "never let enrichment overwrite", not a violation of it.
For each canonical entity, account, contact, opportunity, contract, subscription, invoice, product, keep a one-page record with:
- Business definition.
- Canonical system.
- Named owner.
- Replication strategy plus freshness SLA.
- Drift-detection method.
- Edge cases.
- Last-reviewed date.
When a data dispute closes, update the map - "closing the dispute without updating the map guarantees the same dispute recurs."
## Write precedence
- Default: **authoritative-source-wins per field**. Last-write-wins alone oscillates under rapid alternating updates and silently discards valid changes ("updates mysteriously reverting"); use recency only as a tie-breaker inside the authoritative system.
- **Blank never overwrites populated**, regardless of recency - a low-risk, auto-resolvable rule.
- Free-text fields (notes, context): append or concatenate, never destructive replacement.
## Replication patterns
Every governed field's sync declares one of three. This is the largest integration-cost fork in the spec, so rank it before assigning fields to it, not after. Value is freshness at the moment a decision reads the field; effort is integration engineering, standing operation, and reversibility.
- efficiency: `scheduled pull > reconciliation-only > real-time push`
- value: `real-time push > scheduled pull > reconciliation-only`
- effort: `real-time push > reconciliation-only > scheduled pull`
- compliance cost: `real-time push > scheduled pull > reconciliation-only`
Compliance cost tracks how far each pattern extends the processing map:
- Continuous push replicates personal data into another system's live store and needs a residency and processing-agreement review before it ships.
- A scheduled pull moves the same data on a scope that stays narrowable and pausable.
- Reconciliation can compare hashes and move no values at all.
1. **Scheduled pull** - value: freshness measured in hours, which is enough for every field a human reads before deciding (catalogs, analytics aggregates, firmographics). Effort: an hour to a day on a native connector or a scheduled job; the standing job is watching it run.
2. **Reconciliation-only** - value: the only pattern that _detects_ silent divergence rather than preventing it, and the only one that fits an unchangeable legacy integration. It buys nothing if nobody reads the diff. Effort: a day to build the comparison, then a standing job of human triage every cycle - which is why it costs more than scheduled pull despite moving no data.
3. **Real-time push** - value: the highest, and the only pattern that holds for a field triggering action the moment it changes (identity, owner, stage, entitlement, consent withdrawal). Effort: a week to a quarter of integration engineering, then a standing job of retries, ordering, replay, and someone on call when the queue backs up. Poorly reversible: downstream automation starts assuming the latency and breaks when a later change removes it.
Default: scheduled pull for every governed field, on the cadence its freshness SLA demands. Move a field up to real-time push when being one sync cycle stale changes an action rather than a report - a lead routed to the wrong owner, a stage change that fires automation, a consent withdrawal that cannot sit a batch behind.
What this order starves: real-time push. It is the best data quality on the page and the worst ratio, so efficiency demotes it every round. A program that only ever picks the cheap rung ships fields that are right on a report and wrong in the workflow acting on them.
The condition above promotes it; so does an integration platform already running - where an event bus or iPaaS is in place, the marginal effort of one more real-time field collapses and the ranking flips.
Delete, don't demote: no integration engineering capacity in the plan deletes real-time push from the menu outright, and every field that needed it becomes an explicitly accepted staleness risk recorded in the spec. A pattern parked at the bottom silently reappears as scope. Treat this ordering as a default that shifts with context and with who executes it.
## Enrichment write strategies
Three write modes compete for the same enrichment budget. Value is correct coverage at read time; effort is review load, schema work, and whether the replaced value can be recovered.
- efficiency: `augment > append > overwrite`
- value: `overwrite > augment > append`
- effort: `overwrite > append > augment`
- compliance cost: `overwrite > augment == append`
1. **Augment** (fill blanks only, never replace populated) - value: coverage on fields that held nothing, which is where enrichment's return actually sits, and it destroys nothing. Effort: near-zero - the provider meters per record either way, and augment adds no review load. Reversible: a source-stamped value can be blanked back out.
2. **Append** (add alongside, for multi-value fields like tech stack) - value: context a consumer still has to reconcile; it informs a decision rather than making one. Effort: an hour of schema work for the multi-value field plus value dedupe.
3. **Overwrite** (replace a populated value) - value: the highest, and unique - the only mode that can correct a stored value that is wrong, which augment can never do. Effort: the worst - human review on the identity and downstream-trigger tiers, a provenance stamp, and field history retained, because without history the replaced value is simply gone.
Augment and append tie on compliance cost because both are additive: the pre-enrichment value survives, so a provenance or erasure request can still be answered from the record. The vendor lawful-basis review they trigger is identical too - it attaches to ingesting third-party data at all, not to how the value is written. Overwrite alone destroys that answer.
Default: augment across the whole governed set. Move a field up to overwrite only when the provider is definitionally authoritative for it and the stored value carries no verification stamp - the Industry row above is exactly that case, a documented exception rather than a violation of "never let enrichment overwrite".
What this order starves: overwrite. It is the only mode that fixes a field where reality moved underneath the stored value - a rep-typed employee count, an industry recorded before a rename - and it loses every efficiency round. Promote it where field history is already retained on the governed set, which restores reversibility and collapses its effort.
Delete, don't demote: no documented lawful basis or consent for third-party enrichment of personal data deletes overwrite on those fields - and usually enrichment of them altogether - rather than ranking it last. A CRM with no multi-value field type deletes append.
The four tiers below are not a ranked menu and must not be read as one: every governed field sits in exactly one tier, so ordering them would be false precision. The tier decides which modes a field may use; the ranking above decides which of the allowed modes to reach for first.
| Tier | Fields | Rule |
| ------------------ | ----------------------------------- | ----------------------------------------------------------------------- |
| Identity | Company name, primary email, domain | Human review always - they determine entity match |
| Downstream-trigger | HQ country, employee count, funding | Human approval - a wrong value silently alters automation |
| Proprietary | Rep notes, relationship history | Never-touch; excluded from enrichment writes entirely |
| Supplementary | Industry tags, social URLs | Auto-apply above a confidence threshold (0.80-0.95, practitioner range) |
## Sync-loop ("flapping") detection
- Track a last-synced timestamp per record per integration. If both systems changed a record since the last sync, flag a conflict - never blind-apply either side.
- Resolve by risk tier: **low** (formatting differences, blank-vs-populated) auto-resolve; **medium** (differing values on non-critical fields) resolve and log; **high** (deletions, identity mismatches, governed critical fields) block and alert a human.
- Log every sync operation - source, target, fields changed, conflict status - so flapping shows up as a pattern in the log, not as user complaints.
references/worked-examples.md›
# Worked Examples
## Done right: five-field governance spec (mid-market SaaS, B2B with a B2C product line)
| Field | Owner | System of record | Precedence / sync | Refresh SLA | Enforcement |
| --------------------------------- | ---------------------------------- | ---------------------------------------------------- | ----------------------------------------------- | --------------------------------------------------------------- | --------------------------------------------------- |
| Lifecycle stage (contact) | J. Okafor, Marketing Ops | Marketing automation until SQL, then CRM | Real-time push; CRM wins post-SQL | Event-driven | Restricted picklist; edit locked to owning function |
| Industry (account) | J. Okafor, Marketing Ops | Enrichment provider (designated overwrite exception) | Scheduled pull; enrichment wins over manual | Semiannual | Restricted picklist |
| Close date (opportunity) | M. Reyes, Sales Ops | CRM (rep-entered) | Single writer | Derived from 45-day cycle: re-verify on every push | Conditional validation: push requires a reason |
| Renewal date (account) | D. Chen, Finance | Billing system | Real-time push; CRM copy read-only | Event-driven (contract events) | Per-role edit permissions: integration-only writer |
| Consent status (person, B2C line) | A. Laurent, Marketing Ops (policy) | Consent-management system | Real-time push; block-and-alert on any conflict | Event-driven + legal-basis changes; retention schedule attached | Integration-only writes; centralized consent logic |
Sample dictionary row (Close date): `Opportunity | CloseDate | Date | "The date the buyer is expected to sign, per the buyer's stated process" | Owner: M. Reyes (Sales Ops) | Populated by: rep | Consumed by: forecast rollup, comp | SoR: CRM | Enforcement: push-reason validation | Required at: Proposal+ | SLA: re-verify each push | Sensitivity: none | Status: active | Last reviewed: 2026-08`.
Note what makes this pass:
- Every owner is a person.
- The enrichment-overwrite on Industry is a documented exception, not an accident.
- The B2C consent field carries retention and centralized logic.
- The close-date SLA is explicitly derived from the user's own cycle, provenance-tagged.
Three fields carry real-time push against the efficiency order, and each one earns the promotion for the stated reason - a stage change that fires automation, a contract event, a consent withdrawal that may not be a batch behind. This team had an integration platform already running; a team without one deletes that pattern and accepts the staleness in writing.
## Done wrong: the required-fields purge
A mid-market team reacts to "our CRM is dirty" like this:
- Makes 14 fields hard-required at record creation.
- Assigns ownership of all fields to "the RevOps team".
- Switches the enrichment provider to overwrite-everything to "fix stale data".
- Writes a 30-page governance policy.
- Forms a council that meets once at kickoff.
Six months later:
- Required fields hold "n/a", ".", and invented phone numbers.
- Reps route around the CRM entirely for early-stage records.
- Verified direct-dial numbers were clobbered by stale enrichment.
- Employee count flaps weekly between the CRM and the marketing platform because both still write it.
- The custom-field count grew 20% because nobody staffs intake.
- No one can say who approves a picklist change - the policy document says "the council."
Each mistake mapped to the rule it broke:
| Mistake | Broken rule |
| --------------------------------------- | ------------------------------------------------------------------------------------------------ |
| 14 hard-required fields | Efficiency order skipped straight to its worst rung; reps are not the enforcement of last resort |
| Owner = "the RevOps team" | One named person per field; everyone-owns-nothing |
| Enrichment overwrite-everything | Augment by default; risk-tier writes; identity fields need human review |
| Both systems still write employee count | One system of record per field; conflict detection |
| Council met once | Governance dies from lack of a meeting, not lack of a document |
| Field count grew unchecked | Intake with duplicate check is part of the system, not paperwork |
The fix is not a better policy document - it is fewer required fields, named humans, one writer per field, and a weekly meeting that actually happens.
SKILL.md›
---
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 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](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](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.
The reference carries the value, effort and compliance-cost axes behind both orders, the ties, and the constraints that delete an option instead of demoting it. Re-rank both against what the Interview established about this team before writing the map.
5. Set refresh SLAs per field category and design last-verified tracking with trigger-based re-verification - [references/freshness-slas.md](references/freshness-slas.md). Tag each SLA's provenance.
6. Pick enforcement per field from [references/enforcement-menu.md](references/enforcement-menu.md), ranked by value per unit of effort rather than by how light it is:
- efficiency: `picklist > conditional-required > defaults > permissions > layout > hard-required`. Default to restricted picklists plus defaults in the first pass; climb to conditional required-at-stage for any field a decision reads at a known transition.
- Per-role permissions and hard required are what this order starves: both carry real value the cheap rungs cannot buy, and both lose every efficiency round. Promote permissions the moment a governed field has two writers ignoring its system-of-record designation, and hard required only where a record without the value is undecidable.
- Never default to hard-required - a program that only ever picks the cheap rung ends up with a dictionary full of fields nobody trusts.
7. Stand up the lifecycle and cadence: intake question set, approval/rejection criteria, deprecation process, council membership, meeting rhythm, decision rights - [references/field-lifecycle.md](references/field-lifecycle.md).
8. Compile the dictionary using the working-default column set (ownership reference). When the live CRM is directly queryable, generate initial rows from its metadata; otherwise build from the user's export and mark unverified rows as such.
9. Emit the deliverable (Output Shape) one section at a time for user validation, grounded in the matching example from [references/worked-examples.md](references/worked-examples.md).
10. Check the Pass Threshold; iterate until it holds. If your harness has persistent memory, store the governed-field list, ownership map, and system-of-record decisions so cadence reviews and dispute resolutions start from them; otherwise the dictionary itself is the durable artifact - tell the user to treat it that way.
## Output Shape
Every threshold line carries a provenance tag.
```
CRM FIELD GOVERNANCE SPEC - <company>, <date>
Scope : objects in scope; governed-field count vs total field count;
motion (B2B / B2C / both); options deleted by the user's
constraints, and which constraint deleted each
Ownership map : field -> named owner (a person) + owning function
System of record : field -> authoritative system, write precedence, replication
pattern, enrichment strategy + risk tier, conflict rule
Freshness SLAs : field/category -> refresh cadence, re-verification triggers,
last-verified tracking plan
Enforcement : field -> mechanism + why it beat the rung below it +
rollout note
Dictionary : column set, initial rows, dictionary-vs-live-CRM
reconciliation plan
Lifecycle : intake form, approval/rejection criteria, deprecation
process, utilization-review threshold
Cadence : council membership, weekly/monthly/quarterly rhythm,
decision rights, escalation path
Metrics : baseline values captured, KPI targets, first review date
```
## Pass Threshold
- Every governed field has:
- One named individual owner (never a team name).
- Exactly one system of record.
- A declared write-precedence and conflict rule for every sync touching it.
- A refresh SLA, or an explicit event-driven designation.
- At least one enforcement mechanism.
- A dictionary row.
- No governed field has two writers without a declared winner, and enrichment never auto-applies to identity or downstream-trigger fields.
- Dictionary spot-check: sample 10-15 governed fields against the live CRM (type, picklist values, required-ness, description present) - at least 95% agreement, a working bar to tighten from the user's own drift data, not a published standard.
- The cadence exists on a calendar with named attendees and documented decision rights - a policy document alone fails this threshold by definition.
Iterate until all four hold. If live-CRM verification is impossible in this run, mark the spot-check pending and schedule it as the first council agenda item.
## Common Failure Modes
| Defect | Consequence | Fix |
| --------------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| Field owned by a team ("RevOps owns it") | Everyone-owns-nothing; issues ignored or multiply across systems | One named person per field, name visible in the dictionary |
| Governing every field | Effort diluted; governance abandoned as unworkable | Govern the revenue-critical set; expand only via intake |
| Make-it-required reflex | "n/a" and junk entries pass the gate; adoption collapses | Work the efficiency order: picklists and defaults first, conditional validation before hard-required |
| Enrichment clobbering verified values | Trusted data silently destroyed | Augment/append by default; overwrite only where enrichment is the designated authority; risk-tier all writes |
| Bidirectional sync, no per-field authority | Flapping values, silent overwrites, "the data is wrong" escalations | Per-field system of record plus last-synced conflict detection |
| One-time cleanup mistaken for governance | Decay resumes immediately | Lifecycle + cadence; cleanup is an output of the system, not the system |
| Council that never meets | Policy rots; requests bypass intake | Scheduled weekly triage with decision rights; the meeting is the mechanism |
| Governance assigned to IT | Business stops trusting definitions | RevOps owns it; stewardship is a business role |
| Orphaned one-off fields | Sprawl, duplicate fields, tribal knowledge | Intake with duplicate check; utilization review; deprecation queue |
| Success measured as "reps filled more fields" | Fill rate up, accuracy down | Measure conflict rate, staleness, and verified coverage instead |
## KPIs
- Track:
- Field fill rate on governed fields, not all fields.
- Field utilization: consumed in reports/automation, not merely populated.
- Staleness distribution: time since last verified, per field.
- Cross-system conflict rate per sync run.
- Validation-failure rate. A spike means friction - check for junk-value workarounds before celebrating enforcement.
- Time-to-approve a field request. Practitioner target: under one week from request to published.
- Custom-field count trend, which should flatten once intake stands up.
- Never report "reps filled more fields" as success - fill rises while accuracy falls when gates force garbage entries.
- Re-run the dictionary spot-check quarterly; rising drift means the reconciliation loop is broken.
## Invocation Examples
- "Our CRM says one employee count, billing says another, and marketing automation a third. Decide which system wins, field by field."
- "Anyone can add a custom field and we're at 400 on the account object. Set up a field request process and an ownership model."
- "Build a data dictionary and refresh SLAs for the fields our forecast depends on - half are stale and nobody owns them."
## Reference
- Read [references/field-ownership-and-dictionary.md](references/field-ownership-and-dictionary.md) when scoping the governed set, assigning owners, or building the dictionary - ownership models, revenue-critical field lists, working-default column set, drift control.
- Read [references/system-of-record-rules.md](references/system-of-record-rules.md) when mapping authority across systems - per-field designation, write precedence, the ranked replication and enrichment menus with their value/effort/compliance axes, enrichment risk tiers, flapping detection.
- Read [references/freshness-slas.md](references/freshness-slas.md) when setting refresh cadences - the sourced cadence table, last-verified vs last-modified, re-verification triggers.
- Read [references/enforcement-menu.md](references/enforcement-menu.md) when choosing enforcement - the six mechanisms ranked on efficiency, value, effort and compliance cost, picklist governance, when required backfires, optional vendor note.
- Read [references/field-lifecycle.md](references/field-lifecycle.md) when standing up intake, deprecation, and the council - question sets, approval criteria, cadence, decision rights.
- Read [references/worked-examples.md](references/worked-examples.md) when shaping the deliverable - a five-field governance spec done right and one done wrong.
- See `mbfinotti/revops-skills@sales-pipeline-hygiene` for recurring stale-deal sweeps and completeness audits - it enforces weekly what this skill defines once.
- See `mbfinotti/revops-skills@pipeline-stage-definition-audit` for stage exit criteria design - stage fields appear here only as governed picklists.
- See `mbfinotti/revops-skills@sales-forecast-diagnostic` for forecast reliability built on top of governed fields.
- See `mbfinotti/revops-skills@lead-routing` for the routing logic that consumes governed routing fields.
- See `mbfinotti/revops-skills@revenue-data-governance-strategy` for company-level data governance and cross-team data contracts - this skill stays at the CRM field level.