The first thing we export on a RevOps engagement is not the pipeline. It is the field list. Sort it by fill rate and the same shape appears every time: three to four hundred custom fields, forty filled on more than half the records, and about a dozen that anything downstream actually reads. Nobody decided that. It accreted, one urgent Tuesday at a time, and it is now the thing quietly breaking every dashboard in the company.
A schema is what your CRM has. A data model is something a team writes down on purpose, and most companies have never written one.
A data model is four decisions. Most teams have made none of them.
Say data model and people picture an entity-relationship diagram nobody will open twice. In practice it is four sentences per object, kept somewhere a new ops hire can read them on day one.
- Grain. What does one row mean, exactly? An account is a legal entity, a root domain, a buying group, or a billing relationship — and it is exactly one of those, everywhere, forever.
- Identity. Which key survives a rename, a merger, a rebrand, a person changing jobs? Company name is not a key. Email is a key with an expiry date. Choose keys the outside world also agrees on.
- Ownership. Who may write this field? Exactly one writer: a human, an enrichment source, or an agent. Not two, not "whoever is most recent".
- Lifecycle. What creates the value, and what kills it? Every field needs a birth condition and a death condition, or it will live forever at 4% fill.
Four sentences per object. Most companies cannot produce them, which is precisely why their reporting disagrees with itself and why the answer to how many accounts do we have depends on who is asked.
Fields are cheap to create and impossible to kill. That asymmetry is the entire reason your CRM looks the way it does.
The account object breaks first.
Ask five people in the same company what an account is. You will get the domain, the legal entity, the parent group, the subsidiary that signs, and the logo on the slide. Each answer is defensible, which is the problem: marketing counts domains, sales counts opportunities, finance counts billing entities, and the three numbers on the board deck were never going to reconcile.
Root domain is usually the right grain, because it is the only key the outside world agrees on — enrichment vendors, ad platforms and your own web analytics all speak it natively. Then hold hierarchy explicitly rather than by convention: a parent field, populated by enrichment, never by hand. And no human types a company name into a create form. Ever. Free-text company creation is how Société Générale, Societe Generale, SocGen and SG end up as four accounts in the same funnel, three of them with pipeline on them.
One writer per field
The most common data pathology we find is not missing data. It is two systems fighting. Enrichment overwrites the rep's research on Monday; the rep overwrites it back on Tuesday; the agent, reading whatever it finds, writes a third value on Wednesday and cites it in an email on Thursday. Nobody is wrong and the field is now noise.
If two systems can write a field, its value is a rumour. So every field gets one owner and a source stamp recorded on write. When human research must beat enrichment, that is a rule the writer enforces — not a race decided by who ran last.
Computed fields do not belong in the CRM. Their output does.
Score, tier, segment, ICP fit, propensity: these are not properties of the account. They are the output of a model, and models change. Keeping the formula in the CRM means yesterday's score cannot be explained and last quarter's cannot be reproduced. Keep the logic in the action layer, write the result into the CRM, and stamp it with the version of the model that produced it. Nobody edits a score by hand; you change the model and recompute. This is the same demotion we describe in the CRM is not the system — applied one field at a time.
# The contract behind one field. field: account.tier grain: account = root domain writer: scoring_service # exactly one source: icp_model v4.2 # stamped on every write born: enrichment complete dies: model rewrite → recomputed, never hand-edited
Thirty of these in a document is a data model. It takes a fortnight to write and it outlives three CRMs.
You can predict how a company will scale by asking what an account means. If the answer takes more than one sentence, the reporting is already wrong — it just has not reached a board deck yet.
Hugo Renault · Founding Partner, Mercator AI
The best migration starts with deletions.
Nobody has the appetite for a re-platforming, and nobody needs one. The first pass is subtraction: archive every field under 5% fill that no report, no automation and no integration references. Half the schema usually goes. Archiving is not deleting — the data stays, the field leaves the interface — which is exactly why it is the right first move: it is reversible, and it is the only intervention that makes the second pass affordable.
Then write the contract for the thirty fields that survive. Grain, writer, source, birth, death. The document takes two weeks and one person, no migration, no downtime, and it changes the answer to every question the team has been arguing about for a year.
What a written model buys the agents.
This stops being a hygiene exercise the moment an agent touches the CRM. A human reading a contradictory field shrugs and asks a colleague. An agent reads it, believes it, and writes it into an email to your best prospect. Field-level ownership and source stamps are what make it safe to let software write to the record at all — the model is the contract between the two.
A data model is a set of promises about what a row means.
Every company we work with has more data than it can use and less agreement than it needs. The teams that scale are not the ones with the most fields. They are the ones who can say, in one sentence and without checking, what a row means and who is allowed to change it.
Write the four sentences. Archive the rest. Everything downstream — routing, scoring, reporting, agents — is downstream of that page.
What a written data model buys you
Reporting stops disagreeing with itself. One grain per object and one identity key mean two dashboards asking the same question return the same number.
Every field gets an owner and a stamp. Exactly one writer, with the source recorded on write. Enrichment and reps stop overwriting each other in a loop nobody can see.
Scores become reproducible. Computed values are written by the action layer with the model version attached, so last quarter's tiering can be explained rather than remembered.
The schema stops growing. A field needs a birth and a death condition to exist. Everything else is archived — and nothing downstream notices.
END · NAMIA