Proto Personas

Net Promoter Score

TL;DR

In 2025 I proposed introducing a recurring NPS study at Elastic Email. My goal was not to simply track the score, but to create a regular source of customer feedback that could help us understand churn, identify product strengths and follow up with individual users.

I designed the survey, worked with developers to control who could see it, and prepared a follow-up process for promoters and detractors. The survey generated a steady stream of responses and helped confirm that technical issues were having a real impact on customer sentiment.

My role: full ownership

The problem

We had very little regular feedback telling us how customers felt about the product or why.

High churn

Churn had been a persistent problem for Elastic Email. We had plenty of indicators showing that customers were leaving, but much less information explaining what was driving their dissatisfaction.

Unclear product strengths

We also struggled to describe what customers valued most about the product. That made it harder for the Marketing team to decide which benefits were worth emphasizing in our messaging and advertising.

No regular sentiment measurement

An NPS survey had been attempted in the past, but it never became part of the company's routine. I proposed bringing it back as a recurring study, with the open question treated as an important source of qualitative feedback rather than an addition to the score.

Challenges
Being visible without becoming annoying

The survey needed enough visibility to generate responses, but it could not interrupt customers while they were trying to use the product.

Reaching the right accounts

Some users were not suitable participants. We wanted to exclude accounts with policy issues, customers using obsolete versions of the product and people who had already participated recently.

Turning responses into action

Calculating the score was only part of the idea. I also wanted a process for following up with promoters and detractors, especially when their responses suggested an opportunity to help, learn more or ask for advocacy.

The process
Designing a lightweight survey

We were already using Hotjar, which allowed us to display surveys directly inside the application.

I chose to show the NPS survey on the main dashboard after login, but not on other screens. This made it difficult to miss without repeatedly interrupting normal product use.

The survey appeared as a small slide-up window and contained only two questions: the standard NPS score and one open-ended question asking users to explain their rating.

Keeping it short was deliberate. I wanted to reduce friction and give users an easy way to tell us what was behind the number.

Controlling who could see it

The next step required cooperation with the frontend team.

Together with one of the developers, I created a Hotjar event that fired only for accounts meeting a defined set of conditions. This allowed us to exclude customers we did not want to survey.

The developer also created a record of accounts that had already participated. Since the study was intended to run periodically, this prevented the same customers from being shown the survey too frequently.

Preparing follow-up communication

I also created a simple follow-up system based on the type of response we received.

For common cases, including responses without additional comments, I prepared reusable email templates that could be sent in campaigns.

For responses that needed more attention, I prepared individual email drafts. These included highly dissatisfied customers, users threatening to leave and particularly enthusiastic promoters.

The idea was to make the study useful beyond measurement. Detractors could potentially tell us more about problems or give us an opportunity to help, while promoters could be invited to leave a public review.

Outcome

The survey generated a steady flow of responses, so participation itself was not a problem. Users also regularly answered the open question, giving us useful context behind the scores.

One pattern became especially important.

A noticeable number of detractors mentioned technical difficulties, particularly problems logging into the application. To check whether this was limited to people who had written comments, I reviewed support conversations from other dissatisfied respondents.

The same pattern appeared there.

This gave us stronger evidence that the technical issues were not merely isolated support cases. They were having a measurable effect on customer sentiment. I shared this finding with the Product team, and the underlying issue was subsequently addressed.

Not every part of the project worked equally well.

Follow-up emails produced very little engagement. Detractors generally did not respond, and attempts to encourage promoters to leave public reviews were unsuccessful.

The promoter comments also gave us less clarity about our strengths than I had hoped. "Ease of use" and "good support" appeared repeatedly, but the responses were too varied to support a much stronger conclusion.

The segmentation created through the NPS study was also not ultimately used for targeted marketing activities.

Despite those limitations, the project established a repeatable way to collect customer sentiment and, more importantly, demonstrated how NPS could be used as more than a score. The open-ended feedback helped connect changes in sentiment to concrete customer problems and gave the Product team additional evidence about their impact.

© Piotr Łukaszkiewicz 2026