Behavior-Triggered Emails: Responding to Actions in Real Time
Choosing triggers that mean something, setting the delay, and the suppression rules that stop trigger pile-up.
On this page
The short version
- The trigger has to mean something. Most tracked events are incidental, and firing on one produces a message the recipient cannot connect to anything they did.
- A delay is almost always right. Immediate is appropriate for a handful of triggers and unsettling for most.
- Suppression rules matter more than the triggers. Once several flows fire on behaviour, collision is the default outcome.
Behaviour-triggered email responds to something a subscriber did. Done well it is the most relevant email in a programme; done carelessly it produces messages that arrive for no reason the recipient can identify.
Three decisions separate them: which events are worth acting on, how long to wait, and what stops two flows firing at once.
Which events mean anything
The test is whether the action cost the person something — time, attention, a decision. Actions that cost nothing happen incidentally and carry no signal.
Starting a trial, requesting something specific, replying, returning three times in a week, reaching a milestone inside a product: all of these are deliberate and rare enough to mean something.
Viewing a page, opening an email, clicking a navigation link: common enough that a trigger on them fires for almost everyone, which is another way of saying it selects nobody.
Trigger, delay and why
| Trigger | Delay | Why |
|---|---|---|
| Requested something specific | Immediate | They are waiting for it |
| Completed a setup step | Immediate | Momentum is the point |
| Started a trial | Minutes | Let them look around first |
| Reached a usage milestone | Hours | Acknowledgement, not interruption |
| Stalled partway through setup | A day | Long enough to be genuinely stuck |
| Viewed a considered-purchase page twice | A day | Immediate reads as surveillance |
| Went quiet after regular use | A week | Confirm the pattern before acting |
Suppression is the harder half
One behavioural trigger is straightforward. Five, running alongside a welcome sequence and a campaign schedule, will collide — and the collision is the failure recipients notice.
Three rules cover most of it. A per-subscriber frequency cap across everything, so no combination of flows can produce four messages in a day. A rule that anyone inside a welcome sequence receives nothing else. And a stated precedence order for when two triggers fire in the same window.
The cap is the one that matters most, because it fails safe against the collisions nobody anticipated — and with several behavioural flows running, most collisions are ones nobody anticipated.
Re-entry, and the loop nobody notices
A behavioural trigger fires whenever its condition is met, which means someone who repeatedly does the thing can receive the same message repeatedly.
Every behavioural flow needs a re-entry rule: once per subscriber, once per period, or once per distinct object. Without one, the person who checks the pricing page weekly receives the pricing follow-up weekly, and nobody notices because it looks correct in the flow.
The tell is a subscriber appearing many times in a flow's send log. Worth checking on any behavioural flow after it has been live a month.
Test the trigger, not just the message
Perform the action yourself and confirm the message arrives — with the right delay, containing the right details, and only once.
Then perform the action in a way that should not qualify, and confirm nothing arrives. That second test is the one that catches a condition that was never applied, which is the most common trigger fault and produces a flow that fires for everybody.
Both take minutes and both need repeating whenever the site, product or tracking changes, because a behavioural trigger is a dependency on something outside the email platform.
Behavioural trigger check
- The action cost the person something
- The delay is deliberate, and immediate only where they are waiting
- A re-entry rule exists — once per subscriber, period or object
- A frequency cap applies across every flow
- Anyone in a welcome sequence is suppressed from other flows
- Precedence between triggers is written down
- The trigger was tested by performing the action
- A non-qualifying action was tested and produced nothing
Frequently asked questions
How many behavioural triggers should a programme have?
Two or three that fire on genuinely meaningful actions. Beyond that the suppression logic becomes harder to reason about than the flows are worth.
Should the email reference the action explicitly?
Where the person would expect you to know — a request, a purchase, a setup step. Where the signal was inferred from browsing, reference the subject rather than the act.
What if the tracking breaks?
The flow stops firing and reports nothing, which is silent. Alert on a flow's send volume dropping to zero; it is the only warning you will get.