Smart Notifications: Earn the Right to Interrupt

The most important notification decision happens before anyone writes the copy. It is whether the product has earned the right to interrupt.

Delivery is not neutral. A push alert can break concentration, expose private information on a lock screen, wake someone, or make a product feel less trustworthy.

That cost may be justified. A payment failure, an approaching deadline, or a change that blocks another person can require attention now. A weekly activity total probably does not.

Smart notifications begin with this distinction. They do not maximise the number of messages people open. They spend attention only when an interruption improves a meaningful outcome.

A notification is a request to interrupt

A notification crosses the boundary between the product and the rest of a person’s day. It asks them to stop, interpret new information, and decide whether to act.

The sender knows the event. The recipient pays the cognitive cost.

This makes notifications different from an activity feed or dashboard. Those surfaces wait until someone chooses to look. Push, SMS, and many emails impose themselves on the recipient’s context.

The product team should therefore be able to finish this sentence:

We are interrupting this person now because waiting until their next visit could cause ______.

If the blank contains only “lower engagement” or “they might forget us,” the message is probably serving the product rather than the person.

Silence is not a delivery failure. It is often the correct product behaviour.

Decide whether the event deserves interruption

An event in a system is not automatically a notification. “Record updated,” “report generated,” and “comment created” describe state changes. They do not establish who needs to know or when.

Begin with the user outcome at risk. What becomes harder, slower, less safe, or impossible if the person learns about this event later?

Then test the recipient. The account owner, operator, approver, and observer may need different information from the same event. Broadcasting to everyone shifts the cost of poor routing onto users.

Check whether the event is still true before delivery. A resolved incident, completed approval, or cancelled appointment should suppress any pending reminder about the previous state.

Finally, ask whether the product knows enough to interrupt. When confidence is low, an inbox item may be responsible where an urgent alert would be misleading.

Notification design is therefore a decision system: event, current state, affected person, consequence of delay, and confidence. Copy comes after those parts agree.

Test value, urgency, actionability, and time sensitivity

Four tests make the decision easier to inspect.

Value

Does the information help the recipient protect money, time, safety, access, a commitment, or progress towards a goal they chose?

“A teammate needs your approval” has potential value. “Three people viewed your profile” may be interesting, but interest alone rarely earns an interruption.

Urgency

How much does the outcome deteriorate if the person waits? Urgency should come from the underlying situation, not from promotional wording or a red badge.

Actionability

Can the recipient do something useful now? The message should lead to a clear action, a clear understanding, or a deliberate acknowledgement.

If no action is available, consider recording the event in an activity feed or including it in a digest.

Time sensitivity

When does the information become useful, and when does it expire? A reminder sent too early becomes background noise. The same reminder sent after the deadline becomes evidence of a broken system.

These tests do not require a universal score. They require a defensible routing decision.

A practical outcome is usually one of four treatments: interrupt now, schedule for a meaningful moment, batch into a digest, or retain inside the product without sending anything.

Choose the channel by interruption cost

Channels form a rough ladder of attention cost. The precise order depends on the product and the expectations it has established, but the principle is stable: use the least intrusive channel that protects the outcome.

An in-product activity feed is suitable for durable history. An in-app message can support the task already in progress. Email can carry detail without demanding an immediate response.

Push and SMS can reach someone outside the product. That makes them valuable when delay carries real cost.

For lower-urgency information, the team should justify the interruption or choose a quieter channel.

The channel also changes the information risk. A lock-screen preview may reveal an account name, health detail, financial amount, or workplace activity to someone other than the intended recipient.

Design the fallback path as carefully as the first delivery. If an email bounces, should the product show a persistent warning? If a push is acknowledged, should the scheduled email be cancelled?

Escalation should respond to unresolved risk, not merely to an unopened message. “Not opened” and “not handled” are different states.

Give people consent, control, and recovery

An operating-system permission is not a notification strategy. It grants access to a channel; it does not explain which events the product will send through it.

Apple’s notification guidance recommends asking for authorisation in context and sending timely, useful information.

That standard is valuable beyond Apple devices.

Ask when the benefit is concrete. A project tool can request push access when someone chooses to follow a critical approval, rather than during an abstract first-run tour.

Preferences should describe recognisable purposes, not internal service names. Let people control meaningful categories, channels, quiet periods, digests, and escalation where the product permits it.

Android notification channels support category-level controls at the operating-system level. Product-level preferences still matter because people may use several devices or channels.

Recovery matters too. A person who mutes a noisy category should be able to find and restore it. Someone who disables push should still have a reliable place to review missed events.

Marketing messages and transactional or service messages can be treated differently by law, but the label a team gives a message does not settle its legal status.

The relevant rules depend on the jurisdiction, channel, content, purpose, and relationship with the recipient. Have qualified counsel assess the design; do not turn a product checklist into legal advice.

For example, the UK’s ICO publishes specific guidance on direct marketing by electronic mail. It should inform a legal review where relevant, not be copied into a global consent rule.

Design the taxonomy and state model before adding ML

Many notification problems blamed on weak personalisation are actually weak product modelling.

Create a taxonomy that records, for each notification type:

• the event and user outcome;
• eligible recipients and exclusions;
• severity and expiry;
• available action;
• permitted channels;
• preference and consent requirements;
• deduplication key;
• owner and review date.

Then model the lifecycle. A notification might be eligible, scheduled, suppressed, sent, delivered, seen, actioned, expired, or failed.

Those states answer practical questions. Can a scheduled reminder be cancelled? Does action on one device resolve it everywhere? Can two services create the same alert? Who handles delivery failure?

