Collecting feedback is the easy part. After the first review round, you have forty items: some duplicates, some real bugs, some opinions, a few "while you're at it" requests, and one genuine emergency hiding in the middle.
Triage is how you turn that pile into a plan. On a Kanban board, it takes about fifteen minutes a day.
What triage is (and isn't)
Triage means deciding, for every new item: is this real, how bad is it, and who owns it?
It isn't fixing. The fastest way to derail triage is to start solving the first interesting bug you read. Decide first, fix later — otherwise the forty-item list stays a forty-item list, with one very well-fixed bug at the top.
Set up the board
A board for website feedback doesn't need many columns. pinreview projects start with four:
- Backlog — everything new lands here, untriaged
- To Do — confirmed, prioritised and ready to work on
- Doing — someone is actively on it
- Done — fixed, and visible as fixed
You can rename, add or remove columns to fit your process. Two common additions:
- Needs info — waiting on the reporter to answer a question
- Ready for review — fixed on staging, waiting for the reporter or QA to confirm
Resist adding more. Every extra column is another place for items to stall.
The triage routine
Run this once a day during a review round, and weekly otherwise. Work through Backlog from the top.
1. Is it real?
Open the item and check the report: the screenshot, the pinned element, the page URL, the browser and viewport. With that context attached, you can usually tell in seconds whether it's a real problem.
- Can't reproduce? Try the same browser and viewport from the report. If it still doesn't happen, move it to Needs info with a specific question.
- Working as designed? Reply on the task explaining why, then close it. A clear "this is intentional because…" is better than silence.
2. Is it a duplicate?
Three reviewers will report the same broken hero image. Keep the clearest report, comment on the others pointing to it, and close them. Duplicates left open inflate the board and split the discussion.
3. How bad is it?
Set a severity. pinreview uses a simple scale — Low, Normal, High, Critical — and a shared definition matters more than the labels:
- Critical — blocks launch or loses money: checkout broken, forms not sending, site down on a major browser
- High — a key page or flow is clearly wrong: broken layout on mobile, wrong pricing, missing legal page
- Normal — visible but not blocking: spacing, alignment, copy errors, inconsistent styles
- Low — polish and nice-to-haves: subtle animation, minor wording preferences
Write these definitions down and share them. Otherwise everything reported by the client's CEO is Critical.
Severity is how bad the problem is. Priority — what gets done first — also depends on effort, deadlines and who's affected. A Normal item that takes two minutes on the homepage can reasonably jump the queue. Use severity as the default order, and your judgement for the exceptions.
4. Is it in scope?
Some feedback isn't a bug — it's a new request. "Can we add a testimonials carousel?" arriving in the middle of bug reports is how scope quietly grows.
Tag it (for example, "out of scope" or "change request") rather than silently absorbing it. That turns an awkward conversation later into a simple list now. Our agency review workflow explains why this tag protects margins.
5. Who owns it?
Assign every item that moves to To Do. An item without an owner is an item nobody is working on. Add a due date for anything tied to a launch.
Then move it to To Do. Backlog should be empty — or close to it — when you finish.
Keep the board moving
Limit work in progress. If one developer has eight items in Doing, nothing is really in progress. A rough limit of two or three per person keeps the flow honest.
Keep discussion on the task. Comments on the task keep the conversation next to the screenshot and history. In pinreview, you can mark a comment as internal so your team can discuss freely while the reviewer sees only what's meant for them.
Make progress visible to reviewers. When a reviewer can see their item move to Done, they stop re-reporting it and trust the process. You choose which tasks guests can see, so the client gets a clear view without your internal backlog.
Use the activity history. Every task records status, severity and assignee changes. When someone asks "what happened to my feedback?", the answer is already there.
Get notified without watching the board. Send new feedback to a channel with the Slack integration, or route triaged items to Jira, Trello or Asana with webhooks.
A triage checklist to copy
For each item in Backlog:
- Real? If unclear, ask one specific question and move to Needs info.
- Duplicate? Keep the best, close the rest with a link.
- Severity: Low, Normal, High or Critical, by your written definitions.
- In scope? If not, tag it.
- Owner and due date assigned.
- Moved to To Do.
Then, once a week: clear anything stuck in Needs info for more than a few days, and check that Done items have actually been confirmed.
The bottom line
Triage isn't a meeting; it's a short routine. Decide whether each item is real, merge duplicates, set severity, catch scope creep, and give everything an owner. Do it daily during review rounds and the board stays a plan rather than a pile.
It's much faster when every report already arrives with a screenshot, the exact element and the browser details — which is what pinreview captures on every pin. For the reporting side, see our guide to writing a bug report developers can use.