When to automate marketing: automation is codified judgment.

A workflow is a judgment you have already made, written down.

Which is exactly what makes it valuable when the judgment is settled, and exactly what makes it dangerous when it is not. Software does not improve a decision by executing it faster. It only removes the moment where you would have noticed it was wrong.

Most advice about marketing automation is written as though the question were “can this be automated”. Almost everything can. The useful question is whether the judgment underneath is stable, what happens on the day it turns out not to be, and whether the work it saves is work you are genuinely doing. Three tests, and any one of them can stop a build on its own.

Run them in that order, because they get progressively easier to answer and the first one disqualifies the most candidates. Then ask the question that decides what happens over the following two years, which is what the workflow will cost you to keep.

Have you done it manually five times, the same way?

Five is a threshold rather than a law. It is enough repetitions to have met the edge cases and few enough that you have not wasted a year proving something obvious. What the number is really protecting you from is variance.

Read the last three times you did the work, side by side. If they differ only in wording — the same steps, the same order, the same decision points — the process is stable and ready to be written down. If they differ in their steps, you have been improvising competently, and encoding an improvisation produces a workflow that is wrong in a consistent and invisible way.

Signals that you are not there yet

• →You still make a call halfway through. Somewhere in the middle you look at the specific person and decide something. That decision is the interesting part of the work, and it is the part a workflow cannot make.
• →The trigger is a feeling. “When it seems like the right moment” is not a trigger. If you cannot express the starting condition as something a system could observe, you are not describing a workflow yet.
• →You cannot name the two edge cases. Every process has them: the person who is already a customer, the one who did the thing twice, the one whose data is missing. If you have not met them by hand, the workflow will meet them for you.
• →The copy changes every time for a reason. Not because you are fiddling, but because the situation is genuinely different each time. That is a sign the work is judgment wearing the costume of a process.

One clarification worth making, because it is where this test is most often misapplied: what has to be repeatable is the rule, not the content. A workflow can happily send five different messages to five different branches. What has to be stable is the logic that decides which branch somebody lands in. If you can say “anyone who did X gets the X message” without hesitating, the rule is repeatable even though the output varies.

What happens on the day it fires wrong?

Not whether it will. Every automation eventually does something you did not intend, because data is imperfect, edge cases arrive, and something upstream changes without telling you. The question this test asks is what that costs and how far it reaches.

Two variables: blast radius — how many people see it — and reversibility — whether the effect can be undone. They multiply rather than add. A wrong tag on ten thousand records is a five-minute fix. A wrong email to ten thousand people is a day, an apology, and some number of unsubscribes you will never see again.

The rule this produces

As blast radius rises, add a gate rather than abandoning the automation. The workflow still does the work — it watches the signal, assembles the context, prepares the action — and then it stops and waits for a person. You keep the reliability and the speed of the preparation, and you keep human authority over the part that cannot be undone.

1. 01Cap the audience while it is new. Run a new sending workflow against a small segment for the first two weeks. You are not testing the copy at that point; you are watching for the entry condition being wider than you thought.
2. 02Gate anything irreversible. Money, access, public posts, and anything about somebody’s status. Prepare automatically, send manually, until the rule has been right for a long time.
3. 03Give every workflow a stop. Know how to pause it in under a minute, and make sure whoever notices the problem at 7pm has permission to do it without waiting for you.
4. 04Make failures visible. A workflow that silently stops firing is worse than one that breaks loudly. Decide where the error notice lands and who is expected to read it.

Is the manual cost real, or does it just feel large?

Repetitive work feels more expensive than it is, because the annoyance lives in the interruption rather than in the minutes. Count before you build, and count both sides.

The arithmetic is trivial and almost nobody does it: minutes per instance, multiplied by instances per month, against hours to build plus hours per year to maintain. The following figures are illustrative arithmetic — put your own numbers in, because the whole point is that the answer changes completely between two pieces of work that feel identically irritating.

The second half of the test

Then there is the case the arithmetic misses entirely, and it is the reason the highest value workflows in most businesses are also the smallest. Sending one reminder ten minutes before a session takes two minutes. Doing it reliably, for every session, at any hour, on the day you are ill or presenting or on a plane, is not a two-minute job — it is an impossible one. The same is true of anything that has to happen within minutes of a signal: an abandoned checkout, a registration confirmation, access after a purchase.

So the volume test has two halves, and either can justify a build on its own. Is the time real — hours a month rather than minutes a year. And is the timing possible — could a human reliably hit the window this work has to happen in. Latency and reliability are the honest arguments for automating small things; saved hours are the argument for automating large ones.

Some work stays human on purpose, not because you ran out of time.

There is a category of marketing work that passes all three tests on paper and should still never be automated, because the value of it is precisely that a person did it.

• →First-touch replies. When somebody writes to you as a person for the first time, an automated response answers a question they did not ask. Acknowledging receipt is fine — “this arrived, you will hear from a person by Tuesday” is information. The answer itself is a conversation, and conversations are not workflows.
• →Anything reputational. Apologies, incident notices, changes to pricing, anything about somebody’s money or status. The cost of getting one of these wrong is not one bad email. It is the credibility that made every other email work.
• →The judgment calls. Qualification, exceptions, refunds outside the stated policy, whether this person is a good fit for the expensive thing. These are the decisions your business is actually made of, and they are the last things to hand over.
• →The first run of anything new. Send the first launch by hand. You will learn more from writing forty individual emails once than from any report about a sequence, and the automation you build afterwards will be the right one.
• →Anything where slow is cheaper than wrong. This is the general form of the rule, and it is worth keeping. If a two-hour delay costs you very little and a wrong message costs you a lot, a person should be in the middle.

