← Feature request

The customer feedback loop, and why it rarely closes

A customer feedback loop is the path a piece of feedback takes from the person who sent it, through whoever decides what happens to it, and back to that same person.

Almost every description of one draws the same picture. Collect, analyse, act, repeat. It is a tidy diagram and it is missing the step that makes the word loop mean anything. Six systems described end to end show where each one leaks, and the leak is in the same place every time.

A loop is closed when the person who gave you the feedback finds out what happened to it. Until then you have an arc. You took something from a customer and you did something with it, and from where they are standing nothing came back.

This page is about that last step, because it is the one that gets designed out. Not deliberately. It gets designed out by a decision made much earlier, and by the time anybody notices, the address they would have needed is gone.

What is a customer feedback loop?

A customer feedback loop is the full circle from somebody telling you something to that same person hearing what you did about it.

Four steps rather than three. You collect the feedback, you work out what it means, you act on it, and then you go back and tell the person who raised it. The fourth step is what separates a loop from a suggestion box.

The reason it matters is not politeness. It is supply. A person who tells you something and hears nothing learns that telling you is not worth the effort, and the next idea they have goes somewhere else or nowhere at all.

The loop is not a courtesy at the end of the process. It is the thing that keeps the process fed.

You can see the failure without any instrumentation. A board that filled up in its first month and has been quiet since is almost never a board where people ran out of ideas. It is a board where the first wave of people found out that writing on it did nothing.

The product this site is about does this part on a board, and the demo is open without an account.

The public board a visitor reads, three columns wide, each request carrying its vote count, its views and its comment count
The public board, where anyone can post and vote without an account.

How do you collect customer feedback, and how much of it gets to you?

Four routes, and the one you choose decides how much of the loop you can close later.

A public board lets anybody write and vote with no account, which collects the most and identifies the fewest. A support inbox collects the problems people are angry enough to report and nothing about the ones who quietly left.

A survey collects answers to the questions you already thought of. A sales or renewal call collects what one person says while talking about something else.

How much reaches you is the part worth being honest about. Whatever the route, the people who write are the ones who found the form, had the time and expected an answer, and they are never a random sample of your customers. Who is actually in that sample is a page of its own.

So collection and closing pull against each other, which is the whole subject of the section below.

Why do most feedback loops never close?

Because closing needs a way to reach one specific person, and most collection is designed to avoid asking for one.

This is the trade nobody writes down. Asking for an email address before somebody can tell you something costs you a large share of the feedback you would have got.

People arrive with a thought, meet a form, and leave with the thought. So the sensible thing, and the thing our own board does, is to let them write with no account at all.

That decision is right and it has a consequence that arrives months later. An anonymous voter has no address, so when the thing they asked for ships, there is nobody to tell. The loop cannot close for them, not because anybody forgot, but because the system was built so they never had to identify themselves.

So the honest shape of the problem is a trade rather than a failure. More feedback, or a closable loop. Most tools pick the first, sell it as low friction, and then publish a diagram with four arrows in it.

We would rather say which one we picked and what it costs. We picked more feedback. The loop closes for the people who have an account with us and it does not close by email for anybody else.

What does closing the loop actually require?

Three things, and the third is the one that is usually missing.

You need to know what was asked for, which is the easy part, because the request is written down. You need to know who asked, which is where the identity question bites. And you need a moment where telling them is automatic rather than a task somebody remembers.

That third one is worth dwelling on. A loop that depends on a person remembering to write to fourteen customers after a release is not a loop, it is a chore, and chores lose to whatever is urgent that week.

The only loops that survive contact with a busy quarter are the ones that fire on their own.

In our case the moment is publishing a release. When you publish, we look at the completed items in that release, find the people whose vote is on one of them, and write to each of them naming the headings they personally asked for, with the rest of the release listed underneath so the message is useful rather than narrow. The full mechanism is on the changelog page.

Two details matter more than they look. A release can only be announced once, because the send is claimed by the same update that marks it sent, so two people publishing at the same moment cannot both announce it. And somebody who voted for two things in one release gets one email rather than two.

The public changelog, one card per release, each listing the improvements, new features and fixes that went out in it
The public changelog, one card per release.

Can you close a loop with anonymous feedback?

Not by writing to them. You can only close it in public, and that is a weaker close but it is not nothing.

Publishing is the fallback and it is the one that works for everybody. The card moves across the roadmap where anybody watching can see it, and the release appears on a changelog page that needs no account to read.

A visitor who cared enough to vote can come back and find out, and a fair number will.

What you lose is the arrival. A published answer waits for somebody to come looking. A sent answer arrives while they are thinking about something else, which is exactly when it does its work.

That difference is why a public board is not a substitute for the message, and why we do not pretend it is.

There is a middle path, which is to let people identify themselves when they choose to rather than before they are allowed to speak. Somebody who signs in has an address and gets the message.

Somebody who does not stays anonymous and gets the public version. The important part is that the identity is optional and late rather than required and early.

The voter list, one row per person, showing where each arrived from and how many requests and comments they have left
Everyone who voted, one row each, no account required.

Does saying no close the loop?

Yes, and it is the half of the loop that gets skipped hardest.

A loop closed only when the answer is yes is not a loop, it is an announcement channel. The person whose request you turned down is the person most owed an answer, because they are the one still waiting and still assuming.

Our board takes a position on this that is unusual in the category. There is a Denied column and it is shown by default, and a card in it carries a written response from you rather than sitting there marked no.

You can hide the column if you would rather, and showing it is the better choice, because a public no is an answer and a silent no is the thing that empties a board.

We should be straight about the limit. Denying something sends nobody anything. The answer is published, on the card, where the person who asked can find it, and no message goes out.

The only automatic message in the product is the one that follows a release. If closing the loop on a refusal matters to you, that is a thing you will do by hand.

The private board, with Pending approval holding four suggestions nobody has let through yet, Suggested beside it and Denied with the reason written on each card
The private board, where every new suggestion waits for approval.

How do you know the loop is closed?

You count the answers rather than the collection, and almost nobody does.

The instinct is to measure the top of the funnel. Requests received, votes cast, comments posted. Those numbers go up on their own for a while and they tell you nothing about whether anybody heard back.

The measurement that means something is the share of requests that have an answer on them. Shipped, in progress with a date, or refused with a reason.

A board where most cards have one of those is a board people will keep writing on. A board where most cards are sitting in the first column untouched is one that is going quiet whether or not the arrivals have slowed yet.

The second measurement is the one nobody likes. Look at the people who wrote something six months ago and ask how many of them have written since. That is your loop, measured from the only side that matters.

14 days, a card at signup, then $9 or $39 a month.

The reader this matters to collects feedback already and answers almost none of it. A team that replies to everything by hand, because there are eleven customers, has a closed loop without any of this and should keep it that way until the replies stop fitting in a morning.

In brief

A customer feedback loop is four steps and everybody builds three of them. The missing one needs a way to reach a person, and the decision that removes it is usually made at the very beginning, when somebody sensibly decides not to demand an email address.

There is no clever way around the trade. There is only being clear about which side of it you chose, closing the loop automatically wherever an address exists, and publishing an answer where one does not.

Every request that comes in has somewhere to go, and the ones that get an answer are the reason the next one arrives.

Related reading

Feature request, and what happens to one after it is typed Product roadmap, and why the public one has no dates Release notes, and who actually gets told you published them