A suppression routine that keeps complaint rate down

The complaint rate climbs on a Tuesday. Nothing obvious has changed: same template, same offer, same sending domain, same agency. Someone pulls the audience definition and finds it includes a hundred thousand people who have not opened anything since last summer, because the campaign was built from "all contactable" and nobody questioned it.

That is what a missing suppression routine looks like from the inside. It is rarely one bad decision. It is the absence of a rule that would have stopped the send before a human had to think about it.

Suppression is the least interesting part of a lifecycle programme and the part that protects every other part. Get it right once and it runs quietly for years. Get it wrong and the best creative work in the company arrives in a spam folder.

Suppression is a set of rules, not a file

Most teams treat suppression as a spreadsheet that somebody uploads before a big send. The spreadsheet is the output. The rules that produce it are the actual asset, and if they only exist in one person's head, they will be skipped on a busy Friday.

Write the rules down and give each one an owner, a trigger and a scope. Scope matters more than people expect. Some rules apply to every message the company sends, including receipts. Others apply only to marketing broadcasts. Confusing the two is how a customer who asked for no marketing stops receiving their delivery notifications.

These are the sets we build first, in this order:

1. Unsubscribed. Global, honoured immediately, and honoured by every system that can send, not just the one that recorded the request.
2. Complainants. Anyone who used the spam button, captured through feedback loops where the mailbox provider offers one. Permanent, no exceptions, no re-permission campaign.
3. Hard bounces. Removed after the first hard bounce, not the third. A mailbox that does not exist will not start existing.
4. Repeat soft bounces. A rolling counter. Three soft bounces in thirty days is a reasonable threshold to treat the address as hard.
5. Structurally bad addresses. Role accounts, obvious typo domains, seeded test records, anything imported from a source nobody can name.
6. Sunset. Contacts past the inactivity window defined by your sunset policy.
7. Legal and operational holds. Deletion requests, markets you are not cleared to mail, accounts in dispute.

The first five are mechanical. The sixth is a judgement call that deserves its own section. The seventh is the one that gets discovered during an incident rather than designed, which is the wrong order.

Write the sunset policy as a ladder, not a switch

A single rule that removes anyone who has not opened in one hundred and eighty days is better than nothing, and worse than what you can build in a day.

Use four states instead:

• Engaged. Normal frequency, normal content.
• Cooling. No engagement for one repurchase cycle. Reduce frequency, prioritise the strongest offers, stop sending the low-value filler.
• Win-back. A short, defined series with a fixed end. Three messages, not an open-ended drip.
• Sunset. Out of business-as-usual sending entirely. The record stays for reporting and for suppression matching, but it stops receiving campaigns.

Set the windows from your own data rather than from a number you read somewhere. Take the distribution of days between purchases, or between logins if you are not transactional. Find the point by which the large majority of repeat behaviour has already happened. That is your baseline cycle, and the cooling window sits just past it.

A brand with a weekly consumable and a brand selling mattresses cannot share a sunset window. If your category has a genuine annual rhythm, say insurance renewal or school uniforms, the policy needs an exception that keeps those contacts in scope until their anniversary passes.

Automate bounce and complaint handling on the same day

Every rule above should run without anybody remembering it. Bounces and complaints in particular should never wait for a weekly job, because the damage they cause is cumulative and the window to stop it is short.

Three things worth checking in your platform this week:

• Feedback loop registrations exist for every sending domain, and the resulting complaints are written back to the profile, not just counted in a dashboard.
• One-click unsubscribe is present and functioning on every bulk message, in line with the Gmail and Yahoo sender requirements that came into force earlier this year.
• Unsubscribes and complaints propagate to every sending system within minutes, including the transactional platform, the support tool and anything a regional team runs independently.

The last one catches most teams out. Suppression that exists in one platform and not another is not suppression, it is a reporting artefact.

Run the routine on a schedule and log what it removed

A suppression run that leaves no record cannot be audited, and an unauditable routine is one that gets quietly disabled during a growth push.

Log every run with the date, the rule that fired, the number of records affected, and where they moved to. Keep it somewhere the deliverability conversation can reach, not buried in platform logs that expire after thirty days.

Review the log monthly. Two patterns are worth watching. A rule that suddenly removes ten times its usual volume means something upstream broke, often a form or an import. A rule that has removed nothing for a quarter is probably not running at all.

Measure what suppression costs, honestly

Somebody will ask what the removed contacts were worth. Answer it with a method rather than an assertion.

Before a large sunset run, take a random sample of the group you are about to remove and keep mailing them for one more cycle. Compare revenue per thousand sent and complaint rate against your engaged population. In most programmes we look at, the sample earns a rounding error and complains at several times the normal rate, which ends the argument without anyone having to win it.

Run the same comparison on bounce rate by mailbox provider. Gmail and Microsoft often disagree about the same list, and a blended figure hides whichever one is about to become a problem.

One caution on framing. Suppression changes who you mail, not whether they stay customers. If the churn rate conversation gets folded into the deliverability conversation, both get worse. Keep them separate and measure them separately.

What to do this week

• Write your seven suppression sets on one page, with an owner and a scope against each, and mark the ones that are currently manual.
• Pull the distribution of days between purchases and set your cooling window from it rather than from a default.
• Confirm that an unsubscribe recorded in your main platform reaches every other system that can send, and time how long it takes.