You don’t need to respond to every request that comes in. Instead, we recommend using Pendo Feedback as a library of data that can be used to explore ideas and make data-driven product decisions.
This article summarizes how to review and manage requests, when to decline requests, what to do with requests for the Support team, and what to do with unhelpful comments on requests.
Reviewing and grouping requests
There are several ways to group requests, including any combination of the following:
- Apps. The applications that requests are related to.
- Product Areas. The tangible locations or features in your app. For information on how to create and use Product Areas, see Product Areas in Feedback.
- Statuses. Where the request is in your Feedback Workflow. For information on how to use and customize statuses, see Request status updates and Customize status names.
- Tags. The labels given to request to help categorize them. For information on how to create and use tags, see Tagging in Feedback.
- Assignees. The people that handle or own requests. For information on how to assign requests, see Triage requests. You can also use Product Areas as a way of assigning requests.
- Visibilities. The levels of visibility given to request.
The Browse page is the best place to view and organize requests. The Browse page provides a table view of all your requests. You can edit this view to see requests that are relevant to you and save the view you create to come back to later.
You can also act on groups of requests from the Browse page. Bulk update the status of requests, edit the details of multiple requests, add tags to multiple requests, and assign ownership to team members. For more information, see Manage requests in the Browse page.
Dealing with new requests
We offer several ways for you to review and manage new requests with request moderation, in-app notifications, the vendor Dashboard, the Similarity Report, and the Browse page.
You can enable request moderation to hide new, unreviewed requests from your customers. This gives you time to work through and triage the requests before you start receiving feedback on them from customers. For more information, see the Request moderation article.
You can also launch Feedback to customers with limited visibility by launching it to a subset of customers, preventing new requests from coming in, hiding timestamps, and removing the login link from Feedback emails. For more information, see the Grant Feedback access to customers article.
The notifications page in Feedback lists all the requests and comments you haven't responded to yet. You can respond to these requests and comments from within this page. For more information, see the Manage in-app Feedback notifications article.
The Similarity Report
We recommend that you periodically review your incoming feedback for duplicate or similar requests. We have a Similarity Report to help you do this, from where you can merge requests. You can also merge from the Browse page and from within an individual request. For more information, see the Deal with similar requests article.
The Browse page
By default, requests are ordered from newest to oldest. You can refine the list using the filters at the top and using the keyword search. For example, you can filter the list by Status alongside Assignee or Product Area to find requests that are relevant to you and your responsibilities. For more information, see Manage requests in the Browse page.
The Dashboard tab in the vendor's (internal) Dashboard page offers a variety of features for managing and responding to customer feedback in real time. It helps you to identify the most pressing customer requests and to track progress towards resolving these. For a list of information provided by the vendor Dashboard, see Internal view of Pendo Feedback.
The vendor Dashboard also has a Customer Insights tab, where you can review trends in customer requests and behavior, such as engagement and churn. For more information, see Customer Insights in Feedback.
Editing big requests
Sometimes you get a big request and the only way you can build it is to release it in stages. For example:
"It would be good if we could comment on features, and maybe even tag other users to mention them in comments."
Other times you might get a big request that already has parts of it released. To deal with this you can split the request by creating new ones and linking to the original request.
If you have a request where some but not all the features are already released, you can:
- Create new requests for each feature not released.
- Set the original request to Released and write a custom response that describes the functionality already added to the product. Explain that you're still working on the other part, and link to the new request by entering "#" followed by the request ID.
- Add the visitors who were interested in the original request to the new requests so that they're automatically kept up-to-date.
There are some requests for features that will never be built because they don’t fit your strategy. In these cases, we recommend declining the requests. In the status update message, explain that while you aren't planning on building a requested feature, you’re still interested and will keep the request in Pendo Feedback for future use.
Declining a request doesn’t delete the request from Feedback. Team users can view declined requests in the Browse page, as well as subscribe to them, comment on them, and add visitors to them. The visitor can also still subscribe to and comment on the request. The request disappears from the Visitor Dashboard and Priority list, but the visitor can access the request if they submit or search for a similar request, or if they have the direct URL.
Declined requests aren’t automatically deleted because they can be used to increase transparency and understanding. For example, you might decline an idea because a similar idea is already on the roadmap, and you can communicate this in the status update message. Declining the request allows you the opportunity to explain what’s coming and helps to avoid similar requests being made.
Declined requests can also become relevant in the future, perhaps due to high demand, changes in product strategy, or as evidence of an unmet need. For example, another visitor might offer a different use case for a declined idea that makes the suggestion a more viable option in the future.
Below are some examples for when to say “no” to requests:
Low demand and edge cases
If there’s low demand for a requested feature, or the request is for a solution to an infrequent issue, say so, and explain that you’re focusing on where you can help the most customers. Sometimes, the request is more subjective, such as the preferred location of a button, and you can offer a more detailed explanation for your decision. This helps your customers understand that you're balancing other requirements and how.
Future releases will remove the need
Sometimes, you can say “no” to a specific request whilst also saying “yes” to the requestor. Communicate that improvements are underway that will solve for their need without necessarily providing the exact solution the requestor is asking for.
Low value, high effort
Some requests are more complicated to build than they seem, with low value and demand. If this is the case, explain any implications the requestor hasn’t considered or why it isn’t possible. If possible, offer a workaround.
Some requests aren’t specific enough, such as comments about general usability, or their meaning isn’t clear. Encourage the requestor to submit a more detailed request that includes a specific use case and need.
Requests for Support
You might occasionally get requests that are actually bug reports or usage queries. These should be reserved for Support teams, who have different response times and actions to consider. Unlike Support tickets, which are reactive and time-sensitive, Feedback requests are focused on the future and can be reviewed at a cadence that suits your organization’s internal processes, setting you up for scale.
Decline and delete Support-relevant requests and refer the requestor to your Support team in your status update message. We also recommend letting visitors know where to go with these types of queries in your Product Feedback Policy.
If you ever receive unhelpful comments on requests that you don't want to delete, you can edit or delete the comment and then send a flexible email from the request page to inform the relevant user.
To ensure the feedback is referenced and linked within the email, use the Send email option under Request actions on the details page of the request that the comment was left on.
Below is an example of how you migh structure your response:
We've recently removed one of your comments in Feedback. Feedback is a tool for gathering feedback from our users about feature requests and problems you would like to see resolved.
We encourage customers to post use cases, vote, prioritize, and collaborate with other users to help us better understand your needs. Any comments that don't contribute in this way, or are made for the sole purpose of being negative or derogatory, are removed because they don't help us understand how the system should be improved.
You might also want to include a note in your product feedback policy, informing your customers that unhelpful comments will be removed.
Frequently Asked Questions
What if I get too much feedback?
With Pendo Feedback, there’s no such thing as "too much feedback".
Pendo Feedback is designed to help you with the day-to-day management of your backlog of requests so that you can focus on the ideas that appear at the top of your Feedback reports. Other requests in your backlog might become important in the future, but they don’t need to take up time and effort before then.
If you feel like you’re spending too much time managing the feedback you’re collecting, see The Feedback Workflow for some ideas on how to streamline your process. We recommend moving all incoming requests to "Awaiting Feedback" for you to process later while you focus on your biggest priorities now.
What if people submit bad requests?
Pendo Feedback is designed to help you manage your requests so that good ideas rise to the top of your priority list and bad ideas stay in your backlog. Bad ideas can stay in the "Awaiting Feedback" status until you have more data to make a decision about them. When moving a request to this status, encourage your teams and customers to add their use cases by asking specific questions in the status message or comments section. For more information, see Request status updates and Save custom responses.
When you open yourself up to customer feedback, it’s also likely that you’ll receive some requests that you don’t plan on implementing. If you know you aren’t going to build the requested feature, follow the guidance in Declining requests, in this article. If the request is actually a bug report or usage query, follow the guidance in Requests for Support.