Every workflow you build is something you now own.

Automation is not a one-time cost. It is a small permanent liability paid in attention, and it comes due at the worst possible moment — when the offer changed and the workflow did not.

Nothing about this decay is dramatic. The link still resolves, to a page about last year’s programme. The email still sends, and still says “join us next Tuesday” to somebody reading it on a Thursday in March. The branch still fires, using a rule that made sense when the pricing had three tiers. Nothing breaks loudly. It just slowly stops being true, which is exactly the failure mode that catches always-on evergreen funnels, and for the same reason: nobody is in the room when it runs.

What decays, exactly

• →Links and destinations. Pages get renamed, offers get retired, and a workflow keeps pointing at whatever it was told to point at on the day it was built.
• →Prices, terms and names. The message quotes a number or a policy that a human would have updated instinctively. Automation is the reason your sales page and your receipt can disagree for eight months.
• →Dates and tenses. Anything that says “next week”, “this month” or “the upcoming session” is a small time bomb in an always-on sequence.
• →People. The person who signs the email left. The person the internal task routes to changed roles. Nobody notices until somebody replies to a name that no longer works there.
• →The assumption underneath the branch. The most expensive one, because it is invisible. The rule was correct about a business that no longer exists in that shape.

The inventory, and the rhythm

One list. Every live workflow, what triggers it, who owns it by name, when it was last reviewed, and the single number it is supposed to move. Anything not on the list is either turned off or adopted — those are the only two options, and “we will look at it later” is how a business ends up sending mail nobody can account for.

Review the whole inventory quarterly, and review any individual workflow immediately when an offer, price, name, link or date it references changes. Re-test after every change rather than trusting the edit — the workflow testing checklist covers what to re-run when you touch something live.

Manual, checklist, automation, delegation — in that order.

Four rungs, and the failure in nearly every automation project is skipping the second one. You cannot encode a process you have not written down, so people who jump from doing it by hand to building a workflow end up writing the specification inside the tool while the tool is running.

1. 01ManualDo the work yourself, every time, and pay attention to what you actually do rather than what you think you do. Keep the replies and the awkward cases.What it buys you The real steps, including the ones you would never have thought to write down, and the edge cases that decide the branches later.
2. 02ChecklistWrite it as steps somebody else could follow, then do the work from the written version. Edit the checklist as you go. When the edits stop, the process is stable.What it buys you Consistency without software, the first honest measurement of what the work costs, and the specification you will build from.
3. 03AutomationEncode the checklist: the trigger, the conditions, the branches, and every exit rule. Test it as a real contact before anybody else meets it.What it buys you The work happens on time, at volume, at any hour — and the decision becomes legible to everyone rather than living in your head.
4. 04DelegationHand steps to a person or an agent, with the checklist as the brief and a review gate on anything consequential. The brief is the thing that makes this work, which is why it comes after the checklist and not instead of it.What it buys you Capacity, without giving up authority over what goes out.

The fourth rung is where AI agents belong, and framing them this way settles most of the argument about them. An agent is a worker you are delegating to, not a faster workflow. It needs the same things any new hire needs: the brief, the context, the boundaries, and somebody checking the consequential output before it reaches a customer. Handing an agent an undocumented process is not delegation — it is transferring a problem and adding a layer of plausible-sounding output on top of it. Approval gates covers where to place the gate and what a good review actually inspects; the wider argument for running a business this way is in the agentic operating system.

Six questions, in order, before you open the builder.

This is the whole guide compressed into a procedure. It takes about twenty minutes per candidate and it will talk you out of more builds than it talks you into, which is the intended effect.

1. 01Name the work as a trigger and an outcome. One sentence: “when X happens, Y should happen.” If the sentence needs an “it depends” in the middle, you have found the judgment call, and the judgment call is the thing to look at first.
2. 02Count the repetitions and read the variance. Not how often it happens — how often you have done it, and how differently. Five times the same way is the threshold. Five times three different ways is a draft with a high frequency.
3. 03Ask what a wrong firing costs. The worst message, to the largest group it can reach, on the worst day. If that is an apology, build it. If that is a refund, a lockout or a screenshot, put a person in front of it.
4. 04Do the arithmetic, both halves. Minutes multiplied by instances for the time cost, and then the timing question: could a human do this within the window it needs to happen in, reliably, at any hour. Either half can justify the build.
5. 05Choose the rung, not the tool. Manual, checklist, automation, or automation with a review gate. Most work that feels like it needs automating actually needs a checklist and one more month of doing it.
6. 06Assign an owner and a review date before you build. A name and a date, written next to the workflow. Anything without both becomes the workflow nobody turns off because nobody is sure what it does.

Two outcomes are wins. Building the workflow is a win. Deciding not to build it — and writing down why, so the question does not get relitigated every quarter — is also a win, and it is the one people forget to count. The failure mode is neither: it is building something because it was possible, on a Sunday, with no owner and no number attached to it.

When the answer is build, the order to build in is not a mystery either. Five workflows pass all three tests for nearly every business, and they are worth having in place before you spend judgment on anything more exotic — the first five marketing automations covers each one with its trigger, its exit rules and its number.