Customer feedback examples, in the shapes they arrive

These are examples of feedback customers give you about your product. Not the kind you give a colleague in a review, which is a different subject that shares a phrase.

Most posts under this title give you feedback that has already been cleaned up. A tidy sentence naming a clear problem, sitting in a numbered list, ready to be filed. Almost nothing arrives like that.

What arrives is a fragment, a complaint about the wrong thing, a solution with the problem left out, or four hundred words in which the actual request is in the last line.

So this is a list of the shapes, made up, not lifted from anybody's board, because publishing real customers' words without asking isn't a thing we will do. Each one is followed by what it's really asking and by a version you could put on a board and rank.

What counts as customer feedback?

Anything a person who uses your product tells you about it, whether or not you asked.

A support ticket is feedback. So is a feature request, a one star review, a cancellation reason, a reply to an email, a comment on somebody else's post about you, and a sentence a customer says on a call while they're talking about something else.

The form changes what it costs them to send and therefore who sends it, but the content is the same kind of thing.

The reason to say that plainly is that teams often mean only the formal channels when they say feedback, and the formal channels are the smallest and least representative of the sources.

Every count you build from any of them is a sample of the people who chose to speak, and the sample changes with the effort required.

If you would rather see it than read about it, the demo board is open with no account and no email.

The bug that arrives as a feature request

Would be great if the export didn't drop the last row.

This is a defect report wearing polite clothes, not a feature request, because the person didn't want to sound like they were complaining.

You will get a lot of these and they're the most valuable feedback you receive, because a bug reported by a customer has already survived their decision that it's worth mentioning. Most bugs never clear that bar.

The rewrite is to stop treating it as a request and to treat the sentence after it as the real content.

What to file. Export drops the final row. Reported by a customer, needs reproducing, not a roadmap item.

The reason this matters is that a bug filed on a voting board sits there collecting votes while people wait for you to decide whether it's popular enough to fix.

It never was a decision. The two are worth ranking by completely different measures, and telling them apart at the front door is most of the work.

The feature request that arrives as a bug

The report is broken, it only shows this month.

Nothing is broken. The report shows this month because that's what it was built to show, and this person expected a date range.

These are harder to spot than the first kind, because the word broken makes you go and look at the code, find nothing wrong, and close it. The customer then learns that reporting things achieves nothing.

What to file. Choose a date range on the report. Currently fixed to the current month.

A useful habit is to answer these two ways at once. Tell the person it works as designed and what the design is, and put the request on the board in the same breath. Doing only the first is how you teach somebody to stop telling you things.

The solution with the problem left out

Please add a dropdown at the top of the list to filter by owner.

Somebody has designed a feature for you. They mean well and they have done you half a favour, because a person who has thought about the interface has usually been fighting something for a while.

The trouble is that the dropdown may be a bad answer to a real problem, and if you build it you'll have solved their sketch, not their difficulty.

What to ask. What are you trying to find when you reach for that.

What to file, after they answer. Find my own items in a long list without scrolling. Suggested a filter by owner.

Filing the problem, not the proposal is what lets three separate requests turn out to be the same one. Filing the proposal gives you three cards that all say dropdown and no way to see that they agree.

The one line with no context at all

notifications are annoying

That's the entire message. You will get these constantly and it's tempting to bin them.

Don't bin them, but don't build from them either. The correct response is one question, and the question should be as narrow as you can make it while still being open.

What to ask. Which notification, and what were you doing when it arrived.

About half of these get an answer, and the answers are often the sharpest feedback you get all month, because the person was annoyed enough to write two words and is usually delighted that somebody asked.

The other half go quiet, and that's information too. A complaint nobody will spend thirty seconds explaining wasn't costing them much.

The essay with the request in the last line

Four hundred words about their workflow, their team, the way they used to do it, what they tried, and then, at the very end, one sentence that's the actual ask.

These are the opposite problem to the previous one and they're worth more than they look. Somebody spent twenty minutes writing to you. That's the strongest engagement signal in your inbox and it usually comes from a customer who is close to either becoming a champion or leaving.

What to do. Read the whole thing once. Then write the request as one line, send it back to them, and ask whether that's right. You will be wrong about a third of the time and being corrected is faster than guessing.

What to file. The one line, with a link back to the original so the context isn't lost.

The cancellation reason

Too expensive for what we use it for.

The most misread sentence in the category. It almost never means the price is too high in absolute terms. It means the value they perceived was lower than the price, and those are two different problems with two different fixes.

The version worth acting on comes from the follow up question, which is what they were using it for.

Frequently the answer is that they were using one part of a product they were paying for all of, which is a packaging problem, or that the part they wanted never worked for them, which is a defect they never reported.

