Implementation example
A CRM that keeps the history
Update records while keeping notes, companies and opportunities.
The starting point
A new import creates disconnected records.
The design objective
The update preserves the contact’s context.
The decisions
behind the process.
Open the detail you want to explore.
Where it gets stuck
A new list arrives with incomplete fields and differently written names. Some contacts already exist, some belong to a known company and some need review. Creating one record per row leaves a cleanup job behind.
The intervention
We prepare a shared structure and a sequence of checks. Records are matched using stable identifiers such as email, companies are linked when sufficient evidence exists, and fields are updated according to an explicit rule.
The decision that matters
Filling an empty field is different from replacing an existing value. Notes and relationships need to survive. A name match on its own is not permission to merge two people.
What we check
Before applying changes, we inspect the records that would be created, updated or flagged as ambiguous. A sample review also checks that notes, company links and opportunities remain where the team expects them.
Scope and limits of the example
Identity rules depend on the source and how the CRM is used. An exact match is evidence to interpret, not a universal guarantee that two records refer to one person.
Let’s talk about the work