Marketing Automation That Behaves Like a Person Would

A customer writes to support on Monday because their order arrived broken. On Tuesday morning that same customer receives a cheerful message asking whether they would like to buy the thing again, and, a little further down, an invitation to leave a public review. Nobody decided to send that. Two systems each did something reasonable, and between them they produced something no colleague would have done.

That is the whole subject of this piece. Marketing automation design is not the craft of building more branches. It is the craft of making a machine behave the way an attentive person with the same file would behave. Nothing about the Tuesday email required better copy. It required somebody, or something, to know that a conversation was already happening.

Three rules carry most of the weight. Never send what a person would not send. Respect context and recency. Always leave an exit. What follows is what each one means in practice, plus the structural failure that produces Tuesday mornings: triggered chains that collide because nothing sits above them with the authority to say no.

Rule one: would a person have sent this?

Take any automated message and ask whether a competent colleague, holding the same file, would have sent it that morning. Not whether they would have written it. Whether they would have sent it, then, to that person, in that state. Almost all bad automation fails on timing and state rather than on wording.

The test is useful because it is cheap and very hard to argue with. A campaign brief can survive a great deal of internal justification. The question "would you personally send this to her today?" survives almost none. Ask it out loud in the review and watch which sequences quietly get rewritten before anyone has to defend them.

It also reframes what the work is. Building a lifecycle programme is less like writing campaigns and more like writing standing instructions for an assistant who never gets tired, never reads the room and never asks a clarifying question. Every gap in the instructions gets filled by the machine doing the literal thing, on schedule, to everyone who matches.

Which is why the first artefact we produce is not a flow diagram. It is a list of the situations a person can actually be in, written in ordinary language: waiting for a delivery, halfway through setting something up, unhappy and mid-conversation with support, dormant for a long time, actively comparing you with someone else. Messages get attached to situations. Situations do not get invented to justify messages somebody already wanted to send.

Rule two: context and recency

A message is only as considerate as the facts consulted at the moment it fires. Most platforms know a great deal about a person and check almost none of it, because the trigger was written against one field and shipped on a deadline.

State, not segments

A segment describes a person. A state describes a moment. "Subscribed, in the UK, bought once" is a segment. "Has an open support ticket" is a state, and the state is what should decide whether a promotional send happens this morning. Good automation work spends most of its effort on the conditions rather than on the branches, because the conditions are where the embarrassment lives.

The other half of context is what you asked for in the first place. A form demanding nine fields collects nine fields of noise, and none of them tell you what this person is trying to do. What a landing page should ask for is the upstream version of the same argument: collect the small number of facts you will genuinely use to decide what happens next, and stop collecting the rest.

Recency is a rule, not a courtesy

Before any automated message leaves, the system should be able to answer these five questions. If it cannot answer them, it is not ready to send, whatever the trigger says.

• What has this person received from us recently, on every channel? Not just this channel. Three messages in a morning are three messages in a morning whether they arrive by email, push or SMS.
• What did they just do? A win-back message to someone who purchased yesterday is the clearest possible signal that nobody is watching.
• Is there an open conversation? A live support ticket, a return in progress or a complaint outranks anything scheduled. Marketing should stand down until it closes.
• Have they already done the thing this message asks for? Asking someone to complete a step they finished last week is the automation equivalent of not listening.
• Did they tell us something we are about to contradict? A stated preference, a paused subscription, a reason for leaving. Contradicting a person’s own words is the fastest way to lose them for good.

None of these are difficult queries. They are simply not asked, and the reason is organisational rather than technical: each chain was built by a different person in a different quarter, and nothing above them arbitrates.

Rule three: every message carries an exit

An exit is not the unsubscribe link in the footer. An exit is the reader’s ability to change the relationship at the moment they want to change it, with the change taking effect immediately and without a negotiation. Three things make one real: it is findable, it is graded, and it is honoured at once.

Findable means legible, keyboard-operable and not disguised as body text in a lighter shade of grey. Accessibility applies to the parts of a message nobody demonstrates in a pitch, and the unsubscribe control is the one people go looking for while already irritated. Make it easy to hit on a phone, in a hurry, with one thumb.

Graded means the choice is not only between everything and silence. Most people who unsubscribe do not want nothing; they want less of it, or a different part of it. A preference page offering fewer messages, or only the operational ones, keeps a relationship that an all-or-nothing footer link ends permanently. The people who take the reduced option are often the ones you most wanted to keep.

Honoured at once means the suppression applies before the next queued send, not at the next sync, and that it applies across chains: someone who left the newsletter did not agree to remain in the onboarding drip. In several jurisdictions consent and the right to object are legal obligations rather than preferences, and the operational bar is higher than a link in a footer. You have to be able to show what a person agreed to, and when that changed.

The wording of the exit matters more than teams expect. Guilt-tripping copy on an unsubscribe page turns a mild decision into a resentful one, and resentful people talk. Microcopy is the cheapest conversion work available, and it is also the cheapest way to lose somebody politely instead of badly.

Where marketing automation design breaks: chains that collide

