Implementation worksheet · 5 min read
An In-App Prompt Frequency Budget
Set a hard budget — at most two unrequested interruptions per user per session, at most four per week — and make every prompt spend from it through priority classes: P0 failures/security (always shown, don't count against budget), P1 activation steps for the user's current stage (count), P2 feature announcements and surveys (count double, because they serve you, not the user), P3 everything else (queued to the help hub, never interrupt). One owner arbitrates the budget across product, marketing and support — because the user experiences all teams' prompts as one product, even though no one team ships more than 'a couple'.
Prompt fatigue is a tragedy of the commons: product ships a tour, marketing a survey, support a banner, growth an upsell — each reasonable alone, jointly a product that won't stop talking. The fix is an economy, not a guideline, because guidelines lose to quarterly goals every time.
Put it into practice
1. Inventory every prompt currently live
All of them: tours, tooltips, banners, NPS, upsells, cookie bars, changelog popups. Teams are consistently shocked by the count — the inventory alone usually kills a third of them out of embarrassment.
2. Assign priority classes with teeth
P0 failure/security always shows. P1 helps the user's current task. P2 helps you (announcements, surveys, upsells) — costs double budget. P3 never interrupts; it lives in the help hub and badge counts. The class assignment argument is the useful fight — have it once, in a room, not forever in shipped prompts.
3. Enforce the cap in code, not culture
A prompt service that checks the session's remaining budget before rendering, with P-class priority when prompts compete. Culture-based caps die at the first 'just this launch' exception; the service makes exceptions require a code review.
4. Give surveys and upsells a cooldown ledger
NPS at most quarterly per user; upsell prompts only on trigger events (hit a limit) and never twice for a dismissed offer within 30 days. A dismissed upsell re-shown weekly converts dismissal into resentment measurably fast.
5. Review the budget monthly against outcomes
Prompt-attributed activation vs prompt-attributed dismissal-and-churn signals. Any prompt with dismissal above ~80% loses its slot — the budget is for prompts that earn their interruption.
Priority classes
Copy this structure into your review document and record your observed result for each row.
| Class | Examples | Budget cost | Can interrupt? |
|---|---|---|---|
| P0 | failed action recovery, security, billing breakage | free | always |
| P1 | next activation step, blocking-task help | 1 | yes, within cap |
| P2 | announcements, NPS, upsells | 2 | yes, within cap |
| P3 | tips, changelog, cross-sell | — | never — help hub only |
A failure worth checking
The compounding-annoyance failure: each team measures its own prompt's engagement and sees 'fine'; nobody measures the fourth prompt in one session, whose dismissal rate approaches 100% and whose actual output is the user learning to close everything unread — including tomorrow's P0. Interruption tolerance is a shared, exhaustible resource; the budget exists because no single team's dashboard can see it draining.
Common questions
Who should own the prompt budget?
Whoever owns overall product experience — with the authority to bump a launch announcement for an activation prompt. If the owner can't say no to marketing's launch week, the budget is decoration.
Doesn't a hard cap risk hiding important messages?
P0 exists precisely so genuinely important messages (failures, security, billing) never compete for budget. Everything else claiming importance is the reason the cap exists — 'important to whom?' is the class-assignment question.
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.