Behavioral email triggers: design the condition first.

If you cannot say it in one sentence, it is a broadcast.

A trigger is not an email that happens to be automated. It is a condition — and the condition is the part that decides whether the message is welcome, because it decides who receives it and what they were doing a moment before.

The test takes ten seconds. Write the rule as one plain sentence, in the past tense, from the other person’s point of view: they watched to the end of the session and did not buy, they finished module two and have not opened a lesson in a week. If the sentence needs an “and also” to hold together, you have two triggers. If it describes a state of mind rather than an event — “is a hot lead”, “seems interested” — you have an opinion, and no system can fire on an opinion.

Doing it in this order changes the copy as much as the mechanics. Once the condition is written down you know exactly what the recipient just did, which means the message can refer to it plainly instead of opening with the generic paragraph that every automated email opens with. Most of what people call “personalisation” is just a trigger whose condition was specific enough to write about.

The order that goes wrong

Content first is how a business ends up with nine sequences that all say roughly the same thing to roughly the same people, each fired by a condition reverse-engineered to justify a message somebody had already written. It is also why those sequences are impossible to fix: there is no way to make a message more relevant when the rule that sends it was chosen last.

Five kinds of behaviour, and what each one does not prove.

Nearly every trigger worth building comes from one of five families. Knowing which family you are in tells you how much weight the signal can carry — and the last column is the one that keeps you honest.

Two practical consequences fall out of that table. The first is that purchases and state are the only family requiring no interpretation, which is why they belong in the qualifier of almost every other trigger — “and does not already own this” is the single most valuable condition you will ever write. The second is that inactivity is the family small businesses skip, and it is the one covering the work nobody does by hand, because nobody has ever remembered to check who quietly stopped.

Combining families is where the precision is

A single signal is usually too blunt to write to. Watch time plus purchase state gives you the engaged non-buyer. A click plus an absence gives you someone who looked at the offer and stopped. Attendance plus inactivity gives you the person who showed up, meant it, and then let it slide. Two conditions is usually the sweet spot; by the fourth you have built something that fires for eleven people a quarter and takes an afternoon to debug.

Seven fields, filled in before you write a word.

This is the whole method. Fill in the spec, read it back as a sentence, and only then open the editor. It takes about five minutes and it is the difference between a trigger you can maintain and one you will eventually switch off because nobody remembers what it does.

1. 01The event. What happened, in the past tense, from the other person’s point of view. “Watched to the end of the session”, not “is a hot lead”. If you cannot write it in the past tense, it is a state or an opinion, not an event.
2. 02The qualifier. What else has to be true about this person for the message to make sense. Almost every regrettable automated email is a missing qualifier: they had already bought, already replied, already been sent it last week.
3. 03The wait. How long after the event the action runs. The wait is a content decision, not a technical one — it sets what the recipient remembers when it arrives.
4. 04The action. One thing. Send one message, create one task, add to one audience, grant one access. A trigger that does four things is four triggers wearing a coat, and it fails four ways.
5. 05The stop. What cancels the action between the trigger firing and the action running. Usually: they did the thing anyway. Without a stop condition you will email people to ask why they have not done something they did an hour ago.
6. 06The else. What happens to the people who fired the event and failed the qualifier. Writing “nothing, deliberately” is a complete answer. Leaving it blank is not.
7. 07The owner. The person who reads the replies. Automated messages generate human answers, and a trigger with no owner sends them into a mailbox nobody opens.

The spec

Copy this into a document, one block per trigger, and keep the document. It is the only documentation this part of your business needs, and it is what turns a quarterly review from an archaeology project into a twenty-minute read.

TRIGGER   [short name someone else would understand]
WHEN      [the event, written in the past tense]
ONLY IF   [what else must be true about this person]
WAIT      [how long after the event]
DO        [one action]
STOP IF   [what cancels it before it runs]
ELSE      [what happens to everyone who fails the ONLY IF]
OWNER     [the person who reads the replies]

