Your review request went out while she was on the phone complaining.

She was on the phone with your office, explaining what was wrong with the job, when her phone buzzed against her ear. A text from your business, the one she is on the phone complaining about, asking her to rate her experience and leave a Google review.

Nothing was broken. The review automation fired exactly when it was built to fire, two days after the job was marked complete, which is what everybody recommends. It had no idea a complaint existed, because the thing that logs complaints and the thing that asks for reviews have never been introduced.

So you handed a frustrated customer a form and asked her to write down how she felt, at the one moment she was least inclined to let it go.

Every system involved reported success

Automations arrive one at a time. Somebody solves the no-show problem one spring and the review problem two summers later. Each one gets built alone, tested alone against a test contact, and reported alone in its own dashboard.

By that afternoon there were four sets of statistics and every one of them was green. Sent and delivered, on schedule. The only instrument capable of noticing what actually happened was the customer, and she does not have a login.

Your customer never experiences your systems. She experiences a phone.

Which is also why the volume question never gets asked properly. Texting cadence gets decided inside the texting tool and email cadence gets decided inside the email tool, each one sensible on its own. She is not receiving two texts and three emails. She is receiving five messages from a business she hired once.

The collision with a legal floor under it

The review request is the one that costs you a rating. This is the one that costs you more than that.

A customer asks you to stop contacting her. Sometimes that is a literal STOP reply. More often she tells the tech at the door, or says it on the phone to whoever picked up, and somebody writes it down. Two weeks later the drip campaign that never saw the note sends her another email.

Twilio's messaging policy is not ambiguous about the texting half of this. Once someone revokes consent you get one final message confirming it, and any message after that is prohibited. One. Not one per automation. The recognized opt-out keywords also run well past STOP alone, covering UNSUBSCRIBE, CANCEL, END, REVOKE and several others, so a customer can opt out in a way your platform registers and your other tools never hear about. The full picture on consent and registration is its own subject, and it is worth reading before your next campaign.

The part that belongs here is narrower. A stop request is a fact about a person, and most stacks store it as a setting inside whichever tool happened to receive it.

Then the ones that just make you look careless

Status updates that are not true. "Your technician is on the way" while the truck is still two jobs back. "Your job is complete" sent to somebody standing in a half-finished kitchen. The message is triggered by a field somebody changes in the office, and the field gets changed when the paperwork moves rather than when the work does, so the automation faithfully announces a version of the day that did not happen.

And the reminder for an appointment that already moved. She called, you rescheduled her, everybody was pleasant about it, and the reminder went out for the original slot anyway because it was queued in the system that never got told. Now she has two times in her head and neither of you is sure which one she believes.

None of these are messaging problems. Every one of them is the same problem: a system that acts on a record while the truth lives somewhere else.

The fix is a rule about silence

What is missing is not a better sequence. It is a rule that says when this is true, that does not send.

An open complaint suppresses the review ask until it closes. A stop request suppresses everything, everywhere, including email, including the campaign that lives in a different tool. A rescheduled job cancels its original reminder instead of adding to it. A status message fires off the thing that actually happened rather than off a checkbox somebody ticks at the end of the day.

We build these for clients, and the honest description of the work is boring. It is not technically difficult. It is skipped almost universally, because writing those rules means somebody has to hold the whole stack in their head at once, and no single automation project has ever required that. Each one was scoped to its own job and signed off on its own job.

A suppression rule is also the rare piece of automation work whose success looks like nothing happening. That is exactly why it never gets prioritized, and exactly why it never gets noticed once it is running.

How you find yours

Put a real job through the whole thing and read the transcript. Not a test contact firing one sequence, which is how each automation was checked when it was built. A booking, a reschedule, a completion, a complaint if you can stomach staging one, with every message that lands collected in the order it arrived, emails included.

When we run this it is a two-part job. We drive the sequences and collect what comes out; the client reads it against what was actually happening, because we cannot tell from the outside whether "your technician is on the way" was true at the moment it went out. The collisions live in that gap, and each of us can only see one half of it.

How long that takes comes down to the scope of what you are running. On a small stack it can be as few as a couple of days. What comes back is not a list of things we think might be happening, because every item on it was triggered on purpose and watched.

Why nothing flagged it

Every campaign reports its own sends and its own opens, which is the same blindness that lets an automation stop working entirely without anybody noticing. Success measured per system cannot describe a failure that happens between systems. There is no dashboard for the seam.

Suppression rules across tools are the automation work we do, because no single sequence can see the others and somebody has to look at all of them together. If you are running more than two automations and have never read one customer's week end to end, book a strategy call and we will map what fires when. Most of the rules write themselves once everything is on one page.