Writing
Ten to a hundred
I built an outbound pipeline to run my own job search. This is what I would change to run it at ten times the volume for a B2B SaaS company, and the one part I would refuse to change.
The system this is written against is not hypothetical. It scrapes four ATS providers, scores 7,190 live job postings for buying intent, enriches the survivors through Clay, and sends ten emails a day, each one gated on the recipient's local morning. Stop-on-reply, bounce handling, a kill switch. It is running right now.
Ten a day is a personal cadence. A hundred is a company's. Almost everything about the pipeline survives the jump. Three things do not, and the failures are not where people expect.
At ten a day, send from your real domain. At a hundred, never.
At low volume your primary domain is a credential. The recipient searches it, finds you, and the mail is more credible for having come from the same place. Burner domains actively hurt.
At a hundred a day the same domain is an asset under load. One scraped list, one week at 5% bounces, and you have damaged the domain that sales, support and billing all send from. The blast radius is the whole company, and reputation degrades far faster than it recovers.
What the volume actually forces
The binding number is not Google's 2,000-recipient daily ceiling. It is the safe cold-outreach rate per mailbox, which sits around 30 to 50 a day. Past that, providers start treating the sender as bulk regardless of what the messages say.
100/day ÷ ~40 per mailbox = 3 mailboxes minimum each on its own sending domain each warmed 3 to 4 weeks before carrying load each with an independent daily cap
Two constraints move with it. The daily cap becomes per mailbox rather than global. And bounce tolerance tightens brutally: at a hundred a day, holding under 2% means two bounces. Verification stops being hygiene and becomes a precondition for operating at all.
Intent scoring stops being optional
At ten a day you read every posting yourself. At a hundred you cannot, so the scoring layer becomes the product rather than an accessory to it.
The distinction carrying the most weight is between a state and a change. "They use Salesforce" is permanently true and therefore worthless. "They installed Salesforce last month" is a reason to write today. Every signal needs an expiry date.
| Signal | Window | What it means |
|---|---|---|
| GTM role opened | 30 days | Someone signed off on building the function |
| Role stalled | 60–365 days | They cannot fill it. The strongest and least contested signal |
| New funding | 60 days | Budget exists and targets just moved |
| New GTM leader | 90 days | New VPs rebuild the stack, and the window is short |
| Stack change | 90 days | Something was just adopted or abandoned |
| Posting > 1 year | — | Anti-signal. An evergreen listing nobody closes |
That last row is where most target lists quietly rot, and it cost me. One company in my own run showed ten open GTM roles and scored as the strongest target on the list. Its postings had been sitting open between 470 and 850 days. I had built a scorer that asked whether roles were open and never asked when they opened, so a listing from 2024 counted the same as one from last week.
155 companies, scored on recency STALLED 15 cannot fill a GTM engineering role DECIDED 29 two or more GTM roles opened in 30 days SCALING 3 RECENT 32 OPEN 70 ← roles exist, nothing recent happened EVERGREEN 6
Forty-four of a hundred and fifty-five had a defensible reason to hear from me this week. Emailing the other hundred and eleven is how a campaign produces volume and no replies.
Most people chase fresh postings. For anything you are selling into a hiring problem, the stalled ones are stronger. A role open six months is not a queue of candidates; it is a search that has failed, and the person who owns it knows.
Where the model goes, and the rule that keeps it honest
At a hundred a day the opening line cannot be hand-written. How the model is used decides whether the output is worth sending.
The failure mode is asking for a personalised email. What comes back is fluent, confident, and about nothing. The fix is to invert the flow: the pipeline finds a fact, and the model's only job is to phrase it.
wrong "Write a personalised opener for Acme."
→ "I've been really impressed by Acme's growth..."
right fact: role="Growth Engineer" days_open=180
"Write one sentence stating this."
→ "Your Growth Engineer has been open about six months."
Then the gate that makes it survivable: reject any line without a checkable particular — a number, a job title, a date, a city. If the sentence would be equally true of a hundred other companies, it goes back. It is a cheap programmatic check, and it is the whole difference between personalisation and the appearance of it.
What breaks first, in order
Volume does not degrade a pipeline evenly. Four things saturate, and none of them is the sending.
Reply capacity, long before send capacity
A hundred a day at a 10% reply rate is ten replies a day. Miss the 24-hour window and the campaign starts manufacturing bad impressions at ten a day, among precisely the people who raised their hand.
Teams scale sending and forget this. It is the most common way a working outbound motion turns into a reputation problem.
List quality, faster than you expect
Forty-four qualified targets is four days of sending at a hundred. On day five you are writing to companies with no reason to hear from you, the reply rate halves, and the natural conclusion is that the copy stopped working.
The answer is not a bigger list. It is more signal sources, so the qualified pool refills as fast as it drains.
Suppression, with the worst blast radius
Current customers, open opportunities, anyone contacted in the last six months, anyone who said no, competitors. At ten a day you hold this in your head. At a hundred it needs a table and a check before every send.
Cold-emailing an existing customer is the kind of mistake that reaches the CRO the same afternoon.
Attribution, quietly
At forty sends a week you can hold the whole campaign in your head. At five hundred you cannot tell which change moved which number unless cohorts were tracked from the start. This one cannot be retrofitted, because the data was never recorded.
What does not change
| Component | Why | |
|---|---|---|
| Local-morning send window | holds | Per-recipient timezone; volume is irrelevant to it |
| Sending-day calendar | holds | Same logic, evaluated per recipient |
| Stop on reply | holds | More valuable at volume, not less |
| Send jitter | holds | Matters more as batches grow |
| Global kill switch | holds | Earns its place faster the higher the volume |
| Daily cap | moves | Becomes per mailbox rather than global |
| Single sending identity | moves | Becomes rotation across mailboxes and domains |
| Hand-written openers | moves | Model-generated from a fact, gated on specificity |
Five of eight carry over untouched, and the pattern in which five is the useful part. Everything that survives a tenfold increase was built around the recipient's constraints: their morning, their working week, their decision to reply. Everything that breaks was built around the sender's convenience.
That is the whole lesson, and it is why I would automate the sourcing, the enrichment and the scoring, and still write the opening line myself. At ten a day that sentence costs twenty minutes. It is the cheapest competitive advantage I will ever buy.
← Back home