Notification System Specification Template

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.

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.

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.

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. ---