Use deterministic rules where the requirement is clear. Do not train a model to discover that a completed task no longer needs a reminder or that quiet hours should be respected.

Practical AI Workflow Automation for Product Teams explains why explicit events, states, exceptions, and ownership should precede more adaptive automation.

Rules provide an intelligible baseline. Without one, a model can optimise behaviour that the team has never decided is desirable.

Measure the outcome and the harm

Delivery rate tells you whether infrastructure worked. Open rate tells you that the message attracted attention. Neither proves that interrupting was worthwhile.

Choose a user outcome that matches the message: approvals completed before a deadline, failed payments recovered, incidents acknowledged, or appointments successfully changed.

Define the denominator carefully. A click rate among delivered messages can hide poor eligibility rules. Measure against people or events that qualified for the decision, including those deliberately suppressed.

Track harm alongside benefit:

• category mutes and channel opt-outs;
• operating-system permission loss;
• immediate dismissals and repeated non-response;
• duplicate, stale, or wrong-recipient messages;
• complaints and support contacts;
• actions started but abandoned after the notification.

Segment these signals by notification type and frequency. An acceptable aggregate can conceal one small category that repeatedly breaks trust.

Treat preferences as direct evidence, not as inconvenience to optimise around. When someone says “not this, not here, or not now,” the system has received a product requirement.

Experiment with restraint

Notification experiments often optimise copy while leaving the interruption itself unquestioned. A more useful test may remove a message, batch it, delay it, or move it into the product.

State the behavioural hypothesis before choosing the metric. “A reminder six hours before expiry will help eligible approvers act in time” is testable. “A punchier subject line will increase opens” is too detached from value.

Change one decision at a time where possible: eligibility, timing, channel, frequency, or presentation. Otherwise, the result will not reveal why behaviour changed.

Set guardrails and stop conditions in advance. A lift in immediate action should not excuse a rise in opt-outs, duplicate alerts, or later disengagement.

Use holdouts only when withholding the message is responsible. Safety alerts, legally required notices, and events with serious consequences need a different evaluation design and specialist review.

Restraint also applies to statistical certainty. Rare events may never produce a large experimental sample. Combine quantitative evidence with incident reviews, usability work, and explicit risk judgement.

Know when personalisation or ML is justified

Machine learning can help when a product repeatedly chooses among many plausible messages, times, or channels and fixed rules cannot express the variation economically.

It is not justified merely because behaviour data exists.

Before adding a model, check for:

• a valuable decision made often enough to learn from;
• reliable labels tied to a user outcome;
• sufficient variation and volume;
• an acceptable cost of a wrong prediction;
• a deterministic fallback;
• monitoring for drift and uneven harm;
• a way for people to understand and override the result.

Personalisation can rank eligible messages or choose among safe delivery windows. It should not invent eligibility, ignore explicit preferences, or turn uncertainty into manufactured urgency.

The Product Manager’s Guide to Personalization Engines examines the evidence and operating conditions required before adaptive ranking becomes useful.

When the system makes a consequential or surprising choice, the experience must communicate it honestly. That is an interaction-design problem, not only a modelling problem.

The Product Manager’s Guide to AI User Experience covers uncertainty, control, and recovery in intelligent product behaviour.

A hypothetical notification-design review

The following scenario is invented to show the decision process. It is not a case study or a claim about measured results.

A workflow product detects that a supplier approval will expire in 24 hours. The first proposal is to push every project member immediately and send an email if nobody opens the alert.

The review begins with the outcome: the correct approver must act before expiry so dependent work can continue.

That removes observers from the urgent audience. They can see the event in the activity feed, but interrupting them cannot resolve the risk.

The team defines a rule-based sequence:

1. Show a persistent in-product task to the current approver.
2. Send an email at 24 hours if approval remains unresolved.
3. Send push at two hours only if the approver opted into deadline alerts.
4. Cancel every pending message when the approval is completed, reassigned, or withdrawn.
5. Escalate to the project owner only when the unresolved deadline crosses an agreed threshold.

The message links directly to the decision and shows the consequence of delay. Its deduplication key combines the approval, recipient, and escalation stage.

The team measures on-time resolution and time to action. It also watches opt-outs, stale deliveries, duplicate alerts, and escalations that reached someone unable to help.

ML is rejected for the first release. The eligibility and timing rules are explicit, the event volume is limited, and the team has no trustworthy labels for a better prediction.

That rejection is part of smart notification design. The team has built an observable decision system that could support personalisation later without depending on it now.

A practical notification audit

Review each notification type, not merely each delivery campaign.

• What user outcome could deteriorate if this waits?
• Is the recipient able and authorised to act?
• Is the event still true at delivery time?
• What makes it valuable, urgent, actionable, and time-sensitive?
• Is this the least interruptive effective channel?
• What consent, preference, quiet-hour, and privacy rules apply?
• Can delivery be cancelled, deduplicated, acknowledged, and recovered?
• Which product state triggers and resolves the message?
• What outcome proves value beyond an open or click?
• Which harm signals can stop or change the system?
• Would a clear rule solve the problem before personalisation or ML?
• Who owns the notification after launch, and when will it be reviewed?

A smart notification is not the one with the most sophisticated delivery model. It is the one the product can justify from event to interruption to outcome.

The standard is simple and demanding: interrupt only when the person benefits from knowing now, preserve their control, and learn from both action and refusal.

Sources

• Notifications — Apple Human Interface Guidelines
• About notifications — Android Developers
• Guidance on direct marketing using electronic mail — Information Commissioner’s Office

Read next

The Product Manager’s Guide to AI User Experience explores how intelligent features should expose uncertainty, preserve control, and help people recover when the system is wrong.