Data governance arrives in a mid-market company as a document. Someone writes a policy about ownership, quality and access, it is approved, and the data carries on exactly as before, because a policy does not stop a rep saving a lead without a company name. The enterprise frameworks that rank for the term are built for a data office that a 200-person company does not have and should not hire.
The version that works at this size is five rules, each one a setting in the systems rather than a sentence in a document, and the reason to do them now is that an agent is about to act on the records. We wrote earlier about how to tell what shape your CRM data is in; that is the measurement. This is the set of rules that keeps the measurement good.
A quarterly cleanup corrects data at the pace a person can review it. An agent reads and writes records at the pace of the queue, and it acts on what it reads. A duplicate account is an annoyance for a rep and a wrong decision for an agent. A lead with no industry is a gap in a report for a person and a record the agent fills in from a guess. A record the company should have deleted is invisible to most people and fully visible to an agent reading the account's history.
So the rules have to be enforced where the records are, so that the data arriving at the agent already obeys them. A rule in a document is a rule the agent never sees.
Not a person, a role, because people leave. Every module that an agent will read has a field that names the role accountable for its records being right, and the role has a person in it. For the customer record, which every agent reads first, the owner question is the one we worked through in which system owns the customer, and it has to be settled across systems, not just inside the CRM.
The enforcement: the owner field is required, and a report of records whose owner role is vacant runs weekly.
Decide which fields on each record the agent will reason from, and make them required at creation, enforced by the module's validation, not by a reminder. If the agent qualifies leads on industry, size and role, those three cannot be blank on a saved lead. The rep who does not know the industry picks unknown, which is a value, not a blank, and the agent treats unknown as a reason to ask rather than a reason to guess.
The enforcement: validation rules on the module, applied to every door, form, import, connection and hand entry alike.
A merge is what you do after the duplicate has already caused the damage. The rule is that the system refuses the second copy at creation, on a key the company has chosen, email domain plus company name for accounts, email for contacts, and that the key is checked at every door. Zoho CRM has the settings for this, and most estates have never turned them on for imports and integrations, which is where the duplicates come from.
The enforcement: unique fields and duplicate checks on each module, with the import and integration paths included.
The customer's address, the product's price, the invoice's status: each one has exactly one system that may write it, and the others receive it. An agent that can write the same fact in two systems will, and the two will disagree by the end of the week. This is the write rule we set out in the piece on system of record versus source of truth, and for an agent it is enforced by the agent's identity having write access to a fact in one system only.
The enforcement: the agent's profile, and the integration's direction, set so that each fact flows one way.
What the company keeps, for how long, and who may see it, are decisions a company has usually made for people and never applied to an agent. An agent reading an account's full history reads the records that should have been purged, the notes that were meant for one person, and the fields that only a profile with finance access was meant to see. Its reach is its identity's reach, so the rule is applied by giving the agent an identity whose profile sees only what its job needs, and by making the retention rule a scheduled deletion rather than an intention.
The enforcement: a dedicated profile per agent, and retention as a scheduled job with a log.
None of this means the document is useless. It records the decisions: who owns which record, which fields matter, what the duplicate key is, which system writes which fact, what the agent may see. The mistake is treating the document as the enforcement. The document is the design, written once and read by the people who set the settings; the settings are the governance, applied every time a record is saved. A company that has the document and not the settings has governance on paper, which an agent cannot read.
The useful test of a governance document, then, is whether every sentence in it points at a setting. If a sentence cannot be made into a validation rule, a unique field, a profile or a scheduled job, it is a hope, and it should be rewritten until it is one of those four or removed.
A record arriving at an agent that has an accountable owner, the fields the agent needs filled with values rather than blanks, no twin, one system allowed to write each fact in it, and only the parts the agent's job needs visible. That is the whole of data governance a mid-market company needs before its first agent, and all five are settings an administrator can make in a week, once the decisions behind them are made.
The decisions are the work. Who owns the account record. Which fields the agent reasons from. What the duplicate key is. Which system writes the price. What the agent may see. We built the broader AI readiness assessment for a Zoho estate around exactly these questions, because the companies whose AI projects fail are the ones that skipped them.
Pick the one module the first agent will read, usually Leads or Accounts, and check it against the five rules as settings, not as intentions. Most estates pass one of the five, usually ownership, and have the other four as policies. Fix the four in that module before the agent is built, then repeat for the next module the agent needs.
Discovery is no-risk: we check the five rules against the modules your first agent would touch, show you which are settings and which are sentences, and you pay only if you go ahead.
The AI Readiness Review is a 90-minute working session plus a written scorecard across data hygiene, documented process, permissions and ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
What Happens To A Lead At 6pm On Friday | Zoho CRM Assignment Rules And Routing (video)
How Many Layouts Is Too Many | Zoho CRM Page Layouts And Layout Rules (video)
Where Bad Data Gets In (video)
The AI Readiness Review is a 90-minute working session plus a written scorecard across data hygiene, documented process, permissions and ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
