Implementation worksheet · 5 min read
An In-App NPS Eligibility and Cooldown Worksheet
Fill five fields before any in-app NPS ships: eligibility floor (user has completed activation AND 14+ days tenure — surveying users who haven't experienced the product measures onboarding, not loyalty), moment rule (show at a natural pause — after task completion, never mid-flow or on login), response cooldown (90 days after answering), dismissal cooldown (30-45 days after dismissing, and the dismissal persists across sessions and devices), and exclusion list (users in open support escalations, users who hit an error this session, brand-new payers in their first week). Sample continuously in small random slices within eligibility rather than blasting quarterly — the trend line smooths and no single week's mood dominates.
NPS methodology debates rage about the score; the operational failures are all in eligibility. The same prompt shown at the wrong moment to the wrong user measures irritation with the prompt itself — and in-app delivery, precisely because it converts so well, amplifies every eligibility mistake email would have softened by being ignored.
Put it into practice
1. Set the eligibility floor at experienced-the-product
Activation complete plus a tenure minimum (14-30 days). Pre-activation responses are onboarding feedback wearing an NPS costume — collect that separately with a different question at a different moment.
2. Define the moment as a pause, not a page
After a completed task, on returning to a dashboard, post-export — the natural exhale. Never during a flow, never on the login splash (the one moment every user is mid-intent), never stacked on another prompt (the frequency budget decides collisions).
3. Set both cooldowns, and persist them
90 days post-response; 30-45 days post-dismissal. The dismissal must persist across sessions, devices and (if you can) the tool migration — a prompt that reappears tomorrow after being dismissed today teaches users that dismissing is meaningless.
4. Write the exclusion list from the support queue's perspective
Open escalation → excluded (a loyalty question during a complaint reads as satire). Error this session → excluded. First-week payers → excluded (honeymoon inflates; buyer's remorse deflates; neither is trend).
5. Sample continuously, review quarterly
Small random slices of the eligible pool daily beats quarterly blasts: smoother trends, no fatigue spikes, and seasonal moods average out. Review the worksheet itself quarterly — eligibility rules rot as the product changes.
The worksheet
Copy this structure into your review document and record your observed result for each row.
| Field | Default | Your value |
|---|---|---|
| Eligibility floor | activated + 14d tenure | |
| Moment rule | post-task pause; never mid-flow/login | |
| Response cooldown | 90 days | |
| Dismissal cooldown | 30-45 days, persisted | |
| Exclusions | open escalation; error this session; first-week payers | |
| Sampling | continuous random slices |
A failure worth checking
The survey-the-angry failure: no exclusion rules, so the user whose export just failed — twice — gets the loyalty prompt while writing a support ticket. The 0-out-of-10 that follows is real data about your prompting, not your product, and enough of them convince a roadmap meeting that 'users hate the new version' when users hate being surveyed mid-incident. Exclusions aren't score inflation; they're measurement hygiene.
Common questions
Isn't excluding unhappy moments just gaming the score?
No — it's separating signals. The user in an escalation should be heard through the escalation, and surveyed when the interaction is resolved (a post-resolution CSAT is the right instrument there). Sampling loyalty during acute incidents doesn't measure loyalty; it measures the incident twice.
Should NPS pause during incidents and big releases?
Pause during outages (you know the answer; don't spend user patience confirming it). Keep sampling through releases — release-window responses are exactly the trend signal you want, just annotate the chart.
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.