The problem this solves
The messy list is a recurring character in every go-to-market motion: the event export with names in capitals, the purchased file with three domain formats, the partner spreadsheet where company and contact share a column. The pressure is always to import it now, because the leads are time-sensitive and the cleanup can theoretically happen later. Later never comes. The raw rows land, collide with existing records, and the CRM absorbs another sediment layer that every future report has to dig through.
The damage from one careless import outlasts the campaign it served. Duplicates split activity history, unverified addresses bounce and dent sender reputation, and inconsistent company names break the joins that scoring and reporting depend on. Worse, imports are the moment where bad data enters at scale: a single afternoon of enthusiasm can undo a quarter of careful hygiene work, and the person importing rarely sees the downstream cost.
The discipline that fixes this is simple and rarely followed because it is tedious: clean before the list lands. Normalize the rows, verify every address, and check each one against what the CRM already holds, so the import adds only genuinely new, genuinely reachable people. Making that discipline effortless is the entire point of running it as a mission, because a quality gate only works if it is easier than skipping it.
How the mission runs
- Parse and normalize the raw CSV. The agent takes the CSV from the thread and standardizes it: names to consistent casing, companies stripped of stray suffixes and whitespace, domains canonicalized, columns mapped to your CRM fields. Malformed rows are set aside with the reason, so the file's problems are cataloged instead of imported.
- Verify every email on the list. Email Verification runs on each row before anything else happens. Valid addresses continue; bounced, dead-domain, and role addresses are moved to a rejects section with their classification. On purchased or scraped lists this step routinely removes a substantial slice, which is precisely the slice that would have damaged deliverability.
- Dedupe against HubSpot. Each surviving row is checked against your existing HubSpot contacts and companies, by email, by domain, and by normalized name. Genuine new records go to the import queue; matches to existing records are held out separately, since updating a known contact is a different decision than adding a stranger.
- Import only the clean additions. The verified, deduplicated remainder is imported to HubSpot in one idempotent pass, each record noting the source list and import date, so this batch remains identifiable and reversible as a cohort forever. Re-running the mission on the same file never creates a second copy of anything.
- Deliver the reconciliation. You receive the full accounting as a CSV: rows imported, rows rejected with the failure reason, and rows matched to existing records with the match evidence. Every row of the original file is accounted for in one of the three buckets, so nothing simply vanishes in the wash.
The prompt
This is the exact objective the agent receives. Swap the obvious placeholders for your own domain, segment or channel and run it as-is from the console, Slack, or the API.
What comes back
A HubSpot database that gained only clean rows: normalized, verified, deduplicated contacts imported with the source list noted on every record, and existing records untouched. Alongside it, a reconciliation CSV accounting for every row in the original file - imported, rejected with reason, or matched to an existing record - so you can defend exactly what entered the CRM, and the messy original can be archived with a clear conscience.
Make it yours
- Add an enrichment pass so the clean rows arrive with firmographics already attached, turning the import gate into an import-and-qualify gate in the same run.
- For the matched-to-existing bucket, ask for a proposed field-update list, then apply it as a second gated step once someone has reviewed what would change.
- Make it the standing intake path for every list source you have - events, partners, content syndication - so nothing reaches HubSpot without passing the same gate.
Frequently asked questions
What happens to rows that match existing CRM records?
They are held out and delivered as their own section of the reconciliation, with the matching evidence per row. Updating a record you already own is a judgment call, so the mission surfaces the matches and waits; applying updates is a second, explicitly approved step rather than a side effect of an import.
Can I review the clean list before it imports?
Yes. Ask for the gated variation and the mission stops after verification and dedupe, delivering the proposed import as a file for approval. Many teams run the gate for purchased lists and let event lists flow straight through, which is a policy the prompt states in one sentence.
How is a re-import of the same file kept safe?
Imports are idempotent and every record notes its source list, so running the mission twice on the same file adds nothing twice. The same marker makes the whole batch identifiable later: if a source turns out to be low quality, the cohort can be found, evaluated, and unwound as a unit.