Everyone has a horror story.
The automation that ran for three months before anyone noticed it was enrolling the same contacts twice. The sequence that went out to churned customers because someone forgot to add an exclusion filter. The workflow that worked perfectly until the person who built it left the company, and nobody could figure out how to change it, so they just left it running and hoped for the best. Which is a sentence that should make every revenue leader uncomfortable.
Automation failure is usually blamed on the technology. The tool was too complex. The integration broke. The data wasn't clean enough.
That's rarely the actual problem.
Most sales automation breaks because teams build the workflow before they've defined the play. They jump straight to the mechanics — triggers, sequences, enrollment conditions, branching logic — without first answering the question the whole system depends on: what is this automation supposed to do, and under exactly what conditions should it do it?
Build the workflow first and you're encoding your assumptions into software. When the assumptions are wrong — and they usually are, at least partially — the software faithfully executes the wrong thing at scale. Quickly. Repeatedly. To real people.
The play comes before the workflow
A play is not a sequence. A sequence is a series of messages. A play is the full logic of a triggered motion — the signal that fires it, the fit criteria that qualify it, the message that responds to it, the action that follows, and the outcome that determines what happens next.
When you define the play properly before you build anything, the workflow almost builds itself. Every branching decision, every conditional, every exclusion filter maps directly to something you've already decided. You're not making judgment calls in a workflow builder at 4pm on a Thursday. You're translating a decision you made earlier into a system that executes it.
When you skip the play and go straight to the workflow, you make those same judgment calls implicitly, inside the tool, where nobody can see them or question them. And then six months later nobody remembers why the workflow works the way it does, including the person who built it, who has since moved on to a different company and is unreachable on Slack.
What a well-defined play actually looks like
Before a single workflow gets built, a play needs five things defined in plain language. Not in a workflow builder. In a document. With words.
The trigger. What specific event causes this play to fire? Not "high intent accounts" — that's a vibe, not a trigger. The trigger is a specific, observable signal: an executive at a target account signs up and records their first meeting within 48 hours. Three or more people from the same company sign up within seven days. A target account hits five or more service deployments. Vague triggers produce vague automation, which produces vague results, which produces a vague sense that automation doesn't really work.
The fit criteria. Not every account that triggers the play should enter it. What conditions must an account meet to qualify? ICP tier, company size, industry, existing customer status, do-not-contact rules, territory ownership. These are your exclusion filters — the ones that, when missing, produce the horror stories from paragraph one.
The message logic. What is this play actually saying, and why is it relevant to this account right now? The message should be derivable from the trigger. If you can't write a sentence that connects the signal to the outreach — "we're reaching out because X happened, which tells us Y might be valuable" — the play isn't defined well enough yet. Go back. Define it better. Then build.
The tiering rule. Who reviews before this goes out, and who doesn't? This decision needs to be made once, in advance, not by whoever happens to be looking at the queue on a given afternoon and making judgment calls based on their current mood and workload.
The exit conditions. What causes an account to leave the play? A response, a meeting booked, a status change in CRM, a manual override. Automation without exit conditions is how contacts end up getting the same email eleven times. They notice. They remember.
Define all five and you have a play. Build the workflow from that and you have automation that does what you intended.
The tiering model that prevents most failures
The single highest-leverage decision in sales automation is also the one most teams make inconsistently: which accounts get human review before anything goes out, and which run automatically.
Made inconsistently, this produces both over-automation — sequences going to accounts that deserved a personal touch — and under-automation — reps manually reviewing things that didn't need it, which means they stop reviewing anything carefully, which defeats the purpose entirely.
The model that works is simple and needs to be decided once.
High signal plus high fit: human reviews before anything sends. These are your best opportunities. The cost of a bad first impression outweighs the cost of a few minutes of rep time. Every time.
Strong signal and medium fit: full automation. The signal is real but the opportunity isn't your highest priority. Automation handles it consistently at a fraction of the cost of human attention, which you should be saving for the previous category.
Low signal or low fit: nothing, or low-touch nurture at most. This is the hardest discipline to maintain because the temptation is always to do something. The right answer is usually don't. Every piece of irrelevant outreach that goes out makes the relevant ones harder to land — and slowly trains your market to tune you out entirely.
No signal: no action. Full stop. Not a nurture sequence. Not a "just wanted to check in." Nothing. The discipline is the point.
The maintenance problem nobody plans for
Here's what happens to most automation six months after it goes live.
The person who built it is heads-down on something new. The system is running. Nobody is quite sure what it's doing or why. Someone makes a small change to fix one thing and breaks something else. A new exclusion list gets added to CRM but nobody updates the workflow. A new product tier launches and the trigger conditions are suddenly wrong but nobody notices until a very unfortunate sequence of emails goes out to a very important prospect.
Automation that nobody understands is automation that nobody trusts. Automation that nobody trusts gets turned off — usually right after it does something embarrassing, and usually by someone who had nothing to do with building it and now owns the cleanup.
The solution isn't simpler tools. It's documentation that lives next to the workflow, not in someone's head or a Google Doc that hasn't been opened since the quarter it was written.
Every play should have a plain-language description of what it does, why it exists, what triggers it, and what conditions would require it to be updated. Not a technical spec. A two-paragraph explanation that a new team member could read and understand in five minutes without asking anyone for help.
Teams that do this maintain their automation. Teams that don't abandon it and start over. Usually more than once.
What good looks like at scale
The go-to-market teams running automation well share a few characteristics that have nothing to do with which tools they use.
They defined the plays before they built the workflows. Every trigger condition, every fit criterion, every message rationale was written down in plain language before anyone opened a workflow builder. This sounds obvious. It is almost never done.
They made tiering decisions in advance and stuck to them. The rules about what gets human review and what runs automated are explicit, documented, and applied consistently — not re-litigated every time someone looks at the queue.
They built for handoff from day one. The person who built the automation wrote it as if they were going to leave the company the following week. Because eventually, they will.
And they treat the plays as living documents. When a signal stops predicting conversion, they update the play. When a new product behavior emerges as a leading indicator, they add it. The automation reflects what's actually true about how their best customers buy — which changes, because markets change, and automation that doesn't change with them quietly becomes a liability.
The goal isn't automation that runs forever without anyone touching it.
The goal is automation that's easy to understand, easy to update, and trusted enough that people actually use it.
That's the system that scales.
Next in the series: the organizational changes that have to happen alongside the technical ones - what your team actually needs to look like to run this motion.