Implementation worksheet · 6 min read
A Feature Discovery Prompt Priority Policy
Put a cap and a priority order in front of every prompt rather than letting each one decide for itself. Three parts: a per-user limit per session and per week, a priority order covering every prompt type, and a suppression rule that blocks prompts while the user is mid-task. Then define what a losing prompt does — defer to the next eligible moment, or drop. Without a central policy, each prompt is individually reasonable and collectively a product that interrupts constantly, and the team that ships the most prompts wins the user's attention regardless of what matters.
In-app prompts accumulate the same way lifecycle emails do: one team, one feature, one reasonable request. Nobody owns the total, and the user experiences the total. The difference from email is that there is no inbox to absorb them — every prompt lands directly on top of whatever the person was doing.
Put it into practice
1. Cap prompts per session and per week, per user
Two numbers. Per-session stops a user opening the app and receiving three prompts in a minute; per-week stops a steady drip. Derive both from your own dismissal data — the rate at which prompts are dismissed without reading rises sharply past a threshold you can measure.
2. Suppress during active tasks
A user typing in a form, in a checkout, in a flow with unsaved state, or mid-onboarding is not available. A prompt interrupting a task is worse than no prompt, because it costs the task as well as being ignored. Define 'mid-task' explicitly per surface rather than leaving it to judgement.
3. Rank every prompt type, including the ones nobody wants to rank
Account and billing issues first, then onboarding progress, then contextual help, then feature discovery, then research and surveys. Every prompt needs a rank. An unranked prompt resolves ties by whichever code path ran first, which is not a decision anyone made.
4. Decide defer versus drop per prompt
A feature announcement deferred by two days is fine. A time-bound offer deferred past its window is worse than dropped. Give deferred prompts an expiry so nothing surfaces a week late referring to something that has passed.
5. Cap repeat attempts per prompt
Dismissed twice means no. A third attempt converts a mild irritation into a signal that the product does not listen. Record dismissals per user per prompt and enforce the limit centrally, because individual prompt owners will always believe theirs deserves another try.
6. Report suppression back to prompt owners
How many times each prompt lost to the cap, and to what. Without it, an owner sees low impressions and concludes their targeting is broken. With it, the cap becomes a shared constraint people design around — and the argument moves to priority, which is the right argument to have.
The prompt priority policy
Copy this structure into your review document and record your observed result for each row.
| Prompt type | Priority | Defer or drop | Max attempts | Set |
|---|---|---|---|---|
| Billing or account problem | 1 | defer | until resolved | |
| Security or access notice | 1 | defer | until resolved | |
| Onboarding step | 2 | defer | 3 | |
| Contextual help on a blocked action | 3 | defer | 2 | |
| Feature discovery | 4 | defer | 2 | |
| Upgrade or upsell prompt | 5 | drop | 1 per cycle | |
| Survey or research request | 6 | drop | 1 | |
| Per-session cap | — | — | — | |
| Per-week cap | — | — | — | |
| Mid-task suppression | — | — | — |
A failure worth checking
The prompt that interrupts the thing it is advertising. A user is halfway through configuring the exact feature a discovery prompt is about to introduce. The prompt fires, covers the interface, and is dismissed with irritation — the feature is now associated with an interruption rather than with a benefit. Mid-task suppression prevents it, and the reason it is so common is that the targeting rule (`user is on this screen`) is the same condition that means they are already using it.
Common questions
What is a reasonable prompt cap?
Derive it from your own dismissal data rather than a benchmark. Look at dismissal-without-interaction rate against prompts-per-week per user; the point where it rises sharply is your ceiling. It differs enormously between a daily-use tool and a monthly one.
Should onboarding prompts count against the cap?
Yes, with a high priority. Exempting a category is how caps stop constraining anything — the exemption list grows until every team's prompt is exempt. Rank it highly instead, which achieves the same outcome honestly.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.