Feedback that nobody sees for three days might as well not exist. If your team spends the day in Slack, the fastest way to make feedback visible is to put it there — automatically, the moment it arrives.
Done well, a feedback channel becomes the team's early-warning system. Done badly, it's a firehose everyone mutes by Wednesday. Here's how to set it up and keep it on the right side of that line.
What you can send
pinreview can post to Slack when four things happen on a project:
- New feedback — a reviewer pins a comment and a task is created
- Status changed — a task moves between columns, such as To Do → Doing
- Task updated — a task's details change, such as its title, severity or assignee
- New comment — someone replies on a task
Each message is a compact card: the task number and title (linked straight back to the task in pinreview), its status, severity, assignee and tags, and who triggered the event. Cards are colour-coded by severity, so high-severity items stand out in a busy channel. Status changes show the move from one column to the next; comment events include the comment text.
You pick which events to forward, and integrations are set up per project.
Set it up in about five minutes
Slack integrations use Slack's Incoming Webhooks, which you create inside a Slack app. You only need to do this once per channel.
- Go to api.slack.com/apps and click Create New App → From scratch. Name it (for example "pinreview") and choose your workspace.
- In the app's left sidebar, under Features, click Incoming Webhooks and switch Activate Incoming Webhooks on.
- Click Add New Webhook to Workspace, choose the channel feedback should post to, and allow access.
- Copy the webhook URL. It starts with
https://hooks.slack.com/services/. - In pinreview, open your project's Integrations, choose Slack, paste the URL, pick the events you want, and click Add.
New feedback on that project now appears in the channel. Integrations are included on pinreview's paid plans.
Treat the webhook URL like a password: anyone who has it can post to that channel.
Choose events deliberately
The most common mistake is forwarding everything to one channel. It works for a week, until the volume makes people stop reading.
A better starting point:
Client review channel (for example #acme-feedback): new feedback only. The team sees every new item as it arrives, and nothing else.
Delivery channel (optional): status changed, so a project lead can follow items moving to done without opening the board.
Comments: forward these only where conversation genuinely happens in real time, such as during a launch week. Otherwise comment notifications are the fastest route to a muted channel.
Task updated is the noisiest event — every edit fires one. Leave it off unless you have a specific reason.
Keep the channel useful
One channel per client or project. Mixing projects forces everyone to filter mentally. Per-project channels also make it obvious when one client's review round is heating up.
React, don't reply. Use an emoji to acknowledge an item ("👀 looking"), but keep the discussion on the task itself. That way the context, screenshot and history stay together, and the reviewer can see the answer. Slack threads about a task are invisible to the person who reported it.
Triage from the board, not the channel. Slack tells you something arrived. The board is where you assign, set severity and decide what's next. Our guide to triaging website bugs on a Kanban board covers a routine that takes minutes a day.
Revisit after the first review round. If people are ignoring the channel, cut events. If items are sitting unseen, add them. The right setting depends on volume, and volume depends on the phase of the project.
Beyond Slack
Slack is for visibility: "something happened, go look." If you need feedback to become a ticket in another tool — Jira, Trello, Asana — use webhooks instead. pinreview sends signed webhook events you can point at Zapier, Make or n8n; see how to send website bug reports to Jira, Trello or Asana.
And if your review process itself needs work, start upstream with how to collect client feedback on a website.
The bottom line
Sending website feedback to Slack takes five minutes: create an incoming webhook, paste it into pinreview, and pick your events. The skill is in the settings — new feedback to a per-project channel, status changes only where someone needs them, and discussion kept on the task where the reporter can see it.
Do that, and Slack becomes the place your team notices feedback, while the board stays the place it gets done.