The Customer Feedback Loop: How to Collect, Prioritise and Actually Close It

Every company collects customer feedback. Almost none of them close the loop.

The collecting part is easy, and that is precisely the problem. Requests arrive through support tickets, sales calls, a shared inbox, three different Slack channels, the founder's DMs, and a spreadsheet somebody made in 2023 that four people still update. None of it is wrong, exactly. It is just that none of it adds up to an answer when someone asks the only question that matters: what should we build next, and how do we know?

The feedback loop is the discipline that turns that noise into a decision and then reports the decision back to the people who raised it. It has four parts, and teams reliably fail at the last two:

1. Capture — get the request out of the conversation and into one place.
2. Consolidate — merge the duplicates so you can see true demand.
3. Prioritise — rank by something defensible, not by who asked most recently.
4. Close — tell the people who asked, when it ships.

This guide covers all four in working detail: the mechanics that make each one survive contact with a real team, the failure modes that quietly break them, and how to tell whether yours is actually working. It assumes you are a small-to-mid-sized product team without a dedicated research function — the case where the loop most often falls apart, because nobody owns it.

Part one: capture, without drowning

The two-inbox problem

Feedback arrives in two fundamentally different shapes, and conflating them is the first mistake.

Solicited feedback is what you get when you ask: a portal where customers post ideas, a survey, an interview. It is structured, it is attributable, and it arrives in a form you can act on. Its weakness is bias — the people who fill in your portal are your most engaged users, not your most representative ones. The customer about to churn does not file a feature request; they just leave.

Unsolicited feedback is what shows up in the course of doing business: a support ticket that ends with "it would be great if…", a sales call where the prospect asks whether you do X, a frustrated message in a shared channel. This is where the honest signal lives. Its weakness is that it is buried in conversations nobody re-reads.

A feedback system that only handles the first kind will show you a tidy, ranked list of what your power users want, and miss the thing that is costing you deals. A system that only handles the second will drown you.

You need both, and you need them landing in the same place.

Make the portal the path of least resistance

If posting a request is harder than sending a message to your account manager, people will send the message. That is not a discipline problem; it is a design problem.

The mechanics that matter:

No account required. Every field you put between a person and their idea costs you ideas. A public portal where someone can type a title, add a sentence of detail, and hit post — with an optional email — collects dramatically more than one behind a login. Identify the visitor with a key in their browser so their own votes and posts are recognised when they come back, and treat the email as a bonus rather than a gate.

Duplicates caught at the moment of typing. The single highest-leverage feature in a feedback tool is suggesting similar existing requests while someone types the title. It is worth more than any amount of merging afterwards, because it converts a new duplicate into a vote on an existing request — which is exactly what you want. A person who was about to write "dark theme" sees "Dark mode (127 votes)" and votes instead. You gained signal and lost nothing.

Voting that means something. A vote is a cheap, honest unit of demand. It is not a decision — we will get to that — but it lets a hundred people express a preference in a second each.

Somewhere for the conversation. A request with a comment thread is worth several times one without, because the thread is where you find out what people actually mean. "Add export" turns out to be four different requests once you ask.

Capture the unsolicited half deliberately

The support-ticket half needs a habit, not a tool, though a tool helps.

The habit is: whoever hears it, files it. Not "raises it in the next product meeting" — files it, as a request, with the customer attached. This works only if filing takes under thirty seconds and the person filing does not need to judge whether the idea is good. Judgment is the prioritisation step's job; conflating them means support engineers become gatekeepers and most feedback dies in their heads.

Give support and sales a way to log a request on behalf of a customer, with that customer attached. This matters more than it sounds: it means the request carries the account, which means it carries the revenue, which is what makes the prioritisation step possible later.

If you want to automate this, the modern approach is to have an AI read support and sales conversations and extract requests automatically — this is what Canny's Autopilot does, and for teams whose feedback lives overwhelmingly in Intercom or Gong it can be transformative. But automation is an accelerant, not a substitute. A team without the habit will get an automatically generated pile they still do not read.

What to do about the loudest customer

Every team has one: the account that files fifteen requests a month, all urgent. The instinct is either to give them everything (they are paying) or to start ignoring them (they are exhausting). Both are wrong.

The right move is structural. Because each request carries the account behind it, a single customer filing fifteen requests shows up as one account across fifteen requests rather than fifteen units of demand. The moment you can see that, the loudest customer stops distorting the list. You have not silenced them; you have put them in proportion.

Part two: consolidate

