Permission is a one-shot resource
Once someone declines notification permission, or disables it later, getting it back is close to impossible. That makes the request itself a design decision worth care.
Asking on first launch, before any value has been demonstrated, is the most common way to lose the channel before you have used it.
Ask at the right moment
Ask after the user does something that implies they want to be told about something: setting a reminder, following an item, submitting a request they will want an answer to. Context makes the answer yes.
Explain what they will receive before the system dialogue appears, in your own words, with an option to decline that does not trigger the system prompt.
Send only what was asked for
- Something they are waiting for — a status change, an approval, a reply
- Something time-sensitive that they would want to act on now
- A reminder they set themselves
- Not: marketing, engagement nudges, or announcements that could be an email
Respect time and volume
Nothing outside working hours unless it is genuinely urgent. Batch non-urgent items into a single daily summary. Never send several notifications about one event.
A notification at 2am about something that could have waited until morning costs you the permission, permanently, from a user who was otherwise engaged.
Make preferences granular and honest
One toggle for everything means people turn everything off to escape one category. Per-category preferences let them keep what they value.
Include a quiet hours setting and honour it. Systems that ignore quiet hours for “important” messages define important too broadly within a month.
Measure the right thing
Not open rate. Measure the proportion of users who still have notifications enabled after 30 and 90 days, and watch whether a particular category correlates with disabling.
That figure tells you whether the channel is being spent or invested.