Why is this important?
The status of each request can be seen across the Feedback app and is visible to your teams and visitors, so everyone knows at a quick glance what your plans are for each piece of feedback. Customers & team users will (optionally) get an email notification every time you update a request status in Feedback. Each status has a specific function within Feedback so the lifecycle of a request will usually be the same, but you can edit the status names to suit your organization’s language.
Make sure you use status responses to add more detail to your statuses, and help set the correct expectations with customers. Head here to learn more about how to configure & use status responses.
Warning: If you are using Feedback in one of our localized languages (French, Dutch, German), you will not be able to define custom statuses in-app for each language. If this is a requirement, please contact us at help@pendo.io to help you get set up.
Overview
There are six status options for your requests in Feedback. The default statuses are:
Each status has its own function and color within Feedback, and should be quick & easy to understand for your stakeholders. Statuses are visible across the app wherever requests are found, including:
- Team & Visitor dashboards
- Browse & Reports pages
- Email notifications sent out when a status is updated
- Any integrations you have set up, including the Salesforce integration
It’s important to have alignment on what each status means, so that users who are consuming feedback updates at a high level can quickly see what is happening with their requests. For more nuance & detailed status responses, users can click into the request page to learn more.
Your internal users will need the correct permissions if they want to update statuses on requests. Read more about permissions here.
What you’ll need before customizing status names
1. A Feedback workflow
Decide what your Feedback workflow will look like before you customize your status names. This is because the workflow could impact how you phrase certain statuses, e.g. because you are not reviewing incoming requests regularly.
2. A Product Feedback Policy
Your Feedback Policy should provide a high level overview of your Feedback workflow & the lifecycle of a request when it comes in, so that your customers know what to expect after they send in their feedback.
3. Internal education & alignment
Make sure your teams are aligned on what each status means and in what situations it should be used, so that your customers & stakeholders get a consistent experience & messaging across your product lines.
Default statuses & their functions
"Not Reviewed"
What does it mean?
This will be the status of a request when it first comes into your account. It should indicate to your visitors that this piece of feedback has not yet been reviewed, and lets your teams know it requires a response.
Where can it be found?
New or “Not Reviewed” requests can be found across the app, including the Visitor Dashboard. Requests in this status are included in your reports by default.
This status is connected to the Request Moderation setting. Enabling Request Moderation means requests in this status are not visible to your end users, becoming visible only when the status has been updated. Read more about this setting here.
Best practice
The Feedback workflow you implement, in particular the triage phase, will impact how you word this status.
The most common method of triage is to do a quick review of new requests, and then to change the status to “Awaiting Feedback”. This sends an email out to the request submitter, letting them know you have received their feedback.
If you get large volumes of feedback and you don’t have a regular cadence to review incoming data, it can make more sense to leave all requests in the “Not Reviewed” status indefinitely.
Decide what workflow makes the most sense & clearly document it in your Product Feedback Policy. If the second method of triage is more aligned to your workflow, make sure the status name sets the correct expectations with your stakeholders. “New” or “Not reviewed” suggests that some action is needed on your part; in this case opt for something like “Open for Voting'' instead.
Examples
New
Awaiting Review
Open for Voting
Status: "Awaiting Feedback"
What does it mean?
This status should indicate to the request submitter that you have received their feedback, but you need more data before making a decision. It lets other stakeholders know you are gauging demand and that the request is open for voting & comments.
Where can it be found?
Requests in the “Awaiting Feedback” status can be found across the app, including the Visitor Dashboard. Requests in this phase are included in your reports by default.
If you have turned on the Request Moderation setting, a request will become visible once it is progressed to this new status.
Best practice
Think of all of your requests in "Awaiting feedback" as a library. You don't need to check in with each item every day, but the stories, use cases, and data are there when you're ready to work on your product.
It’s totally fine, and even expected, for your company to have most of your feedback in the “Awaiting Feedback” status for many months or years. Make sure the wording of this status is therefore clear to your users and sets expectations appropriately. Use a status response to add even more detail & context.
Examples
Open for Voting
Acknowledged
Gathering Data
Status: "Planned"
What does it mean?
Your "Planned" requests are those which you want to build. They let your customers know that their request is in line with your product vision, and can indicate to your teams what they should be working on next.
Where can it be found?
Requests in the “Planned” status can be found across the app, including the Visitor Dashboard. Requests in this phase are included in your reports by default.
The What’s Coming report is auto-populated with requests in this status. It provides a light touch, low maintenance way to communicate a high level roadmap to your stakeholders.
Best Practice
Make sure you have alignment internally on what “Planned” means, and be very clear with your customers what they can expect.
This status can merely indicate that you like an idea and it aligns with your vision for the future, but it’s not necessarily a priority and may not make it on the roadmap for a long while - or ever.
It could mean that you are interested in this idea and plan to put resources on it, e.g. to research an idea, but that it could be de-prioritized according to your findings.
A more cautious approach is to use this status only when you know you will definitely build something, and you’re confident enough to represent it on a roadmap.
Whichever meaning you choose, make sure your teams use the status consistently and its meaning is clear to your customers. Use status response and roadmaps to provide extra clarification.
Examples
Aligns to our Vision
In Discovery
Committed
On the Roadmap
Status: "Building"
What does it mean?
Your "Building" requests are the ones you're literally in the process of building, and so this status will generally be a stop-gap between Planned and Released, but it's important for letting your customers and team members know what you're currently working on.
Where can it be found?
Requests in the “Building” status can be found across the app, including the Visitor Dashboard. Requests in this phase are included in your reports by default.
The What’s Coming report is auto-populated with requests in this status. It provides a light touch, low maintenance way to communicate a high level roadmap to your stakeholders.
Best Practice
This status should be used only when your developers have started work on something, and your customers will be able to use the resulting feature.
Note that if a request doesn’t correspond exactly to a feature you’re building, but you believe it will solve for the same pain, we believe it’s fine - and even recommended - to move all related requests to “Building” in this case. Just make sure you add context and clarification in the status response.
Examples
In development
In Progress
Under Construction
Status: "Released"
What does it mean?
Your "Released" requests are those which have been built and rolled out, and are now implemented into your product.
Where can it be found?
“Released” requests will no longer appear in Visitor Dashboards, but will move to your Release Log instead. Requests in this status will no longer appear in your reports by default, but you can optionally include them.
Best Practice
Use “Released” when your engineers have finished work on a feature and you want to let your stakeholders know the feature is available. You can also use the status when you get a request about a feature which already exists.
In both cases, make sure you adjust the status response to educate your users and drive adoption, by explaining where the feature can be found and how it should be used.
Examples
Done
Delivered
Available
Status: "Declined"
What does it mean?
Your "Declined" requests are used for ideas which you never have any intention of building. This might be because a request is not at all aligned with your product vision, or because you can offer a sound work-around already.
Where can it be found?
“Declined” requests will not show up in your visitors' dashboards, though they will surface if a similar request is suggested. Visitors can no longer add their votes, but they can add comments.
Requests in this status will no longer appear in your reports by default, but you can optionally include them.
Best practice
Be transparent with your customers when you know you cannot or will not build a feature, but add as much detail as you can in a status response about why you do not see the value in a request.
Don’t delete requests you have declined. If one user has enquired about a feature, it’s likely other users will have the same experience & 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 may 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.
Examples
Closed
Not being considered
No action
Customizing request statuses names
To rename request statuses in your Feedback account, head to Settings < Product Settings.
From there, scroll down & select “Custom Request Statuses”
Edit your status names here, then hit “Save Changes” at the bottom.
After you save changes, a confirmation window will appear. Hit Confirm & Apply to apply the changes. This will take a few seconds to take effect while the changes are propagated across the app.
Warning: Once you’ve hit “Confirm & Apply”, statuses will be updated across the app and are therefore visible to anyone with access to Pendo Feedback, including your customers if you have given them access.
In Practice: Updating statuses
Once your statuses are all set up, your workflow has been established and your teams trained, you can start using your own statuses to let your users know when requests move along the request lifecycle.
Head here to learn how to change the status on a request.