Modelling Contacts and Organisations
Almost every CRM implementation has people and the organisations they belong to. How you relate them determines what you can ask later.
Where to find it
Architect Panel → Data:
- Datastores — where the model is defined
- Record Links — relationships that are events rather than structure
- Record Numbering — human references for both
Two datastores, not one
Resist holding organisations as a text field on a person. It looks simpler and it costs you everything interesting: you cannot list everybody at one organisation, cannot hold an address once, and cannot see that three enquiries came from the same company.
Two datastores with a relationship between them is barely more work and answers all of it.
People move between organisations
This is the modelling decision people regret. A person linked directly to one organisation cannot easily represent somebody who changes employer — and if you overwrite the link, the history of who they were when they dealt with you is lost.
Decide early whether you need that history. If you do, model the relationship as its own thing with dates on it rather than as a field on the person.
One person, one record
The commonest data quality failure is the same person existing several times because they came in through different routes. Set up a match policy on the people datastore before you start loading data, not after.
Duplicates are far cheaper to prevent than to merge, even with a merge feature that works well.
Hold contact details as fields, not free text
Campaigns need to know which field is the e-mail address and which is the phone number. Notes saying "best contacted on the mobile" are useful to a person and invisible to a segment.
Give both a reference
Set up record numbering on people and organisations. Quoting a database ID to a colleague is awkward, and a reference is what makes an import or an integration traceable later.
Use links for events
Structural relationships — this person belongs to that organisation — are fields. Things that happened — this enquiry was converted from that one, this organisation acquired that one — are record links, which carry who recorded them and when.
Plan for retention from the start
People records are personal data, and a CRM accumulates them faster than anything else in the business. Decide how long you keep a contact you have not spoken to, and configure it — otherwise the answer becomes "forever", and that is a decision you will have made by accident.
Worked example
An agency models Organisations and People separately, with employment held as a dated relationship so a contact who moves agency keeps their history at both. A match policy on People runs from day one. Three years later, "who have we ever dealt with at this company" is a query rather than an archaeology exercise.
Recommendations
- Separate people from organisations.
- Decide about job history early — it is expensive to retrofit.
- Set up matching before loading data.
- Configure retention on people at the start.