CRM Data Model: Separating Account, Contact and Opportunity
What is the right CRM data model?
The right model separates three entities: the account (company), the contact (a person at that company) and the opportunity (a specific sales attempt). Merged into a single "customer" table, two people from the same company become two customers, history is lost when a person changes employer, and two quotes to the same company never see each other. Splitting the model later requires re-linking every existing record by hand.
Records that also need separating
- Activity: calls, e-mails, visits, linkable to both a contact and an opportunity.
- Product or service line: the items inside an opportunity; the amount should not live only on the header.
- Competitor and loss reason: chosen from a list rather than typed as free text.
- Relationship type: the same person can be both decision maker and technical evaluator.
Write the deduplication rule first
Duplicate records are the first reason a CRM becomes unusable. Define the rule set in advance: tax number as the primary key for companies, falling back to a normalised legal name plus city; e-mail as the primary key for contacts, falling back to a phone number normalised to international format. Similarity checking must run at the moment of entry, not in a later report, and the merge operation should be able to ask which record wins field by field.
Consent management is a CRM function
If you send marketing communication, consent must be stored per channel and with a date: is there e-mail consent, is there SMS consent, when and under which text was it obtained, and when was it withdrawn? A CRM without consent records creates direct legal risk for commercial electronic messages, and a withdrawal must propagate automatically to every sending list.
Making the pipeline measurable
Stages should be defined by evidence, not by a representative's feeling. A "quotation sent" stage is valid when a quotation document exists in the system. Once transition conditions are written, several measurements become meaningful: conversion per stage, average time in stage, the stage distribution of lost opportunities, and forecast accuracy — the gap between predicted and actual close.
Fewer fields means higher adoption
A CRM produces no data unless the sales team fills it in. Limit mandatory fields to those genuinely used in reports. A practical rule: if a field appears in no report and no automation, it should not be mandatory. Field proliferation does not improve data quality; it stops records being created at all.
Relationship with the ERP
The CRM manages pre-sales and the ERP manages post-sales, with the boundary at order creation. When an opportunity closes, the order should be created in the ERP and the ERP account code written back to the CRM account. Maintaining customer records separately in both systems inevitably produces divergent address and legal-name data. For the technical side of the hand-off see the [API integration guide](/en/blog/api-integration-guide).
Frequently asked questions
Should historical data be migrated into the CRM?
Open opportunities, active contacts and the last two years of activity are usually enough. Migrating everything copies duplicate and stale records into the new system and inherits the old system's problems.
Should representatives be able to hide their records from each other?
Visibility is a company policy that the system should be able to express, but a fully closed model loses knowledge when a representative leaves. Full visibility at least at manager level is advisable.
Where should CRM automation start?
With reminders and assignment. Routing an incoming enquiry to an owner and escalating an unanswered one produces the most visible benefit for the least effort.