One more field is worth adding in your head even if it never makes it onto the page: what does this person know at the moment the message arrives? A no-show has not heard your argument. Someone who watched to the end has heard all of it and declined. A student who stalled knows exactly where they got stuck and would rather you named it than pretended not to notice. Write to that state, and the copy mostly writes itself.

Triggers do not break loudly. They break by both firing.

A single trigger is easy. The trouble starts at the fourth, when two of them are individually reasonable and jointly embarrassing. These eight rules cost nothing to apply on the day you build something and are painful to retrofit.

1. 01One owner-action per trigger. The action you would name if someone asked what this trigger is for. Bundling a send, a tag, a task and an audience change into one trigger makes it impossible to say which part misfired.
2. 02A cooldown, per person, per trigger. Somebody who clicks the same link four times in a week should hear from that trigger once. Pick a window — seven days is a sane default for anything sales-adjacent — and set it on the day you build the trigger, not on the day someone complains.
3. 03A cap across everything. Cooldowns stop one trigger repeating. They do nothing about six triggers each firing once on the same busy Thursday. A ceiling on automated messages per person per week is the only rule that survives adding new triggers later.
4. 04A written priority order. When two triggers both qualify, one of them wins. Decide the order once, on paper, in the order of how close each is to money: purchase-adjacent beats engagement-adjacent beats housekeeping.
5. 05Suppression that is checked, not assumed. Buyers, unsubscribes, bounced addresses, people already inside a sequence, people who replied to a human this week. Every one of these should be a condition on the trigger, because none of them will be true when you first build it and all of them will be true within a month.
6. 06Traceability from the message back to the trigger. For any message a person received, you should be able to say which trigger sent it and why they qualified. If you cannot, you cannot debug it, and every fix from then on is a guess.
7. 07An off switch you can reach in one action. Not a rebuild. Not deleting the trigger. A pause you can hit from your phone, because the moment you need it is never a moment you are at a desk.
8. 08A named owner and a review date. Triggers do not break loudly. They quietly keep sending a message about a webinar you stopped running in March. Put a date in the calendar to read the list.

When two triggers both want to fire

This is not an edge case; it is Tuesday. The same person attends the session, clicks the offer, and hits the seven-day mark on a course they stalled in — three qualifying conditions inside one afternoon. There are three ways to resolve it and only one of them is worth a small team’s attention.

• →Priority — one wins, the other drops. The simplest rule and the right default for a small team. The purchase-adjacent trigger fires; the newsletter-adjacent one is discarded rather than queued. You lose a message you would probably not have missed.
• →Queue — both run, with a gap. Fire the higher-priority one now and the second after a minimum interval, provided its conditions are still true. Recheck the conditions before the second one sends: the interval is exactly long enough for them to have stopped being relevant.
• →Merge — one message covers both. Occasionally right, usually more work than it saves. If two triggers are so often true together that merging them looks appealing, they are probably one trigger with a branch inside it.

Every trigger you build creates a second one you did not.

The moment you write “if they attended”, you have created the group who did not attend and left it empty. That group is almost always larger than the one you built for, and it is where most of the unclaimed value in a small business sits.

Read the right-hand column as a list of people who did something meaningful and then heard nothing. Someone who reached your checkout and stopped told you more than almost anyone on your list, and in most small businesses the response is silence, because the automation was built for the people who completed the purchase.

Three legitimate things to do with an else branch

• →Send something genuinely different. Not the same email with a sadder subject line. A no-show did not hear your argument at all, so a message referring to “what we covered” reads as though it was written for somebody else — because it was.
• →Wait for a better signal. A perfectly good else branch is a pause. Someone who opened and did not click has told you almost nothing; responding to almost nothing trains people to ignore you. Leave them in the ordinary rhythm and wait.
• →Change the audience quietly. Move them out of the sequence, off the segment, into the slower list. No message at all, just a state change that makes the next trigger more accurate.

What is not legitimate is the fourth option everyone reaches for: the same message with a slightly sadder subject line. The right-hand column is a different audience in a different state, not a worse version of the left-hand one, and a message that treats them as failed attendees reads exactly like what it is.

