Structure briefing · the LeadGrow campaign · Pod 1, personal Bison install
This page is the layout, top down: which Bison install the campaign lives on, what a pod actually is, how two different clients share one workspace, how 116 domains and 613 inboxes are arranged underneath, and where the campaign pipeline plugs in. Numbers are here to describe the shape of the build, not to grade it. A short read on how the current run is going sits at the end.
Five layers. Read it downward: an install holds pods, a pod holds a workspace, the workspace holds domains, domains hold inboxes, each inbox has a sender identity. The client is the thing that does not appear in that chain. It arrives sideways, as an assignment written onto sender identities.
This is the part worth slowing down on. Pod 1 is a single Bison workspace, and it is shared. 613 inboxes sit inside it. The LeadGrow campaign holds 525 of them, 48 still carry the tag of a client that has since churned, and 40 carry no client tag at all. Nothing in the workspace, and nothing in the domain names, separates one client's sending identity from another's. The separation is the tag on the sender email, and only that. That churn is why the fleet looks the way it does. The top 75 percent of the departing client's domains were reassigned to LeadGrow, which is a retag and a redirect rather than a rebuild, so a large part of what LeadGrow sends from today is inherited infrastructure that was already warm.
Practically, this means the tag is load bearing. Anything that selects inboxes for a send has to filter on it, every time, or one client's campaign can reach for another client's sending identity inside the same workspace.
116 domains carry the 613 inboxes, and they are not one fleet. They are two, with different shapes. Most domains carry 2 inboxes each, the pod default, and sit on the neutral agency naming pool shared with the churned client's domains. Four domains carry about 100 inboxes each and sit outside that pool entirely. Split by tag, LeadGrow's 525 inboxes are 113 on 59 pod shaped domains and 412 on 12 others, with 396 of those on the four large ones. So roughly three quarters of what LeadGrow sends from is not in the pod shape. The default is 2 inboxes per domain, provisioning warns above 3, and the documented hard cap is around 20, so those four are about five times the cap. That is not a fault to fix today. It is legacy bulk sitting alongside the pod fleet, and it matters because it changes how rotation can work.
Inboxes sit on two mailbox providers, and that matters structurally because the ramp schedule differs by provider. How fast an inbox is allowed to climb, and where it tops out, is decided by what the fleet model thinks that inbox is.
These are settings, read from configuration. They describe what the pod is allowed to send, which is the structural number. What it did send is in the closing section.
Configured capacity is not a target. The operating posture is that roughly half the fleet sends while the other half rotates and rests, and that split applies to whatever share of the fleet is in play rather than only to the whole. Resting is what keeps a domain and its inboxes healthy enough to still be sending in three months.
The pod already has the shape for this built in. Its rotation template is two active batches plus one reserve on a fourteen day cadence, so a third of the fleet is meant to be held back and cycled in. A half sending, half resting posture is tighter than that template, deliberately.
So the gap to close is concrete: the fleet is currently configured as if all 525 inboxes send, and the agreed posture is that about half should be resting at any time. That is a configuration change to make deliberately, not a fault. It lowers the daily ceiling and is meant to.
One practical consequence, given the shape above. Resting is a domain level move, not an inbox level one, because reputation lives on the domain. On a 2 inbox domain that is easy, rest the domain and 2 inboxes go quiet. On a 100 inbox domain the smallest honest unit of rest is 100 inboxes at once, about a fifth of the LeadGrow fleet. So a half sending, half resting posture is straightforward across the 59 pod shaped domains and lumpy across the four large ones. Worth deciding deliberately rather than discovering later.
Twelve campaigns sit in Pod 1. Because a pod is shared, a campaign cannot infer its client from the workspace it is in. It binds by name prefix, longest match wins.
The campaign pipeline now understands pods. Given a campaign, it works out which pod that campaign belongs to, and uses that pod's own key rather than switching workspace part way through a run.
When it picks inboxes to send from, it will only take inboxes carrying the right client tag. Given that the tag is the only separation inside a shared pod, that is the piece that keeps one client's campaign inside its own half of the fleet.
A short read on the current state of the campaign, kept deliberately brief. It describes this run, not the structure above.
| Where the 12 campaigns stand | Count | What that means |
|---|---|---|
| Completed | 2 | Finished their list |
| Between 95 and 100 percent through | 5 | Read as paused, effectively finished rather than blocked |
| Real runway left | 2 | One at 68.6 percent, one at 13.45 percent |
| Never sent | 3 | Staged or stalled, not yet established |
| Total | 12 |
Open rates appear nowhere on this page. Open tracking is switched off deliberately in the standard sending settings, so opens are not measured rather than zero.
29,438 sends across 613 inboxes is roughly 48 per inbox for the life of the fleet (derived), which is low for a fleet this size.
Young and still warming means the number rises on its own. Idle means capacity was paid for and not used.
16 of 416 Microsoft inboxes carry the tag. Either it governs what actually goes out, or it only shapes what the fleet model believes.
One answer from whoever owns send rates settles it. Cosmetic means nothing to fix.
Three campaigns exist in Pod 1 and have never sent an email.
Staged deliberately means nothing to do. Stalled means prepared work is sitting idle.
The provider split is structure, not a scoreboard. The Microsoft and Google counts are here because ramp ceilings differ by provider, which changes the shape of the fleet. They are not a comparison of how the two groups perform.
The 7,492 per day figure is what is configured. Real throughput against that setting has not been tested here, so nothing on this page says actual capacity is higher or lower.