CRM DATA QUALITY
Recognize matching contact data without guessing who a person is.
Use defined contact-matching rules when importing customer data, and understand where human review still matters.
Contact match in the import preview
Review the proposed update before applying the import.
A wrong match can cost more than a visible duplicate
When two customers share a similar name, merging them can put one person’s history under the wrong identity. Tsumira’s contact-import matching uses explicit identifiers instead of promising that every similar spelling refers to the same person. The rules help reduce repeated records while leaving important identity decisions understandable to the person reviewing the import.
Start with stronger contact identifiers
The contact import tries an email match before a normalized telephone match. Email comparison ignores letter case; phone values use the CRM’s own normalization rules. These identifiers are often more useful than a display name, but they still deserve review. A shared office number or a reused address can have business meaning that the team understands better than an automated rule. Check the preview when a proposed update appears unexpected.
- Email comparison without case differences
- Normalized telephone matching
- Review of proposed record updates
Match by normalized email
Review the proposed update before applying the import.
Keep name and reading matching deliberately narrow
If stronger identifiers do not identify an existing contact, the importer compares the exact written name together with its reading. It does not claim to merge arbitrary kanji variants, former names or every person with a similar pronunciation. Missing readings are handled as a flagged fallback during import. This narrower rule makes the behavior explainable and avoids presenting a broad identity-resolution claim that the implementation does not support.
- Exact written-name and reading combination
- No blanket kanji-variant identity guarantee
- Missing-reading warning rather than invented pronunciation
Review duplicates in the file as well as the CRM
The import plan considers the existing contact pool and adds planned creations to its matching pool as it proceeds. That allows later repeated rows in the same file to resolve against earlier planned contacts instead of automatically creating another person. The result is still a proposed import, with creates and updates to review. Correct the source or mapping if a match would combine the wrong information, and verify important records after applying the batch.
- Existing-record matching
- Repeated rows within the same upload
- Visible plan before applying changes
A concrete workflow
Choose reliable identifiers
Include accurate email and telephone columns where the source legitimately contains them.
Inspect the mapping
Confirm that the contact name, reading and communication fields have the intended meanings.
Examine proposed matches
Read unexpected updates carefully and check whether shared identifiers really refer to the same person.
Apply a reviewed batch
Resolve uncertainty before applying the plan, then verify a representative selection of contact records.
An illustrative working example
Illustrative workflow: two people with similar names
A customer list contains two contacts with the same display name at different companies. Their email addresses differ. The reviewer checks the proposed import outcomes against those identifiers instead of assuming that similar names mean one person. Elsewhere, the same existing customer appears twice with the same email. The plan can recognize that repeated contact, while the team remains responsible for checking whether the resulting update is appropriate.
Questions about this topic
Is this a guarantee that duplicate contacts can never occur?
No. These are defined matching rules for supported flows. Missing identifiers, changed details or ambiguous real-world data can still require a person’s decision.
Does the importer match different kanji spellings using only the reading?
That is not the contact import rule. Its final name-based match requires the exact written name and reading together.
What if several people share an office phone?
Review the proposed update carefully. Normalization makes telephone formatting comparable; it does not determine whether a shared number identifies one particular person.
Does this page describe a general-purpose record-merging tool?
No. It explains the contact matching used in the import implementation. Do not assume that every CRM record can be automatically merged through a separate bulk-cleanup feature.
Explore connections around this workflow.
Ideas for intended connections. Check the actual availability, permissions and supported data for each app before using a scenario.
Pipedrive
Workflow concept: Compare duplicate export rows and confirm the intended contact before import.
Microsoft Excel
Workflow concept: Review normalized email and phone candidates in a dedicated matching worksheet.
Salesforce
Workflow concept: Separate true duplicate contacts from different people with similar names.