Deliverability problems don't announce themselves: domains burn quietly, bounces pile up, and by the time reply rates drop, the damage took weeks. This is the dashboard and set of automations I built on EmailBison and EmailGuard so the whole team could see sending health at a granular level, with the routine responses handled automatically.
A cold email program is dozens of sending domains, hundreds of inboxes, and thousands of sends a day. Any one of those pieces can go bad: a domain lands on a blocklist, an inbox disconnects overnight, a campaign starts hitting a wall of bounces. The email platform knows, but it doesn't tell you. The default state of deliverability information is buried.
So I built the place where it all surfaces: one password-protected dashboard the whole team can read, backed by automations that handle the routine responses on their own.
flowchart TD
subgraph IN["What feeds it"]
direction LR
EB[EmailBison
sends, bounces, replies,
account events]
EG[EmailGuard
domain health,
placement tests]
end
IN --> HUB[One place receives every event
+ scheduled safety sweeps]
HUB --> DASH[Team dashboard]
HUB --> AUTO[Automations]
subgraph DASH2["What the team sees"]
direction LR
D1[Warmup +
domain health]
D2[Bounce +
reply analytics]
D3[Placement
tests]
D4[Blacklist +
automation logs]
end
DASH --> DASH2
subgraph AUTO2["What runs on its own"]
direction LR
A1[Bounce handling
+ suppression]
A2[Reply routing]
A3[Disconnect
rechecks]
A4[Slack
alerts]
end
AUTO --> AUTO2
style IN stroke:#8b5cf6
style AUTO2 stroke:#10b981
Modeled on how an ops team actually works a sending program day to day. Each view answers one question:
| View | The question it answers |
|---|---|
| Overview | Is anything on fire? High-level account, campaign, warmup, blacklist, and recent-automation metrics in one screen. |
| Warmup monitoring | Are our domains healthy? EmailGuard-powered domain health and host checks, per domain, before problems reach real prospects. |
| Account management | Which inboxes are connected, sending, or quietly broken? |
| Campaign view | What's actively sending right now across EmailBison? |
| Bounce & reply analytics | Where are bounces concentrating, and how do replies break down by email provider (Google, Microsoft, everyone else)? Provider-level grouping is what catches "we're fine on Google but dying on Microsoft." |
| Delivery cohort diagnostics | Is one campaign or account segment underperforming the rest? Compare cohorts side by side instead of staring at averages. |
| Placement tests | Are we landing in the inbox or the spam folder? Inbox placement review using recent live campaign copy, so tests reflect what's actually being sent. |
| Blacklist management | Who have we suppressed and why, with logs and history for every automated action. |
The design assumption behind all of it: any single alert can fail, so every alert has a sweep behind it that catches what slipped through.
Here's the problem with per-rep sequencing tools: every SDR ends up building their own campaigns, copy drifts, naming turns to chaos, and nobody can see the whole program. The fix wasn't one automation, it was two, each solving a different half of the ownership problem.
The first keeps ownership itself correct: reps and managers reassign accounts in HubSpot throughout the day, and Lemlist has no way of knowing that on its own, so a nightly sync pushes current HubSpot ownership into Lemlist's own owner field. That's what makes Lemlist's native "send as contact owner" setting work: drop a lead into the right standing campaign (one per rep, per play, created and updated centrally by script) and it sends from the correct rep automatically.
The second handles brand-new accounts that show up with no owner at all: when a signal (a job posting, or a job change for a former prospect) surfaces a company that isn't in HubSpot yet, it gets scored in Clay, and if it tiers as workable, it's round-robined to an SDR or account executive in that segment and written back to HubSpot — where the next nightly sync carries it into Lemlist.
Neither system touches every lead, on purpose. Shared, unowned plays — broad LinkedIn outreach, mainly — skip ownership entirely: SDRs use the Lemlist browser extension to drop leads into the same campaign without anyone worrying about whose account it is.
flowchart TD
subgraph SYNC["Nightly ownership sync"]
direction LR
S1[HubSpot ownership:
reassigned all day by reps + managers] --> S2[Synced to Lemlist's
owner field, nightly]
end
S2 --> OWNER[Lemlist: send as
contact owner]
OWNER --> STAND[Standing campaign,
one per rep per play]
subgraph NEWACCT["New-account round-robin"]
direction LR
N1[Signal: job posting or
job change] --> N2{In HubSpot yet?}
N2 -->|No| N3[Scored in Clay]
N3 --> N4{Tiers workable,
no owner?}
N4 -->|Yes| N5[Round-robin to an
SDR/AE in that segment]
N5 --> N6[Written to HubSpot]
end
N6 --> SLACK[Slack card tags the rep
+ one-click remove button]
N6 -.->|next nightly sync| S1
EXT[SDR uses the
Lemlist extension] --> GEN[Shared campaign,
no ownership check]
style SYNC stroke:#8b5cf6
style NEWACCT stroke:#10b981
style GEN stroke:#f59e0b,stroke-width:2px
Why this matters: SDRs never touch campaign setup. They don't build sequences, they don't copy templates, they don't decide routing. Ownership stays correct without anyone updating two systems by hand, new accounts get a rep the moment they're workable, and a new hire joins the program by being added to the routing pool. That's what an expensive sales engagement platform sells, rebuilt on a lightweight tool with a pair of ownership automations underneath it.