Why is this important?
The statuses on each request or idea in Feedback are color-coded and visible to your teams and (optionally) visitors so they know at a quick glance what your plans are for each piece of feedback. The status response adds more detail on the status of a request and sets additional expectations for each item. Define custom saved responses to help save time and align your messaging.
Overview
There are six status options for your requests in Feedback:
When you change the status on a request, you have the option of adding an entirely personalized response, or selecting a response which has been pre-defined by your Feedback champions. Head here for more detail on how to set these up.
Once you have added a status response, this message will be shown on the request page and is therefore visible to all visitors and users of Feedback. Optionally, you can choose to send this response out as an email to users who have subscribed to a particular request.
Clicking "Awaiting feedback" on this form send this status response to the 3 users subscribed to this request. This message now shows on the request page:
Status: "Not Reviewed"
When feedback first comes into your account, it's marked as "Not reviewed". This simply lets your visitors know that a request has not been reviewed by your team.
Most requests will usually move straight into "Awaiting Feedback", or they could remain in this "Not Reviewed" status indefinitely. This all depends on how you plan to manage triage, and what you have communicated in your Product Feedback Policy.
Status: "Awaiting Feedback"
Awaiting feedback typically means "We're gauging demand for this idea."
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 is there when you're ready to work on your product.
Quick tips:
- It's totally fine, in fact, it's expected, for your company to have most of your feedback in "Awaiting feedback" status for many months or years. Learn why.
- It's also ok to use the same response for all items in "Awaiting feedback". You need to spend time building products, not managing every single piece of feedback that comes into your account.
- Use the status message to provide further context, set expectations, and include sections from or a link to your product feedback policy.
Examples:
"Thank you for taking the time to give us your valuable feedback.
This request is now "Awaiting Feedback" so that we can gauge demand from other customers and gather use cases.
Make sure to click "Want" on this request if you also need it and keep your priorities up-to-date.
Be sure to check out our product feedback policy at example.com/feedback-policy for more information on what we do with your awesome feedback.
"Thanks for this suggestion! We review all suggestions monthly and work on the ones which our users find most valuable. If we release any ideas you have personally requested or voted on, we will e-mail you to let you know when it has been released. Thank you very much!"
"This request has been reviewed and will stay in "Awaiting Feedback" as we gauge demand from others. Please let us know if you have additional context and/or feedback to share on this request.
"Thanks for your feedback! We think this is a great idea, but it's not a top priority at the moment."
"Requests that we decide to build are thoughtfully considered to ensure maximum value for all of our customers. We appreciate your patience as we improve our product!"
"We are evaluating how this fits in our strategy and gauging demand before making a decision on this request."
Status: "Planned"
Your "Planned" requests are those which you want to build at some point in the future. This doesn't necessarily mean you have to build them right away. Your roadmap can be helpful for extra information and clarification.
Quick Tips:
- Don't feel that planned means you have to prioritize it. It's reasonable to assume that you might plan a request to be built at a time in the future.
- Planned requests are added to the list of requests that you are able to add to the roadmap. So if you have an idea of when you'll be building it, you can easily add it on.
- Planned requests are automatically added to your "What's coming" list.
Examples:
"We like this idea but this isn't a top priority right now. We do plan to look at this in the future because it aligns with where we are taking our product."
"We like this idea & it's where we are taking our product. While we're unable to provide an exact time frame right now, keep an eye on our roadmap for more information on when you can expect this to be built."
"This work hasn't been scheduled yet, but it's on our project list for next year."
Status: "Building"
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.
Quick Tips:
- Make sure you don't get trigger-happy and set the status to Building before you've actually started working on the request.
- Building requests are added to the list of requests that you are able to add to the roadmap. So if you have an idea of when you'll be building it, you can easily add it on.
- Building requests are automatically added to your "What's coming" list.
"Our development team is hard at work on this request right now. You can check back soon for an update!"
"We are currently working on this request and will let you know when it is released. In the meantime, go check out our roadmap to learn about more features we're building!"
Status: "Released"
Your "Released" requests are those which have been built and rolled out, and are now implemented into your product. They will appear automatically on your release log.
Quick Tips:
- Consider including details in your message on how to use or find the new part of your product, and direct them to relevant help documentation.
Examples:
"We have now released this request! Thank you so much for your feedback, and for helping us to improve our product."
"This feature is now live! Go check out our knowledge base for more information on how to use it."
Status: "Declined"
Your "Declined" requests are used for ideas which you never have any intentions 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.
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. This transparency with declined requests has two advantages:
- Helping your visitors understand why their requests aren't being built reduces friction, because they aren't left waiting for months or years to find that a request won't be built anyway.
- By allowing continued discussion, you leave yourself the option of reconsidering a request if it suddenly resurfaces and gets a lot of traffic.
Quick Tips
For a comprehensive guide on how to say no to requests, head here.
Examples:
"We appreciate every suggestion. Right now this doesn't fit with our strategy but it may do in the future."
"Good news! You can already do this. Just go to... We'll close this one off, if you have any questions, reply to this message."
"What we suggest is.... As there would be a large amount of coding work to accomplish something with a simple workaround we're going to turn this one down. If you have any questions, reply to this message."
Default saved responses
By default you have several pre-populated options in your account, as listed below. Once you have added your own custom saved responses, you can hide the default responses by following these instructions.
Awaiting Feedback
"We're gathering feedback from visitors, so that we can gauge demand for this request. Make sure to click "Want" on this request if you need it.."
Planned
"Coming soon! this is a high priority for the team here!"
"This is on our roadmap now, we can't give a definite date for release, but it's coming."
Building
"We've started on this request, we'll let you know when it's released."
"Our development team are hard at work on this request right now, check back soon for an update."
Released
"Released now. Thanks for all your interest in this request, your feedback helps us to build a better product."
"This has been built, and should be available in our next release, which is scheduled for [DATE OF RELEASE]."
Declined
"This is out of scope. We don't envision that this is somewhere we're taking our product."
"We don't think there's enough demand from our visitors, and we've got to focus on where we can help the most users."
"Duplicate, I'm declining this as we've got this covered in another request: [LINK TO REQUEST]."
Advanced
Reporting
Requests in the "Released" and "Declined" statuses will default to not appearing in your reporting. This is an optional setting which you can adjust where needed, head here for more info on your Feedback reports.
More Detailed Feedback Statuses
Status Responses give your team all the flexibility needed to add nuance and different meanings to customer-facing statuses.
For example, if you have a request your team want to spend more time researching before making a decision on whether to build it or not, there are several ways you can handle this.
Usually, if you've not yet made the decision about whether to build a request or not, then your best option is to set the request to "Awaiting Feedback" with a detailed custom response to explain.
"Planned" is also an option if you want to be more transparent about a research phase. It's perfectly fine to move a "planned" request back to "awaiting feedback", but just make sure that your Product Feedback Policy reflects these statuses accurately.
Use tags to categorize additional development phases. This allows your teams to quickly surface requests which may be in more nuanced phases, but without showing this information to your visitors. In this example, use the tags "Research" to any requests you're still discussing. From here, a request could remain in the "Awaiting Feedback" status if you decide not to build it, or it could move to "Planned" if your research has led to this decision.
Note that you can keep the status as it is but send out a new response if you have some detail to add to a new request phase. For example, a request is already in the "Awaiting Feedback" phase with this message:
"We are evaluating how this fits in our strategy and gauging demand before making a decision on this request."
Click the Status response box and re-select the Awaiting Feedback status, but add a new message:
"We are doing more research around this feature and would love to hear your thoughts. Please get in touch with product@example.com to discuss how this feature would help your organization."