Three specs, filled in.

One from each of the three families worth starting with. The bracketed parts are yours to replace; the intervals are working defaults rather than findings, and the note under each one explains which choices are load-bearing and which are arbitrary.

TRIGGER   Engaged non-buyer — [session name]
WHEN      The session ended
ONLY IF   Watch time passed [the point where the offer starts]
          AND has not purchased [offer]
WAIT      2 hours
DO        Send [the one email that answers the objection you
          actually heard in the room]
STOP IF   They purchase before it sends
ELSE      Left before the offer → [replay email, timestamped to
          the part they missed]
OWNER     [name]

TRIGGER   Clicked [offer link], no checkout
WHEN      [Offer link] was clicked
ONLY IF   No checkout started in the next 48 hours
          AND does not already own [offer]
          AND has not had this trigger in [7] days
WAIT      48 hours from the click
DO        Send [the short email naming the two questions people
          ask before they buy this]
STOP IF   A checkout is started, or they reply to a human
ELSE      Opened and did not click → nothing. Wait for a
          better signal.
OWNER     [name]

TRIGGER   Stalled after [module]
WHEN      [Module] was completed
ONLY IF   No lesson activity for [7] days
          AND [next module] has not been started
WAIT      7 days from the last activity
DO        Send [the specific help for the thing that comes next]
          AND create a task for [owner] if [high-value customer]
STOP IF   Any lesson activity happens
ELSE      Carried straight on → no message. They are fine.
OWNER     [name]

Notice what the three have in common. Each one has a qualifier that checks state, a stop condition that cancels it if the person acts first, an else branch that is decided rather than empty, and exactly one action. Those four properties are what make a trigger safe to leave running while you are on holiday, which is the only real test of an automation.

A trigger can only fire on behaviour your system records.

This is the constraint that quietly decides which triggers on this page you can actually build, and it has nothing to do with how good your automation tool is. It is about whether the signal and the qualifier can be read from the same person at the same moment.

Take design 01. “Watch time passed the offer marker AND has not purchased” needs the watch-time data and the purchase data to sit on one record. If the webinar tool holds the first, the checkout holds the second and the email tool holds neither, that condition is not a trigger — it is an export, a spreadsheet, a manual segment upload, and a twenty-four hour delay by the time anyone has done it. So the trigger you actually build is the blunter one that your weakest integration supports, which is why so many small businesses end up sending “thanks for attending” to a list that includes the people who bought.

The three questions to ask your own stack

1. 01Can the signal reach the rule at all? Not eventually, through a nightly sync — within minutes, while the message would still make sense. A trigger with a sixteen-hour lag is a scheduled send with extra steps.
2. 02Can the qualifier be checked at the moment of firing? Purchase state is the one that matters most and the one most often stale. If your automation tool learns about purchases once a day, every purchase-adjacent trigger has a window in which it will embarrass you.
3. 03Can you see, afterwards, what happened to one person? When something misfires you will want the path a single record took through the rule. If that requires three logins and a guess, you will not check, and the trigger will stay slightly wrong for months.

None of this is an argument for a particular product. It is an argument for testing the condition before designing around it: pick the trigger you most want, and check whether both halves of it are visible in one place before you write the email.

Three triggers, running, beats thirty on a whiteboard.

Trigger design is enjoyable enough that it becomes a substitute for shipping. Build these three, in this order, and leave them alone for a month before adding a fourth.

How to know it works before anyone else does

Put yourself through it first. Register, do not attend, watch half, click the link, abandon the checkout — whatever the condition describes — and receive the consequence in your own inbox with your own timing. Then check the execution history forty-eight hours later and read what actually happened to five real people, not the summary count. The count tells you the trigger fired. Only the path tells you it fired for the right reason.

Then put a date in the calendar. Once a quarter, read the specs, check which triggers fired at all, and switch off the ones that fired for nobody or fired for everybody. Both are broken; only one of them is obvious.