Every few weeks a developer gets pulled into a meeting they didn't ask for. The revenue team's CRM is "a mess," the reports don't match, and someone has decided that the engineer who once wrote a SQL query against it is now responsible for fixing it.
If that's you, this is the map I wish someone had handed me the first time I opened a CRM with several hundred custom properties and a lifecycle field nobody could explain. And if you're on the revenue side, this is the data model conversation your CRM vendor never had with you, because sprawl sells seats.
Your CRM is a database with an opinion problem
A CRM data model is exactly what it sounds like: the schema of your revenue system. Objects, fields, relationships, states.
The catch is that CRMs ship schema-less in practice. Anyone with admin rights can add a property, invent a pipeline stage, clone a workflow. So the schema isn't designed, it's sedimented. Layer on layer of past campaigns, departed employees, and temporary fields that outlived three marketing directors.
Data silos inside a CRM are rarely a tooling problem. They're what happens when three teams write to one database using three incompatible mental models. Marketing thinks in leads. Sales thinks in deals. Customer success thinks in accounts. Nobody wrote down how those map to each other, so every report becomes an argument.
The repair is a deliberately small object model.
The three-object architecture
You need exactly three first-class objects. Everything else is an attribute or an event.
- Company. The account, the economic entity that pays you. One record per real-world business, deduplicated without mercy. This is your primary key for revenue truth.
- Contact. A human at a company. Contacts never carry deal state. The moment you store "interested in the Q4 promotion" on a person, you've forked your pipeline into a shadow database that no report will ever read.
- Deal. A discrete revenue opportunity with a lifecycle. Open states, a won state, lost states with mandatory reason codes. Deals are the only object allowed to have pipeline stages.
Everything people try to promote into a fourth object is either a state on one of these three, or an event in their history. "Lead" is a Contact whose company has no open Deal yet. "Renewal" is a Deal with type=renewal. "MQL" is a threshold, not a thing. Materialize any of them as its own object and you've built a silo with a name and a tab in the navigation.
The full reference version of the model, with relationships, state machines, and required fields, lives on the Artefact site. This post is the developer's-eye view of why it works.
Why small models beat rich models
You already know this from schema design, but the CRM-specific mechanics are worth spelling out.
Joins become unambiguous. Three objects with clean foreign keys (Contact → Company, Deal → Company, Deal → Contacts) make every revenue question a two-hop query. "Which campaigns touched companies that closed last quarter" stops being an archaeology project.
State is legible. A deal is in exactly one stage, and a stage has documented entry and exit criteria. Compare that to the usual arrangement: pipeline stage on the Deal, lifecycle stage on the Contact, status field on the Company, three automations writing to them independently and quietly disagreeing. Three sources of truth is zero sources of truth.
Automation stops colliding. Workflows keyed to a small state machine compose. Workflows keyed to four hundred properties collide constantly, silently, and usually at quarter end.
Agents become possible. This is the 2026 reason. Every agent you point at your CRM reasons over this schema. A tight model gives it unambiguous state to read. Property sprawl gives it room to invent.
Migrating without paralyzing the sales team
Knowing the target model is the easy half. The hard half is getting there while reps are working live deals in the old mess.
Week 1: inventory, touch nothing. Export every property with its fill rate and last-updated date. The low-fill tail is your deletion candidate list, and it comes with its own evidence attached, which is what makes the conversation short.
Week 2: define the target state machine on paper. Three objects, their fields, their states, entry and exit criteria per deal stage. Get sales, marketing, and customer success to sign the same document. This meeting is painful and it's the entire project. Everything after it is mechanics.
Weeks 3 and 4: migrate strangler-fig style. New model runs beside the old fields, automations move one at a time, old properties get hidden for a quarter before deletion. Never big-bang a CRM migration. Reps will route around your new model permanently, and they'll be right to.
The judgment calls inside that sequence are where most migrations quietly fail, and I went through those trade-offs in a companion post on structuring CRM data without paralyzing your sales team.
One practical note about week 2: most schema arguments turn out to be two teams using one word for two things. A shared glossary defuses them faster than any diagram, so we keep a free RevOps glossary for exactly that meeting.
The acceptance test
Here's the test I hold client systems to:
Any revenue question answerable in principle should be answerable by one query path, and two people running it should get the same number.
Pipeline by stage. Win rate by segment. Time in stage by rep. If any of those come back with "it depends which report you trust," the model isn't done.
Article 1 in this series argued that go-to-market is an engineering discipline, with the data model as its foundation layer. This is that foundation, concretely.
Next: what happens when you put agents on top of a clean model, including the MCP server I built to do it.
I'm Alex, revenue operations consultant at Artefact Ventures. Previously in this series: GTM engineering.
Top comments (0)