KaizenSpark Tech Outbound infrastructure we build, run and answer for · how it is built, including what is not finished
What this isThe rulesThe system SizingHow it works How it is builtOpen the platform
Outbound infrastructure

Outbound that protects the domain you actually trade on.

Sending domains, warmup, sequences, deliverability monitoring and a reply inbox a person actually works — built, run and answered for by us. You get booked meetings and a report you can check. We run it on our own pipeline before anyone else's, which is the only honest basis for offering it.

We publish what is not finished as plainly as what is. The capability table on how it is built names every gap, including the ones nobody would ask about.

Size it — who are you targeting?
Sends per working day
Mailboxes needed
Sending domains
Live sending begins

Sized for eight meetings a month at this motion's typical reply rate. Adjust the target in the full model below.

21 days

Of warmup before anyone is contacted

45

Messages per mailbox per day, hard ceiling

0

Sends from your primary domain, ever

2

Contacts per company per 30 days

What this is

An outbound function, run for you.

We build software for a living, so we did not rent an outbound tool and hope. We built the thing, and we run it on our own pipeline before we run it on yours.

What you get

Sending domains and mailboxes stood up and warmed properly, sequences written for your motion, every reply read and answered by a named person, meetings booked into your calendar, and a weekly report with the numbers behind it.

What it is not

Not a tool you log into and operate yourself — not yet. We run it; you receive the meetings and the report. Self-serve is a later phase and we are not pretending otherwise.

Why it is ours

Because the rules that keep a domain alive have to be enforced in code, not agreed in a document. Renting a tool means inheriting somebody else's decisions about what happens when the quarter is short.

Non-negotiables

Eight rules the system will not let anyone break.

These are not guidelines. Each one is a function or a constraint in the database, with a test that fails if it is removed — because the reason outbound programmes burn a domain is that under pressure somebody decides just this once is fine. Nobody here can make that decision, including us.

01

Never your primary domain

Your primary domain is never in the sending path. Cold volume there puts invoices, client replies and password resets at risk, and that damage is not quickly undone. We send from registered near-variants that redirect to your real site.

02

Nothing sends before day 21

A mailbox ramps five messages a day toward a ceiling of forty-five. It cannot join a live campaign before its domain is twenty-one days old. The engine refuses; it is not a setting anyone can override in a hurry.

03

Health below 60 pauses the domain

Computed hourly from authentication state, rolling bounce and complaint rates, blocklist status and age. It resumes at 68, not 60 — the gap is deliberate, so a domain sitting on the line does not flap in and out of service.

04

Suppression is permanent and one-way

Hard bounce, complaint, unsubscribe or an explicit ask: the address is out, workspace-wide, with no remove button. A list you can quietly un-suppress is a pause button, and it is the easiest way to end up in front of a regulator.

05

Two people per company per month

Three colleagues receiving near-identical mail in one week is how an entire company marks us as spam at once. The throttle is enforced in the send loop.

06

A missing variable blocks the send

An unresolved {{company}} is never guessed, never left blank, never silently substituted. The message does not go, and the block is written to the event log so somebody fixes the data.

07

Open tracking stays off

Pixels are an extra remote image in every message and Apple Mail Privacy Protection made the number meaningless anyway. We report reply rate and seed-measured placement, both of which we can defend.

08

A person reads every reply

Drafting is assisted. Sending is not. Nobody on our team sends an unread automated reply to a prospect, because the first time that goes wrong it goes wrong in public.

The system

Six parts, operated as one thing.

Five working and one broken produces the same result as none working, which is why they are not separable.

01 · Domains and mailboxes

Near-variant domains with MX, SPF inside the lookup limit, 2048-bit DKIM and DMARC. Two to three mailboxes each, because more concentrates the risk. Gmail, Microsoft 365, Zoho or SMTP behind each one.

02 · Warmup that never stops

Peer and seed traffic that is opened, replied to and pulled out of spam. Placement measured weekly per domain per provider. It keeps running alongside live campaigns rather than stopping at go-live.

03 · Sequencing

Multi-step with delays, in-thread follow-ups, spintax, branching on lead attributes, and A/B arms tested with chi-squared rather than a hunch. Stops on reply, bounce or opt-out.

04 · Deliverability

Seed placement testing, blocklist monitoring across four zones, a pre-send content scorer, first-bounce suppression and one-click unsubscribe on every message.

