Customer request handling: how SaaS company obsessed with feedback does it

Struggling to figure out how to grow your customer request, evaluate and build them, and let your customers know that they’ve been released?

This is the story of how Christina, a product manager, set up a feature request workflow with a simple button in her product. This was so that she could learn directly from the customers what to build next. That button sent new feature requests to the moon and is responsible for a huge part of the company’s monthly recurring revenue (MRR) growth.


How about if I told you this was also the first time this product manager’s company created this particular process for feature requests? Since then, 54% of everything built from the roadmap was facilitated by that bashful little button.

More intrigued about the customer request strategy?

Christina’s a PM at Usersnap (that’s us). We built a feature customer request option in our product in order to receive more of them quicker from customers.

By the end of this article, you’ll be able to:

  1. Setup a feature customer request workflow for your product
  2. Take action on the feature requests, and build your roadmap
  3. See the tangible impact this workflow could have on your company.

Ready to start prioritizing feature requests?

While you go through this and plan your customer request strategy, keep this in mind:

“It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you’ll do things differently.”

Warren Buffett

BTW: if you need a little more context, we’ve got the ultimate guide to customer feedback, on tap just for you 🍻 cheers to that!

Aligning the customer request with product goals

At Usersnap, we’re all about collecting customer feedback. However, we came to a point in our own evolution where we weren’t quite sure where to turn next. Things were going well, with a great foothold in the quality assurance and software testing niche. However, we also saw the opportunity to go to market for other personas and their needs. We had some hypotheses, a lot of energy and talent across teams, and our fair share of experience in design and product management.

We follow this ideology –

“You can’t transform something you don’t understand. If you don’t know and understand what the current state of the customer experience is, how can you possibly design the desired future state?”

Annette Franz, CX Journey Inc.

So, we decided to make our process better. And we approached our roadmap and feature building in more or less the following way:

Saas Customer request roadmap  - Usersnap blog
This is how we approached our roadmap in the past.

In other words, after failing too slow and sometimes banging our heads on the wall one too many times, we wanted to get back to what we knew how to do best.

It was to – build a future product roadmap based on validated customer needs.

This included getting a deep understanding of our personas. It also includes crafting a long-term product vision that would help our customers get to their desired outcomes. But how do you create a product roadmap that puts customers at the heart of it? Apart from quantitative data collection, Christina started asking them an important question at an equally important touchpoint during their experience.

The question was – which feature suggestions do you have, and what would they solve for you?

customer request and feedback obtaining plan by Christina - Usersnap blog

She kicked it into overdrive, off to the races to do product manager work. Christina was determined to make sure we could know which features our customers actually wanted. One by one, through researching and interviewing what felt like hundreds of customers, Christina and the product team realized there were loads of insights from our customers. Besides the research, demos, data analytics, customer interviews, and customer support and service tickets, there was still something crucial missing here.

It was – if we want to know what exactly customers need, the best moment to get insights from people is to find out while they’re in their context, looking to accomplish their goals.

And what was the best way to figure that out? A possibility for our customers to send in product requests while they are mid-experience. The most valuable ideas that have shaped our roadmap in the last year have come in one at a time from in-context feedback. It helped us prioritize and build the features that our customers really like to use. That’s why Christina placed a button into the product that opens a feature request widget. Simple as that.

How do I set up a workflow for feedback requests?

1. Make it easy for product managers to collect SaaS feedback

First and foremost, Christina set up a feedback collector in our product. She made it an option for customers using the product and asked for people to contact us if they had any specific ideas they’d like to shout out. Above all, the desired outcome was to get feedback from customers who cared enough to find the feature request option. And then type one up at that moment in time for a product manager to see. Importantly, Christina configured the customer request option to be shown to those who logged into the product. Essentially, it means, we were only hearing from our customers.

feedback request button  - Usersnap blog
feedback request option - Usersnap blog

At first, it was a digital ghost town, with no feedback to speak of and digest. “Why hadn’t a single customer reached out yet?” Our hero product manager Christina asked herself, scratching her head. Staying patient, the team got a notification: Usersnap’s first feature request via the button. 

feedback requests - Usersnap blog

Pop the champagne bottles? Not quite. The product team had a long way to go. However, it was a win because the team could know with certainty that someone wanted to give suggestions in the first place from that button. Great start.

2. Manage incoming SaaS product features requests

After that, it was time to drill down as a great product manager does. Directly in the Usersnap dashboard, Christina could see which company sent the feedback and what people wanted to tell us. People tend to give solutions to their specific needs or challenge. But in reality, what’s most helpful is, getting to the need or the challenge itself (and beyond the solution). Christina could dive into any feature request by communicating directly in the feedback solution and getting to the core of the need of users.

Also, the product team got colleagues into the customer feedback loop by allowing them to also send in feature requests, tag them, and start both internal and external conversations from the same place. This was awesome to monitor customer needs and create a sense of customer-centric ownership across departments and teams.

Finally, when Christina wanted to sound a loud gong on a particular feature request to the entire team, she could use the Slack integration to push the customer request directly into a channel for all colleagues to see. In summation, the product team could listen to the customer more thoroughly and give themselves more qualitative ammo when prioritizing the roadmap.

3. Label and organize feature requests

In the midst of communicating to customers and colleagues about ideas, Christina started to make a portfolio of feature requests. Day by day, she and her colleagues checked and saw more. The list grew beyond what we all had imagined, and it forced everyone to start categorizing. With labels, all colleagues were able to put each request in an overarching bucket, and categorize it within buckets to see the frequency of feature requests. We could get a real overview of what our users wanted.

And how do I take action with my customer request for the SaaS features in mind?

4. Prioritize and build the SaaS product roadmap

Prioritization is always hard work and happens in a few ways for the team. 

