The problem this solves
The cold email that lands in a customer's inbox is the one the account team hears about first. The one that reaches a competitor gives away the pitch, and the one that reaches a partner strains a relationship built over months. None of these companies belong on an outbound list, and all of them end up there because lists are built from external data that knows nothing about your relationships.
Suppression is a matching problem before it is a policy problem. The customer in HubSpot is Acme Corporation with acme.com on the record; the list has Acme Corp with acme.io; the competitor CSV has ACME. Exact matching misses most of these. Matching on normalized domain and on name variants catches them, and every catch needs a reason attached so the person reviewing the removals knows which rule fired.
The counts are as much the deliverable as the list. If 300 of 2,000 rows are current customers, the list source overlaps your base and the next list should exclude it upstream. If the do-not-contact file removes a handful, the policy is working.
How the mission runs
- Load the three suppression sources. The Lead Verification Agent reads current customers from HubSpot (companies at the customer lifecycle stage, or the definition you give it), parses the attached competitor and partner CSV, and loads your do-not-contact domains. Each source is normalized to domains and canonical names, and the agent reports the size of each before matching starts.
- Match list <name> against each source. Every row on list <name> is compared on normalized domain first, then on company name variants with suffixes removed, casing folded and common abbreviations expanded, with the person's email domain as a further clue. Each match records the source it came from and the rule that fired, so a name-only match can be reviewed separately from a domain match.
- Resolve the ambiguous matches. Name-variant matches without a domain match are grouped for review rather than removed silently, with both records shown side by side. You can approve them in bulk, or ask the agent to resolve the domain for both sides through company search and decide on the evidence.
- Save <name> - suppressed with counts per reason. The surviving rows are saved as a new persistent list named <name> - suppressed, leaving the original untouched. The removed rows are kept in a companion list with the reason on each, and the summary shows the count per exclusion reason: customer, competitor, partner, do-not-contact, and any row that hit more than one.
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 new list <name> - suppressed in the workspace with only the rows that passed every check, refreshable against the same suppression sources next time. A count per exclusion reason - current customer, competitor, partner, do-not-contact - plus the number of rows that matched more than one source and the number held for review as name-only matches. The removed rows sit in a companion list with their reason and the matched record, so the suppression can be audited or reversed row by row, and the original list <name> is unchanged.
Make it yours
- Add open opportunities to the customer definition so companies mid-deal are suppressed along with closed-won accounts.
- Suppress people instead of companies by matching contact emails against HubSpot, for the cases where only specific stakeholders at an account are off limits.
- Use Pipedrive, Attio or Zoho CRM as the customer source; the CSV and do-not-contact matching are unchanged.
- Run the suppression automatically before every export to Instantly or Lemlist, so no list leaves the workspace without passing through it.
Frequently asked questions
Why keep the removed rows at all?
So the removal can be checked. A loose name on the competitor CSV can remove a legitimate prospect, and the companion list lets you find that row, see the rule that matched, and restore it without rebuilding the list.
How are subsidiaries handled?
By domain they are separate companies and stay on the list unless the CSV or the do-not-contact file names them. If you want a customer's subsidiaries suppressed too, ask the agent to look them up through company search and propose the additions for your approval as a fifth reason.
Does anything change in HubSpot?
No. HubSpot is read as a suppression source only. The mission writes two lists in the workspace and a summary, and the audit trail shows every read it performed.
Can the do-not-contact list live somewhere other than a file?
Yes. Point the agent at a Google Sheet, a HubSpot list or a persistent list in the workspace, and it treats that as the source each time the mission runs, so additions are picked up on the next refresh.