What to file. Rarely a roadmap item. Usually a note against the account and a tally, because one of these is an anecdote and eleven of them in a quarter is a finding.

The praise

Love the new board, so much faster.

Feels like nothing to act on. It's worth one thing, which is knowing which change earned it, because that's the only feedback you'll ever get that tells you something worked.

What to do. Reply, and note which release it followed. Nothing goes on the board.

The trap is treating praise as a measurement. It arrives from the same self selecting group as everything else, and a week of nice messages isn't evidence that the last release was good.

The comparison

The tool we used before had this and it was much easier.

Two pieces of information in one sentence and most teams only hear the first.

The first is the feature. The second, and the more useful, is that this person has used a competing product recently enough to compare, which tells you what they're measuring you against and what their idea of easy looks like.

What to ask. What did it do that made it easier.

What to file. The behaviour they describe, not the name of the other product. A card reading make this work like the other tool is unbuildable, and it also puts a competitor's name permanently on your public board.

The duplicate

The same request, in different words, for the tenth time.

This one isn't a shape of feedback so much as a fact about volume, and it decides whether your board stays readable. Ten cards saying roughly the same thing look like ten different ideas in a sorted list, and each one carries a fraction of the votes the idea actually has.

The answer is to fold them into one, and the thing to check about whichever tool you use is what it does to the numbers when you do.

Adding two vote counts together is the wrong answer, because somebody who asked twice then counts twice, which inflates exactly the number you merged in order to be able to trust.

What does a customer feedback message example look like?

Like one of the nine above, and almost never like the tidy sentence a template shows you.

The nine shapes on this page are messages, not categories, which is the useful thing about reading them as examples.

A message arrives as one line with no context, or as a solution with the problem left out, or as a cancellation reason, or as four hundred words whose request is in the last line.

That's what a customer feedback message example actually looks like, and it's why the three questions below matter more than any filing system.

Nothing on this page was lifted from a real board. Every message was written for the post, which is the only honest way to publish this kind of example without asking somebody's permission first.

Are product feedback examples different?

Only in what they're about, and the difference decides where the message goes next.

Product feedback examples are about the thing itself, being what it does, what it can't do and where it breaks. Feedback that arrives from inside a phone app is the same set of messages in a different place, and the screens it arrives on are worth seeing once.

Customer feedback is the wider set and includes the parts that are nothing to do with the product, being the price, the support reply, the invoice, the sales call. Both arrive in the same inbox and in the same shapes.

The split that actually matters is the first of the three questions below, which is whether the thing is broken or missing.

A broken thing goes to a bug queue and never onto a voting board, because whether to fix a defect isn't a popularity question, and that holds whichever of the two labels you put on the message.

How do you turn any of these into something you can act on?

Three questions, in this order, and they work on every shape above.

Is it broken or is it missing. Broken goes to a bug queue and never onto a voting board, because whether to fix a defect isn't a popularity question.

What were they trying to do. This is the one that turns a proposal into a problem, and it's the only question that lets separate requests merge.

Would you recognise it if it arrived again. If the card is written so specifically that the next person describing the same difficulty would file a new one, it's written wrong. Write the difficulty, not the incident.

Everything after those three is ranking, and ranking is a different job with its own set of arguments.

Which of these belong on a public board?

Fewer than you think, and the filter is whether other people can meaningfully agree with it.

A missing feature, yes. A workflow difficulty, yes. A bug, no, because voting on a defect is a category error and because a public list of your defects is a decision you should make deliberately rather than by accident. A cancellation reason, no. Praise, no.

If you run a board where visitors can suggest things themselves, this filter is the reason a review step exists at all.

On ours nothing a visitor writes appears publicly until somebody approves it, and there's no way to switch that off, which is a constraint we would rather explain than have discovered. The board and its queue work like this.

What makes a good customer feedback example, and what makes one useless?

Being about a person, not the product, and being unfalsifiable.

The product is bad is unfalsifiable. Nothing follows from it. It should make you curious, not defensive, and the follow up is what were you trying to do when you decided that, but on its own there's nothing to file.

Feedback about a person, whether that's praise for somebody in support or a complaint about them, is real and important and belongs nowhere near your roadmap.

Route it to whoever runs that team and keep it out of the board, because a card with a colleague's name on it's a problem you've created for yourself.

How many examples do you need before you act?

Fewer for a defect and more for a direction.

One credible bug report is enough to go and look. One feature request is enough to write down and never enough to build from.

The number that should move you isn't really a number, it's whether the same difficulty is arriving from people who have nothing else in common, because that's the difference between one team's workflow and a gap in the product.

The honest version is that most teams have the opposite problem. Not too little feedback, but a pile of it and no way to see which parts of the pile are the same thing said differently. That's a sorting problem, not a collecting problem, and it's the one worth spending money on.

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