You open a customer record and find three phone numbers, two versions of the company name and a note saying someone else has already followed up. Another record appears to be the same person. Neither tells you which information to trust.
It is a reasonable job to outsource. A virtual assistant can inspect records, standardise agreed fields and prepare corrections while you get on with running the business. But “tidy up the CRM” leaves some surprisingly important decisions unstated.
Should two contacts become one? Does an old address need replacing or preserving? Could changing a status send an email? A cleaner-looking database can still be less accurate than the untidy one you started with.
The safest first project separates proposed corrections from live changes. Here is how to set up that service, test the rules and hand over useful work without handing over unrestricted authority.
Start with one record problem, not the whole database
A customer relationship management system, or CRM, stores information about contacts, organisations and your dealings with them. CRM data cleanup means correcting or organising those records. It can include inconsistent formatting, missing information, suspected duplicates and outdated details, but these are different jobs with different risks.
Choose a problem that is already making work harder. Perhaps company names appear in several formats, so nobody can find the right account. Perhaps contact records lack a country, making phone numbers ambiguous. Describe the operational problem before asking someone to make everything complete.
Write a bounded assignment: review company-name formatting in one saved list, for example, and propose changes without applying them. Specify the record type, selection filter and fields included. Exclude active disputes, sensitive records or linked accounts that need specialist judgement.
An old record is not automatically wrong. A customer who has not bought recently may still have an open warranty question, a contractual relationship or a valid reason to remain in your records. Age alone does not authorise deletion or a change in marketing status.
For a first engagement, buy a defined review service from an independent virtual assistant provider. Agree the deliverable, fee, availability and approval points. You do not need to buy ongoing CRM administration before discovering whether a small cleanup actually helps.
When selecting a provider, ask them to explain how they would investigate two conflicting records in your particular CRM. Look for questions about identifiers, sources and permissions. Familiarity with a product is helpful, but someone who immediately proposes bulk merging has not yet understood your boundaries.
Ask for an example using fictional or properly anonymised data, not another customer's export. A useful demonstration shows the original value, evidence, proposed decision and reason for escalation. You are checking their method, not requesting confidential proof of another business's records.
Confirm what their quote includes. Investigation, source checking, proposal preparation and correction after your review can take different amounts of work. Agree how unclear cases are billed and whether the provider will pause when the sample reveals a larger problem. That avoids a fixed-price formatting job quietly expanding into an open-ended database repair.
Keep specialist work separate. Broken integrations, complex data migrations and recovery after accidental merges may require a CRM administrator or implementation specialist rather than general administrative support. The VA can document the symptoms without being expected to repair a system they were never engaged to maintain.
If your task list still includes everything from prospect research to invoice chasing, use the guide to choosing a first VA task to separate those services. This project should leave you with an understandable set of proposed corrections, not a new person making undocumented business decisions.
Check what your backup can actually recover
Before anyone edits live records, the account owner or CRM administrator should arrange an appropriate backup and establish a recovery method. A downloaded spreadsheet is useful evidence of earlier field values. It is not automatically a complete restore point for the system.
Ask what is included: record identifiers, custom fields, linked companies, notes, activities, files and subscription information. Then ask what restoring would require. Could you restore particular values without overwriting legitimate changes made since the export? Who has permission to do it?
HubSpot’s CRM backup documentation illustrates why this matters. Its documented backup includes records and property values, but excludes associations and activity data. The page also explains subscription and administrator requirements. Do not assume a similarly named feature in another CRM has identical coverage.
Download and inspect the completed backup before the cleanup starts. Confirm the relevant records and fields are present, retain the original file unchanged and store it in a business-controlled restricted location. A scheduled backup that has not completed is not evidence you can inspect.
Where your system provides a sandbox or supported test environment, ask the administrator to demonstrate recovery there using suitable test data. If that is unavailable, document the limitation and keep the first live scope narrower. Do not test restoration by overwriting real customers simply to see what happens.
Some actions cannot be reversed through the ordinary interface. HubSpot’s merge documentation explicitly says merged records cannot be unmerged. Recreating a contact is not the same as recovering its original identity and complete history. A backup therefore supports the safety plan; it does not make unrestricted merging safe.
Let the VA investigate without granting every action
List the permissions the service actually needs. Viewing selected records, exporting a limited list, editing a field, importing records, merging and deleting are separate capabilities. Your brief should distinguish them even if the software bundles several inside one role.
Start with a restricted user account and multi-factor authentication where supported. Keep account ownership, billing and recovery with your business. If field-level or record-level restrictions are unavailable on your plan, use a minimised staging extract instead of granting broader access just for convenience.
An export can contain more personal information than the task requires. Exclude payment details, private correspondence and unrelated notes. Agree where the file may be stored, whether downloading to personal devices is permitted, who else may access it and when working copies must be removed.
Confidentiality alone is not a complete data-handling arrangement. Check any applicable processor agreement, approved subcontracting, cross-border transfer and security requirements for your business. The provider should use only authorised tools. Uploading customer records into a public AI chat or an unapproved deduplication service is not an acceptable shortcut.
For the pilot, authorise investigation and proposed corrections only. Reserve live imports, ownership changes, lifecycle changes, consent edits, merges and deletions for the named administrator or a separately approved procedure. A spreadsheet cell saying “approved” should identify who approved what, not substitute for a real decision.
Our secure access guide covers the wider handover. For this project, check permissions using the actual restricted account before work begins. A role name that sounds limited is not proof that the export or delete controls are unavailable.
Decide what makes two records the same entity
Duplicate detection produces candidates, not facts. Similar names may belong to different people. Two companies can share a trading name. Several branches can use one website, and a shared reception email can represent more than one contact.
Start with the CRM’s stable record identifier, usually called a record ID. It tells you which existing record an approved update is meant to affect. It does not prove that two different IDs represent the same entity. That second question needs evidence and an agreed matching rule.
Specify separate rules for contacts and organisations. A contact comparison might consider current email, name, linked company and relevant history. A company comparison might need the legal entity, operating location and account relationship. No single combination is universally reliable; define it around the records you actually hold.
Use categories such as confirmed separate, possible duplicate and insufficient evidence. If your administrator later considers a merge, require both record IDs, the supporting evidence, conflicting values and the proposed surviving record. The assistant should not choose a survivor just because one has more completed fields.
Do not silently strip the parts that distinguish records. Removing branch names can make separate sites appear identical. Replacing every subsidiary with a parent brand can damage account relationships. Normalising presentation and deciding legal identity are different decisions.
Also document non-matches. If two records have been reviewed and deliberately kept separate, save the reason somewhere the next cleanup can find. Otherwise each new provider may rediscover the pair, spend time investigating it and propose the same mistaken consolidation.
Give every field a source-of-truth rule
A source of truth is the place you have agreed to trust for a particular fact. It need not be one application for every field. Your billing system might own invoice details, while a verified customer request supports an updated contact address.
Create a small field dictionary before the VA starts. For each included field, record its meaning, permitted format, accepted evidence and action when sources conflict. Explain the difference between a legal company name and a display name, or between a contact’s location and the company’s registered office.
Keep the original value beside the proposal. A useful staging row contains the CRM record ID, field name, old value, proposed value, evidence reference, date checked, reason and review status. Limit evidence access appropriately rather than copying confidential messages into a widely shared worksheet.
Recency is evidence to consider, not an automatic winning rule. A recently imported directory entry may be less reliable than a direct customer instruction. A new office address does not necessarily replace the invoicing address. If the meaning is unclear, the correct proposal can be “leave unchanged and ask”.
Standardisation also needs care. Removing outer spaces can be straightforward; changing a person’s name into title case may damage their preferred spelling. A phone number without a country cannot always be repaired by adding your own country code. Preserve leading zeros and extensions where relevant.
Do not require every cell to be filled. A blank can mean unknown, not applicable, deliberately withheld or missing from that particular export. Agree how these states are represented without writing placeholder text into fields that drive reporting or messages. Invented completeness makes the data harder to trust.
Protect consent, relationships and automation before imports
Treat marketing permissions and objections as restricted information, not formatting defects. A corrected email address does not create permission to contact it. A duplicate-looking record with an opt-out is not a nuisance to remove so the remaining contact becomes marketable.
Keep the evidence and scope of restrictions intact. If consent or suppression information conflicts, send the issue to the person responsible for that policy. Do not let the provider infer permission from a public website, a past purchase or the absence of an opt-out in an incomplete export.
Review relationships too. Contacts can be associated with companies, deals and support cases. An import containing only names and email addresses may miss those connections. Agree which links must remain unchanged and how the administrator will check them after approved updates.
Field edits can trigger work elsewhere. A stage change might enrol a record in a sequence; a tag might alter a mailing segment; an integration might overwrite the correction. Ask the administrator to inspect the relevant workflows and connected systems before choosing fields for the pilot.
If an automation needs pausing, the administrator should approve that change and its consequences. Record which process was paused, who owns reactivation and what happened during the pause. The VA should not disable business-wide workflows to make a small import easier.
Review the current import instructions for your exact product and plan. HubSpot’s import file guidance distinguishes field formats and unique identifiers used for updating existing records. Check your own importer’s treatment of blank cells, overwrite options and associations rather than copying assumptions from another platform.
Use a pilot that includes awkward records
A pilot is a small paid piece of the real service, not a promise of free work. Agree its size and fee with the provider. Choose enough varied records to test the rules without making the review itself unmanageable; the right size depends on complexity, not a universal quota.
Include an obvious formatting correction, a conflicting source, a possible duplicate and a legitimate separate record that looks similar. Include a record where the permitted response is to leave it alone. A sample containing only easy cases tells you little about judgement at the boundaries.
Give the provider a business-controlled staging sheet and ask for proposals first. Review every pilot decision, including unchanged and escalated records. Look for evidence, correct record IDs and consistent application of the rules rather than simply counting filled cells.
When the same uncertainty appears repeatedly, repair the brief. If “company address” means registered office to you and service location to the provider, telling them to be more careful will not settle it. Add the missing definition and have the affected proposals reviewed again.
Only after the proposals pass should the administrator authorise a very small controlled live test. Preview the field mapping, preserve the exact approved import file and verify the target IDs. Check that an update-only operation will not unexpectedly create new records when an identifier is missing or unmatched.
Read the changed records back from the CRM afterwards. Compare the actual values, associations and status with the approved proposals. Check the import results and relevant automation logs as well. A successful upload message is not proof the intended records changed correctly.
A hypothetical cleanup keeps two branches separate
Imagine a small equipment-servicing business with records collected from enquiries, bookings and trade events. Its owner wants company names to be easier to search. The following is a hypothetical example, not a report of a tested customer project.
The first scope covers company display names in one enquiry list. It excludes billing details, marketing permissions and live service cases. An administrator creates the necessary evidence snapshot, checks recovery limits and gives an independent VA a restricted extract with record IDs and only the comparison fields needed.
The provider finds two records beginning “Harbour Workshop”. One refers to a northern branch and the other to a southern branch. Both use a shared reception address, but their service locations and booking histories differ. The provider records them as separate branches and proposes no merge.
Another record has accidental spaces around a name. The field rule permits trimming outer spaces without changing wording. The provider logs the original and proposed values against that specific record ID. This is an approved type of correction, although it still waits in staging for the pilot review.
A third record uses a shorter trading name than the billing system. The provider does not replace it automatically. The field dictionary says display name and legal billing name serve different purposes. The question returns to the owner, who confirms the current display name should remain.
During the import check, the administrator discovers the display-name field synchronises with another system. They verify the direction and timing before applying the approved small batch. Afterwards they inspect both systems, including the deliberately unchanged branch records.
The result is modest but useful: the agreed formatting fault is corrected, the branches remain distinct and the unresolved policy question has an owner. The service has not been judged by how many records disappeared. It has been judged by whether the right records became easier to use without losing meaning.
Copy this brief, then fill in your own boundaries
Use the following as a working service brief, not as a legal agreement or permission to edit everything. Replace each bracketed item before sharing. The full instructions belong in the same business-controlled location as the staging sheet, so revisions do not get lost in chat.
“Please review [record type and exact saved list] in [CRM]. The problem we are fixing is [observable problem]. This batch covers only [named fields]. Do not work outside this list or add other fields to the project without agreement.
“Prepare proposed changes in [approved staging location]. Include record ID, field, original value, proposed value, supporting evidence, date checked, reason and review status. Keep the original export unchanged. Do not copy customer data into other tools or personal storage.
“Use [source and matching rules] to decide proposals. Keep [specific similar-but-separate cases] separate. When evidence conflicts or identity is uncertain, leave the live record unchanged and add the question to [review queue] for [named decision-maker].
“You may [explicit permitted investigation actions]. You may not import, merge, delete, change consent, alter ownership or lifecycle stages, trigger outreach or change integrations. Any later permission will identify the exact action and approved batch separately.
“The pilot contains [agreed sample and tricky cases]. Delivery is due [agreed date] for [agreed fee and included revisions]. We will review all pilot decisions before authorising any live update. Stop and tell [contact] if unexpected changes, mismatched IDs or sensitive data appear.
“The administrator owns backup and recovery. The known recovery limits are [specific exclusions]. Keep working files in [restricted location], allow access only to [approved people] and follow [agreed retention and deletion process] when the service ends.”
Attach a completed example staging row using fictional data, plus an example of a record that must remain unchanged. Ask the provider to explain those two decisions back in their own words. That short conversation often reveals an ambiguous rule before it reaches actual customer records.
Accept the changes by checking what stayed intact
A completion report should distinguish records reviewed, proposed corrections, approved corrections, applied corrections and unresolved questions. Those are different states. Do not report a proposal as a finished update or count two field edits as two cleaned customers.
Agree the unit of payment too. An hourly review, a fixed batch fee and a price per accepted record create different incentives. A payment rule based only on records removed can encourage unnecessary consolidation. Define accepted work around correct decisions and evidence, including justified decisions to change nothing.
Review all applied pilot changes and all high-risk exceptions. For later low-risk batches, agree a sampling method alongside mandatory review of conflicts. Take samples from different sources and decision types rather than only the first rows in the file. Expand checking if an error suggests a shared rule was misunderstood.
Keep a change log tied to the exact batch. Record who approved it, who applied it, when it ran and where the before-and-after evidence lives. Check important relationships and restrictions separately: field-level parity alone cannot show that a contact stayed linked to the right company.
If something goes wrong, stop the batch and preserve the evidence before attempting repairs. Ask the administrator to compare the current value with the logged before-and-after values. A legitimate update made by someone else after the cleanup must not be overwritten by a blind rollback.
Recovery may require restoring particular fields, correcting associations or specialist help. Never treat deleting the newly visible records, reimporting the whole old export or recreating merged contacts as a universal undo procedure. Work from the product’s current supported recovery options and the actual evidence retained.
Fix the entry point so the same mess does not return
Once a batch is accepted, trace where each recurring problem began. Several apparent duplicates might come from one recurring import. Missing country information might originate in an enquiry form. An integration might be reintroducing old names after every manual correction.
Give the provider a short recurring report of observed patterns, with examples and source references rather than speculation. Keep changes to forms, validation rules and integrations as separate administrator tasks. Someone engaged to review records should not redesign your CRM data model without a new scope.
Decide whether the service should continue. A one-off backlog may need no ongoing retainer. Regular incoming data may justify a periodic exception review, but agree its volume, fields, permissions and escalation process explicitly. Do not allow a successful pilot to become indefinite authority over all customer information.
When the service ends, retain the business copy of the approved changes, rules and unresolved queue. Remove unnecessary access and arrange removal of working copies under the agreed policy. Do not delete the audit evidence you need just because the provider has finished.
If the next project involves adding prospects, our lead research and CRM management guide covers that different workflow. Keep it separate from this cleanup: permission to correct an existing record is not permission to gather new contacts or send messages.
Your first useful outcome is a small, verified batch with a record of why each change happened. Once another person can review it without guessing, you have something you can safely repeat, narrow or stop.