How to Use n8n with ._Template 34 New Review Slack Response

Every new customer review is a time-sensitive signal. A five-star note is a testimonial you should amplify within the hour; a one-star complaint is a churn risk that gets worse every minute it sits unseen in a dashboard nobody checks. Yet most teams find out about reviews days later, buried in a weekly digest email. This template — a new-review-to-Slack-response workflow built in n8n — closes that gap. It watches your review sources, pushes each new review into the right Slack channel the moment it lands, and can even draft or post a response automatically. Here is how to build it and run it in production.

The problem: reviews arrive faster than humans can watch them

Review platforms (Gumroad, G2, Trustpilot, Google Business, app stores, Capterra) all generate reviews on their own schedule — nights, weekends, mid-sprint. The people who should respond are not sitting in those dashboards. The result is a predictable failure pattern:

A negative review sits unanswered for three days, the customer assumes they were ignored, and they escalate publicly. A glowing review that could have become a case study or a quote on your landing page evaporates because nobody flagged it to marketing. Support, sales, and product all care about reviews but none of them own the monitoring, so it falls through the cracks. Manually refreshing five review dashboards is not a system — it is a chore that gets skipped the first busy week.

What you actually need is a single pipe: any new review, from any source, lands in the one place your team already lives — Slack — with enough structure that someone can act in seconds, and with the option to auto-respond when the response is safe to templatize.

The solution: an event-driven review router in n8n

n8n is a fit here because the entire job is trigger → normalize → route → respond, which maps cleanly onto its node model. You do not need a backend service or a cron job you have to babysit. The workflow has four logical stages:

1. Ingest — capture new reviews via webhook or polling. 2. Normalize — reshape every source into a common object (rating, author, text, product, URL). 3. Classify & route — branch on sentiment or star rating so positive and negative reviews go to different channels and playbooks. 4. Respond — post the alert to Slack, and optionally generate and send a reply back to the review platform. Because n8n keeps execution history, every review that flows through is logged, retryable, and debuggable — which matters when a customer asks "did anyone even see my review?"

Step-by-step setup in n8n

Step 1 — The trigger. If your review source can send webhooks (Gumroad "sale/review" events, or a Zapier/Make relay), start with a Webhook node set to POST and copy its production URL into the platform's webhook settings. If the source has no webhooks — common for Google or app-store reviews — use a Schedule Trigger node (every 15 minutes) feeding an HTTP Request node that hits the platform's reviews API. To avoid re-processing the same review on every poll, add a Code node or an n8n Data Store / static-data check that keeps the last-seen review ID and drops anything you've already handled.

Step 2 — Normalize the payload. Add a Set (Edit Fields) node right after the trigger and map each source into a canonical shape:

rating → number 1–5, author → string, text → the review body, product → what was reviewed, review_url → deep link back to the review, source → e.g. "gumroad". Doing this once means every downstream node — Slack, sentiment, auto-reply — reads the same fields regardless of where the review came from. This is the single most important step for keeping the workflow maintainable as you add sources.

Step 3 — Classify sentiment. Add an IF node (or a Switch node for more than two branches) with the condition {{ $json.rating }} >= 4. The true branch is your "wins" path; the false branch is your "at-risk" path. If you want nuance beyond star count — a 4-star review with an angry paragraph — insert a Basic LLM Chain node (or an HTTP Request to the Anthropic API using a Claude model such as claude-haiku-4-5 for speed and low cost) that returns positive / neutral / negative, and switch on that instead.

Step 4 — Post to Slack. Use the Slack node with the "Send Message" operation, authenticated via OAuth2 or a bot token. Route positive reviews to #wins and negative ones to #support-escalations. Build the message with Block Kit so it is scannable — put the star rating and author in a header, the review text in a section block, and add a "View review" button linking to {{ $json.review_url }}. Include the source and product as context fields so whoever picks it up has the full picture without leaving Slack.

Step 5 — Auto-respond (optional but powerful). On the positive branch, a No Operation node plus a thank-you is often enough. On the negative branch, add an LLM node that drafts an empathetic, non-defensive reply from the normalized review text, then either (a) post the draft into the Slack thread with an approval button so a human sends it, or (b) if the platform's API supports posting responses, feed it into an HTTP Request node that publishes the reply directly. Start with human-in-the-loop approval; graduate to full automation only for review types where a templated response is genuinely safe.

The benefits: speed, coverage, and a searchable record

Response time collapses from days to minutes. The review hits Slack the moment it exists, in the channel of the people who can act. Nothing slips through — every source funnels into one normalized pipe, so adding a new review platform is one trigger plus one Set-node mapping, not a new manual habit. Positive reviews become assets — marketing sees the five-star quotes in real time and can pull them into landing pages and ads while the enthusiasm is fresh. You get an audit trail for free — n8n's execution log is a searchable history of every review, how it was classified, and whether a response went out, which is invaluable when you want to measure response SLA or debug a missed alert. And because the whole thing is event-driven, it costs nothing when no reviews come in — no idle server, no polling waste if you use webhooks.

Common pitfalls to avoid

Duplicate alerts from polling. The classic mistake with the Schedule + HTTP Request pattern is re-posting the same reviews every 15 minutes. Always persist a last-seen ID (in n8n static data or a Data Store) and filter the batch before it reaches Slack.

Skipping normalization. Wiring Slack directly to each source's raw payload feels faster on day one and becomes unmaintainable by source three — every downstream expression breaks differently. Spend the ten minutes on the Set node.

Fully automating negative replies too early. An LLM auto-reply that misreads context can turn a recoverable one-star into a public screenshot. Keep humans in the loop on the negative branch until you have evidence a specific response type is safe, and always instruct the model to be empathetic and never argue.

Rate limits and secrets. Slack and review APIs throttle; add a Wait or batching where you send many messages, and enable "Retry On Fail" on the Slack and HTTP nodes. Store every token in n8n Credentials, never hard-coded in a node, so keys can be rotated without editing the workflow.

No error path. Attach an Error Trigger workflow that pings a #ops-alerts channel when an execution fails. A review pipeline that dies silently is worse than no pipeline, because you'll believe you're covered.

Build it once, and every review — good or bad — stops being something you discover late and becomes something you respond to first.