Skip to content

Review and Triage Feedback

You will know how to work through incoming Lens feedback in a repeatable way, so the team always has a clear picture of what is new, what is in progress, and what is done. Triage is the single habit that determines whether Lens stays useful at scale: an unmanaged inbox quickly becomes background noise.

The Lens inbox shows every feedback item for the selected site and environment. Use the list view to understand current volume, recent activity, and which items are still open before clicking into any single item. Search and status filters are most useful when the team needs to focus on a particular environment, issue type, or stage of work.

A productive triage session starts with three questions:

  1. How many open items are there right now?
  2. How many have moved since the last session?
  3. Which items already have a clear next action and which still need one?

If you can answer all three in under a minute from the list view, your filters and statuses are working. If you cannot, the queue is drifting toward “shared inbox” territory and needs cleanup before more items arrive.

This is a repeatable pass that works for most teams. Run it on a fixed cadence (daily for high-volume teams, weekly for low-volume teams) rather than only when someone notices a backlog forming.

  1. Start with open items and recent submissions. Sort by most recent first. New items are the highest risk for being misunderstood or duplicated, so triaging them quickly keeps the rest of the queue honest.

  2. Review the highest-impact or highest-traffic pages first. If two items came in at the same time, the one on the homepage or checkout flow gets attention before the one on a deep marketing page. Use page context from the item to decide.

  3. Move items into review when someone is actively validating them. Do not leave items in their default state once a real person owns them. Moving status is the cheapest way to communicate “I have this.”

  4. Use comments to clarify the next action. Resist the urge to create a second feedback item to add context. A comment on the original item keeps the history intact and prevents duplicates.

  5. Close the loop in writing. When an item is resolved, leave a comment that says what changed and where it can be confirmed. Future reviewers should not have to guess.

The triage pattern above is the same for everyone, but the cadence and ownership model differ depending on volume. Pick the tab that matches your team and use it as a starting point.

Teams that see dozens of new items per day need a stricter rhythm. The inbox cannot survive a “we triage when we have time” approach.

  • Run triage at least once per business day at a fixed time.
  • Assign a rotating triage owner so it is never “everyone’s job.”
  • Move items out of the new state within one working day.
  • Use status filters aggressively. The triage owner should only look at new and recently updated items, never the entire backlog at once.
  • Escalate fast. If an item looks like a support issue, escalate the same session; do not let it sit.
  • Treat resolved items as worth a quick second pass at the end of each week to confirm nothing reopened.

A few patterns reliably degrade a Lens queue. Watch for them.

  • Duplicate items as comments. If a reviewer files a second item to add context to the first, the history splits and triage gets harder. Train the team to comment instead.
  • Leaving everything open. If every item is in the new state, the status field is not earning its keep. Use it.
  • Closing without a comment. Future reviewers cannot tell whether the item was fixed, dismissed, or escalated. Always say why.
  • Triaging across environments in one pass. Each environment has its own context. Do them separately, even if it takes two passes.
  • The team can explain at any moment what is new, what is under review, and what is done.
  • Duplicate work is rare, because Lens is the single source of truth for feedback state.
  • Triage takes a predictable amount of time, not “however long the backlog has grown to.”
  • Escalations to support carry enough context that the support team rarely needs to ask follow-up questions.