Duplicates are not a tidiness problem

It is tempting to treat merging duplicates as housekeeping — a chore for a quiet Friday. It is not. Duplicates are an accuracy problem, and the inaccuracy runs in one direction: it makes popular things look unpopular.

If "dark mode", "night theme", "dark UI" and "please stop burning my eyes" are four separate requests with 30 votes each, they look like four minor requests. Merged, they are one request with 120 votes, and it is now the top item on your roadmap. You did not change what customers want. You changed whether you could see it.

Merge rules that survive a real team

Merge into the clearest statement, not the oldest. The first person to file is not necessarily the person who described it best. Pick the title a stranger would understand.

Move the votes, but do not double-count. If someone voted for both the duplicate and the survivor, they are still one person. A merge that inflates counts is worse than no merge, because it teaches everyone to distrust the numbers.

Keep the duplicate visible. The person who filed it should be able to find it and see where it went, and the survivor should show what was folded into it. Silently deleting someone's request is a good way to teach them not to file again.

Merge aggressively at the top, loosely at the bottom. Two requests with 100 votes each deserve careful thought about whether they are truly the same thing. Two with one vote each can wait — you have not lost much by leaving them apart, and you will not act on either this quarter.

Categories, tags and the difference between them

Teams routinely collapse two distinct jobs into one taxonomy and then wonder why it is unusable.

Categories are for the customer. They exist so a person filing a request can put it in roughly the right place, and so another person browsing can find it. Keep them few and obvious: "Mobile", "Billing", "Integrations". If a customer would not confidently pick one, you have too many.

Tags are for you. They are internal, they can be messy, and they exist to answer questions later: which requests came from enterprise, which are quick wins, which relate to the migration. Nobody outside needs to see them, which is exactly why they are useful — you can tag something "probably-never" without insulting anyone.

The mistake is exposing your internal taxonomy to customers, or forcing your internal analysis through the customer-facing one.

Part three: prioritise by something defensible

Why vote counts are not a roadmap

Vote counts measure enthusiasm among people who found your portal. They do not measure revenue, strategic importance, effort, churn risk, or whether the request is a good idea. Building the top-voted item every quarter is a way to be led by your most engaged users into a product that serves exactly them.

Votes are an input. Here is what to weigh alongside them.

Revenue: the number that ends arguments

The most useful thing you can attach to a request is the money behind it.

The mechanic: track the companies and people who give you feedback, with their MRR or ARR. Votes carry the customer. Each request then shows the revenue it represents. The list can be sorted by it.

The change this produces in a product meeting is dramatic, and it is not that revenue starts winning every argument. It is that the argument becomes about something. "Customers really want this" is unfalsifiable and therefore unarguable. "This represents $14k of monthly revenue across nine accounts, four of which are up for renewal" is a claim people can engage with, agree with, or push back on with a different number.

It also protects you from the opposite failure. Sometimes the top-voted request represents fifty free users and $0. That is not a reason to ignore it — free users become paying ones, and enthusiasm is a leading indicator — but it should be a visible fact rather than a hidden one.

Segments: the same list through different eyes

A single ranked list assumes all your customers want the same thing. They do not, and the differences are usually the most interesting thing in your data.

A segment is a saved filter over your customers — "paying customers", "enterprise", "on the legacy plan", "promoters" — that you can apply to the whole feedback list. The top request for your free users and the top request for your enterprise accounts are frequently different, and the gap between them is a strategy conversation.

The implementation detail that matters: a segment should be a set of rules over customer attributes (MRR greater than X, plan equals Y), not a hand-picked list of people. Hand-picked lists rot within a month.

Scoring, without the theatre

Prioritisation frameworks — RICE, ICE, weighted scoring — have a bad reputation, usually deserved. The failure mode is a spreadsheet with eleven factors, each scored 1–10 by one person's intuition, producing a number with three decimal places and no more truth in it than a coin flip.

Scoring is useful when it is few factors, honestly weighted, and used as a sort rather than a verdict.

A workable setup: three or four factors that reflect how your company actually decides. Perhaps Revenue (weighted heavily), Reach (how many customers), and Effort (as a cost, subtracting from the score). Score each request quickly and roughly. Sort by the total. Then — and this is the part people skip — read the top twenty and use your judgment, because the score's job was to save you from reading two hundred, not to make the decision for you.

If your scoring model never surprises you, it is not doing anything. If it surprises you and you always overrule it, the weights are wrong. Fix the weights.

The things that should beat the list

