How do I prevent notification fatigue without hiding important updates?

Separate notifications into priority tiers (critical, high, normal, low) and apply different frequency controls to each. Critical notifications (payment failures, security alerts) always deliver immediately. High-priority notifications (mentions, due dates) deliver in real-time but respect quiet hours. Normal and low-priority notifications batch into digests. This way, users see urgent items immediately and catch up on everything else in a single digest. Track [notification engagement metrics](/glossary/engagement-rate) to identify categories that users consistently ignore.

Should notification preferences default to opt-in or opt-out?

Default to opt-out (notifications are on by default, users turn them off). The exception is marketing notifications, which should be opt-in per CAN-SPAM and GDPR. For new notification types added to an existing product, consider defaulting to off and announcing the new notification so users can opt in. This avoids surprising existing users with a new message they did not expect. The [PRD Template](/templates/prd-template) includes a section for documenting default states.

How do I handle notifications when a user is mentioned in a channel they have muted?

This is a policy decision. Option 1: Respect the mute (do not notify). Option 2: Override the mute for direct mentions only, with a visual indicator that the notification came from a muted channel. Option 3: Queue the notification and deliver it when the user unmutes. Most products choose option 2 because direct mentions signal that someone specifically needs this person's attention.

What metrics should I track for notification effectiveness?

Track delivery rate (sent vs. delivered), open rate (email), click-through rate (all channels), dismiss rate (in-app, push), unsubscribe rate (email), and time-to-action (notification delivered to user taking the intended action). A notification with high delivery but low click-through needs better content or targeting. A notification with high unsubscribe rate is too frequent or irrelevant. ---

Notification System Specification Template

What This Template Is For

Notification systems are deceptively complex. What starts as "send an email when X happens" grows into a multi-channel, multi-audience system with preference controls, batching logic, escalation rules, and quiet hours. Without a written spec, teams build notifications ad hoc and end up with inconsistent behavior across channels, no central preference management, and users who unsubscribe from everything because they are overwhelmed.

This template captures every dimension of a notification system: channels, triggers, audience targeting, preference controls, frequency limits, delivery infrastructure, and content templates. It works for greenfield builds and for formalizing an existing notification system that has grown organically.

Use this alongside the Feature Specification Template if notifications are part of a larger feature. For products with role-based access, pair with the Permissions Specification Template to define who receives which notification types. For guidance on measuring notification effectiveness, see the Product Analytics Handbook.

Score notification features against other priorities using the RICE Calculator.

How to Use This Template

Inventory every notification your product currently sends (or plans to send). Include informal notifications like banner messages and toast alerts.
Map each notification to a trigger event, target audience, and delivery channel. This is the notification registry and becomes the single source of truth.
Define the preference model. Users should control what they receive and through which channel. Decide whether preferences are opt-in or opt-out by default.
Set frequency controls. Batch digests, quiet hours, and per-channel rate limits prevent notification fatigue.
Specify the content template for each notification type. Consistent structure (subject line pattern, body format, CTA) improves recognition and action rates.
Plan delivery infrastructure. In-app notifications need a real-time transport (WebSocket, SSE). Push notifications need device token management. Email needs a transactional provider.
Review with engineering, design, and customer success before implementation.

The Template

Notification System Overview

Field	Details
Project Name	[Name]
Author	[PM name]
Engineering Lead	[Name]
Target Release	[Date or milestone]
Status	Draft / In Review / Approved

Summary. [1-2 sentences: what the notification system covers and its primary goals.]

Design Principles.

☐ Users control their notification experience (preferences are accessible and respected)
☐ No channel sends more than [X] notifications per [time period] without user action
☐ Every notification is actionable (links to the relevant page or action)
☐ Notification content is consistent in tone, format, and branding across channels
☐ System degrades gracefully (failed delivery retries, channel fallback)

Notification Channels

Channel	Transport	Delivery Speed	Best For	Limitations
In-App	WebSocket / SSE / Polling	Real-time	Active users, low-urgency updates	Only reaches users who are online
Email	Transactional provider (SendGrid, Postmark, SES)	Near real-time to batched	Detailed updates, receipts, digests	Open rates vary (20-40% typical)
Push (Mobile)	APNs / FCM	Real-time	Time-sensitive alerts, brief messages	Requires app install + permission
Push (Desktop)	Web Push API	Real-time	Re-engagement for web users	Low opt-in rates (~5-15%)
SMS	Twilio / MessageBird	Real-time	Critical alerts, 2FA, account security	Cost per message, regulatory compliance
Slack/Teams	Webhook or Bot	Near real-time	Team workflows, integrations	Requires workspace connection

Notification Registry

ID	Trigger Event	Category	Channels	Default State	Batchable	Priority
N-001	[Event 1: e.g., "Task assigned to user"]	Activity	In-App, Email	On	Yes (daily digest)	Normal
N-002	[Event 2: e.g., "Comment on user's task"]	Activity	In-App, Email, Push	On	Yes (hourly)	Normal
N-003	[Event 3: e.g., "Payment failed"]	Billing	Email, SMS	On (cannot disable)	No	Critical
N-004	[Event 4: e.g., "Weekly summary"]	Digest	Email	On	N/A (is the batch)	Low
N-005	[Event 5: e.g., "New team member joined"]	Team	In-App	On	Yes (daily)	Low

