How the problem develops
The team merges duplicate contacts after each import, then finds the same problem after the next form submission. Different entry points use different matching rules. Similar names are mistaken for the same client while changed email addresses split an existing relationship.
What to check first
- Identify every entry path: forms, imports, integrations and manual creation.
- Compare the matching key used by each path and inspect what happens when that key is missing.
A better process
- Agree stable identifiers for contacts, companies and service requests separately.
- Check for an existing record before creation using the approved matching rule.
- Route uncertain matches to review and record why a merge was approved.
What a system can do
Normalize routine formats, find exact approved-key matches and flag likely duplicates for review.
Where people stay in control
Do not automatically merge on a similar name or overwrite conflicting records. Destructive merges require human approval.
Benefits and tradeoffs
The useful outcome
Activity is easier to follow when the same client is not split across several records.
The tradeoff
Strict matching may leave some duplicates unresolved; loose matching risks combining different clients. Prefer a review queue over a guess.
Test before going live
Test repeat imports, shared email addresses, a changed contact email and two companies with similar names. Check both new-record prevention and preserved history.