Team Collaboration: Working Together
Invite team members, manage roles, and collaborate on feedback with your team.
Feedback stops being one person's job the moment a second person cares about it. Qaid keeps the answer small: two roles, an assignee, and email settings people can mostly switch off.
Inviting people
Open your project's Settings and find Team Members. Enter an email, pick Owner or Member, send.
They get a link that works for seven days. If they have no Qaid account yet, the link walks them through making one.
Pending invitations sit in the same section, where you can resend one that got lost, revoke one you regret, and see when each expires. Accepted invitations move into the active list.
Owner and Member
Two roles, and the line between them is administrative rather than about feedback.
Owners do everything a member can, plus invite and remove people, change roles, manage API keys, set up the project, and delete it. Whoever made the project is its first owner and you can have more than one. A second owner is what stops a project going dark when the first one leaves.
Members work the feedback: read it all, archive and unarchive, add admin notes, assign items to anyone on the team, mark things read, and open GitHub issues if that integration is on. They cannot invite anyone, touch API keys, or delete the project.
Member is the right fit for support staff, contractors and QA. Start people there. Promoting someone later is a good conversation; demoting them is not.
Assigning feedback
Open an item, click Assign, pick a person.
They get an email if they have those on, their name and face show on the item, and Qaid records who assigned it and when. You can then filter the inbox by who owns what.
Assign on expertise rather than availability: feedback about checkout goes to whoever owns checkout, because they will recognise in ten seconds what somebody else spends an hour reproducing.
Assign to yourself as a reminder when something needs investigating. It works as a lightweight task and it stops the item drifting back into the pile.
Do not assign everything. A thumbs-up with no message needs no owner, and a queue where every item has a name on it tells you nothing about which ones actually need a person.
Clear or archive assignments when the work is done, or "assigned to me" stops meaning anything within a month.
Filtering the inbox
Assigned to me is your own queue. Assigned to somebody else is theirs. Unassigned is the one worth checking weekly, because that is where things go to be forgotten. Combine any of them with feedback type, date range or archived status.
Notifications
Two layers, and they do not talk to each other.
Each person sets their own in account settings: email on or off, one at a time or a daily digest, and which events count. New feedback, work assigned to you, anything escalated.
Project owners set project-wide recipients, which get everything whatever the individuals chose. That is how you point a shared inbox or a mailing list at a project. Owners also pick which feedback types fire at all.
On top of both, escalation rules fire at once on a keyword, a feedback type, or a captured console error. Those need Pro.
Start with almost everything off and add as you learn your volume. Get forty emails in week one and you turn the lot off in week two, then miss the one that mattered in week three. Where volume is high, the daily digest is what keeps people subscribed.
Point a team mailing list at the project as well, so incoming feedback is somebody's problem even when the person who usually reads it is on holiday.
How this fits together
Negative feedback arrives about a confusing settings page. The project notification reaches your shared inbox. Whoever is on triage reads it and assigns it to the designer who owns settings. The designer writes up what they find in admin notes on the item itself, which keeps the reasoning next to the report instead of in a chat thread. They ship a fix, add a last note, and archive it.
Nothing there requires a process document. It requires that the item has an owner and that the owner can see it.
Next
Linear and Jira turn feedback into tickets, escalation rules make the urgent ones interrupt somebody, and webhooks push events into Slack.