Some work belongs on the roadmap regardless of what the feedback says:

• Things nobody asks for because they cannot imagine them. Customers request faster horses with striking reliability. The feedback loop is a superb instrument for improving what exists and a poor one for inventing what does not.
• Foundational work. Nobody votes for the migration that makes the next two years possible.
• Things that are quietly costing you customers. The people churning over an issue are, by definition, not in your portal filing requests about it.

A healthy roadmap is mostly feedback-driven with deliberate exceptions. A roadmap that is entirely feedback-driven has outsourced strategy to whoever fills in forms.

Part four: close the loop

This is the step teams skip, and skipping it silently destroys the value of the other three.

What "closing the loop" actually means

It means the person who asked finds out what happened. Not "the information is available if they go looking" — finds out.

There are three moments worth communicating:

When you decide. A request moving to "Planned" is news to the person who filed it. So is a move to "Not doing" — more on that shortly.

When you start. "In progress" tells someone their request is real, which buys patience.

When you ship. This is the one that matters most and the one most often botched.

The mechanics that make it happen

Communication that depends on someone remembering to send it does not happen. Build it into the workflow instead:

Voting subscribes you. Anyone who voted or commented is following the request by default. No separate "notify me" checkbox, which nobody ticks.

Status changes notify automatically, with a note. When you move a request, you should be able to attach a sentence — "shipping in the next release" — that goes out with the notification. The sentence is what turns a status change into communication.

The changelog links to the requests it ships. This is the highest-leverage connection in the whole system. When you publish an update, link the requests it delivers. Everyone who voted for any of them gets told. The person who asked for something eight months ago and had given up hearing back gets an email saying you built it.

That last moment is worth more goodwill than almost anything else you can do for the same effort. It is also, in most companies, nobody's job — which is why it needs to be automatic.

Saying no properly

Most requests will never be built. Pretending otherwise — leaving everything permanently "Open" — is a slow-motion trust problem. Six months of silence reads as "they do not care", which is worse than a clear no.

A good no has three parts: it is explicit (the status says so), it is explained (one sentence, not a paragraph of corporate language), and it is honest about the category. There is a real difference between "not now", "not unless a lot more people want this", and "this is not the product we are building", and customers respond much better to the specific version.

Teams fear that saying no publicly will upset people. In practice it does the opposite. What upsets people is being ignored. A public "we are not planning to do this, because X" is respected far more often than it is argued with, and it stops the same request arriving every quarter forever.

The public roadmap question

Should your roadmap be public? The honest answer is partly.

A public roadmap that says what you are working on now and what is next is a trust-builder and a sales asset. A public roadmap with dates is a promise-generating machine that will make your engineering team miserable and your customers cynical.

The workable compromise: public columns, private dates. Show "Under review", "Planned", "In progress". Do not show "March". If you must indicate timing, use coarse buckets, and internalise that customers will treat whatever you publish as a commitment no matter how many caveats you attach.

B2B and B2C loops are not the same loop

Most writing about customer feedback quietly assumes one of two very different situations. It is worth knowing which one you are in, because the mechanics that work in one actively mislead in the other.

In B2B, the unit is the account, not the person. Ten votes from ten individuals at one company is one customer wanting something, and treating it as ten is how a single enthusiastic team distorts your entire roadmap. Weight by account, and weight accounts by what they are worth. Equally, a single vote from your largest customer carries information that a hundred votes from free users do not — not because they matter more as people, but because you will find out about the churn either way and you would rather find out now.

In B2C, volume genuinely is the signal. With thousands of users and no account structure, vote counts are a reasonable proxy for demand, and revenue weighting mostly is not available to you. What matters more is segmentation by behaviour: what do the users who stayed twelve months want, versus the ones who left in week two? Those two groups will ask for different things, and only one of those lists tells you how to grow.

The common mistake is running a B2B product on B2C instincts — chasing raw vote counts while your enterprise accounts quietly renew elsewhere — or running a B2C product on B2B instincts, and letting a handful of vocal power users define a product meant for a mass audience.

Internal feedback deserves the same loop

Your own team files feature requests constantly. They just do it in passing, in meetings, in messages that scroll away — and because there is no place for it, the loudest internal voice wins by default, usually whoever spoke to the CEO most recently.

Running internal requests through the same board as customer ones has three effects worth having. It makes internal demand visible rather than political. It lets you see when an internal hunch and customer demand agree, which is the strongest signal you will ever get. And it stops the awkward situation where a support engineer has heard the same complaint forty times and has no way to make that count.

