How to Automate Product Feedback & NPS Analyzer — GPT-4o Categorizes Every Response and Creates Linear Issues with n8n
Every NPS survey response is a signal — and most of them rot in a spreadsheet no one opens. You launch the survey, responses trickle in, and within a week you have 200 rows of free-text feedback that
Every NPS survey response is a signal — and most of them rot in a spreadsheet no one opens. You launch the survey, responses trickle in, and within a week you have 200 rows of free-text feedback that nobody has time to read line by line. The "9s and 10s" get a mental high-five, the "0 to 6s" get ignored until one of them churns, and the actual themes — the recurring complaint about onboarding, the three people asking for the same integration — never surface until it's too late to act cheaply.
This article shows you how to build an n8n workflow that reads every single response, uses GPT-4o to categorize the theme, classifies each respondent as a detractor, passive, or promoter, and automatically opens prioritized issues in Linear — so your product backlog reflects what customers actually said, not what you remembered from skimming.
The problem: feedback volume outruns human attention
NPS math is deceptively simple: percentage of promoters (9–10) minus percentage of detractors (0–6). The score is trivial. The value is in the comments — and that's exactly the part that doesn't scale.
Manual triage fails in three predictable ways. First, it's inconsistent: whoever reads the responses this month categorizes "the app is slow" differently than last month's reader, so you can't trend anything. Second, it's slow: by the time someone batches through 300 comments, the detractor who wrote "canceling next month unless X" has already churned. Third, it dies in the gap between insight and action: even when someone spots a theme, translating it into a tracked, prioritized engineering ticket is a separate manual step that rarely happens. The feedback and the backlog live in two different worlds.
The result: you're paying to collect signal you never process. A workflow fixes all three failure modes at once — consistency, speed, and the handoff into your issue tracker.
The solution: a daily pipeline from response to prioritized issue
The workflow runs on a schedule (daily is the sweet spot) and moves each response through a fixed pipeline:
- Ingest new NPS responses since the last run.
- Classify the score into detractor / passive / promoter deterministically.
- Categorize the theme with GPT-4o — onboarding, pricing, performance, missing feature, bug, support, UX — plus a one-line summary and a severity read.
- Route: detractors with actionable complaints become Linear issues; promoters get logged for testimonials; passives get themed for trend analysis.
- Deduplicate and prioritize so ten people complaining about the same thing become one high-priority issue, not ten tickets.
Because GPT-4o applies the same categorization prompt to every response, you get the consistency a rotating human reviewer can never deliver. And because the last step writes directly to Linear, the insight lands where your team already works.
Step-by-step setup in n8n
Here's the node-by-node build. The whole thing is around a dozen nodes.
1. Schedule Trigger. Set the Schedule Trigger node to run once daily — 07:00 works well so themes are waiting when the team logs on. Store the last-run timestamp so you only pull new responses.
2. Fetch responses. Add an HTTP Request node pointed at your survey tool's API (Typeform, Delighted, SurveyMonkey, or a Google Sheets export). Use the since or submitted_at parameter with the stored timestamp so each run is incremental. If your source is a sheet, swap in the Google Sheets node with a "read rows" operation filtered on a "processed" flag.
3. Split into items. Use a Split Out (or Item Lists) node so each response becomes its own item and flows through the rest of the pipeline independently.
4. Score classification. A Code or IF node buckets the numeric score deterministically — score <= 6 → detractor, 7–8 → passive, 9–10 → promoter. Keep this out of the LLM; it's exact math and you don't want to pay tokens or risk hallucination for a comparison.
5. GPT-4o categorization. Add the OpenAI node (or a generic HTTP Request to the Chat Completions endpoint) with model gpt-4o. Set temperature to 0 for stable categories and request a JSON response. Your system prompt should pin the taxonomy explicitly:
"You categorize product feedback. Return strict JSON with: category (one of: onboarding, performance, pricing, missing_feature, bug, support, ux, other), summary (one sentence), severity (low/medium/high), and actionable (boolean). Respond with JSON only."
Pass the raw comment as the user message. Enabling response_format: json_object keeps the output parseable. Feeding the closed taxonomy is what makes results trend-able — free-form categories drift and can't be counted.
6. Parse and merge. Use a JSON/Set node to flatten the model output into clean fields alongside the score bucket, respondent email, and timestamp.
7. Route by segment. A Switch node branches on the score bucket. Detractors and any high-severity actionable feedback go to the Linear branch. Promoters route to a "testimonials" sheet or Slack channel. Passives get appended to a themes log for weekly trend review.
8. Deduplicate before creating issues. Before writing to Linear, query existing issues via the Linear node (or the GraphQL API through HTTP Request) filtered by category label. If an open issue with the same category already exists, use an Update operation to increment a count and bump priority instead of creating a duplicate. This single step is the difference between a useful backlog and 200 noise tickets.
9. Create the Linear issue. The Linear node's "Create Issue" operation takes a team ID, title, description, and priority. Build the title from the summary ([Feedback] Slow dashboard load — 4 detractors), put the raw quotes and NPS scores in the description, map severity to Linear priority (high → Urgent/High), and attach a label matching the GPT-4o category so issues stay filterable.
10. Mark processed. Write the new last-run timestamp back to your state store (a Set node feeding a small data store, or a "processed" column update) so the next run doesn't reprocess the same responses.
The benefits: consistency, speed, and a backlog that reflects reality
Once this runs, a few things change immediately. Every response gets read — not skimmed, read and categorized — the same way, every day. Detractors turn into tickets within hours, not weeks, which is often the window where an at-risk account can still be saved. Themes become countable: because the taxonomy is fixed, you can finally answer "what's the #1 complaint this quarter?" with a number instead of a hunch.
The compounding win is prioritization. When the workflow increments a count on an existing issue instead of spawning a new one, your Linear board naturally sorts by how many customers raised each problem. Your roadmap stops being driven by whoever complained loudest in the last meeting and starts being driven by aggregated signal. For a small ops or product team, that's the difference between reactive and deliberate.
Common pitfalls (and how to avoid them)
Letting the LLM classify the score. Don't. Numeric bucketing is exact math — do it in a Code node. Reserve GPT-4o for the one thing only it can do: understanding free text.
Skipping deduplication. Without the dedupe step, a spike of similar feedback floods Linear and your team learns to ignore the whole label. Always check for an existing open issue by category first.
Open-ended categories. If you don't pin the taxonomy in the prompt, GPT-4o will invent slightly different category names each run ("speed" vs "performance" vs "slowness") and you lose all trend-ability. Enumerate the allowed categories and set temperature: 0.
No incremental cursor. Forgetting to store and filter on a last-run timestamp means every run reprocesses old responses — duplicate issues and wasted tokens. Persist the cursor and mark rows processed.
Unhandled API errors. Add error handling on the OpenAI and Linear nodes (n8n's "Continue On Fail" plus an error branch to Slack) so one malformed response or a rate limit doesn't silently drop a batch of feedback.
Ignoring promoters. Detractors get the attention, but routing promoters to a testimonials log gives marketing a steady supply of social proof for free. Don't let that branch dead-end.
Build it once and NPS stops being a vanity number you check monthly — it becomes a live input to your roadmap that runs itself every morning before you've had coffee.
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 →
