How Top Apps/Saas Ask for User Feedback - NPS, CSAT, Surveys & Reviews

Almost every digital product eventually asks some version of the same question:

How was your experience?

But look closely and the questions are rarely identical.

TikTok asks how you feel about a video.

YouTube asks whether a recommendation was good for you.

Discord asks how a call went.

Wise asks how difficult it was to set up a transfer.

Steam asks whether you would recommend a game after reminding you that you have already played it for 197 hours.

Firecrawl, Twilio and Xolo ask recommendation-style questions.

GitHub asks about satisfaction with Support.

G2 asks users to publicly rate their experience with Slack.

At first glance, these all look like feedback surveys.

From a Product Management perspective, however, they are solving very different problems.

The important question is not:

Which feedback widget should we copy?

It is:

What are we trying to learn, from whom, at what moment, and what will we do with the answer?

That is what makes feedback design a Product problem rather than simply a survey-design problem.

1. TikTok and YouTube: Feedback on the thing the user just experienced

TikTok + YouTube content/recommendation feedback

TikTok asks:

“How do you feel about this video?”

YouTube asks:

“Is the above video a good suggestion for you?”

Neither company is really asking:

Do you like TikTok?

or:

Are you satisfied with YouTube as a product?

They are asking about something much narrower.

TikTok wants feedback about a particular piece of content.

YouTube wants feedback about the quality of a recommendation.

This distinction matters.

If a user gives a YouTube suggestion a poor rating, the Product problem may not be the video itself. The problem could be:

We recommended the wrong video to this particular user.

That feedback can therefore become another signal for improving future recommendations.

This is contextual feedback.

The Product asks about something while the experience is still fresh and while the user clearly knows what they are evaluating.

Specific questions create more actionable signals.

2. Discord: Ask immediately after the interaction

Discord call feedback

Discord asks:

“How’d the call go?”

and asks it immediately after the call.

This is a good example of transactional feedback.

The user still remembers:

• whether the audio broke
• whether there was lag
• whether the call dropped
• whether the experience felt smooth

Imagine Discord asking the same question two days later.

The user would have to reconstruct the experience from memory.

That makes the answer weaker.

There is often a moment when the user's memory of an interaction is at its strongest.

For Product teams, identifying that moment is as important as designing the question.

Discord also includes:

“Don’t show me this again.”

That looks like a tiny UX decision, but it matters.

Repeatedly interrupting users eventually creates survey fatigue. People stop answering thoughtfully and start clicking randomly just to remove the popup.

At that point your dashboard may contain a lot of data, but some of it is fake precision.

The principle

Ask close enough to the experience that the user remembers it, but not at a moment where the survey interrupts the experience itself.

3. Wise: Sometimes effort matters more than satisfaction

Wise effort/ease feedback

Wise asks:

“How difficult or easy was it to set up this transfer?”

Notice that Wise is not simply asking:

“Were you satisfied?”

It is asking about effort.

That is an important distinction.

A user can successfully complete a workflow while still finding it unnecessarily difficult.

Imagine someone successfully completes a bank transfer after:

• going backwards three times
• searching for bank details
• contacting Support
• spending 15 minutes on something that should take 3

The transaction technically succeeded.

A simple success metric might say:

Job completed.

A satisfaction question might even receive a reasonable score because the user eventually achieved the goal.

But an effort question can expose the friction.

This is why Customer Effort Score or similar ease questions can be useful for workflows such as:

• onboarding
• checkout
• account setup
• payments
• configuration
• issue resolution

The Product question becomes:

How much work did we force the customer to do to get their job done?

That can reveal problems that completion rate alone cannot.

CSAT, CES and NPS are not the same thing

Before continuing, it is useful to separate three commonly mixed feedback types.

CSAT

Customer Satisfaction Score usually tries to understand:

How satisfied were you with this experience?

It can work well after a particular event such as:

• Support interaction
• delivery
• checkout
• service experience

CES

Customer Effort Score or similar ease questions ask:

How easy or difficult was this task?

This is useful when the Product team wants to understand friction.

NPS

Net Promoter Score asks something closer to:

How likely are you to recommend this company or Product?

This is much broader.

It is closer to a relationship or advocacy signal than a diagnosis of one specific UI problem.

The biggest mistake is treating one of these numbers as if it tells you everything.

A score is a signal.

It is not automatically the explanation.

4. Toggl Track, Craft and Amazon: Keep lightweight feedback lightweight

Toggl Track + Craft + Amazon satisfaction/reaction examples

Toggl Track uses a simple thumbs-up or thumbs-down interaction.

Craft uses expressive reactions.

