Request statuses (Awaiting feedback, Planned, Released, and so on) offer a quick way of communicating plans and progress. You can create custom messages for each status. These messages are important for setting the correct expectations with customers.
The status of a request is seen across Pendo Feedback and is visible to your internal teams and Visitors. You can also send automatic notification emails for every update to a request's status in Feedback. For more information, see Notification emails in Feedback.
This article describes:
- Best practices for request status updates, including accompanying messages.
- How to change the status of a request and the response you provide with that update.
- How to rename your status labels to suit your organization's language.
Default Statuses in Feedback
There are six status options for your requests in Feedback. Each status has its own function and color within Feedback. The default statuses are:
- Not Reviewed. Light gray. This is the default status for a new request.
- Awaiting Feedback. Dark gray. This status lets users know that you've received their request.
- Planned. Blue. The status given to ideas that you want to build.
- Building. Yellow. The status given to ideas that you're currently working on.
- Released. Green. The status given to ideas that have been built and rolled out.
- Declined. Red. The status given to ideas that you have no intention of building.
You can rename these statuses to align with your Feedback Workflow. For more information on renaming statuses, see Customize status names, below.
Best practices for new requests
Treat incoming requests as a library of data that you can use in discovery and research, and for making data-driven decisions about your product.
When your requests come in, they’re automatically assigned the status of Not Reviewed. If you have a high volume of requests, we recommend bulk updating the requests to Awaiting Feedback with a response in the status message, including a link to your Product Feedback Policy.
By moving new requests to Awaiting Feedback and linking to your Product Feedback Policy, customers know that you’ve received their feedback, and that the request is open for voting and other data collection. This allows you to be less reactive and gives your product teams the scope to build use cases and to make decisions with more clarity, insight, and perspective on what the big problems and opportunities are.
To ensure that new requests aren't visible to end users, you can enable Request Moderation for statuses that are Not Reviewed, or your company's equivalent wording for new requests. If you've enabled Request Moderation, a request becomes visible again once it's progressed to the Awaiting Feedback status, or your company's equivalent wording for the next status. For more information on this setting, see Request moderation.
Status visibility
For internal users, statuses are visible across Feedback, wherever requests are found, including:
- Team and Visitor dashboards.
- The Browse and Reports pages.
- Email notifications sent out when a status is updated.
- Any integrations you've set up, including the Salesforce integration.
Requests with a status of Not Reviewed, Awaiting Feedback, Planned, and Building can be found across your app, including the Visitor Dashboard. Requests in these statuses are included in your reports by default.
The What's Coming report is auto-populated with requests in the Planned and Building statuses for low-maintenance communication of high-level roadmaps. For more information, see What's Coming? report.
Released and Declined requests don't appear in your reports by default, but you can optionally include them. Released requests move from your Visitor Dashboard to your Release Log. For more information, see Release Log. Declined requests don’t appear in your Visitor Dashboard and end-users can no longer add their votes, but they can add comments.
Change the status on a request
Internal users must have the correct permissions to update statuses on requests. For more information on permissions, see Manage Team: Roles and Permissions in Feedback.
You can update a request status from either the Browse page or the Reports page. After you've navigated to one of these pages you can change the status of a request in one of two ways:
- Directly in the request list on the page. Select a new status value from the dropdown menu in the Status column next to the appropriate request.
- In the request itself. Select the relevant request and use the Request status dropdown menu in the top-right corner to select a new status value.
After setting a new status, you're prompted to choose a saved message or write a custom message to let users know why you made the decision. If you customize the response, you can save it for future use by selecting Save response for future use.
If you have the JIRA add-on installed, you can also select Create under project in JIRA. For information on integrating JIRA with Pendo Feedback, see JIRA with Pendo Feedback.
When you're ready, select Next to confirm the change.
Saved responses to status updates
Saved responses allow you to pre-populate status messages when updating the status of a request, rather than typing a response for each update. Feedback gives you a number of pre-populated responses you can choose from and edit, so you can get started and update your Visitors about their requests straight away.
Warning: If you’re using Feedback in one of our localized languages (French, Dutch, German), you can’t define custom statuses in-app for each language. If this is a requirement, contact Pendo Support to help you get set up.
Add saved responses
To add multiple saved responses:
- In the left-side menu, select Settings > Product Settings > Custom Responses.
- Under Custom Responses, select Create a Custom Response.
- Select the relevant status.
- Enter the message you want to add to the status.
- Select Create to save the message.
Edit saved responses
To edit a saved response:
- In the left-side menu, select Settings > Product Settings > Custom Responses.
- Under Custom Responses, select Create a Custom Response.
- Under Status responses for, select Edit next to the corresponding status.
- Update the message.
- Select Update to save the message.
Disable saved responses
After you’ve added your own custom responses, you might want to disable Feedback's default responses. Your users then only see custom responses when you update the status of a response. This only works if you have your own saved responses set up already.
To disable Feedback's default responses:
- In the left-side menu, select Settings > Product Settings > Custom Responses.
- In the Default Responses section, select the box next to Hide default responses.
Customize status names
You don't have to use the default status names provided by Pendo Feedback. Each status has a specific function within Feedback, and so the lifecycle of a request will stay the same, but you can rename the statuses to suit your organization’s language.
For guidance and recommendations on customizing status names, see Best practices for status renaming.
Prerequisites
Your Feedback Workflow – in particular, the review and triage phase – affects how you phrase statuses. Before you rename your statuses, you must decide what workflow makes the most sense for your teams and clearly document this process in your Product Feedback Policy. We highly recommend adding a link to your policy in your communication with submitters.
For consistent messaging across product lines, ensure internal alignment on what each status means and in what situations they're used once you create a clearly defined workflow.
Rename request statuses
Warning: After following this process, statuses will be visible to anyone with access to Pendo Feedback, including your users if you've given them access.
To rename request statuses in your Feedback account:
- Navigate to Settings > Product Settings > Custom Request Statuses.
- In Custom Request Statuses, edit your status names according to your Feedback Workflow.
- Select Save Changes.
- In the confirmation window, select Confirm & Apply.
It can take a few seconds for your status name changes to take effect across the app.
Best practices for status renaming
This section offers some guidance for status renaming based on an established process for triaging requests in Feedback. For more information, see The Feedback Workflow.
Step 1. Establish a review and triage process
How you name your statuses depends on your Feedback Workflow, and especially your review and triage process. To establish a review and triage process, you must determine:
- Who's responsible for which Product Areas.
- Who will review the requests that correspond to your Product Areas.
- Whether you'll have a dedicated product owner or Feedback manager that owns and triages the account.
For more information on creating a Feedback Workflow, including setting up a review and triage process, see The Feedback Workflow. For more information on setting and using Product Areas, see Product Areas in Feedback.
Step 2. Define your statuses
This section offers best practice advice for renaming your statuses based on how they’re defined in your review and triage process.
Not Reviewed
The Not Reviewed status indicates to your users that a request hasn't yet been reviewed, and lets your teams know that it requires a response.
Common alternative names for this status include: Awaiting Review and New. However, these status names imply that you review all requests regularly and that action will be taken on your part.
If you get large volumes of feedback, you can do the following:
- Leave new requests in this initial status until they've received enough votes and rename the status to set different expectations with users. For example, you can rename the status to Open for Voting, rather than Not Reviewed.
- Bulk update request statuses to Awaiting Feedback, or your organization's language for this status, along with a saved custom message to set high-level expectations based on your Feedback Workflow.
Awaiting Feedback
The Awaiting Feedback status indicates to your users that you've received their request and that you're gathering more data before making a decision. It lets people know that you're gauging demand, and that the request is open for voting and comments.
You don't need to check in on these requests every day. You can treat all requests in Awaiting Feedback as a library of data, stories, and use cases that you can revisit when you're ready to work on a product. Feedback can remain in this status for long periods of time, and so it can make sense to rename it.
Common alternative names for this status include: Open for Voting, Acknowledged, and Gathering Data. To provide clarity, we recommend that you set a response for this status and include your Product Feedback Policy in this message.
Planned
We recommend a cautious approach to using the Planned status. Use it only when you know you will definitely build something, and you’re confident enough to represent it on a roadmap.
If you choose a less definitive meaning for this status, you can rename the status to clarify what it means. You might, for example, be interested in researching an idea and then deprioritize the idea based on your findings. In this case, it might make sense to rename this status to In Discovery. Alternatively, an idea might align with your vision, but not be a priority. In this case, you might want to rename the status to Aligns to our Vision.
Whichever purpose for this status you choose, ensure your teams use the status consistently and that its meaning is clear to your users. Common alternative names for this status include: Aligns to our Vision, Committed, and On the Roadmap.
We recommend you provide more information about this status with a status message, including a link to your Product Feedback Policy.
Building
The Building status lets people know what you're currently working on. Only use this status when your developers have started work on something, and know that your users will eventually be able to use the resulting feature.
We recommend that you move all related requests to this status even when they don't correspond exactly to a feature you’re building but do solve the same pain or meet the same need. We also recommend that you provide this context in your status response.
As stop-gap between Planned and Released, common alternative names for this status include: In Development, In Progress, and Under Construction.
Released
The Released status indicates that you've implemented a request into your product. Use this status when engineers have finished work on a feature and you want to let people know that the feature is available. You can also use this status when you get a request about a feature that already exists.
In either case, we recommend that you customize your status response to educate users and drive adoption. Explain what the feature is, where it can be found, and how to use it.
Common alternative names for this status include: Done, Delivered, and Available.
Declined
The Declined status indicates that you don't plan to implement a request. This might be because a request is not aligned with your product vision, because you can offer a work-around already, or because the request is a bug rather than an idea or suggestion.
Regardless of the reason, we recommend:
- Transparency with your users when you know you can't or won't build a feature.
- Adding as much detail as you can in your status response about why you don't see the value in a request.
- Not deleting requests that you've declined. If one user has enquired about a feature, it’s likely other users have the same experience and demand.
Being transparent with declined requests has several advantages:
- Setting you up for scale. Help all your customers understand what your product vision is and why you might not be investing in certain product areas or problem spaces. If it’s good for one user to know, it’s likely helpful for other users too.
- Reducing friction. Users prefer to know if something definitely isn’t being built. Get stakeholders on your side by explaining your decision-making, and drawing attention to areas you are investing in instead.
- Continued data collection. By allowing continued discussion, you leave yourself the option to reconsider a request if it suddenly resurfaces and gets a lot of traffic.
Common alternative names for this status include: Closed, Not being considered, and No Action.