Why you should not limit who gets asked NPS (and why we let our customers do it anyway)

July 6, 2016 Comments


We get lots of requests from people that want to use our NPS product in ways that we don’t recommend. Some people only want to trigger NPS on certain pages. Confirmation pages are a good example of this. A user just got done doing something, and the owner of the app they’re using wants to ask them the NPS question.

This is a bad idea because it defeats the purpose of NPS. NPS is meant to be a rating of how likely your user base is to recommend your product. If your entire sample set is made up of a small percentage of users that finished a specific workflow, the NPS measurement ceases to be a true NPS.

That’s not to say you can’t ask users questions on confirmation pages. If someone just got done with a specific workflow that’s extremely valuable to your business, you should absolutely ask them a question like this one.

Just not NPS.

Another bad idea is to limit who gets asked NPS. Some applications have a usage model where there is an “account owner” (also referred to as an “admin” or a “superuser”) and “team members” (or “users”). We’ve had customers come to us saying they only want to ask NPS of account owners. This is also a bad idea.

In many cases, the “account owner” might just be the person who found your product and threw down a credit card, but the “team members” are the ones actually interacting with the app on a daily basis. The account owner could respond ’10’ to NPS for months, only to suddenly churn because their co-workers revolted. Only asking NPS of the “account owner” shielded you from critical information.

Exceptions. Not Rules.

Ramen allows for some really cool segmentation of NPS results. You can create Audiences inside of Ramen which are dynamic segments based on a user’s behavior and attributes. For the most part, if you’re concerned about how different populations of users are responding to NPS, our recommendation is to ask NPS of everyone and then segment the results after the fact.

But this ignores some relatively common use cases and optimization problem.

We think about customer feedback a lot. We also have an eye towards good UX, both for our users and for their users. But we can’t design for all the edge cases. There are some times where the UX of one constituency must take precedence over the desire to get high quality feedback. You may really want to get NPS from your paying customers, but you don’t want to bother people who are consuming content they are publishing.

Our users could, of course, just have their developers only render the Ramen JavaScript code on specific pages or when specific people are logged in, but that defeats the purpose of having a nice copy/paste JavaScript installation for Ramen.

All this is a long way of explaining why even though you should always ask NPS of all your customers, we give you the flexibility to limit NPS to a specific set of customers.

Limit NPS to an Audience
Limit NPS to an Audience

Context is King

When implementing NPS inside your application, take special care to think through the different constituencies that you want to get feedback from. The context of your app will dictate how best to use the flexibility that Ramen’s NPS affords you. If you have any questions on how to implement NPS in your app — whether it’s via Ramen or not :) — feel free to ask us questions in the comments below.

Join thousands of other Product Creators getting our weekly posts on Product Success

Nothing to see here. Just a yeti.

© Ramen Inc. 2017