Customer feedback loop: what it is and how to close it

What is a customer feedback loop?

A customer feedback loop is the path a piece of feedback takes from the customer to a decision and back to the customer. It has four stages: collect, decide, build or decline, and tell.

The phrase gets used for surveys and support scores too. This guide is about the product side: feature requests, the public board they live on, and the answer each one is owed. That is where the loop is easiest to see, because a request with no status is visible to everyone who voted on it.

The stage that makes it a loop is the last one. Collecting and deciding are work your team does. Telling is the stage that reaches the customer without them checking back, and it is what shows them the board is worth using.

How do you close the feedback loop?

Give the request a public decision, then tell the person who asked and everyone who voted. Closed means both: a status anyone can see, and an answer that reached people without them checking back.

1. Collect into one place

Requests arrive in support tickets, store reviews, calls and chat. Move each one to a single public record, merge duplicates into it, and keep the asker's email attached, because stage four needs someone to tell. A customer feedback tool with voting does this; a shared spreadsheet does it badly but does it.

2. Decide on a schedule

Pick a weekly slot and give every new request one of four answers: planned, not now, no, or already possible. "Not now" is a real answer. "New" three months later is not. Put the statuses where customers can read them, on the board or a public roadmap.

3. Build it or decline it

Move the status to in progress the day work starts, so voters see movement before the release. If the answer is no, write the reason on the request. Do not mark something planned to stop the emails: a fake "planned" keeps the loop open and makes every other status mean less.

4. Tell the people who asked

Email every voter when the status changes, add a changelog entry that names the request when it ships, and send a personal note to the original asker when the request waited a long time. Telling them at the decision, not only at the release, keeps the loop short: the section on timing below shows how long releases take.

FeatQ is our product, so here is exactly what it does at this stage. When you change a request's status, it emails every voter who opted in, and requests marked done appear on the board's changelog. It has no declined status today, and an admin comment shows on the request but does not email anyone. So for a no on a FeatQ board, post the reason as a comment and reply to the original asker yourself. The customer feedback board use case shows the setup end to end.

How often do teams close the loop?

On the median public board, 62% of requests have no public decision, 22% are marked shipped, and 51% have zero comments (220 boards with exact status counts; 182 boards for comments).

These come from our study of 242 public feature request boards, read on 1 November 2026. Each number is the median across boards: half the boards sit above it, half below.

Read them as a snapshot of the public half of the loop. A team can answer a request in a support thread and never touch the board, and the study cannot see that. What it can see is what a voter sees: on the median board, most requests have no public decision, and about half have no comment from anyone, team or customer.

The data cannot say why, and it cannot say what this costs a team in lost customers. It does show where most requests on the median board sat on the day we read them: at stage two, with no public decision yet. A board that only collects is a suggestion box with a vote counter. We wrote about why feedback boards should ship, not store.

How long does a feedback loop take?

On the median board, shipped requests took 165 days from posting, and unresolved requests have waited 515 days so far (medians of each board's own median; 120 and 181 boards).

The ship time comes from boards with 3 or more dated completions, and the spread is wide. About one in five shipped requests ships within a month, and one in three takes more than a year (each board counted once: 22% within 30 days, 33% after more than 365 days; n = 120 boards).

So if the only time you tell people anything is release day, the loop is as slow as your slowest build. Split it in two instead. Close the decision half within a week or two: a status and a sentence. Close the delivery half when it ships. The decision is the part you control, and it costs one line of text.

Closing the loop when the answer is no

A no closes the loop as fully as a release does. On the median board, 2.8% of requests are declined in public (220 boards).

A clear no lets the customer plan: keep the workaround, look elsewhere, or stop waiting. An open request reads as a maybe for as long as it sits there. Write the decision, one true reason and the closest thing that works today, then leave the request up so the answer stays findable.

For the exact words, with three scripts to copy, see our guide on how to say no to a feature request.

Customer feedback loop examples

Three messages that close the loop at different stages. Each names the request, says what happened and says what comes next.

Subject: Planned: bulk edit for products

The request you voted for, "Bulk edit for products", is now planned. We start on it after the release we're finishing now.

We'll email you again when work starts and when it ships. Until then, the request page shows where it stands.

Bulk edit for products

Select products in the list, choose Edit, and change price, stock or tags for all of them at once.

This came from our feature request board, from people editing products one at a time. Thanks to everyone who voted and told us how they'd use it.

We're not going to build a point of sale into the app. Keeping card readers working would take most of our time, and it's a different product.

If you sell in person, a dedicated point of sale tool can send its sales to your store through the orders import.

We're leaving this request up so the answer stays easy to find.

None of them says "we value your feedback". Telling someone what happened to their request already shows that, and saying it on top reads like a form letter.

Customer feedback loop template

A one-page checklist, one block per stage, plus the three numbers to check each month. Paste it into your team notes and fill in the bracket.

Customer feedback loop checklist

COLLECT
[ ] One public place for requests, linked from the app, the help docs and support replies
[ ] Duplicates merged into one request, with their votes kept
[ ] The asker's email stays attached to the request

DECIDE
[ ] A fixed weekly slot to read new requests
[ ] Every request gets a status within [2 weeks]: planned, not now, no, or already possible
[ ] Every no has a one-line reason

BUILD OR DECLINE
[ ] Status moves to in progress the day work starts
[ ] Nothing is marked planned unless you mean to build it

TELL
[ ] Everyone who voted hears about each status change
[ ] Every shipped request gets a changelog entry that names the request
[ ] The original asker gets a personal note when a request waited a long time

EVERY MONTH
[ ] Share of requests with no decision
[ ] Median age of open requests
[ ] Median days from request to shipped

For the collect stage, our product feedback form template asks the questions that make a request useful. For the tell stage, start from the release notes template or turn a list of shipped requests into entries with the changelog generator. When you write to customers yourself, start from our feature request email templates: one email for each stage, from received to shipped.

Three numbers to track on your own board

Share of requests with no decision, median age of open requests, and median days from request to shipped. Here is where public boards sit on each.

A quarter of boards sit below the lower quarter value, half sit between the two quarter values, and a quarter sit above the upper one. The table shows one decimal, so its no decision median of 61.7% is the 62% quoted above, before rounding.

• Share of requests with no decision. Requests still new or under consideration, divided by all requests on the board.
• Median age of open requests (days). For every request not yet shipped or declined, the days since it was posted. Take the middle value.
• Median days from request to shipped. For each shipped request, the days from posting to the day it was marked shipped. Take the middle value.

A board's place in the table says what it looks like from outside, not whether the team is doing well: a new board has young requests by default, and a board that ships rarely but big has slow ship times. The value is in watching your own three numbers move from one month to the next.