Short answer: A CRM cleanup fails when it is treated as a project. Point an autonomous AI agent at the database instead: have it segment records by business value, dedupe and merge on a deterministic key, enrich only the tier that matters, and then re-run weekly on a schedule so decay never rebuilds. Twin agents do this by operating HubSpot, Salesforce or Pipedrive directly in the browser and through their APIs, so no field is out of reach and no export-reimport cycle is needed.
Most revenue teams reach the same wall. The CRM holds 100,000 contacts. Maybe 50,000 are worth keeping. Perhaps 25,000 genuinely matter. Nobody can say which is which, enrichment credits are burned indiscriminately, and every attempt at a bulk update turns into a CSV export that never comes back in clean.
Why bulk CRM cleanup keeps failing
Three failure modes repeat across teams:
- The export-reimport loop. Data leaves the CRM as a CSV, gets enriched, and comes back as a partial overwrite that clobbers good values with worse ones.
- Enrichment sprayed evenly. Credits get spent on the 75,000 records nobody will ever call, instead of the 25,000 that drive pipeline.
- No continuity. A cleanup sprint fixes March. By June the same rot is back, because nothing runs between sprints.
Enrichment vendors solve the lookup problem, not the write-back problem. That gap is where the work actually lives.
Step 1: score records before you touch them
Do not start with enrichment. Start with triage. Have the agent read every contact and assign a keep, park or purge tier from evidence already in the system:
- Last meaningful activity date, not just last email open
- Whether an associated company has an open or closed-won deal
- Whether the contact title maps to your buying committee
- Whether the email has hard-bounced or the domain no longer resolves
The output is a scored list, not a change. Nothing has been written yet. This step alone usually reclassifies half a database as archive-only, which immediately cuts the enrichment bill.
Step 2: dedupe on a deterministic key, merge with rules
Duplicate detection by fuzzy name matching produces false merges that are expensive to undo. Give the agent a strict key instead — normalised email domain plus normalised full name, or a CRM-native company ID — and an explicit merge rule set:
- Keep the record with the earliest created date as the survivor
- Take the most recent non-empty value for every field, per field, not per record
- Preserve all activity history, all deal associations, and all list memberships
- Log every merge with both original record IDs so any merge can be reversed
An agent that operates the CRM interface can perform the native merge action, which preserves associations correctly. An API-only script often cannot, and that is where history gets silently dropped.
Step 3: enrich only the tier that matters
Now spend money. For the keep tier only, the agent fills the fields that change decisions: current employer, current title, seniority, headcount band, region of actual operations rather than registered headquarters, and a verified email. Where a data vendor has no answer, the agent goes and looks — company site, careers page, public profile — the same way a researcher would.
Two rules keep this from producing noise:
- Never overwrite a human-entered field. Write to a parallel enriched field and let the CRM owner promote it.
- Stamp every enriched value with a source and a date, so stale data is visible rather than assumed.
Step 4: run it on a schedule so decay never accumulates
Contact data decays continuously. Job changes, acquisitions, domain migrations and departures erode a database at roughly two to three percent a month. A weekly scheduled run over the keep tier costs a fraction of an annual cleanup and never lets the backlog reform.
A practical cadence:
- Daily: new records created in the last 24 hours are deduped and enriched at creation
- Weekly: the keep tier is re-verified for job changes and bounced emails
- Monthly: the park tier is re-scored, and anything that has become relevant is promoted
Step 5: keep an audit trail the RevOps owner trusts
Adoption dies the first time someone finds a wrong value with no explanation. Every run should produce a change log: record ID, field, old value, new value, source, timestamp. Push it to a sheet or a Slack channel. Reviewing a hundred-line diff takes four minutes and buys the permission to keep writing.
What to measure so you know it is working
Pick four numbers and track them weekly. Anything else is noise:
- Duplicate rate in the keep tier, which should trend to under one percent and stay there
- Field completeness on the six fields that actually drive routing and scoring
- Bounce rate on sends, the fastest external proof that verification is holding
- Records touched per run, which should fall over time as the backlog clears and the agent settles into maintenance volume
If duplicate rate is flat but records touched keeps climbing, your intake is broken, not your cleanup. Fix the creation path — usually a form or an import — before adding more enrichment.
Where Twin fits
Twin agents are fully autonomous and self-serve: you describe the cleanup policy in plain language, and the agent builds itself, then runs on a schedule or on an event such as a new record being created. Because Twin operates real web applications in the cloud as well as APIs, it can perform native merges, edit fields the API never exposed, and work across your CRM, your enrichment vendor and your sequencing tool even where no integration exists between them. When a CRM interface changes, the agent self-heals instead of failing silently at 3am. That is the difference between a cleanup you did once and a database that stays clean.
