Triggered Message

Sending one message to everyone at once is easy for the sender and mostly irrelevant to the receiver. Someone who signed up yesterday and someone six months in get the same email, and people already using a feature get told to try it. The sender sees one number for the whole send and can't tell which half of it was wasted.

Pagedeck started that way. Ravi sent a news email to all users on Tuesday mornings. The open rate sat around 9 percent and wouldn't move, and unsubscribes accumulated a little each week. The content wasn't bad, and that was still the result.

Then Ravi tried something different. On day three after signup, only to people who hadn't created a single document yet, he sent one short note. The open rate was 41 percent. The content hadn't improved; the reader happened to be in the state where that note mattered. A triggered message takes the send moment off the calendar and attaches it to a person's behavior.

When a predefined event happens to one person, a message goes to that person alone. Five things get wired.

1. The event — what has to happen. Three kinds exist: doing something, like creating a first document; a state changing, like moving from free to paid; and something not happening, like three days with no activity at all.
2. The condition — which of the people hitting that event actually receive it. Narrow it to free users only, or to people with admin rights. Without a condition, everyone caught by the event gets the same copy, which ends up close to a broadcast with extra machinery behind it.
3. The delay — how long after the event to send. What goes immediately and what goes a day later are different messages. Congratulations on a first document belong immediately; a question about how it went belongs about two days out, once there is something to answer.
4. Channel and content — email, in-app notification, or text, and what to say. One request per message. Two requests in one email usually produce neither.
5. Rules for stopping — don't send to people who already did the thing, and cap how many messages one person can receive in a day. Without the cap, anyone caught by several triggers at once gets four emails in a morning, and unsubscribes from all of them at once.

Of the three kinds, the one that earns the most in practice is something not happening. Messages sent to people who did something reach people already doing fine; messages sent to people who didn't are what unblock a stuck spot. That kind also breaks most easily: set the condition wrong and you're nagging someone who doesn't need it yet, so check the records for how many days to wait before wiring it. The right number is usually longer than it feels.

When the content carries advertising, consent status goes into the condition. A note about a first document is help with using the service, but attach a paid-plan discount to the end of the same email and that email is advertising, with every rule that follows from it.

The heaviest use is the stretch right after signup. Find from the records where new people stop, and wire one trigger at each of those spots. Pagedeck wired three: people with no document by day three, people who created a document but invited nobody, and people who sent an invitation the recipient never opened. Each of the three is a different stuck spot with a different note.

Three other places.

1. Signs of leaving — someone who used to come weekly and hasn't appeared for two weeks. Asking what got in the way earns more replies here than introducing a new feature does, and the replies are worth more than the reactivation.
2. Where operational notices overlap — a failed payment or an arriving invitation has to be sent. Put marketing copy on those and their nature changes, so their lists and consent conditions get handled separately.
3. Where several messages chain — one trigger becoming the condition for the next makes a scenario. A scenario of messages flowing by condition is a customer journey, and designing the whole thing around customer stages is lifecycle marketing.

Some things don't suit it. Content whose timing has nothing to do with the individual doesn't become a trigger. A maintenance notice or a pricing change has to reach everyone on the same day, which is what a broadcast is for. Wiring those as triggers only delays them unevenly.

"Let's wire this as a trigger instead of a broadcast. Only people with no document by day three."

Make the receiver's state the condition.

"Don't set the delay to immediate. An email the second you do something feels like surveillance."

Adjust the gap between event and send.

"This person got three of our emails today. Let's put a daily cap on."

Nothing is stopping overlapping triggers.

Ravi wired the three onboarding triggers and checked the records a month later. The share of people creating a first document went from 52 percent to 61 percent, and unsubscribes came in below the broadcast era. Fewer messages, better outcome — which is the trade this method actually offers.

A new problem surfaced instead. People caught by all three triggers received three emails across two days. Ravi capped it at one a day and ordered them by priority, and that problem went away.

The most common belief is that wiring it once means never touching it again. "Automatic" reads that way. But when the product changes, triggers start lying. A screen gets renamed while the email copy uses the old name, or a removed feature keeps being introduced. Left alone, months of sends go out while nobody is watching, and to users it reads as an unmaintained product. Teams that write a review date when they wire the trigger run into this less, because somebody is made responsible for reading it again.

The other common belief is that more triggers are better. Each one shows a lift, so more should mean more. But the total any one person receives grows with the count, and past some point the open rate falls below the broadcast era. Before wiring one more, count how many messages one person now receives in a week. Personalization — showing different content per person — doesn't rescue a volume problem either.