One way is that the team could take requested features to the roadmap discussions and prioritize them directly when the quantitative data backed up the feedback and told a complete story.

In addition, we could also look at the overall company and product strategy, first from afar. Then, we could dig deeper into the feature requests received to see if their hypotheses about where the company should go were backed up by validated customer needs.

Essentially, requests were broken down into three main categories: 

  • new functionalities, 
  • native integrations,
  • and product improvements.

Feature Category 1: New functionalities

Every SaaS company wants to know which great, earth-shattering feature they should build next. However, that process would always require customers to actually need and want it. Customers came to Christina with great ideas about how she could innovate our product. 

In line with our overall product vision and where we thought our next move could position us in the market, our product managers took these ideas and implemented some of them into our product roadmap as well. For example, some new functionalities included a smiley rater for CSAT, a user interview scheduler, a guest portal, and pop-up widgets (with time-based triggers).

Customer request form - Usersnap blog
customer feedback requests - Usersnap blog

Feature Category 2: Native integrations

A native integration, for us, is an out-of-the-box connection between two systems or applications that can make them both better. In our case, we have several native integrations, and also integrations that can be connected via a third-party service such as Zapier. For us, a customer might like native integrations more because they’re easier to set up and there are no additional costs to connect Usersnap via an intermediary service. Customers requested several, and we started narrowing down those which were most relevant to our product strategy. A few of them eventually made it to our roadmaps, such as Asana, Azure DevOps, MS Teams, Slack, and Trello.

saas product roadmap prioritizing feature requests - Usersnap blog

Feature Category 3: Product improvements

How do we know as a business if what we make is quality, if we don’t ask such questions to a customer (or hundreds)? As part of the feature requests we received, improvements to existing functionality came to the surface as well. Throughout the entire product journey, there were already opportunities for us to improve based on customer feedback. Metrics such as customer satisfaction (CSAT) or customer effort scores (CES) augmented our decision-making process. But that’s another story for another time. The feature requests made prioritizing the roadmap easier. It is as our product managers were able to pinpoint, one-by-one, where our users thought we were falling short of expectations. Some things we eventually improved were our search functionality, our filtering capabilities, and multi-comments for feedback givers.

5. Use the customer request to build the features customers want

After that categorization, Christina knew on a sprint-by-sprint basis what to tackle. She and the team got their hard hats on and started the arduous work of building. Sprints are a 2-week interval for launching new features in our product development process. At each step of the way, Christina could help the design, product, and engineering team on the same page to

  • develop prototypes,
  • scope out the technical requirements,
  • test the upcoming features,
  • beta test, and
  • fully release them.

6. Communicate the new features to everyone

Once we had a well-tested feature to release to all of our customers, how would they know that they can use it? Anyone from the team could get back to the individual customer or customers who requested it directly in the Usersnap dashboard. Sometimes, it was better to have the product manager who originally received the ticket upon handoff; other times, it was our customer success manager.

Customer request results shared with the team - Usersnap blog

Further, we informed our customers at large via newsletters and in-app messages what we just shipped. The goal here was to close the feedback loop. And it was to ensure that our customers knew we’re truly listening to them and innovating on their behalf.

Overall, how valuable is a customer request for a business?

Since launching our feedback request button some time ago, here are some high-level stats:

  • Over 37% of our total paying customer base is using features we built with the help of that feedback button.
  • Over 31% of our total MRR growth is attributed to the features we built and promoted, starting with that button.
  • The contribution to our company’s bottom line is also over 22% of total MRR growth.
  • Over 54% of everything built by Christina and the Usersnap product manager team came from a customer feature request and that feature request button.

Over 42% of all integrations used in the last 30 days are Asana, Azure DevOps, MS Teams, and Trello, double their current usage percentages.

That’s big stuff from a tiny button.

In addition, here is a quick breakdown of some current feature usage and its share of business MRR contributing to Usersnap:

Feature SetOverall Feature UsageCompany MRR Growth
New functionalities
– Emoji-based rater (smileys)
– Pop-ups (with time-based triggers)
– User interviews scheduler
Native integrations
– Asana
– Azure DevOps
– MS Teams
– Trello
– Slack
Some stats on how our feature request button contributes to our company growth.

We mentioned how we approached building our roadmap in the past.

Now take a look at our breakdown for road mapping and building features that customers love to use:

more feature requests led to higher MRR - Usersnap blog

What did we learn from our customer request button?

  1. That quiet little button gave us the opportunity to engage with users beyond their proposed solutions, and get to true customer needs.
  2. We learned how to set up our own feature request workflow in a way that fostered cross-team collaboration.
  3. We used the feature request button as a repository of customer-facing information. When a customer request came originally from a sales demo, our sales team could file it directly in the project; all in one place so that good decisions could be made together.
  4. We learned that the impact our decisions had on Usersnap were substantial. So much so, that we continue doubling down on feature requests we receive (literally).

So, how can I set up my own button for the customer request?

1. Specify what you want to ask your customers

Usersnap configuration for a feature request widget - Usersnap blog

2. Embed the button or pop-up into your product

embed a customer request option for customers - Usersnap blog

3. Too many buttons already? Put ‘em all in one menu

customer request in a feedback menu - Usersnap blog

4. Let the customers’ needs come to you.

Customer request from the users are received - Usersnap blog

This is what we’ve been building lately. What’s stopping you from putting a customer request into your SaaS product? We’ll cover you for the next two weeks

Just remember:

“There is only one boss. The customer.”

Sam Walton

Also, feel free to give us your feedback below.

About Usersnap

Usersnap provides a customer feedback platform that helps software companies (SaaS) to build better, more successful products and services. We do this by collecting actionable user feedback and sharing it with all stakeholders across your company.