CRM data model: how to design it in 7 decisions

The CRM data model is the design that defines which objects the company records, such as company, contact, deal, product and ticket, which properties each object holds, how records connect and which pipelines they move through, and it needs to be written down and approved by the teams before anyone opens the configuration screen. The design fits into seven decisions and a document of a few pages that states, for each piece of information that weighs on a decision, which object it lives in, who fills it in and when. Skipping this step gets expensive months later, when reports, automations and integrations already depend on a structure configured in a hurry and changing an object forces the team to rebuild what it built on top. The company that implements without a design ends up with more fields than anyone can explain and a board that goes back to the spreadsheet to get a number.

In the diagnostics I run on CRMs that come in for restructuring, the first list I ask for is the deal properties with creation date and fill rate, and it usually shows fields nobody opens anymore and duplicates with similar names, created on request, one at a time, without a design that said where each piece of information should live. The discipline of designing before building is fifty years old in computing: in 1976, Peter Chen proposed the entity-relationship model as a database design technique, separating the things an organization records, the relationships between them and the attributes of each one (Chen, 1976). CRM vocabulary is the commercial version of that idea.

What is the CRM data model?

The data model is the map of commercial information inside the CRM. An object is a type of thing the company records, with its own screen, list and reports, and a record is each occurrence of it, such as one company in the database with its tax ID. A property is the information stored in each record, the field on the screen. An association is the link between records, and the association label states the role that link represents, such as the contact who is the decision maker on a deal. A pipeline is the sequence of stages a record moves through, with a criterion to advance.

The seven decisions follow this order: standard objects, custom objects, properties, associations, pipelines, naming and the design document. The boundary between object and property is the decision that weighs most, because it defines what the company can count, filter and add up later.

Why design the model before implementing or restructuring?

The order that protects the project runs from the design to the data dictionary, then to configuration, migration and integrations. The ERP integration maps properties that need to exist with the right type, the migration needs a mapping between old and new fields, and the board report only works if the information is in a format it can group. Fixing it on paper costs a meeting, and after go-live it costs reconfiguration and rebuilt dashboards.

In a restructuring, the work starts with an inventory of what exists, with the fill rate of each property and the reports and automations that depend on it. The new design comes from business decisions, and the inventory comes in afterwards, to build the field mapping that the CRM migration will execute.

Which standard objects does a CRM need?

Almost every B2B operation starts with the standard objects, the ones the platform ships ready, with reports and automations prepared for them. When the CRM talks to the ERP, the product code in the catalog has to match the one used for invoicing, and the design states which of the two systems creates and maintains the catalog.

Object	What it represents	Question it answers
Company	The organization that buys or may buy, identified by tax ID or domain	How much each account and each segment represents in revenue
Contact	The person the company has a relationship with	Who decides, who uses and who pays in each account
Deal	A revenue opportunity, with amount, stage and date	How much comes in, when and with what likelihood
Product and line item	The catalog and the lines of each deal, with quantity, price and discount	What the company sells, at what price and with what discount
Ticket	A customer request someone needs to resolve	How much each account asks for and which reason concentrates problems

When should you create a custom object?

A custom object is a record type the company creates when no standard object represents something it needs to track. I approve one when the thing exists on its own, a company can have several of them at the same time and it has its own cycle, with dates, status and an owner that change without the company or the deal changing. A contract with a term and renewal passes this test, as do a serviced location in a retail network, equipment installed at the customer and an enrollment at a school.

If the information describes a record that already exists, such as size or region, it is a property. If it marks a moment in the sale, such as the proposal sent, it is a stage or an activity. Each custom object needs properties, permissions, reports and mapping in the integrations, and on some platforms it depends on the plan you pay for, so the business question has to justify that cost.

How do you define the properties of each object?

Each property answers a question someone will ask the CRM, and the design records that question before the property is created. A property born without it becomes a field nobody can explain.

Which property type should you choose?

The type defines what the company can do with the data: text does not add up and a date stored as text does not filter by period.

Type	When to use it	Example
Single-select list	A classification that becomes a filter or a grouping	Segment, company size, loss reason
Multi-select	More than one value applies at the same time, with no sums	Products of interest
Number and currency	A quantity or amount used in calculations, with unit and period in the label	Deal amount, number of employees
Date	A moment someone will filter or measure, separating expected from actual	Expected close date, contract start
Yes or no	A condition with two answers and a defined meaning for blank	Requires vendor registration
User	The person responsible inside the company, one property per role	Account owner, CSM
Text	A unique identifier or context nobody groups	Tax ID, meeting summary
Calculated	A value derived from other properties, with a documented formula	Annual value from the monthly value

Required at the moment the person has the information

