The slow reply is the smaller loss
Most of the attention in an automation build goes to speed. The first reply to an enquiry, the chase on an open quote, the reminder the day before a booking, the interval between a completed job and the review request, all of it gets designed carefully and measured at day thirty. A slow reply is a real loss and it is a bounded one. The enquiry that waited until Monday is one enquiry. The contact has usually gone elsewhere by then, and a person with an apology and a quote can sometimes get them back.
A message that arrives after somebody has unsubscribed is a different kind of failure. The person told the company to stop, in the one way the company itself offered, and the company carried on. Nothing about that reads as an accident from where they sit. It reads as a decision, and the usual answer to a decision like that is the spam button, which files a complaint against the sending domain with the mailbox provider.
The complaint is what makes the damage larger than the message. Mailbox providers keep a running count of complaints against a domain, and once that count is high enough they begin routing the domain's mail into the junk folder for everyone, the contacts who asked for it and the customer waiting for an invoice included. One message to one person who left can cost the reach of every message that follows it. A slow reply never does that. It costs one enquiry and leaves the rest of the list untouched.
It is also a breach of the rules on consent, with a penalty attached, and a slow reply breaks no rule at all. We say that once in the strategy session and then leave it. The complaint count makes the case on its own, and it is the figure the team can read for themselves in their email tool's own reporting.
How an unsubscribe gets lost
In the teams we have sat with, the tools themselves honour their own unsubscribe link without exception. What goes wrong is that a company of any size sends from more than one place, and each place keeps its own record of who has left. The newsletter tool has one. The CRM's built-in email has another. The follow-up sequences we build run in an automation tool with a third, the SMS account holds a fourth, and somebody in sales runs a mail merge from a spreadsheet with no record at all.
A contact clicks the link at the bottom of the newsletter and is removed from the newsletter. Nothing tells the quote sequence. Two days later the sequence sends its second chase, from a named person, with a booking link in it, exactly as it was designed to. From the contact's side, they unsubscribed on Tuesday and were written to on Thursday by the same company. The sequence was correct and the connection between the two tools was never built.
There are quieter versions of the same failure. A segment saved on Monday and sent on Thursday, with an unsubscribe on Tuesday between the two dates, goes to a list that was accurate when it was built. A contact who unsubscribed and then filled in a form six months later comes back as a second record with a blank suppression field, and the sequence treats them as new. An export taken for one event invitation lives on in a spreadsheet, gets used for the next event, and carries every address that has left since. A phone number that replied STOP to the SMS account is still on the email list, because the two tools have never exchanged a record. Every one of these happens with every tool working as designed, because there are two lists where there should be one.
We look for these before the first sequence goes live, because finding them afterwards means a person has already been written to after leaving. When one shows up anyway, the reply from the contact who says they had already unsubscribed goes to the top of the list, above the wording and above the reply time, and the sends from every tool are paused until the lists are one. That is a hard thing to do in the second week of a build, with a client watching the reply time they were promised. The reply time will keep.
One list, checked at the moment of sending
The safeguard is a single suppression list, held in one place, usually the CRM because that is where every other tool already looks. Every unsubscribe from every channel writes to it. The link in the newsletter, the link in the sequence, the STOP reply on the SMS account, the hard bounce, and the person who says on the phone that they would rather not hear from the company again all end up as the same flag against the same address, and the flag gets there the same day.
Every send from every tool reads that list before it goes out. The check runs at the moment of sending, because the gap between building a segment and sending it is where the Tuesday unsubscribe falls. Where a tool can read the CRM directly, it reads it. Where it can't, the send list is exported from the CRM on the morning of the send with the suppression filter in the saved query, and an export older than that morning doesn't get used. That rule is written into the handover in those words.
The list matches on the address and the phone number. A contact record can be duplicated, and a person who left and came back through a form six months later has a new record with the same address, which is the thing the sender is about to write to. Matching on the record would let them through. Matching on the address stops the second message, and it is also what catches the spreadsheet, provided the spreadsheet is checked against the list before it is used, which is the next rule.
Manual sends go through the same gate, and it is the rule that gets argued with. A mail merge from a salesperson's own inbox, an event invitation sent from a spreadsheet, a customer survey sent from the form tool, a one-off announcement from the managing director, each of them has to be run against the list before it leaves, and the simplest way to hold that line is to take the spreadsheet away. The list a person sends from is a saved view in the CRM with the suppression filter already on it, and nothing else. It is unpopular in the room, because it takes a working habit away from people who did not cause the problem, and it is the rule we won't trade.
Reply handling belongs on the same list. The sequences we build stop on any reply and route it to a person, and part of that person's job, written into the handover, is that a reply asking to be left alone gets written to the suppression list the same day, whatever words the contact used. The unsubscribe link only catches the people who use it. The rest say it in a sentence, and a sentence read by a person is the only thing that catches those.
Proving it before anyone relies on it
A suppression list that hasn't been tested is a belief. Before the build goes live we test it the way we test reply time, from outside, with a real address. A test contact is created, unsubscribes through one channel, and then every other tool in the company sends to it. Where anything arrives, the connection between that tool and the list is the next piece of work, and go-live waits for it.
The test is repeated from each channel in turn, because the connections are not symmetrical. An unsubscribe from the newsletter usually reaches the CRM. A STOP on the SMS account reaches nothing until somebody connects it. The number of pairs to check grows with every tool that sends, and each of them gets checked, because the pair nobody tested is the one that writes to somebody after they have left.
At day thirty the test runs again and goes into the baseline document next to the five numbers, as a pass or a fail with the date and the name of the person who ran it. It is the only line on that page with no figure attached, and the one we would least like to see change between the two readings. A list that passed at go-live and fails at day thirty means a tool was added or a connection broke in between, and the handover note names who to ask.
Ownership is the other half of every safeguard we put in, and the test settles it. The list has a named person in the client's team, the same person who changes the sequence wording when the offer changes, and the one rule that goes with the name is that a new sending tool connects to the list before it sends anything. New tools arrive without anyone telling marketing, a survey tool that customer service signed up for, a booking system that sends its own reminders. The person who owns the list is the person who asks.
