How to Actually Use Customer Feedback in SaaS (Not Just Collect It)
Collection is the easy half. This is the other half: coding language into data, weighting by revenue, writing down the noes, and closing the loop.
There is a specific moment where feedback programmes die, and it is not the moment anyone expects. It is not that nobody responds. It is not that the answers are vague.
It is the planning meeting six weeks later, where someone says “a lot of customers have been asking for X” and someone else says “really? I keep hearing Y”, and the person who argues most confidently wins. The feedback was collected. It just never became evidence.
Converting language into evidence takes four specific mechanisms: a coding scheme, a weighting formula, a decision log that records refusals, and a loop-closure habit. None of them are software. All of them are unglamorous.
This is the operating system for the half of the problem nobody sells you a tool for.
TL;DR
- Code on two axes: what the feedback is about, and what class of change would fix it. Single-axis taxonomies rot within a quarter.
- The most under-counted cell in SaaS is discoverability × teach — routinely mis-tagged as capability-missing × build, so teams rebuild features they already shipped.
- Weight by MRR, not frequency. Frequency ranking systematically favours your cheapest and loudest users.
- Keep the verbatim attached to the theme forever. A theme that lost its verbatims cannot win a roadmap argument.
- Record why you said no. It is the field that stops the same theme being re-litigated every quarter.
The Gap Between Collected and Used
Spain and Groysberg's Harvard Business Review study of exit interviews found something that transfers directly to customer feedback: organisations run the programme, collect the data, and then fail at the acting-on-it stage — because nobody owns the output and no mechanism converts it into a decision.
The symptoms are recognisable:
- Feedback lives in five tools and nobody has a combined view.
- Themes are named differently by different people, so nothing aggregates.
- Prioritisation arguments resolve by seniority or volume, not evidence.
- The same request gets re-argued every quarter because nobody wrote down the last decision.
- Customers who gave feedback never hear anything, so they stop giving it.
Feedback becomes evidence when it can survive a disagreement. Everything below is designed for that one moment: someone in a planning meeting says “I don't think that's a real problem”, and you can answer it.
Coding: Two Axes, One Primary Tag
Rule zero: a verbatim can carry several tags but exactly one primary tag. Multi-primary tagging is how taxonomies rot — within three months everything is tagged “UX” and the counts mean nothing.
Axis 1 — What is it about?
| Tag | Definition | Example verbatim |
|---|---|---|
| capability-missing | The product cannot do a thing they need | "There’s no way to bulk edit" |
| capability-broken | It can, but it fails or is unreliable | "The export times out over 10k rows" |
| discoverability | It can, they never found it | "I didn’t know that existed until support told me" |
| effort | It can, it costs too much to do | "Four clicks every single time" |
| fit | Product is not for their situation | "We’re an agency, this is built for in-house" |
| price-value | Value does not justify cost | "It works, it’s just not $200-a-month good" |
| price-budget | Value fine, money unavailable | "We lost the budget line in the reorg" |
| trust | Reliability, security, support, vendor risk | "Third outage this quarter" |
| external | Nothing to do with you | "We got acquired and moved to their stack" |
Axis 2 — What class of change would fix it?
| Tag | Owner | Typical fix |
|---|---|---|
| build | Product | New capability or rebuilt flow |
| fix | Engineering | Bug, performance, reliability |
| teach | Lifecycle / docs | Onboarding, in-app guidance, docs |
| position | Marketing | Landing page, pricing page, qualification |
| package | Commercial | Plan boundaries, price, contract terms |
| none | Nobody | Genuinely out of scope — log and move on |
Two axes rather than one, because single-axis schemes conflate the problem with the solution — and the conflation is where the expensive mistakes live.
The Cell Everyone Mis-Tags
2
Axes, one primary tag each
9 × 6
Cells in the matrix — most teams use four
1
Cell that causes the most wasted engineering
0
Features you should rebuild before checking this
The cell is discoverability × teach, and it is routinely mis-tagged as capability-missing × build.
The mechanism is simple. A customer says “there's no way to export to CSV”. Whoever codes it hears a missing feature and tags it build. Six weeks later someone points out that CSV export shipped last year, it is behind a menu, and nobody found it.
The verbatim was accurate about the customer's experience and wrong about your product, and both facts matter. Tagged as build, it becomes a duplicate feature. Tagged as discoverability × teach, it becomes a two-hour change to a menu label — which is a considerably better return on the same insight.
Before any verbatim gets tagged capability-missing, someone who knows the product confirms the capability genuinely does not exist. It takes thirty seconds and it is the single highest-return step in the whole coding process.
Weighting by Revenue, Not Frequency
theme_weight = Σ (MRR of each account raising it) × segment_multiplier × recency_decay
Three deliberate choices in that formula:
MRR sum, not account count. Ten accounts at $20 is not the same signal as one at $2,000 — and the reverse is also true. Neither ranking is automatically correct. The point is to decide which you mean before you look at the data, rather than after, when the answer is already visible.
Segment multiplier above 1 only for the segment you have decided to win. If you cannot name that segment in one sentence, use 1 and accept that you currently have no strategy filter. That is a more useful admission than a made-up multiplier.
Recency decay. Feedback older than two quarters describes a product you no longer ship. Halve it. This also stops long-dead themes accumulating weight forever simply by existing.
And track at-risk MRR separately from churned MRR. A theme raised only by accounts that already left is history. The same theme raised by active accounts is a fire — and the at-risk number is nearly always the larger one, which is exactly why frequency-ranked lists under-prioritise the right work.
Why the Verbatim Column Is Non-Negotiable
Keep the exact sentence attached to the theme, permanently, and make it reachable from wherever the theme is displayed.
The reason is not sentimental. It is that aggregated themes persuade nobody and one exact sentence ends the argument. “Fourteen accounts mentioned onboarding friction” invites debate about what counts as friction. “A $1,400-a-month customer said: I set it up twice and both times the import dropped our custom fields” does not.
“A thoughtful exit interview can catalyze leaders' listening skills, reveal what does or doesn't work inside the organization, and highlight hidden challenges and opportunities.”
This is also why any analysis tool that gives you themes without a path back to the raw response is worth less than it appears — a point worth checking against the vendor scorecard before you buy one.
The Decision Log, and the Field That Matters
| Field | What goes in it | Why |
|---|---|---|
| Theme | Topic tag + one line | Stable name so it aggregates |
| Weight | Computed above | Comparable across themes |
| Accounts | Count and names | So you can go back and ask |
| Best verbatim | One exact sentence | Ends arguments |
| Response class | build / fix / teach / position / package | Routes to the right owner |
| Decision | Doing / not doing / waiting | Forces a call |
| Reason for not doing | Required when declining | Stops re-litigation |
| Owner | A person, not a team | Teams do not do things |
| Loop closed | Date you told them | Feeds next quarter’s response rate |
The reason for not doing field is the one that changes how a company works. Without it, every theme you declined returns next quarter, argued by whoever heard it most recently, and the meeting becomes a memory contest. With it, the conversation becomes “has anything changed since we decided no?” — which is a five-minute conversation instead of a forty-minute one.
Note the owner field says a person. Themes assigned to “Product” do not get done. Themes assigned to a named human sometimes do.
Feedback Tagging Taxonomy & Decision Log
The full two-axis scheme with definitions and example verbatims, the weighting formula, and the decision log schema including the field that stops re-litigation.
- Nine topic tags and six response-class tags, with example verbatims for each
- The discoverability × teach trap and how to catch it
- The weighting formula with guidance on each multiplier
- A ten-field decision log schema
- The three loop-closure tiers and a thirty-minute review agenda
Closing the Loop, Three Tiers
Shipped — tell everyone who raised it
Email every account that raised the theme. Name the person if they are still a customer. Reply rates on these are unusually high and they are the best expansion trigger you have, because you are demonstrating that talking to you does something.
Declined — tell them, with the reason
Uncomfortable exactly once, then it buys you enormous credibility. Customers do not expect a yes; they expect to be heard. Almost no vendor sends this message, which is precisely why it lands.
Churned over something you fixed — win back with evidence
Return with the fix, not a discount. This list converts far better than a discount campaign because you are arriving with proof rather than desperation. The people on it told you what would have kept them; you did it.
The mechanism worth understanding: loop closure is not politeness, it is the input to next quarter's response rate. People who see their feedback land will answer you again. People who send feedback into a void stop sending it, and your data quality degrades silently over about two quarters.
The Thirty-Minute Monthly Review
| Agenda item | Time | Output |
|---|---|---|
| New themes since last month | 5 min | Added to the log |
| Top five by weight | 10 min | What changed and why |
| Decisions | 10 min | Doing / not doing / waiting, one line each |
| Loop closure | 5 min | Who did we tell |
Ban slide decks. If a theme needs a deck to be persuasive, what it actually needs is a verbatim — and if it does not have one, it is not ready for this meeting.
Thirty minutes is not an aspiration, it is a constraint that forces the preparation to happen beforehand. A ninety-minute feedback review is a review where the coding was done in the room, and coding done in the room is coding done by whoever is loudest.
For where this sits in the wider system, see the seven-stage feedback architecture; for the churn-specific version with MRR prioritisation, see the churn feedback loop framework.
Frequently asked questions
- How do you prioritise conflicting customer feedback?
By weighting rather than arbitrating. Sum the MRR behind each theme, apply a multiplier for the segment you have decided to win, decay anything older than two quarters, and compare the numbers. Conflicting feedback usually stops conflicting once you notice the two groups are different segments — at which point the question becomes which segment you are building for, which is a strategy question rather than a feedback question.
- Who should own customer feedback analysis?
One named person with authority to change the roadmap. The common failure is assigning it to whoever configured the tools — usually support or growth — which leaves the decision and loop-closure stages orphaned, because those people cannot commit engineering time. Analysis without authority produces reports, not changes.
- How often should we review customer feedback?
Monthly for the themes, continuously for the verbatims. The monthly cadence is fast enough to catch a trend and slow enough that the coding gets done properly beforehand. Weekly reviews tend to degrade into reading whatever arrived that week, which is how recency bias gets institutionalised.
- Should we tell customers when we decide not to build something?
Yes, and it is the most under-used message in SaaS. Customers do not expect to get everything they ask for — they expect to be told. An explained no is remembered far more positively than indefinite silence, which readers correctly interpret as a no anyway, but with added resentment at having been ignored.
Sources & further reading
- 1Making Exit Interviews Count — Harvard Business ReviewSpain & Groysberg on why organisations collect feedback and fail to act on it.
- 2Why 5 Participants Are Okay in a Qualitative Study, but Not in a Quantitative One — Nielsen Norman GroupOn what qualitative feedback can and cannot be used to size.
- 3Continuous Product Discovery — Teresa Torres — The Product FolksOn making discovery a continuous habit rather than a periodic project.
- 4SaaS Retention Report — ChartMogul
Keep reading
Coded, weighted, and back in 48 hours.
saasfeedback.ai returns themes already tagged on both axes, weighted by the MRR behind them, with every verbatim still attached. You run the decision log.
Book a demo