What is an in-app survey?
In-app surveys are short questionnaires shown to users inside a product while they use it, such as an NPS question, a CSAT rating or a single question about a feature. Because they appear in context, they capture feedback close to the moment it describes.
What types of in-app surveys are there?
Most in-app surveys fall into four types. Each answers a different question, so pick the type from the decision you need to make.
| Type | What it asks | Use it to decide |
|---|---|---|
| NPS | How likely are you to recommend us? (0 to 10) | Where overall loyalty is heading, by segment |
| CSAT | How satisfied were you with this? | Whether a specific interaction or flow worked |
| CES (customer effort score) | How easy was it to do this? | Which tasks feel harder than they should |
| Feature feedback | Did this feature do what you needed? | Whether to keep investing in a feature |
Add one open question after the rating ("What's the main reason for your score?"). The number tells you something moved; the comment tells you why.
How do you run an in-app NPS survey?
An in-app NPS survey asks the standard question inside the product, usually in a small slideout, then asks for a reason.
- Who: users who have had time to form a view. Skip the first days after sign-up; ask once they've used the product for real work.
- When: at a calm moment, such as after they finish a task or when they return to the home screen. Never in the middle of a form or checkout.
- How often: once per user per quarter or half-year at most, with a cap so no one sees it twice in a short window.
- Score: NPS = (promoters minus detractors) ÷ responses × 100, where promoters answer 9 or 10 and detractors 0 to 6. If 500 users answer, 250 are promoters and 100 are detractors, NPS = (250 minus 100) ÷ 500 × 100 = 30. NPS is a score from −100 to 100, not a percentage, though its parts are: here 50% promoters and 20% detractors.
- Follow up: route detractor comments to the team that owns the problem and close the loop with the user.
When should you show an in-app survey?
Timing matters more than wording. Tie each survey to the event it asks about: a CSAT question right after a support conversation closes, a feature question after someone uses the feature a few times, a CES question right after a setup step finishes.
Response rates vary widely with audience, placement, survey length and how often users are asked, so benchmark against your own past surveys rather than an industry number. What consistently helps: one or two questions, a clear reason for asking, and a visible change when users give feedback.
Surveys have one built-in limit. They only capture what you thought to ask, from the users who choose to answer, at the moment you chose.
How do you learn what users need beyond surveys?
Requests users make on their own, in the middle of their work, fill that gap. When a product has a place to ask for help in plain words, every request records what someone was trying to do, in their own words, at the moment they needed it, including the requests the product couldn't handle.
Foldspace's Conversational Analytics reads what users ask the Product Agent unprompted and shows the goal behind each request, whether the conversation was resolved, and the knowledge and action gaps, so teams can set those requests next to their survey results.