To turn customer feedback into an action plan with AI, run it as a chain of separate prompts rather than one: first clean and tag the raw comments, then group them into themes with counts and quotes, then score each theme on how many customers it affects and how badly, and only then ask for actions with owners and dates. Asking for recommendations straight from raw feedback gives generic advice; asking after the themes are counted and scored gives a plan you can defend. The prompts below cover each step, with a worked example.
The workflow works for support tickets, app-store reviews, NPS comments, survey open-ends and sales-call notes. It suits batches from a few dozen to a few hundred comments per run; past that, split the batch and merge the theme lists.
Why feedback reviews stall, and what the AI should and should not do
Feedback reviews stall because the raw material is scattered and repetitive. Comments live in a helpdesk, a review site, a survey tool and a sales CRM; reading them all takes hours, so teams skim a sample, remember the loudest complaint and call it a priority.
An AI model is good at the slow, mechanical part: reading every comment, grouping similar ones, counting them and pulling representative quotes. It is weak at the parts that need knowledge it does not have: how hard a fix is in your codebase, what your team’s capacity is, which customers are strategically important. A good prompt chain gives the model the first job and keeps humans in charge of the second. Every prompt below leaves explicit slots for information only you can supply.
Step 0: prepare the input
Preparation means putting every comment in one consistent format before any analysis prompt sees it. Five minutes here prevents most bad output later.
- One comment per line, with an ID. IDs let you trace every theme back to real comments and spot when the model invents one.
- Keep useful metadata. Source (ticket, review, survey), date, plan or customer segment, and a rating if there is one. Segment is what later lets you say “this hurts enterprise accounts” instead of “some users”.
- Remove personal data. Strip names, emails, phone numbers and account numbers before pasting into any AI tool, and check that the tool is approved under your company’s data policy.
- Do not pre-filter by sentiment. Positive comments tell you what to protect. You can separate them later.
A workable line format looks like this: F-031 | survey | 2026-09-14 | Pro plan | 6/10 | Export to CSV keeps timing out on big projects.
Step 1: tag each comment
Tagging means labeling every comment individually before grouping, so that the themes are built from evidence rather than from the model’s first impression of the batch.
<feedback>
[paste comments, one per line: ID | source | date | segment | rating | text]
</feedback>
Context: we are [product/company, one sentence]. Our customers are [who].
For every comment above, output one row in a table with these columns:
ID | Sentiment (positive / negative / mixed / neutral) | Type (bug, missing feature, usability, performance, pricing, support experience, praise, other) | Specific issue in 3-8 words | Mentions churn or switching? (yes/no)
Rules:
- One row per comment ID. Do not skip any; the table must have exactly as many rows as there are comments.
- If a comment raises two separate issues, output two rows with the same ID.
- Describe the issue in the customer's terms, not in a guessed technical cause.
- "Mentions churn" is yes only if the customer says they are leaving, canceling, downgrading or looking at alternatives.The row-count rule is a cheap completeness check: if you pasted 120 comments and got 104 rows, the model skipped some. The churn column matters because “I’m moving to a competitor” is a stronger severity signal than any adjective the model could assign. If you plan to load the table into a spreadsheet, ask for CSV or JSON instead; the guide to getting structured JSON output from AI models covers how to make that reliable.
Step 2: cluster the tags into themes
Clustering is the AI version of affinity diagramming, a research technique the Nielsen Norman Group describes as organizing related observations into distinct clusters. Working from the tagged table instead of the raw text makes the clusters more consistent.
Using the tagged table from the previous step, group the rows into themes.
For each theme output:
- Theme name: a specific problem statement (e.g. "CSV export fails on large projects"), not a category ("Export issues").
- Count: number of distinct comment IDs in the theme.
- IDs: the full list.
- Segments affected, with counts per segment.
- Churn mentions: how many IDs in this theme had churn = yes.
- 2-3 representative quotes, copied exactly, each with its ID.
Rules:
- A comment can belong to at most two themes.
- Put comments that fit nowhere in a theme called "Unclustered" rather than forcing them in.
- Do not merge themes just because they share a product area; merge only when customers describe the same underlying problem.
- Sort themes by count, highest first.What to check before moving on
- Theme names are problems, not areas. “Onboarding” is not actionable; “New users can’t find where to invite teammates” is.
- Quotes are real. Search for two or three quotes in your source. If one does not exist word for word, rerun the step.
- Counts add up. The sum of theme counts should be close to the number of comments (higher if some belong to two themes, never wildly higher).
- “Unclustered” is not huge. If a third of comments are unclustered, the themes are too narrow; ask the model to propose broader groupings for them.
Step 3: score the themes
Scoring turns a sorted list of complaints into a ranked list of problems, and the model can only do half of it. Frequency and churn signals come from the data; effort and strategic value come from you. A simple way to combine them is the RICE method published by Intercom, which multiplies reach, impact and confidence, then divides by effort, with impact on a fixed scale (3 for massive down to 0.25 for minimal) and effort in person-months.
Here are the themes from the previous step. Here is what I know that you don't:
<team_input>
Total active customers in the period: [number]
Feedback volume in the period: [number] comments
Effort estimates from engineering (person-months): [Theme A: 0.5, Theme B: 2, ...]
Strategic notes: [e.g. "Enterprise segment is our growth priority this half", "Theme C is already on the roadmap for November"]
</team_input>
For each theme, fill in this table:
Theme | Count | Churn mentions | Reach estimate | Impact (3/2/1/0.5/0.25) | Confidence (100/80/50%) | Effort (from team_input) | Score = Reach x Impact x Confidence / Effort | Reasoning (one sentence)
Rules:
- Reach: estimate customers affected per quarter. State how you derived it from the count and volume, and mark it as an estimate.
- Impact: base it on what customers describe (blocked from core task = 2 or 3; annoyance = 0.5 or 0.25) and on churn mentions.
- Confidence: 100% only if the theme has many comments from several segments; 50% if it rests on a handful of comments or one loud customer.
- If an effort estimate is missing for a theme, write "needs estimate" and do not compute a score.
- After the table, list any theme where a high count is driven mainly by a single segment or a single week, since that may be a temporary spike.The “needs estimate” rule is deliberate. A model that cannot see your codebase will happily guess that a fix is “low effort”, and a ranking built on guessed effort looks rigorous while being made up. Get the estimates from the people who would do the work. Reach is still an estimate, because feedback comes mostly from customers motivated enough to write; treat it as a relative signal across themes, not a headcount.
Step 4: draft the action plan
The action plan prompt runs only on the top-ranked themes, which keeps the output concrete. Three to five themes per cycle is a realistic number for most teams.
Take the top [3] themes by score. For each one, write:
1. Problem statement: one sentence, in the customer's terms, with the count and a quote ID.
2. Proposed action: the smallest change that would resolve most of the complaints in this theme. If the right action is to investigate first (e.g. reproduce a bug, interview 5 customers), say so.
3. Owner team: product, engineering, support, docs, billing, or success. One team owns it; others can be listed as contributors.
4. Success measure: what we will observe if it worked (e.g. "tickets tagged CSV export drop below 5 per month"), using data we already collect: [list your metrics].
5. Quick mitigation: something support or docs can do this week while the real fix is built (help article, macro reply, workaround).
6. Customer follow-up: who to tell when it ships, using the IDs and segments in the theme.
Do not propose actions for themes outside the top [3]. Do not invent metrics we do not collect.The quick-mitigation field is often the most immediately useful output: most fixes take weeks, but a help-center article or a support macro can reduce the pain within days. The customer follow-up field closes the loop, which is what makes customers keep giving feedback. If some of the themes come from public reviews, pair this with the prompts for responding to negative reviews.
Worked example: 140 comments from one quarter
The following is an illustrative example with made-up data for a fictional project-management app. It shows what the chain’s output looks like at each stage, not a real result.
After tagging and clustering, the four largest themes were:
| Theme | Count | Churn mentions | Main segment | Impact | Confidence | Effort (team) |
|---|---|---|---|---|---|---|
| CSV export times out on large projects | 23 | 4 | Business plan | 2 | 100% | 1 |
| Mobile app logs users out daily | 31 | 1 | All plans | 1 | 80% | 0.5 |
| Want Gantt view | 18 | 3 | Business plan | 1 | 80% | 4 |
| Invoices missing VAT number field | 9 | 2 | EU customers | 2 | 80% | 0.5 |
Sorting by count alone would put the mobile logout first and the VAT field last. Scored with reach, impact, confidence and effort, the small but blocking VAT issue moves up because it is cheap and stops EU customers from expensing the product, while the Gantt request drops because it is a large build with moderate impact. The CSV export issue stays near the top because it blocks a core task and carries the most churn mentions.
The resulting plan for the quarter, in this example, would be: fix the VAT field (billing team, quick mitigation: support sends a manual invoice on request), fix mobile session expiry (engineering, mitigation: help article on staying signed in), and investigate CSV export limits (engineering, mitigation: support macro recommending filtered exports). The Gantt request goes to the product team’s discovery backlog with its 18 IDs attached for later interviews.
Making it repeatable every month
The chain becomes much more valuable when it runs on a schedule with the same theme names each time, because then you can see whether a theme is growing or shrinking after a fix ships. Three practices make that work.
- Carry the theme list forward. In the clustering prompt for the next batch, paste last month’s theme names and add: “Assign comments to these existing themes where they fit; create new themes only for problems not covered.” Without this, the model renames themes each run and trends become impossible to read.
- Save the prompts as versioned templates. Store the four prompts with placeholders in a shared document or repository so anyone on the team can run them the same way. The guide on building a prompt library for your team covers how to keep them maintained.
- Keep the steps separate. Running tagging, clustering, scoring and planning as distinct calls is a form of prompt chaining: you can inspect each output, fix a bad cluster before it reaches the plan, and rerun one step without redoing the others.
If the feedback arrives through a helpdesk, the same tagging logic can run at intake; the prompts for triaging support tickets by urgency and category apply the idea ticket by ticket.
Common mistakes
- Asking for “insights and recommendations” in one prompt. The model skips counting and jumps to familiar advice (“improve onboarding”, “communicate better”). Count first, recommend last.
- Treating counts as market share. Twenty complaints about one feature does not mean twenty percent of customers have the problem. Feedback is self-selected; use counts to compare themes against each other.
- Letting the model estimate effort. It has no view of your systems. Use the “needs estimate” rule.
- Ignoring positive feedback. Praise clusters tell you what not to break during a redesign. Run them through the same clustering step and keep the list next to the action plan.
- Mixing very different sources without labels. Sales-call notes describe prospects’ objections, support tickets describe current users’ failures. Keep the source column so you can filter themes by source.
- Never closing the loop. The IDs in each theme are a list of people to tell when the fix ships. Using it is what turns feedback collection into a relationship.
How much feedback you need, and when to use a dedicated tool
Clustering is worth running once you have more comments than you can comfortably read and compare in one sitting; below a couple of dozen, reading them yourself is faster and loses nothing. For a few hundred comments a month, a general-purpose model with these prompts is usually enough. When feedback arrives continuously in the thousands, a dedicated feedback-analytics platform that tags at intake and tracks themes over time becomes the better fit, and these prompts are still useful for the periodic deep-dive on its top themes.
For lost-deal feedback specifically, where the question is why prospects chose someone else, the structure in win-loss analysis with AI prompts fits better than a product-feedback chain.
