Last month, a client's enterprise system sent 847 email notifications to a single user in one day. The user had 847 tasks assigned to them during a bulk import. Each assignment triggered an email. The user didn't read any of them. They set up a mail rule to delete anything from the system automatically. We'd built a notification system. What we'd actually created was noise.
What You Need to Know
- Enterprise notification systems fail when they treat every event as equally important
- The core design challenge is relevance, not delivery: sending the right notification through the right channel at the right time
- Users should control notification preferences at a granular level, not just on/off
- Batching, deduplication, and priority tiering are essential features, not nice-to-haves
The Notification Hierarchy
Not all notifications are equal. A system that treats a critical security alert the same as a task assignment has failed at the most basic design level.
We use a four-tier model:
Critical. Something requires immediate action and has real consequences if ignored. Security breach. System failure. Compliance deadline. These go to every channel available: push, SMS, email, in-app. They interrupt.
Action Required. Something needs the user's attention within hours. An approval waiting. A task assigned. A comment that needs a response. These go to the user's preferred channel with a reasonable delivery window.
Informational. Something the user might want to know but doesn't need to act on. A project update. A report completing. A colleague completing related work. These go to in-app notifications only. No push. No email.
Digest. Aggregated low-priority updates. Activity summaries. Weekly reports. These are batched and sent at scheduled intervals.
63%
of enterprise users say notification overload reduces their productivity
Source: RescueTime Productivity Report, 2021
Channel Selection
Good for: notifications that need a permanent record, notifications the user may need to reference later, weekly digests.
Bad for: anything time-sensitive, anything high-frequency. Email is a storage medium, not an alerting mechanism. By the time someone checks email, the notification is stale.
Push Notifications
Good for: time-sensitive action items, critical alerts. Push interrupts, which makes it powerful and dangerous. Every unnecessary push notification trains the user to ignore push notifications.
Bad for: high-frequency updates, informational content. If your system sends more than 5-10 push notifications per day to a single user, push has become noise.
In-App Notifications
Good for: everything that doesn't require interruption. The notification badge or inbox within the application is the appropriate channel for most enterprise notifications. The user sees them when they're working in the system, which is when they can act on them.
Bad for: critical alerts that need attention even when the user isn't in the application.
SMS
Good for: critical alerts and two-factor authentication. SMS has the highest open rate of any channel. Reserve it for the notifications that genuinely need it.
Bad for: anything routine. SMS notifications for task assignments will result in the user blocking the number.
The test for every notification is: would the user thank you for sending this, through this channel, at this time? If the answer is no, you're training them to ignore your system.
John Li
Chief Technology Officer
Essential Features
Batching
If a bulk operation creates 100 tasks, send one notification: "100 tasks were assigned to you." Not 100 notifications. This sounds obvious. Most enterprise systems get it wrong because the notification is triggered at the event level without batch awareness.
Implementation: queue notifications for a configurable window (30 seconds to 5 minutes). Before sending, check for duplicate or related notifications in the queue. Merge them into a single notification.
User Preferences
Users should control:
- Which channels they receive notifications on
- Which types of notifications they receive
- When they receive notifications (quiet hours)
- How notifications are grouped or batched
The preference UI should be simple. Two levels: quick toggles for common preferences, and a detailed matrix for users who want granular control. Default to sensible settings that most users won't need to change.
Deduplication
If a user is mentioned in a comment and also assigned the task that was commented on, send one notification, not two. The deduplication logic should merge related events within a time window and send the most informative single notification.
Priority Override
Critical notifications should bypass quiet hours and preference settings. A security alert at 2am needs to arrive at 2am. The user accepted this when they accepted an admin role. Non-critical notifications respect the user's preferences without exception.
Architecture
The notification system should be a separate service, not embedded in the application logic.
Events from the application flow to the notification service. The service handles channel selection, user preferences, batching, deduplication, and delivery. The application doesn't know or care how notifications are delivered. It just emits events.
This separation means:
- Adding a new notification channel doesn't change application code
- Notification preferences are managed in one place
- Batching and deduplication logic is centralised
- The notification service can be tested independently
Keep the notification service simple. It's infrastructure, not business logic. The complexity should be in the rules (what to send, when, to whom), not in the delivery mechanism.