How to triage customer feedback
Review new feedback in one weekly batch. Give every item a status (new, planned, in progress, done or closed), group repeats by type and page, act on bugs first, and tell customers when their request ships.
By Rafael Thayto · Last updated
Use a small, fixed set of statuses
A status answers one question: what happens next with this item? Five are enough:
| Status | Meaning |
|---|---|
| New | Nobody has read it yet. Your inbox-zero target. |
| Planned | You decided to act on it. |
| In progress | Someone is working on it now. |
| Done | Shipped or fixed. Time to tell the customer. |
| Closed | Read and decided not to act, a duplicate, or spam. |
Everything outside New has been read. Everything in Planned or In progress is a promise.
The weekly routine
Set aside 30 minutes once a week. Real-time alerts tell you that something arrived; the weekly batch is where you decide.
- Filter to New. Read every item.
- Bugs first. Reproduce with the page URL and browser saved on the item. Fix or move to Planned.
- Ideas: look for repeats. Search the inbox for the same words. Five customers asking for the same export format is a signal; one is an anecdote.
- Praise: note what to protect. Praise tells you what not to break and makes good copy for your landing page (with permission).
- Close the rest with a short internal note explaining why, so you don't re-decide it next month.
- Check the 30-day chart and rating. A spike in bugs after a release or a falling average rating is worth a look even when no single message is alarming.
How do you prioritize feature requests?
Weigh each idea by:
- Frequency: how many distinct customers asked.
- Who asked: paying customers on the plan you want to grow count more.
- Effort: small requests that many people want are the easy wins.
- Fit: does it move the product in the direction you already chose?
Feedback is input, not a vote. Customers describe problems well and solutions badly; look for the problem behind the request.
Close the loop
When an item moves to Done, reply to the customers who asked. A one-line "this shipped today, thanks for the idea" turns a customer into someone who sends feedback again. Use the internal notes on each item to record who to tell.
Common triage mistakes
- Letting New pile up. An inbox with 300 unread items stops being read at all. Close aggressively; you can always reopen.
- Treating every request as a vote. Ten requests from free trials that never converted weigh less than two from your best customers.
- Deciding without context. Read the page URL, plan and metadata before judging a bug as "can't reproduce".
- Never saying no. Closing an idea with a note is a decision. Leaving it open forever is not.
Export for deeper analysis
A CSV export of a product's feedback lets you count themes in a spreadsheet, share a quarterly summary or feed an AI model to cluster requests. Escuta Produto exports UTF-8 CSV that opens correctly in Excel and Google Sheets.
Who should own triage?
On a small team, one person owns the weekly pass and everyone else can read the inbox. Ownership rotates monthly so nobody becomes the only person who knows what customers are asking for. On a solo product, the owner is you; protect the slot on your calendar the way you would a customer call.
Whoever owns it makes three kinds of decision and nothing else: what's a bug to fix now, what's an idea worth planning, and what gets closed. Building, designing and replying can be handed to others. If you run several products, see A feedback routine for running five products.
A worked example
Suppose a week brings in 18 new items for one product (an example, not a benchmark):
| Type | Count | Decision |
|---|---|---|
| Bug | 5 | 3 reproduced and fixed, 1 planned, 1 closed as a duplicate with a note |
| Idea | 9 | 2 repeats of an existing planned item (noted), 1 new item planned, 6 closed with reasons |
| Praise | 3 | Noted what customers liked; asked one for permission to quote them |
| Other | 1 | A billing question forwarded to support, then closed |
The inbox ends the week at zero new items, and every decision has a short note explaining it.
Related
Frequently asked questions
How often should a team review customer feedback?
Once a week in a fixed 30-minute batch, with real-time Slack or Discord alerts only for awareness. Batching lets you spot repeats and decide consistently.
What statuses should a feedback workflow use?
Five are enough: New (unread), Planned (decided to act), In progress (being worked on), Done (shipped, tell the customer) and Closed (won't act, duplicate or spam).
How do you prioritize feature requests from customers?
Weigh how many distinct customers asked, which customers asked, how much effort it takes and whether it fits the product direction. Look for the underlying problem rather than the exact solution requested.
Related
- How to use RICE to prioritize customer feedbackScore feedback with RICE: count distinct customers for reach, rate impact and confidence, then divide by effort. Includes a worked example.
- How to apply the Kano model to feature requestsUse the Kano model to sort feature requests into basic, performance, delighter and other groups, and learn when the model stops being useful.
- Prioritize bugs by frequency and severityRank bugs by how often customers hit them and how much damage they cause. A 2x2 grid, a frequency count from feedback and clear rules for what goes first.
- How to build a tagging system for customer feedbackEscuta Produto has no tags, so build a small, stable set of areas in metadata and notes. Define each label, review the list quarterly and keep it short.