The Automated Reminder That Annoyed Every Customer

Why this matters

A reminder sequence that misfires does not fail once. It fails at the speed of your send queue, to every name in the segment, and the damage keeps landing for as long as the queue has messages in it. The instinct is to work out what went wrong. The right first move is to stop what is still scheduled, because in a multi-step sequence the worst message is often not the one that already went out. This case is a fourteen-person lawn and pest shop on a Monday in March, and it runs in the order that matters: contain, count, then diagnose.

The signal

At 9:40 on a Monday the office phone started ringing with people who had not been customers in years. By 10:30 there were a dozen voicemails and a stack of text replies, most of them some version of "who is this" or "STOP". Several were angry about one line: "Your Termite Inspection is due - reply YES to book." Most of the people saying so had never had a termite inspection from this shop. One had moved out of the house in 2021.

The office manager assumed it was a handful of bad records and started calling people back one at a time. The owner saw the reply count at 1:15 and asked the question that changed the afternoon: is anything else still scheduled to go?

Contain before you diagnose

Three things were done between 1:15 and 1:30, in this order, and the order matters.

Pause the sequence, do not delete it. Most field and marketing software lets you pause a sequence, which holds every queued message, or delete it, which on some systems clears the queue and the send history together. The send log is the only record of who received what. Deleting it to "make it stop" destroys the evidence you need for the next three hours and for any complaint that arrives later.

Look at the queue, not just the sent folder. The queue showed what nobody had guessed: two more steps were waiting for every recipient, one due at 4:12 that afternoon and one at 11:12 that night. The pause at 1:30 caught both. A text at 11:12 at night, to people who had not asked for it, would have been far worse than the morning's message, and it would have gone out to every recipient.

Check every channel the sequence uses. This sequence sent email to recipients with an address and text to those with only a mobile number. The email platform and the texting platform were separate, so each queue was checked separately.

Then a holding reply went on the text line: "Sorry, that message was sent in error. You won't receive more. Reply STOP to opt out of all texts from us." The office stopped calling people back one at a time and started counting.

What the send log said

The send log records, for each message, the time, the recipient, the channel, the template version, the values the merge fields took, and the delivery result. Here is a lightly trimmed excerpt from three entries on that morning:

09:12:04 EMAIL  step1  tpl v7  -> DELIVERED
  segment: CUSTOMERS_SINCE_DATE (date: blank)
  plan_name: ""  -> fallback "Termite Inspection"
  last_service: 2019-06-11  wasp nest removal
09:14:51 TEXT   step1  tpl v7  -> DELIVERED
  sms_opt_out: TRUE   segment excludes: none
09:15:02 QUEUED step2  due 16:12  delay 7 HOURS
09:15:02 QUEUED step3  due 23:12  delay 14 HOURS

Reading the whole log rather than the excerpt gave the count. The sequence had sent step 1 to 2,340 recipients: 1,560 by email and 780 by text. The intended audience was the shop's 412 active service-plan customers. The other 1,928 were past customers going back to 2019. That closes: 412 plus 1,928 is 2,340.

Of the 780 text recipients, 38 carried the "SMS opted out" flag in the field software. They had texted STOP at some point in the past and been texted anyway.

Every one of the 1,928 non-plan recipients got "Termite Inspection", because none of them had a plan name and the fallback text fired.

Three causes, one edit

All three faults came from one edit made the previous Friday. The sequence had run correctly for two springs. On Friday someone updated the wording, which is a reasonable thing to do, and in the same session changed three other things without noticing they had.

The segment. The old version targeted "active service plan". The editor switched it to "customers since a date", meaning to set a date to catch plan customers who had lapsed in the last year. The date was left blank. On this software a blank date means no limit, so the segment became every customer record in the system.

The merge field fallback. A merge field is a placeholder the system fills from the record, here the customer's plan name. A fallback is the text used when the record has no value. To preview the template, the editor had loaded a termite customer as the sample and typed that customer's plan name into the fallback box so the preview looked filled. On plan customers it never showed, because they all have a plan name. On 1,928 people without one, it printed every time.

The delay unit. The intended spacing was step 2 seven days after step 1 and step 3 fourteen days after. The editor typed 7 and 14 into the delay boxes. The unit selector beside them had reset to hours when the template was duplicated. So the sequence meant to run over two weeks was set to run over fourteen hours, ending at 11:12 at night.

