CRM data quality and status
Distinguish companies, contacts, enquiries and opportunities before defining fields, statuses and merge rules.
Author：WeTech technical team · Updated： (Hong Kong time (GMT+8))
Define what each CRM record represents, who owns it and how it changes before setting required fields, duplicates and statuses. One contact can generate multiple enquiries; merging contacts must not erase distinct opportunities. Preserve provenance, preferences and corrections alongside the record.
When to use this guide
For teams with duplicate CRM records, conflicting statuses or different definitions of qualified enquiries.
CRM data rules checklist
| Rule | Define | Test |
|---|---|---|
| Entities | Company, contact, enquiry, opportunity | One person, multiple enquiries |
| Fields | Format, source, required, owner | Blank, obsolete, conflicting values |
| Duplicates | Match criteria and review | Same name, shared email, recovery |
| Status | Transitions, permissions, reasons | Reopen, stale, reassignment |
Map record relationships
A company can have several contacts, and a contact can generate several enquiries for different projects. Give each entity a stable identifier instead of using changeable names as keys. Retain source IDs during migration to investigate merges and mismatches.
Make duplicate rules reviewable
Separate exact, possible and ambiguous matches. Define surviving values, activity transfer and protection of preferences or suppression states. A shared company email or telephone is not proof of one person. Test false merges with representative samples before enabling automation.
Give statuses business meaning
Define entry and exit conditions for new, contacted, qualified, paused and unsuitable states. Retain reasons, owner and timestamps rather than relying on free text alone. Report new enquiries separately from reopened opportunities and manage retention and access according to need.
Illustrative scenario
Hypothetical design: link a returning customer’s new project enquiry to the existing contact while preserving a new enquiry ID and source. Do not overwrite the earlier opportunity, and review shared email addresses before merging.
Frequently asked questions
Is the same email enough to merge?
Consider shared accounts and distinct business records before setting match and review rules.
Are more mandatory fields better?
Require information needed at that stage rather than encouraging meaningless placeholder values.
Should unsuitable enquiries be deleted?
Follow retention and deletion rules rather than removing records to improve reports.
Brand and public case scope
WeTech Consulting, also called WeTech or WeTech AI HK, provides AI and IT consulting in Hong Kong. WeProperty HK and WeCredit HK are self-developed products. Their cases support the observable features listed: property, estate and transaction-reference entry points for WeProperty; submission, review and public-data masking for WeCredit. WeCredit is not a TU credit-rating service or a final determination of facts.
WeProperty HK · WeCredit HK (case studies in Traditional Chinese)
Reference sources
Official documents support the technical, risk and measurement concepts. Checklists, estimation methods and illustrative scenarios are WeTech planning recommendations, not official prices or client results. Check the supplier’s current plan and terms. Sources reviewed: (GMT+8)
Related guides
Discuss your project
Share your workflow, systems and goals. We will review scope before discussing deliverables, acceptance and a quotation.
Request an initial consultationExplore this service