Increased engagement doesn’t always mean more new requests. As time passes, you should see fewer new requests but more engagement as Visitors vote on requests, prioritize requests, and view the Release Log and What’s Coming? reports.
Over the first six to twelve months of using Feedback, you can expect to see the following trends in customer engagement. The trend chart, below, shows the average number of new requests (green), votes (purple), prioritizations (yellow), and page views (blue) over time.
At first, you might receive a lot of new requests. This activity settles as your Feedback dashboard populates with different requests that cover most customer issues and ideas. As the number of new requests settles, so does your workload. Over time, customers instead sign in to vote on and prioritize existing requests, and to view progress on planned features. Engagement increases as you start building and releasing requests.
Customers won’t prioritize much to begin with because there won’t be many requests to prioritize. As the months continue, and you gather more feedback, your customers can browse through more requests to then vote on and prioritize.
Pendo Feedback is designed to help you learn more about what your customers want. To this end, we recommend using requests as library of data, even if they stay in your backlog for long periods of time, for the following reasons:
- An idea that was once not on your roadmap can become a priority based on user votes and comments, which can prompt your company to reassess what it wants to focus on next.
- Depending on your company’s strategy or priorities, the Product team can use Feedback’s backlog of requests to explore needs and to make decisions about what to build next.
- If you're planning or building a new feature, you can wait for more requests and votes to come in to gather more data.
Sometimes, requests stay in the “Awaiting Feedback” status for long periods of time without any update as you wait for other Visitors to vote on and prioritize requests. We recommend hiding timestamps from Visitors to avoid misconceptions about when (and if) requests receive a response. For instructions, see Settings for Pendo Feedback.
Responding to requests
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, as described in Gathering requests.
To set expectations, be open and transparent about this in your status update message when you move new requests to “Awaiting Feedback”. For instructions on writing a status update message, see Request status updates.
Add as much detail as possible to the status message of a request to help your Visitors understand where an idea is going. If you don’t have enough data yet, explain that you’re going through the top percentage of requests and, as a result, not all requests are considered by the Product team. However, over time, requests can move up the list based on demand and considered at a later date. Communicate this in your Product Feedback Policy, and consider including the following FAQ:
Question: "My request hasn't been reviewed yet and it's been over 6 months. What should I do?"
Answer: "If we haven't gotten around to reviewing your request, there are some things you can do to increase the chances of it being discussed.
- Set the request as your highest priority.
- Ensure the request is worded clearly, and that you explain why you need this feature. What problem does it solve for you?
Any further details can be added to the request as a comment."
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.
Frequently Asked Questions
How can I increase customer engagement?
To increase engagement, you can include a Feedback link in your help menu or your footer, using the instructions outlined in Grant Feedback access to customers. You can also send an engagement email to raise awareness. For instructions, see Notification emails in Feedback.
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.
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.