A property required when the record is created produces invented data, because the seller does not know the deal amount at first contact. In the design, the requirement is tied to the stage or event in which the information exists. The per-stage field rule is in CRM data quality.

A closed list instead of free text

Any information leadership will filter, group or compare goes in as a list, with the values written in the design session with the teams. Each value has a label, which the team reads, and an internal value, which integrations and reports use. The label can change with the market’s vocabulary, and the internal value stays stable, because changing it breaks saved filters and integration mappings.

One single writer for each property

Each property has one source: a person, an integration or an automation. When the ERP owns the customer’s financial status, the CRM shows the value as read-only, otherwise the next sync wipes out the correction the seller made by hand. The design marks the master system and the direction of each piece of data that comes from outside, and the flows between the two systems are in CRM and ERP integration.

Associations and association labels: how do you connect records?

An association defines which records connect and how many on each side. A deal links to a primary company, to several contacts and to several line items. A contact can be linked to more than one company, like the director who changed jobs, and a ticket links to the company and to the person who opened it. The design chooses the association that drives the reports, such as the deal’s primary company, which decides in which account the revenue shows up.

The label states the role of the link. Between deal and contact, labels describe the buying committee, such as decision maker, influencer, user, procurement and legal, and leadership can then filter deals at proposal stage with no decision maker associated; mapping that group is covered in B2B buying committee. Between companies, labels record parent and subsidiary, business group, reseller and end customer. In a network where headquarters signs and the locations use the service, revenue sits with headquarters, tickets with the locations, and the account report adds up both ends through the association.

Pipelines and stages: where do they fit in the model?

A pipeline belongs to an object. The deal has the new business pipeline and, when the customer’s decision changes, a renewal and expansion pipeline, and the ticket has the support queue. In the design, each stage carries the exit criterion, the properties that become required, who can move the record and the automation the change triggers. The method for writing criteria based on the buyer’s decision is in B2B sales funnel. Seller, region and channel work better as properties and filters than as pipelines of their own.

How do you name objects, properties and values?

Each property has two names. The label appears on the screen and follows the team’s language, and the internal name, used by integrations, automations and exports, follows a technical pattern and does not change after creation, because the integration points to it.

The design document: object, key properties, who fills in and when

The design document records the decisions in a table the board reads in a few minutes and the administrator uses to configure. It lists the key properties, the ones that feed a report, a handoff, an integration or a rule. The template below is the starting point I adapt with each operation, with a custom contract object as an example.

Object	Key property	Type	Who fills it in	When	Report or decision that uses it
Company	Tax ID	Text with validation	SDR or enrichment	At creation	Duplicates and matching with the ERP
Company	Segment	Single-select list	SDR	Before qualification	Conversion by segment
Company	Account owner	User	Sales leadership	When the portfolio is assigned	Portfolio and commission
Contact	Job level	Single-select list	Marketing or SDR	At qualification	Lead criteria and committee coverage
Deal	Amount	Currency, calculated from line items	Seller	At proposal	Forecast
Deal	Expected close date	Date	Seller	At proposal, reviewed every week	Pipeline meeting
Deal	Loss reason	Single-select list per stage	Seller	When marked as lost	Loss analysis
Ticket	Category	Single-select list	Support	When opened	Volume by reason and by account
Contract	Term start and end	Date	ERP integration	At signature	Renewals for the quarter

The document has two more pieces: the association diagram, with one box per object and the labels written on each line, and the list of pipelines with stages, exit criteria and required properties. The data dictionary completes the set, fixing what each term and each field in this model means for the business, with calculation rule, source and owner.

How do you validate the data model with the teams?

Exceptions show up when someone tries to record a real customer in the new model. In the implementations I follow, the real-case test is the one that changes the design the most, because the customer who bought through a reseller or the contract signed by headquarters for several locations comes up in the case and never comes up in a requirements meeting. The version that passes the tests gets a number and a date, the board signs it, and only then does the administrator configure.

Test	How to run it	Who takes part	Approved when
Real cases	Walk ten customers from the last year through the model on paper, from first contact to renewal	Sales, marketing and CS	Every piece of information in the case has an object and a property
Board reports	Each leader lists the reports for the monthly meeting	Leaders and the board	Every report comes out of the model with no side spreadsheet
Handoff	Simulate passing the lead to sales and the won customer to CS	SDR, seller and CSM	The next team finds what it needs in a property with an owner
Integrations	Mark the properties that come from another system	IT and revenue operations	Every property has a single writer
Personal data	Review the purpose of every property holding personal data	Data protection officer and legal	No personal data without a written purpose

Who owns the CRM data model?

