Build a Product Feedback & NPS Analyzer — GPT-4o Categorizes Every Response and Creates Linear Issues Workflow with n8n
Your NPS survey has 340 responses sitting in a spreadsheet. You know there's gold in there — a churn signal, a feature request that keeps recurring, a detractor who is about to cancel a $2k/month cont
Your NPS survey has 340 responses sitting in a spreadsheet. You know there's gold in there — a churn signal, a feature request that keeps recurring, a detractor who is about to cancel a $2k/month contract. But reading all 340, tagging each by theme, and turning the useful ones into engineering tickets is a four-hour job nobody on your team wants to own. So it doesn't get done. The responses pile up, and the signal decays until it's worthless.
This article shows you how to build an n8n workflow that does that four-hour job every morning in about ninety seconds. It reads every new feedback and NPS response, uses GPT-4o to categorize the theme and classify the sentiment, separates detractors from promoters, and opens prioritized issues in Linear — with no human in the loop until a founder reviews the ticket queue.
The problem: feedback that never becomes action
Most feedback pipelines break at the same place. Collection is easy — Typeform, Delighted, a survey column in your product DB, an intercom export. The breakage is downstream. Someone has to read raw text, decide "this is about onboarding" vs "this is about pricing," judge whether the customer is angry or delighted, and then decide if it's worth a ticket. That's judgment work at volume, and judgment work at volume is exactly what teams silently drop.
The cost is invisible until it isn't. NPS gets calculated as a single number — "we're at 32" — and the actual verbatims, where all the decisions live, go unread. Detractors don't get a follow-up. The same complaint appears in 18 responses and nobody notices the pattern because nobody read all 18. You're paying to collect feedback and then throwing away 90% of its value at the last step.
The fix isn't more discipline. It's removing the human from the reading-and-tagging step, which is precisely the step an LLM does well and cheaply.
The solution: an autonomous categorize-and-route pipeline
The workflow runs on a schedule and moves each response through five stages: pull new responses, structure them, classify with GPT-4o, filter for what deserves a ticket, and create Linear issues. Everything is deterministic except the one genuinely fuzzy step — reading the text — which GPT-4o handles with a structured output contract so the rest of the pipeline stays predictable.
The key design decision is that GPT-4o returns structured JSON, not prose. Each response comes back with a fixed schema: theme, sentiment, nps_bucket, priority, summary, and should_create_issue. Because the model output is structured, the downstream nodes can branch, filter, and map fields without any fragile text parsing. That single choice is what makes the automation reliable enough to run unattended.
Step-by-step setup in n8n
Here's the node-by-node build. The whole thing is seven nodes.
1. Schedule Trigger. Add a Schedule Trigger node set to run once daily — 07:00 is a good slot so tickets are waiting when the team logs in. If you'd rather process feedback the moment it arrives, swap this for a Webhook node and point your survey tool's webhook (Delighted, Typeform, Tally) at the n8n production URL.
2. Fetch responses. Use an HTTP Request node (or the native Google Sheets / Postgres node if your responses live there). Query only rows created since the last run — pass a since timestamp so you never reprocess. If you're hitting a survey API, authenticate with a Header Auth credential and page through results. Store the last-run timestamp in a Set node or a static-data field so each run is idempotent.
3. Split Out. Feed the array of responses into a Split Out node (or Loop Over Items if you want batching). This turns one API response containing 40 rows into 40 individual items, so each response is classified independently.
4. GPT-4o classification. Add the OpenAI node (Message a Model) or a bare HTTP Request to https://api.openai.com/v1/chat/completions. Set the model to gpt-4o, temperature to 0 for consistent tagging, and turn on JSON mode with response_format: { "type": "json_object" }. Your system prompt should pin the contract:
"You classify product feedback. Return JSON only. Fields: theme (one of: onboarding, pricing, performance, bug, feature_request, support, other), sentiment (positive|neutral|negative), nps_bucket (promoter|passive|detractor based on the score), priority (P0|P1|P2|P3), summary (one sentence), should_create_issue (boolean — true only for actionable bugs, feature requests, or detractor complaints)."
Pass the response text and the numeric NPS score in the user message. Because temperature is 0 and the schema is fixed, two identical responses always get identical tags — which matters when you're grouping themes over time.
5. Filter. Add a Filter node with the condition should_create_issue = true. Promoters and low-signal "everything's great" responses drop out here. This is where you avoid flooding Linear with noise — typically only 20–40% of responses pass.
6. Deduplicate (optional but recommended). Before creating issues, add a Code node or a Merge against existing open issues. Query Linear for open issues with the same theme label and, if one exists, append a comment ("+1 from NPS response, score 3") instead of opening a duplicate. This keeps the same recurring complaint as one ticket with a rising count, not 18 separate tickets.
7. Create Linear issue. Use the native Linear node (Create Issue). Map the title from GPT-4o's summary, the description to the full verbatim plus the original score, the priority field from the model's priority output, and add a label matching the theme. Route detractor responses to a specific team or project so customer-facing owners see them first. Authenticate with a Linear API Key credential from your workspace settings.
Connect the nodes in order, run once manually against a small batch to verify the JSON contract holds, then activate the workflow.
The benefits: signal, speed, and a paper trail
Once this runs, three things change. First, every response gets read — not the ones someone had time for, all of them. Your NPS number stops being a lonely metric and becomes a live queue of specific, tagged, prioritized work.
Second, detractors get caught fast. A score of 2 with an angry verbatim becomes a P1 ticket in the right team's queue the same morning, not three weeks later during a quarterly review. That speed is the difference between saving an account and reading its churn note.
Third, patterns become visible. Because themes are tagged consistently by a zero-temperature model, you can count them. Fifteen tickets labeled onboarding in one week is an argument for a roadmap decision — an argument you literally could not make when the verbatims were unread. The workflow turns qualitative feedback into something you can sort, count, and act on.
Common pitfalls and how to avoid them
Skipping JSON mode. If you let GPT-4o answer in prose, you'll spend more time debugging string parsing than you saved on reading. Always use response_format: json_object and validate the shape in a Code node before the Filter — if a field is missing, route that item to a fallback rather than crashing the run.
Reprocessing old responses. The most common failure is a trigger that pulls the entire table every run and re-creates every issue daily. Track a last-run timestamp and query only newer rows. Test idempotency by running twice in a row — the second run should create zero issues.
Flooding Linear. Without the dedup step, one viral complaint generates dozens of tickets and your team learns to ignore the queue. The append-a-comment-on-match pattern keeps one ticket per theme and makes the count itself the priority signal.
Trusting the model on priority blindly. GPT-4o is good at theme and sentiment; it's weaker at your specific business priority. Anchor the priority rubric in the system prompt with concrete examples ("a detractor mentioning cancellation is always P0/P1") rather than leaving "priority" undefined. Review the first week of tickets and tighten the prompt where the model over- or under-rated.
Rate limits on large batches. If you dump 500 responses through the OpenAI node at once, you'll hit rate limits. Use Loop Over Items with a batch size of 10–20 and a small Wait node between batches, or enable n8n's built-in retry on the OpenAI node so transient 429s self-heal.
Build this once and your feedback stops rotting in a spreadsheet. Every morning the useful signal is already sorted, tagged, and sitting in Linear — and the four-hour job nobody wanted is a workflow nobody has to think about.
Ja construimos isso pra voce
Nao comece do zero. O Product Feedback & NPS Analyzer — GPT-4o Categorizes Every Response and Creates Linear Issues e um workflow n8n pronto para instalar — conecta suas ferramentas em minutos, sem codigo.
Instalar por $49 →
