Notification Strategy

Notifications usually get attached by whichever team builds the feature. Ship comments, add a comment alert. Ship billing, add a payment-failure alert. Each one is defensible on its own. The trouble is that the people attaching them don't know about each other.

At Pagedeck this became obvious the day Grace spent a working day on her own account. A marketing roundup arrived in the morning, three comment alerts arrived around lunch, and in the evening came a win-back push notification from the growth team. Six messages in a day, and the number six appeared in no internal document anywhere, because three teams had each sent two and each considered two reasonable.

A notification strategy fills that gap. Instead of arguing message by message about whether something should go out, the team writes down in advance which conditions produce which message, and new alerts have to fit into that. Only then does anyone own the total a single user receives.

It is written as a list of rules pairing a condition with a handling, not as a one-line policy. Each rule settles six things.

1. The trigger — what event causes the message. Someone comments on my document, a payment fails, a user hasn't opened the product in seven days. Each is something the system can decide on its own. An event that reaches out and pulls someone back in like this is called a trigger.
2. The audience — who receives it. Whether a single comment notifies only the document's author or everyone who ever wrote in it changes the daily total by a factor of several.
3. The channel — where it goes. A push notification on the device, an email, or an in-app message that appears only inside the product. Urgency and intrusiveness differ across all three.
4. The timing — immediately, or batched into one send at a fixed hour. Quiet-hours rules live here too.
5. The cap — the maximum number of messages one person can receive in a given period.
6. The off switch — whether a user can silence this alert specifically or only all alerts at once. The finer this control, the more of the remaining messages survive a moment of irritation.

Filled in, one rule reads like this: when someone comments on a document I created, notify me, by push, immediately, exempt from the cap, and let me turn off comment alerts without touching anything else.

Rules fall into two groups: messages the user's own activity produced, and messages the company decided to send. The first kind is news the recipient was waiting for, so it sits outside the cap. The second kind competes for space inside it. Skip that distinction and a cap of two per week fills up with two comment alerts, leaving no room for the announcement that actually needed to go out.

The document gets opened most often just before a feature ships, when the team decides whether the feature needs an alert, checks it against the existing rules, and writes a new rule if none fits. Four other places come up regularly.

1. Planning a win-back campaign. Deciding what to send someone who hasn't shown up in a few days is the core of it, and results here move the retention numbers. Retention measures how reliably existing users return, so noting that some of those returns were bought with messaging is what keeps the number readable later.
2. Designing the notification settings screen. Split the switches by type and an annoyed user silences the one thing bothering them. Offer only all-or-nothing and that same user silences everything.
3. Collecting consent. Promotional messages can go only to people who agreed to receive them in advance, an arrangement called opt-in. In most markets marketing consent is a legal requirement rather than a courtesy, so the strategy records the consent basis channel by channel.
4. Balancing one user's total load. When several teams bring something to send in the same week, they take turns within the cap. Pagedeck holds that conversation every Monday, and it is usually the only place where anyone sees the week's full outbound volume for a single person in one view.

"Where does this one fit in the strategy? Is it an immediate rule or does it go in the morning batch?"

A request to place the new alert inside an existing rule instead of inventing a path for it.

"Campaign pushes are capped at two a week, so there's no slot left this week."

The decision is settled by the agreed cap rather than by arguing about whose message is more deserving.

"Let me turn off comment alerts on their own. Right now it's all or nothing."

The off switch is too coarse, so anyone who dislikes one type ends up silencing every type, including the ones they would have kept.

At Pagedeck, Mia owns the document and Ravi comes to it asking for slots. Last month he wanted to push people twice a week about documents they'd abandoned, but the cap was already taken by launch announcements, so one of those moved to an in-app message to free a slot. Theo wired the rules so the running code reads them directly, which means changing the cap in the document changes what actually goes out.

When the document and the code drift apart, the strategy stops describing reality within about six months. Rules are always updated more slowly than the product they cover, and nobody notices the gap until someone counts what a real account received last week.

The most common reduction is treating it as a decision about frequency. The word strategy sounds like a dial for how often to send. In practice the longest arguments in the document are about what will not be sent at all. Deciding what is worth sending belongs to the team that built the feature; the strategy filters that list down to what deserves to light up a screen. Lose that distinction and the rules keep growing while nothing is ever filtered out, which is the same as having no strategy with more paperwork.

The second mistake is treating it as a document that gets written once. It feels that way because the first version takes several teams and a long meeting. But every new feature adds a rule. Without someone named to maintain it, the document lists twelve rules while twenty-five are firing, and from that point nobody can answer whether the cap is being honored.