Role	What it does in the model	What it approves
The board, as sponsor	Sets priorities and settles conflicts between teams	The final version and changes that affect official reporting
Model owner, in revenue operations or CRM administration	Writes the design, maintains the document and receives change requests	New properties, list values and naming
Marketing, sales and CS leaders	State which decisions need data and hold the team to filling it in	Properties, lists and stages for their own team
IT	Answers for integrations, access and security	Integration mappings and access profiles
Data protection officer and legal	Check the purpose and necessity of each piece of personal data	Properties holding personal data

A request for a new property reaches the model owner with the business question, the report that will use the value, who fills it in and when. The owner first looks for an existing property that answers the same question and decides at the monthly meeting with the leaders.

Common mistakes when designing the CRM data model

Copying the old spreadsheet

The team’s spreadsheet becomes, column by column, the set of deal properties. It mixed company, contact and contract in one row, and the CRM inherits the mix, with the decision maker as text and the product typed by hand. Use the columns as a list of requirements and let the design decide which object each one lives in.

Creating a field for every request

Each team asks for its own field, the administrator delivers, and within a year the deal has properties only one person fills in. When the field holds personal data, the excess carries legal weight: Brazil’s data protection law (LGPD) requires purposes that are “legitimate, specific, explicit and informed to the data subject” and limits processing to “the minimum necessary to achieve its purposes” (Lei 13.709/2018, art. 6, items I and III).

Free text where leadership will need a filter

A text field looks flexible during configuration and charges its price on the first report, with the segment spelled five ways and a history someone will standardize record by record. In the design session, ask whether anyone will filter, group or compare the information, and if the answer is yes, the property starts life as a list.

Forcing everything into the deal

Contracts, implementation projects and support requests become deals in improvised pipelines, because the deal is the object the team knows. The pipeline report starts adding new revenue to renewals and complaints, and the forecast mixes things that do not add up. Anything with its own cycle after the sale calls for a ticket or a custom object.

Training: who needs to learn what

The model owner learns to choose types, build associations, assess requests and maintain the document. Leaders learn to read the design, to know which property feeds each report they bring to the board and to hold the team to filling it in at the team meeting. Sellers, SDRs, marketing and CS learn what they fill in, when and who uses that data next, in the CRM already configured with the approved model, and get a short update with every relevant change.

30-day roadmap for leadership

1. Days 1 to 3: name the sponsor and the model owner. Write down what the owner approves and tell the teams.
2. Days 4 to 7: list decisions and reports. Each leader brings the reports for the monthly meeting and the questions they cannot answer today; in a restructuring, also run the property inventory.
3. Days 8 to 12: design objects and associations, applying the own-cycle test to every custom object candidate.
4. Days 13 to 17: fill in the design document with the key properties, types, who fills them in, when and the values of each list.
5. Days 18 to 21: write pipelines, stages and naming, with exit criteria and required properties per stage.
6. Days 22 to 26: validate with real cases and fix the design wherever a case did not fit.
7. Days 27 to 30: approve version 1 and open the request flow. The board signs and the administrator configures from the document.

If your company is about to implement or restructure its CRM and nobody can say where each piece of information should live, that is the work of the in-company CRM adoption training. I run the program with the leaders, the model owner and every role that records data, on the cases and reports of your operation. The group leaves with the CRM best-practices guide, with objects, properties and naming designed, and with the portfolio and database management manual, which defines account ownership, associations and the routine that keeps the model standing.

Frequently asked questions

What is a CRM data model?

It is the design that defines which objects the CRM records, which properties each one holds, how records are associated and which pipelines they move through. It is written in a document the teams approve before configuration, and it guides integrations, migration and reporting.

When should you create a custom object in the CRM?

When the thing the company needs to track exists on its own, appears several times in the same account and has its own cycle, with dates, status and an owner. Contracts, serviced locations and installed equipment usually pass this test. If the information only describes an existing record, it is a property.

What is the difference between a data model and a data dictionary?

The data model shows the structure: objects, associations, pipelines and the key properties with who fills them in and when. The dictionary fixes what each term and field means for the business, with calculation rule, source and owner. The model comes before configuration, and the dictionary follows the operation afterwards.

How many properties should a CRM object have?

No number works as a yardstick; the criterion matters more than the count. Each property needs a business question, someone who fills it in and a report or rule that uses the value, and any property that fails this test leaves at the next model review.

Can you change the data model once the CRM is in use?

Yes, at a higher cost with every month of use, because reports, automations and integrations depend on the structure. The change goes through the model owner, with an analysis of what depends on it, a plan for the history and notice to the affected roles.

How do you prepare the team to work with the new data model?

Train each role in the CRM already configured, showing what they fill in, when and which report or team uses that data. Leaders go through the program first, because they are the ones who hold the team to recording at the team meeting. Repeat a short update with every relevant change to the model.