Amazon uses a lightweight satisfaction scale.

These experiences show another useful principle:

The amount of feedback you ask for should roughly match the importance and depth of the experience.

Suppose someone used a small feature for thirty seconds.

A twenty-question questionnaire is probably unreasonable.

You may only deserve:

👍 or 👎

But suppose someone just completed a three-month enterprise implementation.

Now a longer survey or even a customer interview may be reasonable.

Product teams often design surveys around:

How much information do we want?

A better question is:

How much attention has this interaction reasonably earned from the user?

Think of customer attention as a limited budget.

A tiny interaction might deserve one tap.

A meaningful workflow might deserve:

rating + optional explanation.

A major lifecycle event might justify deeper research.

The number is often just the doorway

Consider this answer:

6/10.

What exactly should the Product team fix?

You don't know.

Now imagine the same user adds:

“After completing payment I couldn’t find my invoice and had to contact Support.”

That is much more actionable.

This is why many strong feedback patterns combine:

Structured score → qualitative explanation

The structured score helps with:

• trends
• segmentation
• comparison
• severity

The open-ended response gives you:

• reason
• context
• customer language
• possible Product problems

The score tells you that something may be happening.

The explanation helps you investigate why.

The follow-up question can change with the score

You do not necessarily have to ask everyone:

“Why did you give this rating?”

A better feedback flow can branch.

Low score

“What went wrong?”

Middle score

“What would have made this easier?”

High score

“What worked especially well?”

Different emotional states contain different information.

Low-scoring users can expose failure.

Neutral users can reveal improvement opportunities.

Highly satisfied users can help you understand what should be protected.

5. Firecrawl, Twilio and Xolo: Recommendation feedback is broader than feature feedback

Firecrawl + Twilio + Xolo NPS/recommendation-style feedback

Firecrawl, Twilio and Xolo use recommendation-style questions such as:

“How likely are you to recommend us to a friend or colleague?”

This is different from asking:

“Was this button easy to use?”

The user is now being asked to evaluate a much broader experience.

That means timing matters differently.

Someone who created an account three minutes ago probably does not have enough Product experience to meaningfully answer:

Would you recommend us?

The user needs enough exposure to form an opinion.

This gives us an important distinction.

Transactional feedback

About one interaction.

Examples:

How was your call?

How easy was your transfer?

Relationship feedback

About the broader Product or company.

Examples:

Would you recommend us?

How satisfied are you overall?

The rule is simple:

The scope of the question should match the scope of the user’s experience.

Do not ask a lifetime-relationship question based on a 30-second interaction.

6. GitHub and NVIDIA: Overall satisfaction can identify a problem, but not diagnose it

GitHub + NVIDIA satisfaction examples

GitHub asks about satisfaction with the Support experience.

NVIDIA asks users to rate their overall website experience.

These broader satisfaction questions can be useful for monitoring experience quality.

But Product teams need to be careful with what they conclude.

Suppose:

Website satisfaction = 4.6/5.

That does not automatically mean:

The website has no serious Product problems.

Why?

Because every survey contains some form of sampling.

Who saw the survey?

Who answered it?

Who dismissed it?

Who abandoned the Product before they ever reached the survey?

This leads to one of the most important concepts in feedback design.

Trigger bias - Your survey can accidentally exclude the unhappy users

Imagine a payment flow.

1,000 users start checkout.

700 successfully pay.

300:

• abandon
• encounter an error
• fail verification
• get frustrated and leave

Now you show:

“How was your payment experience?”

only on the payment-success screen.

Your survey population is now mostly:

people who successfully completed payment.

Six months later the Product dashboard says:

Payment CSAT = 4.8/5

That number may be completely genuine.

But the Product still has a serious problem.

The people who had the worst payment experiences may never have been eligible to answer.

So whenever looking at a feedback score, Product Managers should ask:

What did we ask?

but also:

Who was eligible to see this question?

and:

Who disappeared before they could answer it?

Sometimes the trigger rule biases the result more than the wording of the question.

7. Steam: Give the user context before asking for judgment

Steam “197 hours played” recommendation example

Steam does something particularly interesting.

Before asking:

“Would you recommend this game to other players?”

it reminds the user:

“You’ve played for 197 hours.”

That behavioural context helps the user evaluate the Product.

Instead of asking the brain:

“How do I feel about this game?”

Steam reminds the user:

You have spent a significant amount of time with it.

This reduces the mental effort required to form an answer.

It also introduces a powerful Product pattern:

Anchor feedback in the experience being evaluated.

Imagine an enterprise Product asking:

“How satisfied are you with this project?”

Very broad.

Now imagine:

“You tracked 14 milestones and completed four approvals through this project. How easy was it to understand the current project status?”

The second question gives the user a clear frame of reference.

Context can improve the quality of feedback.

What users say vs what users actually do

Steam also helps reveal another important idea.

Feedback is explicit information.

The user deliberately tells you something.

Examples:

• survey score
• thumbs up/down
• written feedback
• interview answer
• review

But Products also collect implicit information through behaviour.

Examples:

• user abandons checkout
• repeatedly returns to a feature
• spends 197 hours in a game
• stops using a Product
• searches repeatedly
• contacts Support after a workflow

These signals can disagree.

Imagine a user says:

“The dashboard is useful.”

But analytics shows:

they opened it once and never returned.

Or someone says:

“Onboarding was easy.”

while Product analytics shows:

35% of users abandon Step 3.

The correct conclusion is not:

The survey is wrong.

or:

Analytics is always right.

The interesting Product question is:

Why are stated feedback and observed behaviour telling us different stories?

That disagreement often reveals something worth investigating.

A useful rule:

Explicit feedback tells us what users say. Behavioural data tells us what users do.

Good Product teams use both.

8. G2 and Slack: Sometimes feedback is not for Product improvement at all

G2 + Slack public review/social-proof example

The G2 example changes the problem completely.

A user is being asked to publicly rate their experience with Slack.

This is not exactly the same job as an internal Product survey.

A private feedback response primarily helps the company understand an existing customer.

A public review can influence the next customer.

That means public reviews are partly about:

• trust
• reputation
• social proof
• consideration
• conversion

Imagine two SaaS Products.

Product A

4.8/5 from thousands of reviewers.

Product B

3.7/5 from a few dozen reviewers.

Before comparing features, a buyer may already perceive Product A as the safer choice.

That is why companies care about reviews on:

• G2
• Trustpilot
• App Store
• Google Play
• other software marketplaces

But Product Managers need to understand the difference between:

collecting honest Product feedback

and:

building public reputation.

Both are legitimate business goals.

They are simply different systems.

Product feedback vs public reviews

A private survey asks:

Help us understand your experience.

A public review request asks:

Would you share your experience so other potential users can evaluate us?

The destination changes the Product objective.

For private feedback, the result may lead to:

• Product investigation
• usability research
• Support follow-up
• roadmap discussion

For public reviews, the result can also affect:

• reputation
• buyer trust
• marketplace presence
• acquisition

That is why Product, Growth and Marketing sometimes all care about the same rating interaction for completely different reasons.

Solicited and unsolicited feedback are also different

There is another useful distinction.

Solicited feedback

The company asks the user:

Tell us what you think.

Examples:

• popup survey
• NPS request
• CSAT question
• interview

Unsolicited feedback

The user independently:

• opens a Support ticket
• writes an App Store review
• posts on Reddit
• sends an angry email
• leaves a G2 review

Unsolicited feedback often requires more effort.

That can mean stronger motivation.

But it creates another bias.

Very happy and very angry customers may speak much more frequently than everyone in the middle.

So:

Intensity does not automatically equal prevalence.

One furious customer may reveal an extremely serious defect.

It does not automatically mean most customers experience it.

Product still needs to investigate the broader evidence.

Measure the feedback system itself

Product teams often track:

NPS = 42.

or:

CSAT = 4.5.

But the number did not magically appear.

There was a Product funnel behind it.

For example:

Survey eligible
→ survey shown
→ user responds
→ user writes explanation
→ user dismisses

Suppose one trigger gets:

25% response.

Another gets:

3%.

That tells you something about your feedback experience.

You can experiment with:

• timing
• wording
• placement
• question length
• trigger
• follow-up

Your feedback mechanism is itself a Product feature.

It should therefore be measurable like one.

The biggest lesson from the big players

TikTok, YouTube, Discord, Wise, Steam, GitHub and others are useful because they show that there is no universal “best feedback survey.”

The right mechanism depends on the Product question.

TikTok and YouTube ask about content.

Discord asks about an interaction.

Wise asks about effort.

Toggl and Craft use lightweight reactions.

Firecrawl, Twilio and Xolo ask broader recommendation questions.

GitHub and NVIDIA measure satisfaction.

Steam anchors the question in actual usage.

G2 turns the rating into public social proof.

The interfaces may all look like ratings.

The Product logic underneath them is completely different.

That is the real lesson.

Good feedback design is not about adding a five-star popup. It is about choosing the right user, the right moment, the right question, and the right destination for the decision you need to make.

Sometimes you ask feedback to understand the current customer.

Sometimes you ask for a review to influence the next customer.

A good Product Manager knows which one they are designing for.