deliverability is maintenance

I had a team come to me with an annoying problem.

Their campaign had been “cranking,” and they were getting a ton of positive replies, but the booking KPI started to worry them, so they shut off what was working and ran a bunch of other tests.

Nothing hit.

They went back to the previous winner and got “crickets.”

That left us with a messy question - was it the new lists, the new scripts, the domains, the warmup, or some combination of those things moving at the same time?

The first useful question I asked was how much true script variance they had outside spintax, because I wanted to know whether they were testing genuinely different emails or one structure with the wording changed.

They already had evidence that the offer could produce positive replies, so I wanted to keep the offer and build 20 genuinely different plain-text scripts around it.

One version could package the offer with humor, another could use a current trend, and another could speak directly to the type of customer that brand sells to.

Same offer, completely different way of getting into it.

The subject lines needed the same treatment.

When we looked across their campaigns, very similar subject-line patterns kept showing up on different domains, which meant the sending footprint could still look repetitive even when the body copy had changed.

I wasn’t going to tell them that repetition definitely caused the drop, because we didn’t have evidence for that.

It was a clear fingerprinting risk, though, and it meant the script tests weren’t as different as they looked.

The offer still had evidence behind it, but the team had lost a clean way to separate a creative problem from an infrastructure problem.

Then we got into the domains.

They were rotating infrastructure on a schedule and using fixed reply-rate thresholds to decide what looked burned.

I get why - when you’re managing multiple clients, a hard rule feels much easier than making a judgment every time.

The problem is that a healthy reply rate depends on the offer and the market, so the same cutoff can’t tell you whether every domain is actually underperforming.

We went back to the team’s own healthy sending period instead.

Take the best domains from that period, use their performance as the benchmark, then compare each current domain with that history.

And do it at the domain level, not inbox by inbox, because the decision you’re making is whether that domain should keep sending or be replaced.

You also can’t benchmark against the recent period when performance has already “fallen off a cliff.”

By the end of the call, the order of operations looked like this:

• Write the genuinely different scripts now
• Keep the strongest existing domains sending while the new infrastructure warms
• Compare each domain with its healthy history and rotate the clear underperformers

They still needed new infrastructure, and I agreed with them on that.

But the number-one priority was getting those scripts made, because putting the same email and the same subject-line pattern onto fresh domains would eventually put them right back in the same spot.

Once the monitoring is automated, the team doesn’t have to rely on gut instinct or have someone watching every domain all day just to keep the channel alive.

That matters a lot more when client uptime is attached to it.

Where I can help you:

• YouTube - see the cold email systems and experiments we're running
• Legion - join the waitlist for the GTM operating system coming soon
• LeadGrow - apply for a free campaign and let us prove the funnel with you

- Mitch

Something I’ve been thinking about: good automation is mostly deciding which judgment calls deserve a rule, and which ones still need a human.