And one fault that was not new. The opt-out exclusion had never been a rule in the sequence. It had been an accident of the old segment: the 412 plan customers were all people who had agreed to texts when they signed up, so nobody opted out had ever been in it. When the segment widened, nothing stood between the sequence and the 38 flagged numbers. The email platform kept its own unsubscribe list and suppressed those addresses automatically; the texting side relied on the flag in the field software, and the sequence never checked it.

Note what the log let the shop prove and what it could not. It proved exactly who got what, when, and with which merge values. It could not show who made the Friday edit or what the sequence looked like before it, because the software kept no version history. That gap is the finding the fix is built on.

The legal layer, and where to stop reading this

This is not legal advice, and this is the part of the case where an owner should pick up the phone to their attorney rather than act on an article.

At the federal level, marketing texts are governed by the Telephone Consumer Protection Act, an FCC-administered statute, and its rules at 47 CFR 64.1200. Two things in this case touch it. A message urging a past customer to book is marketing rather than a transactional reminder about a scheduled job, and marketing texts carry consent requirements that an old customer relationship may not satisfy. And the FCC's rules require a consumer's revocation of consent, such as a STOP reply, to be honored; as of 2026 the FCC's rule gives a business 10 business days to do so, which the 38 numbers here were well past. The same rules restrict telephone solicitation to between 8 a.m. and 9 p.m. at the recipient's location, which is why the 11:12 p.m. step being caught in the queue mattered.

States add a layer on top that is often stricter: Florida and Oklahoma have their own telemarketing statutes with tighter consent and timing rules and their own private lawsuits, and other states have followed. Which applies depends on where the recipients live, not where the shop is.

For email, the federal CAN-SPAM Act and the FTC's rule at 16 CFR Part 316 require a working opt-out and that it be honored within 10 business days. The email side of this case held, because the platform's suppression list did that job.

The fork: if a misfire reached numbers flagged as opted out, or sent texts outside the permitted hours, stop handling it as a customer-service problem. Walk into your attorney's office with the send log export, the count of opted-out recipients reached, the time window of every message, and the record of what consent each recipient gave and when. The statute sets damages per message, and at hundreds of messages that is a number to take seriously.

The cleanup that did not make it worse

No mass apology. The tempting move was a second message to all 2,340 explaining the error. That would have been another unsolicited text to 1,928 past customers and the 38 opted-out numbers, compounding the first. Instead, everyone who replied or called got a personal response, and nobody else got anything.

Two opt-out lists became one. The 112 STOP replies from that morning had been recorded by the texting platform but not in the field software. They were copied across by hand that afternoon, and the opt-out check was added to the sequence as an explicit exclusion so it no longer depended on the segment happening to exclude those people.

The sequence was rebuilt, not patched. Segment back to active service plan. Fallback for plan name set to skip the send rather than print default text, so a record without a value gets no message instead of a wrong one. Delays set to days and re-checked on the saved version, not the editing screen.

How they confirmed the fix

The rebuilt sequence was run against five test records owned by staff: a plan customer, a lapsed customer, a past customer with no plan, a customer flagged as SMS opted out, and a record with no plan name. The plan customer got step 1 and showed steps 2 and 3 queued 7 and 14 days out. The lapsed and past customers got nothing. The opted-out record got nothing. The record with no plan name was skipped and logged as skipped. Each preview was opened on a phone, because the editing screen had hidden the unit selector that caused the timing fault. Then it went live.

The lesson that generalizes

Nothing in this sequence was broken until Friday, and nothing on Friday looked like more than a wording change. The edit touched four things and the editor knew about one. That is the ordinary way automations fail: not in the build, but in a quick later change made by someone in the middle of a busy afternoon, with no second person, no test send and no record of the prior version.

The fix that holds is a change process, not a smarter editor: a written description of the change, a test send to staff records covering every branch, a phone preview, a named second person who approves it, a way to put the old version back, and a record of all of it. That procedure has its own SOP. See related: The Automation Change-Control SOP.

References

• Telephone Consumer Protection Act and FCC rules at 47 CFR 64.1200 (consent, revocation, calling-hour limits for telephone solicitation)
• CAN-SPAM Act and FTC rule at 16 CFR Part 316 (email opt-out and the 10-business-day honor period)
• See related: The Automation Change-Control SOP
• See related: Mapping a Process Before You Automate It
• See related: Automation Versus AI: Two Different Tools