CRM Data Model: How to Structure Contacts, Companies and Deals

CRM data is the full set of customer, company, sales opportunity and interaction records held in a CRM. A CRM data model is the skeleton that decides which objects (contact, company, opportunity and so on) hold that data, with which fields, and how they connect to each other. Build the model well and your reports become reliable; build it badly and you get duplicate records, broken relationships and numbers nobody believes.

What does CRM data consist of?

When people hear "customer data", most think of a name, a phone number and an email address. A CRM that actually works holds five kinds of data side by side:

• Identity data: a person's name, job title and contact details; a company's legal name, tax number, industry and address.
• Relationship data: which company a person works at and in what role; the group or dealer structure a company belongs to.
• Transaction data: quotes, opportunities, orders and contracts.
• Interaction data: calls, meetings, emails, support requests and web form submissions.
• Consent data: marketing message consent, records of privacy notices given, and contact preferences.

The data model defines where each of these five lives and how they link together.

What are the core objects in a CRM data model?

Nearly all major CRMs are built on the same core. The names differ, but the logic is shared.

• Company (account): the organization you sell to. In B2B, this is the center of the model.
• Contact: the individual you deal with at that company. In B2C, this is the center.
• Opportunity (deal): a specific chance of a sale. Amount, stage, expected close date and owner live on this record.
• Activity: a call, meeting, task or email. It is always linked to a contact, a company or an opportunity.
• Case (ticket): a post-sale support record.

A common mistake is writing opportunity details onto the contact record. When a note such as "quote sent, negotiating" sits on the contact card, the report gets muddled the moment a second deal opens with the same person. Amount and stage should always live on the opportunity object, because one contact can have several opportunities.

How do you model relationships: one-to-many and many-to-many?

The real work of a data model shows up in its relationships.

One-to-many is the most common: one company has several employees, and one opportunity has several activities. It is easy to set up; a "parent company" field on the contact record is enough.

Many-to-many comes up in real life more often than people expect. An accountant handles the books for ten different companies; a purchasing manager makes decisions for three companies in a group; a technical manager and a finance director both influence the same deal. A model that locks a contact to a single company tries to solve these cases with duplicate records or free-text notes, and both break your reporting.

Popular CRMs solve this under different names. In Salesforce, the "Contacts to Multiple Accounts" feature links one contact to several accounts; the contact's primary account is a direct relationship and the others are indirect relationships. In HubSpot, associations are always two-way, and a contact can be associated with several companies and deals; the first company a contact is associated with is treated as the primary company by default. Adding labels such as "consultant" or "manager" to an association is available in HubSpot's Professional and Enterprise tiers.

Hierarchy is the third key relationship. A holding company, its subsidiaries and branches are linked through a parent account relationship. In Microsoft Dataverse, this is set with the parent account field on the account record, which lets reports show the parent and child companies together.

What does a CRM data model look like in practice? B2B and B2C examples

A distributor selling industrial products: The company is at the center. Every dealer and end customer is created as a company, and branches are linked to a parent company. Contacts are linked to companies with a role (purchasing, technical, finance). Opportunities are linked to the company, and the decision makers in each opportunity are linked as contacts. The ERP customer account code is stored on the company record, so a quote won in the CRM lands as an order on the right customer account in the ERP.

A brand selling online: The contact is at the center; most customers have no company. The contact record holds an order history summary, last order date, channel (website, marketplace, store) and contact consent. Orders and support tickets take the place of the opportunity object. The company object stays available for corporate purchases but is not mandatory.

In both examples the point is the same: the model reflects how the business actually runs. Copying another company's CRM template as it is usually leaves you with a system full of fields you do not need.

How do you prevent duplicate records?

Clean data starts with choosing a unique key. HubSpot automatically deduplicates contacts by email address and companies by domain name; a form submitted with an existing email updates the existing contact instead of creating a new one. For B2B work in Turkey, the company tax identification number is a sturdier key, because not every company has a domain and branches may share the same one.

Avoid collecting personal data such as national ID numbers just to have a key. Turkey's Personal Data Protection Law No. 6698 requires personal data to be relevant, limited and proportionate to the purpose for which it is processed; data you do not need for sales follow-up simply stays on your books as a risk.

These also help:

• Use picklists instead of free text for fields such as stage, industry and source.
• Keep mandatory fields few and meaningful; making everything mandatory leads to made-up entries.
• Run a duplicates report once a month and merge records.
• Clean old spreadsheet lists before you import them.

How do you build a CRM data model step by step?

1. Map the process: Where do leads come from, who handles them, which stages does a quote go through, and what happens after the sale?
2. Choose the objects: Which core objects do you need, and do you need custom objects (for example, project, contract or installed device)?
3. Write a field dictionary: Record each field's name, type, whether it is mandatory and who fills it in, in a single document.
4. Define relationships and roles: Is the contact-company relationship single or multiple, and which roles link people to an opportunity?
5. Set the keys: The tax number or customer account code for companies, email for contacts.
6. Map integrations: Decide up front which CRM fields correspond to ERP, email, web form and accounting fields.
7. Start with a pilot: Import a small data set, test the reports, then move everything.

Models tend to bloat over time, because every team wants its own fields. We cover how to keep that complexity in check in our article on CRM data model complexity.

In short: signs of a good model

• Each piece of information lives in one place; the same data is not maintained by hand in two objects.
• Amount and stage live on the opportunity; identity data lives on the contact and the company.
• Many-to-many relationships are built with roles, not notes.
• Key fields mean imports do not create duplicates.
• The field dictionary is written down and kept current.

If you want to design your CRM together with your ERP, take a look at our CRM and ERP solutions. Our own business management platform, Nexfabra, is built on the same logic, bringing customer, quote, order and documents together in a single customer record.