Keep them marked as internal so they never appear on the public portal — your customers do not need to see your team's half-formed ideas — but rank them in the same list. An internal request with no customer demand behind it should have to justify itself against one with real accounts attached.

Measuring whether the loop is working

Four numbers, checked quarterly, will tell you more than any amount of intuition:

Time to first response. How long between a request being posted and a human replying or setting a status. If this drifts past a week, people stop posting. Under two days is excellent; under a week is fine.

Percentage of requests with a status other than "Open". This is your triage health. If eighty percent of your board is untouched, you do not have a feedback system — you have an inbox.

Percentage of shipped work traceable to a request. Of the things you released last quarter, how many were linked to feedback? Neither zero nor a hundred is right. Zero means the loop is decorative. A hundred means you have stopped doing anything customers could not have asked for. Somewhere between forty and seventy is the range most healthy product teams land in.

Repeat request rate. How often does something get filed that duplicates a request you already closed as "not doing"? A high rate means your noes are not visible enough, and every one of those duplicates is a customer who felt ignored.

There is a fifth, softer measure worth tracking informally: what happens when you publish a changelog entry. If linking requests to a release produces replies from customers, the loop is alive. If it produces silence, people stopped believing you were listening some time ago, and the fix is not more collection — it is a few months of visibly closing.

Where the loop breaks, and how to tell

Some diagnostics worth running on your own process:

Duplicates outnumber merges. If your board has four versions of the same request, your top item is not really your top item. Look at whether people see suggestions while typing.

Nothing has ever moved to "Not doing". A board where nothing is ever declined is a board nobody trusts, and probably one nobody reads.

Your changelog does not link to requests. If you ship things and never connect them back, you are doing the work and getting none of the goodwill.

Only your ten most engaged customers appear. Check how many distinct accounts have voted in the last quarter. If it is a handful, your portal is a suggestion box for enthusiasts, not a representative signal.

Feedback lives somewhere your team does not. The most common structural failure. If the feedback tool is a separate product that only the PM logs into, engineers never see it, support stops filing into it, and it slowly becomes a spreadsheet with better styling.

That last one is the argument for keeping feedback in the same workspace as the work. When the request and the board are in the same place, the engineer picking up the ticket can see who asked for it and why — and that context is the difference between building the letter of a request and building what the person actually needed.

A two-week rollout

If you are starting from nothing, this is the shortest path to a loop that works:

Days 1–2. Set up one board. Not five — one. "Feature requests". Add your statuses: Open, Under review, Planned, In progress, Complete, Closed. Decide which of those appear on the public roadmap.

Days 3–4. Seed it. Go through the last three months of support tickets and sales notes and file the requests you find, on behalf of the customers who raised them. A board with forty real requests is credible; an empty board is a ghost town nobody posts in.

Day 5. Add your customers and their revenue. Even roughly. This is the step that will feel like admin and pay for itself the first time you sort by revenue impact.

Week 2, days 1–2. Turn on the portal and tell your customers it exists — in-app, in your newsletter, in support replies. Reply to the first ten posts personally and fast. The tone of the first two weeks sets whether anyone posts in month three.

Week 2, days 3–4. Merge duplicates. Set the top ten requests' statuses honestly, including the ones you are not going to do.

Week 2, day 5. Publish a changelog entry for something you shipped recently and link the requests it covers. Watch what happens when people who asked for it get told. That reaction is the reason to do all of this.

Then hold two recurring commitments: a weekly triage (thirty minutes, merge duplicates, set statuses on new requests) and a changelog entry with every release (ten minutes, link the requests). The loop breaks when those two habits lapse, and essentially never for any other reason.

The point

A feedback loop is not a tool you install. It is a promise you make: tell us what you need, and we will tell you what we did about it. The tooling exists to make keeping that promise cheap enough that you actually keep it.

Most teams fail at the second half of the promise, not the first. They collect diligently and report back never, and then wonder why the same requests keep arriving and why customers stopped bothering. Closing the loop — reliably, automatically, including the noes — is the part that turns feedback from a suggestion box into a relationship.

---

Openbook includes a Feedback room with public boards, voting, duplicate detection and merging, revenue-weighted prioritisation, customer segments, a roadmap with columns you define yourself, and a changelog that notifies everyone who voted for what you shipped — in the same workspace as your Kanban boards, docs and chat. See how it compares to Canny, or read about choosing all-in-one over best-of-breed.