The problem this solves
Every outbound program leaks in the same place: the suppression data lives in the sending tools while the master database lives in the CRM, and nothing reconciles them. Someone unsubscribes in a Lemlist campaign; their HubSpot record stays innocently contactable, and next quarter a different campaign - built by a different person from a different list pull - emails them again. To the recipient it reads as a company ignoring their explicit request, because functionally it is.
Hard bounces cause quieter damage. Every campaign that resends to known-dead addresses spends domain reputation on guaranteed failures, and reputation is cumulative: mailbox providers remember bounce rates across sends. The information to prevent this already exists inside the sending tools after every campaign; it simply never travels back to the system every future list gets pulled from, so each new campaign re-learns the same dead addresses at full price.
This is compliance work as much as performance work. Honoring an unsubscribe is a legal obligation that does not care which tool collected the request, and 'the suppression stayed in the sending platform' is an explanation nobody wants to give. The sweep is dull, recurring, and consequence-laden - the exact profile of work that should never depend on someone remembering.
How the mission runs
- Export suppressions from both tools. The agent pulls unsubscribes and hard bounces from your Lemlist and Instantly campaigns - both tools, because a program running two senders has two separate leaks, and reconciling only one leaves the other quietly feeding future mistakes into every new list.
- Deduplicate and classify the sweep. The combined list is deduplicated across tools and split by type, since unsubscribes and bounces carry different meanings: one is a request to honor permanently, the other a deliverability fact that protects your domain. Soft bounces are excluded so temporary failures are never promoted into permanent suppression.
- Match each address to its HubSpot record. Every swept address is matched to its HubSpot contact. Addresses with no existing record are noted separately rather than silently dropped, so the report accounts for every row and future imports can be screened against them before they reach a campaign.
- Stage the do-not-contact updates for review. The agent prepares the batch - unsubscribed contacts marked do-not-contact, hard bounces flagged so list pulls exclude them - and stages it behind the review gate. You see exactly which records change and how before HubSpot is touched, and the applied batch matches what you approved.
- Deliver the hygiene report. A closing report and CSV summarize the sweep: totals by type and tool, records updated, addresses that had no CRM match, and any anomaly worth a look - like a bounce cluster pointing at one bad source list. The paper trail doubles as your compliance record.
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 reconciled HubSpot: every unsubscribe from Lemlist and Instantly marked do-not-contact, every hard bounce flagged out of future list pulls, all applied through your review. The hygiene report and CSV document the sweep end to end - counts by type and tool, unmatched addresses, and any pattern worth investigating - so the next campaign launches against a database that respects both the law and your domain.
Make it yours
- Run it as a standing post-campaign step, so suppressions travel to the CRM within days of being collected rather than at quarter end.
- Extend the sweep with complaint markers and repeated soft-bouncers as a watch list, catching addresses trending toward dead before they get there.
- Add a monthly one-line summary to your team channel, keeping suppression hygiene visible to everyone without asking anyone to open a report they never will.
Frequently asked questions
Why do hard bounces matter if the person never asked to be excluded?
Because mailbox providers score senders on bounce rates, and repeatedly mailing dead addresses erodes deliverability for every future campaign. Flagging hard bounces in the CRM means every list pulled from it is pre-cleaned, which quietly raises the floor of everything you send afterward.
Can a do-not-contact flag be applied by mistake?
The review gate exists for exactly this: you see each proposed change with its source - which tool, which campaign, unsubscribe or bounce - before anything writes. Soft bounces are excluded by design, and any edge case you decline in review simply stays unchanged in HubSpot.
What about swept addresses that are not in HubSpot at all?
They are reported as their own list rather than discarded, because they typically came from an imported list that bypassed the CRM. Keeping them lets you screen future imports against known unsubscribes and dead addresses, closing the side door that suppression leaks usually enter through.