Category definitions.

Category	Description	Default Channels
Activity	Actions related to user's own work items	In-App + Email
Mentions	Direct @mentions or replies	In-App + Email + Push
Team	Team membership and administrative changes	In-App
Billing	Payment, subscription, and invoice events	Email (mandatory)
Security	Login alerts, password changes, 2FA	Email + SMS (mandatory)
Digest	Batched summaries of activity	Email
Marketing	Product updates, feature announcements	Email (opt-in)

User Preference Model

Preference Levels.

Level	Scope	Example
Global	All notifications on/off per channel	"Disable all email notifications"
Category	Category on/off per channel	"Disable Activity emails but keep Activity in-app"
Individual	Single notification type on/off	"Disable 'task assigned' email"

Preference Defaults.

Category	In-App	Email	Push	SMS
Activity	On	On	Off	Off
Mentions	On	On	On	Off
Team	On	Off	Off	Off
Billing	On	On (locked)	Off	Off
Security	On	On (locked)	Off	On (locked)
Digest	N/A	On	N/A	N/A
Marketing	N/A	Off (opt-in)	N/A	N/A

Locked notifications. Some notifications cannot be disabled (billing failures, security alerts). Mark these as "locked" in the preference UI with a tooltip explaining why.

Frequency Controls

Control	Value	Applies To
Quiet Hours	[e.g., 10pm-8am user's timezone]	Push, SMS
Email rate limit	Max [X] emails per [time period]	All email except security
Push rate limit	Max [X] pushes per hour	All push notifications
Digest batching	[Hourly / Daily / Weekly]	Batchable notifications
Duplicate suppression	Same notification not sent twice within [X] minutes	All channels

Batching Logic.

Batchable notifications are queued instead of sent immediately
At the batch interval, queued notifications are combined into a single digest
If only 1 notification is in the queue, send it as an individual notification (not a digest of one)
Batch subject line: "[X] updates in [Product Name]"

Content Templates

Email Template Structure.

Section	Content
Subject	[Action verb] + [Object]: e.g., "Sarah commented on your task"
Preheader	[1-line preview text visible in inbox]
Header	Product logo, notification category badge
Body	[Who] [did what] [to which object]. Context paragraph if needed.
CTA Button	[Action verb]: "View Comment", "Open Task", "Review Invoice"
Footer	Preference link, unsubscribe link, company address

In-App Notification Structure.

Field	Content
Icon	Actor's avatar or system icon
Title	[Actor name] [action] [object]: "Sarah Chen commented on 'Update pricing page'"
Timestamp	Relative time (2m ago, 1h ago, Yesterday)
Read state	Unread (bold) / Read (normal weight)
Click action	Navigate to the relevant page/object

Push Notification Structure.

Field	Content	Limit
Title	[Product Name]	50 chars
Body	[Actor] [action]: [brief context]	100 chars
Deep link	Opens app to relevant screen

Delivery Infrastructure

Component	Technology	Notes
Event bus	[Kafka / RabbitMQ / SQS / Redis Streams]	Source of trigger events
Notification service	[Custom / Novu / Knock / OneSignal]	Orchestrates channel routing
Email provider	[SendGrid / Postmark / SES]	Transactional email delivery
Push provider	[FCM + APNs / OneSignal]	Mobile and web push
SMS provider	[Twilio / MessageBird]	Critical alerts only
In-app transport	[WebSocket / SSE / Polling]	Real-time in-app delivery
Preference store	[Database table / Notification service]	User preference persistence

Open Questions

#	Question	Owner	Status	Decision
1	[Question]	[Name]	Open
2	[Question]	[Name]	Open

Filled Example: TaskFlow Notification System

Notification Registry (excerpt)

ID	Trigger	Category	Channels	Default	Priority
N-001	Task assigned to user	Activity	In-App, Email	On	Normal
N-002	Comment on user's task	Mentions	In-App, Email, Push	On	Normal
N-003	@mention in comment	Mentions	In-App, Email, Push	On	High
N-004	Task due in 24 hours	Activity	In-App, Email, Push	On	High
N-005	Task overdue	Activity	In-App, Email	On	High
N-006	Sprint started	Team	In-App	On	Low
N-007	Weekly project summary	Digest	Email	On	Low
N-008	Payment failed	Billing	Email	On (locked)	Critical

Frequency Controls. Quiet hours: 10pm-8am in the user's timezone (push and SMS only). Email rate limit: max 20 emails/day per user (excluding security). Batchable notifications digest hourly for active projects, daily for inactive projects. Duplicate suppression window: 5 minutes.

Key Takeaways

Build a notification registry as the single source of truth for all notification types
Give users control at global, category, and individual notification levels
Set frequency controls (quiet hours, rate limits, batching) to prevent fatigue
Make every notification actionable with a direct link to the relevant context
Separate mandatory notifications (billing, security) from user-controllable ones

About This Template

Created by: Tim Adair

Last Updated: 3/5/2026

Version: 1.0.0

License: Free for personal and commercial use

Notification System Specification Template