Every programme starts with one chain and ends with eleven. Welcome, onboarding, abandoned basket, re-engagement, review request, seasonal promotion, product announcement, renewal reminder, referral push, feedback survey, and one somebody built for an event two years ago and never switched off.

Each is sensible on its own. They were written independently, tested in isolation, and released into the same inbox. So the collisions arrive: the win-back to somebody who bought yesterday, the review request in the middle of a complaint, the onboarding tip to a person who cancelled last week, three messages in one morning because three unrelated triggers happened to fire together.

Why it happens

This is an ownership problem wearing a technical costume. Nobody owns the total volume one human being receives, because no report shows it. Platform reporting is per-campaign, and per-campaign reporting cannot see a collision by design: the offending messages appear in different tables, each with a respectable open rate.

The second cause is that switching things off is nobody’s job. Every chain has an author who wanted it built. None has an author who wants it dead. So the programme accumulates, quietly, until the volume itself becomes the problem and no single message can be blamed for it.

The fix: one gate everything passes through

The structural fix is a single send gate: one place every automated message passes through before it leaves, with the authority to delay it or drop it. Not another workflow. A rule that runs last, after the chain has decided it wants to send. It needs four things: a frequency cap per person across channels, a priority order for when two messages qualify at once, a suppression list keyed to states rather than segments, and a quiet window that is actually enforced.

Read the right-hand column as the real specification. Most programmes have the first two columns documented somewhere and the third column nowhere at all, which is precisely why Tuesday morning happens. Write the suppression rules first and the sequences second, and the sequences get shorter.

Automation rarely fails because a message was wrong. It fails because every message was right in isolation and nobody was in charge of the whole conversation.

Where an assistant fits, and where it does not

A site assistant changes the shape of this problem, because it moves part of the conversation to the moment the person is already thinking about you. A message you send is an interruption you scheduled. An answer you give is a response to something asked. The second is far easier to get right, and the constraints on it are different.

That is the job a widget like Flidu does: website-informed answers alongside contact, information and conversion actions in one place, so a visitor with a question gets it answered instead of joining a sequence that guesses at the question. Used well, it takes pressure off the automated programme by removing the messages that only existed to cover uncertainty about what somebody wanted.

The failure modes are worth knowing before you install anything. An assistant answering confidently from stale or missing content produces exactly the trust problem the automation was meant to avoid. Our parent company has written about why a chatbot gives wrong answers and about when an answer is not enough, which is the more interesting case: the moment where the correct response is to hand the conversation to a person rather than to answer it better.

The boundary we hold is simple. An assistant may answer, route, book and collect. It should say plainly that it is a machine, and it should hand over without argument the moment somebody asks for a person. AI development and integration that skips those two rules produces a support cost, not a saving.

What to instrument, so you can tell

Per-campaign reporting will tell you a message performed. It cannot tell you the programme is wearing people down, because the person who received four messages this week appears as four unrelated rows in four different reports.

So instrument at the level of the person. Messages received per person per week, across every channel. Unsubscribe rate attributed to the preceding message as well as the one they left from, because the send that caused the exit is often not the send that carried the link. Complaints tagged with the state the recipient was in. And the time between a support contact and the next marketing send, which is the one measure that would have caught the Tuesday email before anyone outside the building saw it.

None of that is exotic. It is ordinary analytics work pointed at your own outbound behaviour instead of at your channels, and it usually takes less effort than the reporting already being produced.

Then there is credit, which automation distorts more than any other channel, because a lifecycle programme touches almost everyone and therefore appears in almost every path. Your best performing channel is probably being miscredited explains how the distortion arises. When the question arrives from someone senior, attribution you can defend is the version of the answer that survives being challenged.

Where we would start

If you have inherited a programme with eleven chains and no gate, do not redesign it. Redesigning is what everyone proposes, and it takes a quarter and changes nothing about the collisions. Do this instead, in this order.

1. Inventory every send. Every automated message that can leave the building, including the ones nobody remembers building. Put a name against each. Anything with no owner gets switched off, and the business survives it.
2. Receive your own programme. Put a real address through the main paths and read what arrives, in the order it arrives, at the hours it arrives. This is unglamorous and it finds more than an audit does.
3. Add the gate before adding anything else. Frequency cap, priority order, suppression states, quiet window. It is less work than one new chain and it prevents more damage than all of them combined.
4. Fix the exits. Graded preferences, honest wording, suppression that applies immediately and across every chain rather than only the one they left.
5. Only then write new sequences. Attached to the situations you listed at the start, not to the campaign calendar for the quarter.

Here is the honest cost. A gate loses you sends, and somebody will notice. Suppressing a promotional email because the recipient has an open ticket is a message that does not go out, and the report for that campaign will be smaller than it would have been. We think that is the right trade every time, and it is still a trade. Make it explicitly, in the room, with the person who owns the number, rather than letting a platform default make it quietly.

The rule to keep, if you keep only one: automate the sending, never the judgement. A system decides when the stated conditions are met. A person decides what the conditions should be and revisits that decision when the business changes. If a programme has grown past what anyone can hold in their head, tell us what is currently firing and we will start with the inventory.