05 · The reply inbox

Every reply from every mailbox in one queue, classified before it is answered. Out-of-office pauses the sequence to the stated return date instead of ending it.

06 · Us

The part no software replaces. Somebody on our team reads the reply, handles the objection, and books the meeting with the four BANT fields recorded.

Sizing

What your target actually requires.

Set the target and the model works backwards to the infrastructure it needs, and forwards to what it would produce. Every constant in it is a rule the system enforces, not a figure chosen to flatter the output.

Who you are targeting
Meetings you want per month8
240
Average deal value
Meetings that become customers20%
5%50%
Reply rate to assume4.5%
1.5% — cold, broad9% — tight, warm
Infrastructure required
Messages per month
Messages per working day
Mailboxes, 45/day cap each
Sending domains
New contacts needed monthly
Live sending begins
What that produces
Replies per month
Of which positive
Meetings booked
Customers won per month
New revenue, annualised
A model, not a forecast

Positive replies at 32% of all replies and 55% of those converting to a booked meeting — ranges the engine uses, not a promise. Twenty-two working days a month, 45 sends per mailbox per day, and a floor of four mailboxes across two domains so no single domain is a point of failure. Pull the reply rate down to test the pessimistic case.

What is built

The parts that are not finished, named.

Most of this system is built and running against a real database. Some of it is not, and we would rather you read that here than discover it later.

Running now

The engine, the rules, the interface and the reply inbox, on Postgres with row level security forced on every table. The worker that speaks SMTP and IMAP is written and tested, with DKIM signing and TLS that is never downgraded.

Not sent yet

Our own sending domain is inside its 21-day warmup, so no live message has gone to a real person. The system refuses to let it out early — which is the rule working, and worth saying out loud rather than letting the page imply otherwise.

Not built

OAuth for Google and Microsoft — mailboxes connect with an app password today. DMARC aggregate reports are not parsed. There is no self-serve signup and no billing, because in this phase nobody outside KaizenSpark logs in.

The whole table, including the parts nobody asks about

Sixteen capabilities with a state against each, the reasoning behind the rules, and the bugs we found and fixed while proving them. If you are evaluating whether to trust this with your domain, that page is the one to read.

How it is built
How it works

What an engagement actually looks like.

Four weeks before the first message goes out, because that is what the domain needs. Anyone promising sends in week one is either using somebody else's domain reputation or about to spend yours.

Week 1Set up

Domains and mailboxes

We register near-variant sending domains, publish MX, SPF, DKIM and DMARC, stand up two to three mailboxes on each, and agree the target list and the qualification bar with you. Nothing sends.

Weeks 1–3Warm up

Reputation, before volume

Mailboxes ramp five messages a day toward a ceiling of forty-five, on peer and seed traffic that is opened, replied to and pulled out of spam. Placement is measured weekly per provider. Meanwhile we write and review the sequences with you.

Week 4Live

Sending, and a person on every reply

Sending begins at the ramped cap, two contacts per company per thirty days. Every reply is read and answered by a named person on our team, meetings are booked with the qualification recorded, and you get a weekly report: placement, bounce and complaint trend, reply rate, meetings, and anything paused and why.

What we will not do

Send from your primary domain. Send before day twenty-one. Contact three people at the same company in a week. Guess at a missing merge field. Un-suppress somebody who asked to be left alone. Report an open rate as though Apple had not made it meaningless. Send a reply no human read. Each of those is refused by the system, not by our good intentions.

Who does what

The part no software replaces.

Drafting is assisted. Sending is not. The reason outbound gets a bad name is automated replies to real people, and there is no configuration in this system that produces one.

Daily · us

Work the reply queue — classify, answer, book. Interest has a half-life measured in hours, so this is the one thing that cannot slip.

Daily · us

Check alerts. A rejected credential or a paused domain stops sending quietly; the alert is the thing that says so, and it names the fix.

Weekly · you

Read the report. Seed placement per provider, bounce and complaint trend, reply rate, meetings booked, anything paused and why.

Monthly · together

Review sequences against reply data, tighten who we are writing to, and retire losing A/B arms once a test has actually concluded rather than when it looks decided.

Next

Read the engineering, then talk to us.

The capability table is the honest version of this page. Read that first — if the gaps we list are ones you can live with, the conversation is a short one.

How it is built Open the platform Ask a question