How to Plan Notifications and Alerts

Notifications are part of a business process, not a decorative feature. They tell a person that something has changed, that a decision is needed or that a deadline is approaching. When they are planned badly, users either miss important work or receive so many messages that they ignore all of them.

This guide focuses on messages sent to the people who use a web application: employees, customers, suppliers or partners. Alerts about the technical health of the application belong to a separate operational process. Keeping those two concerns apart makes both easier to design and manage.

Start with the event, not the delivery channel

A common starting point is to ask whether the application should send email, SMS or in-app messages. That is too early. First identify the business event, the person affected and the action that may be required. Only then choose the most suitable channel and timing.

For each process, list the moments when a person needs new information. Typical events include a record being assigned, a document being submitted, an approval being requested, a payment failing or a deadline passing. The purpose of the notification should be clear enough to complete the sentence: “The recipient needs this message so that they can…”

Choose channels according to urgency and user behaviour

In-app notifications

In-app messages work well for information that can wait until the user next signs in. They keep the history close to the relevant records and avoid filling an inbox. They are not enough when the user may be away from the application for several days.

Email

Email is useful when a person needs to know about an event without being logged in. It suits approvals, document reviews, status changes and reminders that require a response within hours or days. The message should contain enough context to judge urgency, while sensitive information should remain inside the authenticated application.

SMS and other interruptive channels

SMS or push notifications should be reserved for events where delay has a real operational or customer cost. Using an interruptive channel for routine updates increases expense and encourages users to disable it. The business should be able to explain why an event deserves that level of attention.

Separate urgency from importance

An event can be important without requiring an immediate message. A weekly compliance summary may be important, but an individual email for every low-risk update may be unnecessary. Conversely, a failed payment or an appointment cancellation may require quick action even though it affects only one record.

Define a small set of notification levels in business language, for example:

• Information: useful context with no immediate action.
• Action required: a named person or role must respond.
• Reminder: an earlier request is still outstanding.
• Escalation: the expected action has not happened within the agreed time.
• Urgent: delay may create a material operational, financial or customer impact.

Do not create too many levels. Users and administrators must understand the difference without consulting a technical manual.

Plan immediate messages, digests and escalations

Immediate delivery is appropriate when the recipient can act immediately and the event is infrequent enough to deserve attention. High-volume updates are usually better grouped into a daily or weekly digest. A manager responsible for fifty cases may need a summary of changes, while the case owner may need an immediate request to approve one item.

Escalation should reflect responsibility, not merely send the same message repeatedly. A useful escalation rule states:

• who is expected to act first;
• how long they have;
• who is informed if they do not act;
• whether the original recipient remains responsible;
• when the escalation stops.

Without a stopping condition, reminders can continue after a record has been closed, reassigned or made irrelevant.

Write messages that help the recipient decide

“Something has changed” is not a useful notification. A good message explains what happened, which record is affected, whether action is required and where to continue. It should use the same terms the business uses in the application.

A notification normally needs:

• a clear subject or title;
• the relevant customer, case, order or document reference;
• the event in plain language;
• the expected action and deadline, where applicable;
• a direct link to the correct authenticated screen;
• a safe fallback instruction if the link cannot be used.

Avoid placing confidential details in email subjects or SMS messages. The external message can identify the action while the full record remains behind sign-in.

Give users sensible control without weakening the process

Users should be able to reduce low-priority noise, choose digest frequency or disable optional channels. They should not be able to silence messages that are essential to safety, account access or a mandatory business process without an agreed alternative.

Preferences work best when defaults are set by role or organisation. The system should make clear which notifications are optional, which are required and why. Administrators also need a controlled way to change templates and defaults without requesting a code change for every wording adjustment.

Plan delivery records and failure handling

Sending a message is not the same as delivering it. Email can bounce, SMS can fail and in-app queues can be delayed. The application should record when the notification was created, which channel was attempted, whether the provider accepted it and whether a retry is pending.

Do not promise evidence the channel cannot provide. An email provider may confirm that it accepted a message for delivery, but that does not prove the recipient read or acted on it. If acknowledgement matters, require the user to complete an action in the application and record that action separately.

Write acceptance criteria for the notification process

Notification requirements should be testable. Examples include:

• When an application is assigned to a reviewer, that reviewer receives one in-app notification immediately.
• If the review remains incomplete after two working days, the reviewer receives a reminder and the team manager receives an escalation.
• Closing or reassigning the application cancels any pending reminders for the previous reviewer.
• An administrator can see the trigger, recipient, channel, timestamp and delivery status for each attempted message.
• A user cannot disable account-security messages, but can change routine status updates from immediate email to a daily digest.

Test duplicates, reassignment, expired links, missing contact details and events generated in bulk. These are the conditions most likely to expose weak notification logic.

Questions to put to a supplier

• Can notification rules be changed through configuration, or does every change require development?
• How are duplicate messages prevented when the same event is processed more than once?
• How are messages queued, retried and throttled during a high-volume event?
• Which delivery statuses are available for each channel, and what do they actually prove?
• Can templates be managed safely by an administrator?
• How are user preferences, mandatory messages and organisation-level defaults separated?
• What information is recorded for support and audit purposes?

Practical next step

Build a notification matrix from the process map before discussing providers or message templates. If an event, recipient and expected action cannot be stated clearly, the underlying business rule is not ready for development. Once the user-facing messages are defined, plan the separate process for errors and operational alerts that require action from the support or technical team.