How to keep feedback visible and moving between support, product, development, and design, so it doesn't stall with one person or one tool.
Feedback rarely belongs to one person. A bug report reaches support, goes to a developer, informs a product decision, and is closed when the reporter hears back. If only one person sees it in Userback, every handoff after that depends on screenshots and Slack messages. Put the whole team in Userback and each step happens where the feedback lives.
How feedback moves through a team
A typical feedback item, set up well, moves like this:
It arrives and gets classified. A user submits through the widget. AI sets its type and category.
It gets an owner. Triage rules assign it based on its type, for example bugs to a developer and ideas to the product manager.
The team works on it together. Internal notes carry the discussion. If it needs work in Jira, Linear, or ClickUp, it syncs there.
The reporter hears back. When it's resolved, the reporter gets an update. Voters on a shipped idea are notified.
The sections below set up each step.
Who to add to Userback
Add everyone who acts on feedback, not only the person who set Userback up.
Product managers turn feedback, votes, and survey results into roadmap decisions. See Best Practices for Product Managers.
Developers fix bugs with session replays, console logs, and network requests instead of vague descriptions. See Best Practices for Developers.
Support agents log what customers report, escalate it with context, and update customers when it's fixed. See Best Practices for Customer Support Teams.
QA testers report issues on staging or production with annotated screenshots, video, and metadata from the Browser Extension.
Designers see how users actually move through the product in session replays, and get annotated feedback on designs and prototypes.
Marketers collect feedback on your website and landing pages with the widget, and hear the words customers use for their problems.
Give everyone one view
The Inbox shows activity from every site you belong to in one list, so nothing is missed because it landed on a site someone wasn't watching. See Inbox.
To stop workspace-wide visibility becoming noise, team members can set their Inbox notifications to Focus mode. They then see feedback that involves them, not every new item. See Manage My Notification Settings.
Route feedback to an owner automatically
Feedback without an owner waits. Set triage rules on Feedback > Settings > Automation so each new item gets an assignee and a due date based on its type, and turn on AI categorization so it arrives sorted. See Best Practices for Managing Feedback Faster with Userback for how to set these up.
For Slack alerts when feedback arrives, connect the Slack integration. See Connect Userback with Slack.
Keep team discussion on the feedback
A discussion in Slack or email is hard to find later, and half the team never sees it. Keep it on the feedback item instead.
Use internal notes. In the comment box, check Internal before you post. Internal notes are visible to your team only, never to the reporter.
@mention a teammate to bring them in. They get a notification.
Limit some members to internal notes. In Site Settings > Members, set a member's permission to Internal notes only so they can discuss feedback but never reply to a user by mistake. See Set Per-Site Member Permissions.
Connect the tools each team uses
Developers may live in Jira or Linear, support in Zendesk or Intercom, product in ClickUp or Asana. Connect them, so feedback isn't stranded at each handoff.
Two-way sync links a feedback item to a Jira, Linear, or ClickUp issue. When a developer closes the issue, the feedback item updates, and support can see it without chasing anyone.
Support tool integrations with Zendesk and Intercom let support see feedback and its status from their own tool.
Webhooks and the REST API send Userback events to any other system.
Give every team the user's context
With User Identification set up, every feedback item is linked to a known user: their name, email, plan, account, and any custom attributes you send. Each role uses that differently:
Support knows who's reporting without asking, and can see their earlier feedback.
Developers can check whether an issue affects one user or many.
Product managers can filter feedback by segment or plan to see who an issue affects.
See Users and Creating Segments for step-by-step instructions on viewing your users and grouping them into segments.
Make one person responsible for the system
Automation routes feedback, but someone still needs to own the process as a whole. In most teams, that's a product manager or team lead who watches the system, not only their own queue. Their job:
Maintain the triage rules, categories, and statuses so feedback is organized the same way whoever handles it. See Configure Your Feedback Settings.
Check Reports for volume, resolution time, and anything requiring action, and follow up on what's stalling.
Make sure reporters hear back. See Best Practices for Closing the Feedback Loop.
Set up before you invite a team
A team adopts Userback faster when it works for them on day one. Before you send invites:
Name your sites clearly, so people know where to look and where to log things.
Set up anything that team will rely on. For a support team, that's Email Forwarding for the support inbox and at least one Reply Template.
Choose the right role. Most team members need the Collaborator role, not Admin.
Invite the team and give a short walkthrough of the Inbox, internal notes, and reply templates. A formal training session usually isn't needed.
When you introduce Userback, frame it around their work. For a support team, for example: "When a customer reports a bug, log it in Userback instead of Slack. It takes 30 seconds, and the product team gets everything they need without coming back to you."
What's next