A reminder goes to the wrong owner. A customer receives a follow-up for work already completed. Two records carry different versions of the same conversation, and the integration faithfully copies both.
Automation can move information while leaving its meaning unresolved. A CRM cleanup needs decisions about which records matter, who can change them and what evidence supports each value.
The approach below is an original management framework for a VA-supported operations team, with product and privacy guidance checked on 26 September 2026. It focuses on controlled corrections and preventing repeat defects.
Give important fields an owner and an authoritative source
Choose the fields that drive actual decisions: customer identity, assigned owner, lifecycle stage and next action. For each, record its definition, authoritative source, update trigger and person who resolves conflicts.
“The CRM is our source of truth” is incomplete if three systems can overwrite its status field. Decide where that particular fact originates and how an authorised change reaches other systems.
| Field | Example source and ownership rule |
|---|---|
| Current contact details | Record verified updates through the approved customer process; nominated owner resolves conflicting details |
| Service status | Operations owns the stage definition and evidence required to change it |
| Commercial terms | Link to the current authorised agreement; sales or commercial owner resolves variations |
| Next action | Assigned case owner records the task, due time and supporting instruction |
This is a suggested map, not a universal hierarchy. A recent import may contain older information than an existing record. Preserve the source and relevant date rather than automatically treating the last update as correct.
For businesses covered by the Australian Privacy Principles, APP 10 requires reasonable steps to maintain personal-information quality at collection and when used or disclosed. Relevance also matters for use or disclosure. OAIC: quality of personal information.
Check how records enter and change
List the entry paths: forms, manual creation, imports, integrations and automated updates. Trace a small example through each. Record which identifiers it supplies, which fields it can overwrite and whether it creates or updates a record.
Product behaviour can differ by path. HubSpot documents automatic contact deduplication using email and company deduplication using domains, but says companies created through its API are not deduplicated by company domain name. That exception includes third-party sync apps. HubSpot: deduplication behaviour.
Verify the actual connector and configuration. A rule that works during manual entry may not protect an integration in the same way.
Also separate duplicate records from repeated contact about one request. An email followed by a phone call may belong to one case without requiring a contact merge. The shared inbox playbook explains how to keep those conversations connected.
Treat duplicate matches as review candidates
A matching name is a reason to investigate. It does not establish that two records represent the same person. Shared telephone numbers, household inboxes and similar company names can also create ambiguity.
In a hypothetical cleanup, two “Taylor Lee” records share a business phone number but have different customer references and active requests. The VA records the evidence and sends the pair for review. They do not choose an identity based on whichever record has more populated fields.
The authorised reviewer confirms whether the records should remain separate, be linked or be merged. If a merge is justified, record the retained values, associated work, rationale and approval before execution. Uncertain cases remain open while the owner seeks verification through the approved process.
HubSpot warns that merged records cannot be unmerged and that effects vary by object. Check your product's behaviour before acting. A downloaded spreadsheet is not a guaranteed way to restore every relationship or activity. HubSpot: merge records.
Clean one bounded batch before scaling
Start with a defined population, such as active service records created through one integration during a specified week. Capture the starting record IDs, selected field values and known defects in an approved location with appropriate access.
Separate formatting corrections from changes to meaning. Applying an agreed display format is different from deciding a customer's identity, changing a commercial status or combining records. Give each change type a clear permission and review rule.
Have the system owner identify workflows, messages and integrations that may react to edits. Test the correction method on a small approved batch and inspect the downstream result. Arrange any necessary containment before changes, with a plan for restoring normal processing.
Use available recovery facilities for reversible edits and confirm their limits. Keep merge decisions separately approved. After each batch, check both changed values and linked work before proceeding. Our small pilot framework provides a way to record acceptance and stop conditions.
Make the review queue specific enough to decide
Each exception needs a record reference, defect type, source evidence, proposed action, decision owner and age. “CRM issue” gives the reviewer little to work with. “Service status conflicts with the completion record; operations to confirm the correct stage” identifies the decision.
Use distinct outcomes: correction approved, records confirmed separate, more evidence required or source process needs repair. A candidate dismissed as a false match should retain its rationale so the team can improve the detection rule.
A trained Filipino VA can collect evidence, apply authorised routine corrections and maintain this queue. Identity decisions and consequential changes follow the agreed approval route. AI may help flag inconsistencies within an approved information-handling arrangement; a generated guess should never fill a missing identity or permission field.
Publish a small weekly data-quality scorecard
Use stable populations and definitions so clearing easy records cannot disguise continuing problems.
| Measure | Working definition |
|---|---|
| Source agreement | Sampled applicable field values matching their designated source ÷ applicable field values checked |
| New-record defect rate | Sampled newly created records with at least one defined defect ÷ new records reviewed |
| Open duplicate candidates | Unresolved candidate groups, each counted once; show oldest first-flag date alongside the count |
| Verified corrections | Applied corrections that pass the agreed post-change check ÷ applied corrections checked |
If 45 of 50 checked corrections pass, verified corrections are 90%. That hypothetical sample describes those checks, not the entire CRM or a Nexus client result. State sample size, period and selection method; show missing evidence separately from confirmed errors.
Review the source of new defects with the integration owner. Fixing the entry rule can prevent the same cleanup from returning next week. Talk to Nexus about CRM administration support to define one bounded queue, its field owners and a correction process your team can maintain.
