How Feedback Flows Through Userorbit
Every piece of feedback in Userorbit follows a defined path from submission to resolution. This path is called the feedback pipeline, and understanding it is key to running an efficient product feedback process. The pipeline is built around statuses that represent where each item stands in your decision-making workflow.
The Default Statuses
Userorbit provides five statuses out of the box. Each one represents a distinct stage in the lifecycle of a feedback item:
- In Review — This is the entry point. Every new piece of feedback starts here. It means your team has received the item but has not yet decided what to do with it. During this stage, you read the feedback, add internal notes, apply tags, and determine whether the request is valid, a duplicate, or out of scope.
- Planned — Moving an item to planned signals that your team has decided to act on this feedback. It does not mean work has started, but it does mean the request has been accepted and is on the radar. Users who voted on or submitted the item will be notified of this status change, which builds trust and engagement.
- In Progress — This status means active work is underway. If you have linked the feedback item to a roadmap topic, this status often aligns with the topic moving into an active development stage. It tells users that their request is being built right now.
- Completed — The request has been fulfilled. The feature has shipped, the bug has been fixed, or the improvement has been made. Moving an item to completed triggers a notification to voters and submitters, closing the feedback loop.
- Closed — Use this status for feedback that will not be acted on. This could be a duplicate that was merged elsewhere, a request that is out of scope, or something that was considered but ultimately declined. Closing an item keeps your pipeline clean without deleting the feedback.
Designing Your Workflow
The default statuses work well for most teams, but the real power comes from how you use them. Here are some practical patterns:
Regular Triage Sessions
Schedule a weekly or biweekly session where your team reviews all items in the in review status. The goal is to move every item out of in review and into one of the other statuses. This prevents your inbox from becoming a graveyard of unprocessed feedback.
Batch Status Updates
When a feature ships, update all related feedback items to completed at once. This is especially easy when you have linked feedback to a roadmap topic, because you can see all related items in one place.
Use Closed Intentionally
Do not be afraid to close feedback. Not every request should be built. Closing an item with a clear explanation (via a public response or note) is better than leaving it in in review forever. Users respect transparency about what you will and will not build.
Connect Statuses to Your Roadmap
Link feedback items to roadmap topics so that status changes on the roadmap can inform status changes on feedback. When a roadmap topic moves to a new stage, review the linked feedback and update statuses accordingly. This keeps your feedback pipeline in sync with actual product development.
Tips for a Healthy Pipeline
- Keep the in review queue small. If it grows past 50 items, you are not triaging often enough.
- Use tags to pre-sort feedback before triage sessions so you can process items by theme.
- Set a target response time for new submissions. Even a brief acknowledgment builds goodwill with users.
- Review your planned items quarterly. If something has been planned for months without progress, either move it to in progress or reconsider whether it should remain planned.