# How to design a feedback status workflow

> A feedback status workflow uses a few statuses, each with one clear promise: new means unread, planned means decided, in progress means someone is working on it, done means shipped and told, and closed means decided not to act. Define who moves items and when, then check stale items every week.

Source: https://escutaproduto.com/resources/feedback-status-workflow
Last updated: 2026-10-09

## Five statuses and the promise each one makes

A status is a promise about what the team is doing with an item. Keep the set small so everyone uses it the same way. Escuta Produto uses five: new, planned, in progress, done and closed. Each one makes a different promise.

| Status | The promise it makes | Who should see it as true |
| --- | --- | --- |
| New | Nobody has decided yet. | The team, during the weekly review. |
| Planned | We have decided to act, but no one is working on it yet. | The team, and anyone you have told. |
| In progress | Someone is working on it now. | The team, and the customers who asked. |
| Done | It shipped for users, and the people who asked were told. | Everyone. |
| Closed | We read it and decided not to act, or it was a duplicate or spam. | Everyone, with a note explaining why. |

The most common mistake is using a status for a feeling. "Planned" is not a hope, and "done" is not "merged into the main branch". If a status cannot be true or false, it is not a status.

## Who moves an item, and when

Give each move an owner. In a small team, one person owns triage and moves items from new. Engineers move items to in progress when they start, and the person who ships the change moves it to done. Nobody else needs to touch the status.

Write the owners down. A list with one line per status is enough. When a new person joins, that list answers the question "who should I ask before I change this?"

## Allowed moves and the ones to avoid

Most items follow a short path: new to planned or closed, planned to in progress or closed, and in progress to done. Closed can be the end of a path, and some teams reopen a closed item when a new request arrives. Those are the normal moves.

Avoid a few moves:

- **New straight to done.** If it shipped without anyone deciding, you have lost the record of why.
- **Done without a reply.** The customer who asked should hear about the change. See [how to tell customers their request shipped](/resources/tell-customers-request-shipped).
- **Closed without a note.** A closed item with no reason looks like neglect, and the next person will reopen it to find out.

Escuta Produto does not block a move, so these rules live in your team's habits. Write them down and review them when someone breaks one.

## Write down what done means

Done is the status most teams get wrong. Define it in one sentence the whole team agrees on. A useful definition is "the change is live for users and the people who asked have been told." Under that definition, a merged branch is not done, and a released change that nobody announced is not finished either.

Add the definition of closed too. "We decided not to act, and the note says why" is a good one. Without it, closed becomes a graveyard, and nobody trusts the list.

## A weekly check on stale items

Items drift. A planned item from three months ago may no longer matter, and an in progress item may have stopped weeks ago. Check both each week. Filter to planned and in progress, sort by the date the item came in, and read the oldest ones first.

For each stale item, decide one of three things: move it forward, close it with a reason, or add a note saying what would change your mind. An item that sits untouched is a broken promise, even if nobody mentions it. If you find more than a handful of stale items, the problem is usually the process, not the backlog. Shrink the list before you add new rules.

## Handle the items that never fit

Some items do not fit the five statuses cleanly. A duplicate is closed with a note that points to the main item. A message that mixes a bug and an idea should be split into two items when you can, so each one gets a clear status. Spam is closed with a short note so nobody reads it twice. When you are unsure, pick the status that describes the next action, and write the reason in a note.

## Running the workflow in Escuta Produto

Each product has an inbox with filters by status and by type, plus a text search. Use the status filter in your weekly review: start with new, then planned, then in progress. The 30-day chart and the counts by type show whether the inbox is growing faster than you can clear it.

Set the status on the item, then add an internal note whenever the status changes meaning, such as a decision to close or a plan to revisit. The note is private to your team, and it is where the reason lives. The status tells you what happened, and the note tells you why.

If you export the feedback as CSV, the status column lets you count how many items sit in each state, which is useful for a monthly review of the whole process. For the weekly routine that uses these statuses, see [how to triage customer feedback](/resources/how-to-triage-customer-feedback). For the reply that goes with each move, see [how to reply to customer feedback](/resources/reply-to-customer-feedback). New items also arrive in Slack or Discord through the [notifications setup](/docs/notifications), so the team sees each new item as it arrives.

## Frequently asked questions

### How many statuses should a feedback workflow have?

Five is enough for most teams: new, planned, in progress, done and closed. Each one should make a clear promise. More statuses usually mean people pick different ones for the same situation.

### What does done mean for a feature request?

Done means the change is live for users and the people who asked have been told. A merged branch or an internal demo is not done, so define the rule once and keep the whole team to it.

### Who should change the status of a feedback item?

Name one owner for triage, who moves items from new. Engineers move items to in progress when they start, and whoever ships the change moves it to done. Write the owners down so nobody guesses.

### How often should you review stale feedback items?

Review planned and in progress items every week, oldest first. For each one, move it forward, close it with a reason, or note what would change your mind. An untouched item is a broken promise.