Pre-flight bounce check before you launch a cold email sequence

Build me a pre-flight console my outbound team opens right before pressing send on a cold email sequence. The whole point is a gate: it predicts the bounce rate of the send, shows that number against the danger line we configure, and refuses to let anyone launch until the list is clean enough. A dirty list should never be able to torch our sending domain because someone was in a hurry.

Opening screen is a picker with three ways in. First, our draft sequences in Hunter, read with List Sequences, showing name, recipient count and created date, with not yet started sequences first. Second, our saved lead lists, read with List All Leads Lists, showing list name and lead count. Third, a paste box for a Google Sheet link plus a tab name and range, for lists that live outside Hunter. Choosing any one of the three opens the same review screen.

The review screen loads its recipients from whichever source was picked. For a sequence, use List Sequence Recipients, which also gives me each recipient's current sending status. For a lead list, use Get Leads List and List Leads to page through every lead. For a spreadsheet, use Get Values on the range the rep gave, show the header row, and let the rep map which column holds the email address and which optional columns hold name and company.

At the top of the review screen sits the headline number: the projected bounce rate for this send if it launched exactly as it stands. Render it large, colored against the configured danger line, defaulting to a 2 percent danger line and a 1 percent target since deliverability guidance says reputation damage begins as bounces approach 2 to 2.5 percent. Directly under it, a breakdown bar with counts and percentages for each verdict bucket: deliverable, risky, catch all, unknown, disposable, and undeliverable, plus separate counters for rows that are still pending and rows never checked. Next to that, two flag counters: role based addresses such as info@ and sales@, and addresses whose local part looks like gibberish.

Compute the projection as a weighted sum rather than a raw count, and make the weights visible and editable in settings. Sensible defaults: deliverable 0.5 percent, catch all 15 percent, risky 40 percent, unknown 30 percent, disposable 85 percent, undeliverable 100 percent. Rows that are pending or never checked should be weighted at the unknown rate so an unverified list can never look safe. Let the rep expand the headline to see the arithmetic, bucket by bucket, so nobody has to take the number on faith.

Below the headline is the recipient table, sortable and filterable, one row per recipient. Columns: email address, name, company, verdict badge, the date that verdict was produced, a role based flag, a gibberish flag, current status inside the sequence when the source is a sequence, and the underlying lead id when the source is a lead list. Let me sort by verdict severity, filter to any bucket or flag, and search by address or domain. Selecting rows with checkboxes is the core interaction, including a one click select all risky and unknown.

Verification runs through Verify Email Address, one call per address, batched with sensible concurrency and backoff because the verifier is rate limited. Two nuances matter here. Hunter's verifier can answer with a verification in progress response instead of a verdict, so those rows must show a pending state and get re-checked on a backoff until a real verdict lands. Never render a guess in place of a pending answer. And verification burns credits, so cache every verdict with its address and check date in app storage shared across the team, and only spend a credit on addresses that have no cached verdict or a verdict older than the freshness window, which is configurable and defaults to 90 days. Show cached rows as checked on their date, give every row a re-verify button, offer a bulk re-verify for a selection, and warn the rep with an address count before kicking off any large verification pass.

The gate itself: the Start button stays disabled the entire time projected bounce sits above the danger line, with a tooltip explaining roughly how many risky and unknown recipients would need to go for the number to clear. As the rep ticks rows for removal, recalculate the headline live so they can see the projection fall before committing to anything.

Cleaning happens inside the app, never by sending someone back to Hunter. With rows selected, the rep can cancel any already scheduled emails for those recipients using Cancel Scheduled Emails, delete the bad leads outright with Delete Lead, or keep them for later by tagging them through Update Lead with an excluded from send marker so they stay in the list but are visibly quarantined. Every bulk action needs a confirmation dialog naming the exact count, and afterwards the table should refresh from List Sequence Recipients, Get Leads List or List Leads so the rep is always looking at the real current state.

Once the number is green, Start becomes clickable and launches the sequence with Start Sequence, behind a confirmation that restates the projected bounce, the recipient count going out, and how many recipients were removed during pre-flight. Log that send to history immediately.

For the spreadsheet path, everything above works the same except there is no sequence to launch. After verification, a write verdicts back button uses Update Values to write the verdict, the check date, the role based flag and the gibberish flag into columns beside each row, creating those header cells if they are missing, so the sheet itself stays the source of truth. Instead of a Start button, show a clear ready or not ready verdict for the list along with the headline projection.

Add a history view listing every past send: date, sequence name, recipient count, projected bounce at launch, how many recipients were dropped in pre-flight, and the actual bounce once it is known. A refresh outcomes button should re-read List Sequence Recipients for past sends and recompute actual bounce from the recipient delivery statuses. Show predicted versus actual side by side with the gap called out, because that gap is how the team learns where to set the threshold.

Finally a settings page holding the danger line, the target line, the verification freshness window, the per bucket bounce weights, the list of role based prefixes with defaults of info, sales, admin, support, contact, hello, billing, office, team, marketing, hr, jobs and no-reply, and which buckets get auto selected when a rep clicks clean up. Anyone on the outbound team can open the app, and the verdict cache, settings and send history are shared across the whole team so no address gets paid for twice.