In short
Send a notification only when the person needs to know now and can act on it. Match the channel to the urgency — in-app for awareness, email for reference, push for genuinely time-sensitive things — and batch anything that is not urgent. Notification fatigue is irreversible: once people mute you, the important message does not arrive either.
The test
Before adding any notification: would this person want to be interrupted for this?
Not did something happen. Not could we tell them. Would they want the interruption.
Most notification systems fail because they were built from the event log — anything the system can detect becomes something the user is told. That produces volume, and volume produces muting.
And muting is the failure that matters, because it is not selective. Someone who turns off your notifications does not receive the important one either. You spent their attention on trivia and lost the channel.
Three questions per notification type
Does the person need to know? Not would they find it mildly interesting. If nothing changes for them, it is a log entry, not a notification.
Do they need to know now? If it can wait until they next open the product, it is an in-app indicator. If it can wait until tomorrow, it belongs in a digest.
Can they act on it? A notification with no possible action is an anxiety generator. Either give it an action or do not send it.
Anything failing all three should not exist. Anything passing all three deserves a real channel.
Choosing the channel
Each has different cost to the recipient, and should carry different content.
In-app is the cheapest — a badge, an inbox, a subtle indicator. Right for anything the person will care about when they next visit. Most notifications belong here and nowhere else.
Email is asynchronous and searchable. Right for things needing a record: receipts, confirmations, summaries, anything with a link they may return to. It is also the only channel that reliably persists.
Push is the most expensive, because it interrupts a device. Reserve it for genuinely time-sensitive things the person asked for. Marketing via push is the fastest way to have your app's notifications disabled entirely.
SMS is more expensive still, costs money, and should be reserved for security codes and urgent operational messages.
A common mistake is sending the same content to several channels. Receiving the same thing three ways reads as broken rather than thorough.
Batch aggressively
Most systems notify per event. Most people want a summary.
Ten comments on a document should be one notification saying ten comments arrived, not ten. A team member completing six tasks is one update.
Batch by default, escalate by exception. Digest what is not urgent — hourly, daily, weekly depending on the product — and send immediately only when there is a genuine reason.
Batching also solves the burst problem, where activity produces a flood that buries everything including the parts that mattered.
Write them to be read on a lock screen
A notification is often read in full at a glance and never opened.
Lead with what happened, then who. "Invoice #204 was paid" before the sender's name.
Be specific. "You have a new notification" wastes the interruption entirely.
Fit the preview. Assume roughly the first line is all anyone reads.
Include the action. If the point is to approve something, say so and link straight there — not to a dashboard from which they must navigate.
Avoid false urgency. "Action required" on something optional trains people to ignore the phrase, including when it is true.
Control without a maze
People need control, but a page of forty toggles is its own failure — nobody configures it, and the defaults decide everything anyway.
Group by category, not by event. "Comments", "Billing", "Security" rather than every trigger individually.
Offer frequency, not just on and off. Immediate, daily digest, weekly, never. Frequency choice keeps people subscribed who would otherwise unsubscribe entirely.
Make unsubscribe one click from any email, and honour it immediately. A buried unsubscribe becomes a spam complaint, which is materially worse — it damages deliverability for everything including transactional mail.
Never let people disable security notifications. Password changes, new logins, permission changes. These are not preferences.
Respect quiet hours, in the recipient's time zone, for anything non-urgent.
Defaults decide everything
Almost nobody changes notification settings, so your defaults are what nearly everyone experiences.
Default to less. It is easy to increase what you send after someone engages; it is nearly impossible to recover from being muted. Start with the notifications that clearly pass all three tests, and add only when there is evidence people want more.
For anything intrusive, default to off and let people opt in.
Measuring it
Open rates are weak here, since notifications are often read without being opened.
Better signals: the mute and unsubscribe rate per notification type, which tells you directly which ones people resent; whether people act on the ones with actions; and whether overall engagement falls after you introduce a new type, which indicates fatigue rather than success.
If a notification type has a high mute rate, that is not a tuning problem. It is the answer.
If you are adding notifications to a product and want the defaults set deliberately, book a call.
Common questions
When should a product send a notification?
Only when the person needs to know, needs to know now, and can act on it. If nothing changes for them it is a log entry; if it can wait until they next open the product it is an in-app indicator; and a notification with no possible action generates anxiety rather than value.
Which notification channel should I use?
In-app for anything they will care about on their next visit, which is most notifications. Email for things needing a record — receipts, confirmations, summaries. Push only for genuinely time-sensitive things they asked for. SMS for security codes and urgent operational messages. Avoid sending the same content to several channels.
Should notifications be batched?
Yes, by default, escalating only by exception. Ten comments on a document should be one notification rather than ten. Batching also solves the burst problem, where a flood of activity buries the messages that actually mattered.
How do I stop people muting notifications?
Send fewer, and default to less — muting is not selective, so someone who turns you off stops receiving the important messages too. Offer frequency options rather than only on and off, since that keeps people subscribed who would otherwise leave entirely.
What should a notification say?
What happened, then who, in the first line — since that is often all anyone reads on a lock screen. Be specific rather than generic, include the action and link directly to it rather than to a dashboard, and avoid 'action required' on anything optional, which trains people to ignore the phrase.
