In this article
The short answer
Don't clean every sales record before a small test. Fix the fields that could make this task go wrong. Start with company identity, ownership and the stop list.
Start with the workflow's required fields
A research workflow may need a company website and a clear offering. Sending a message also needs a valid recipient, an owner and a current stop list decision. A meeting workflow adds calendar ownership and time-zone handling.
List those requirements separately.
The 2026 State of Sales research reports disconnected systems and data cleaning as concerns for sales artificial intelligence (AI) adoption. Those are survey responses, not proof that a particular cleanup project produces revenue. They explain why readiness belongs in the setup plan. [1]
Start with 1 workflow and name the fields it needs. Treat missing fields outside that task as a separate clean-up decision.
Resolve identity before adding more information
Company names are not reliable identifiers on their own. Similar names, local trading names and parent companies can cause a correct fact to land on the wrong record. Review the website, legal or trading relationship and the scope of the company you intend to sell to.
Treat a domain as evidence, not a perfect identity key. Groups may share domains; one business may use several. When the match is unclear, keep the proposed research separate until someone confirms the relationship.
Adding more facts to the wrong company makes the error harder to spot.
For a hypothetical Bengaluru business with several offices, verify whether a Pune contact belongs to the same buying team. A shared company name is insufficient.
Check 2 records with similar company names before importing research. Make the reviewer confirm the website and business unit.
Protect suppression and ownership
An opt-out must survive imports, duplicate merges and tool changes. Test a suppressed contact through the full workflow before sending real messages. A copy of the same person in another list should not create a fresh permission to contact them.
Give each active record a named owner. Decide how existing customer relationships and open conversations affect new campaigns. This prevents a technically valid automation from interrupting a conversation already being handled by another person.
Import 1 stopped test contact again. The stop decision should remain even if a fresh row appears in another list.
Make changes narrow and inspectable
For every field the automation can update, document the source, the allowed change and the conflict rule. An imported value should not silently erase a deliberate human correction. Store proposed changes separately when the confidence or authority is insufficient.
Check what happens when the connection fails halfway through. The next run should identify work already completed and continue safely. Repeating an operation must not create duplicate people or close a task twice.
Ask for a demonstration using interrupted work, not just a clean first run.
For a hypothetical Indian services team, keep rupee values and foreign-currency values labelled. A currency conversion should never silently replace the original sales record.
Attempt 1 permitted field change and 1 forbidden change in a safe test. Check both results before granting real access.
Measure readiness by exceptions
Sample the records in your pilot and count the blockers. Look for unclear companies, missing owners, unresolved duplicates, missing contact details and stop list conflicts. Fix the most common blockers for that workflow.
Keep the resulting checklist small enough to use every week. Track how often people repair outputs and which fields cause those repairs. That gives the team a practical improvement queue.
A complete-looking customer relationship management system (CRM) is less useful than a smaller set of dependable records with clear ownership.
Choose 5 failed records and group their causes. Fix the most common cause before buying more facts for those same records.
Put it into practice
Test five messy records first
Before connecting a real campaign, prepare a small test set your team can inspect. Use invented records or records you have permission to test. Never send to them by accident.
For an illustrative Bengaluru team, Priya prepares 5 cases. She includes a duplicate person, a shared domain, an old job title, an opted-out contact and a disputed owner.
Write the correct outcome beside each case before the run. A duplicate should not receive two messages. An unknown owner should go to a review queue.
Your customer relationship management system, or CRM, may hold several views of the same person. Agree which record wins when their contact choices conflict. Test that rule.
The shared-domain case checks company identity. A parent group and a business unit may need different research. A domain match alone should not choose the sales target.
The old-title case checks freshness. The tool should retain the date and source of the role. If it can't confirm the current role, the brief should say so.
The disputed-owner case checks authority. Ask whether the tool can propose a change without applying it. Review should not require granting write access to unrelated fields.
Then interrupt a safe test halfway through. Run it again and inspect the results. Look for duplicate records, repeated tasks and changes that lost their original reason.
The tempting mistake is adding more contact fields before fixing identity. We would reverse that order. More detail makes a wrong match look more convincing.
For a Pune colleague reviewing the test, a simple sheet is enough: input, expected outcome, actual outcome, owner and next step. Keep the failed rows.
Fix the first repeated failure and run those cases again. You don't need a large clean-up project to learn whether the chosen workflow can be trusted.
Common questions
Do we need to clean the entire CRM first?
No. Start with records and fields required by the pilot. Keep incomplete or disputed records out of automatic actions until their blocking issues are resolved.
Should an AI tool overwrite CRM fields automatically?
Only within explicit field-level rules and authority. Conflicts with human corrections should be visible and resolved deliberately.