The short version
- A paying client is careful and political, so what they write is rarely what they mean.
- Ten real messages here, each with what it means, what to reply, and where it belongs.
- Most client feedback is lost because it was said once, in a call, to one person.
- "We are reviewing our tools this quarter" is a renewal at risk, not a feature request.
Client feedback differs from user feedback in one way that changes everything, and the examples below all turn on it. The person writing is paying you directly and knows it. That makes them more careful, more political and much less likely to say the thing they actually mean.
Ten examples below, written for this post. Each one is followed by what it usually means, the reply, and where it should end up, because the third of those is the part that gets skipped.
What counts as client feedback?
Anything from the account that pays you, about the work or the product, including the things said in a call and never written down.
The last clause is where most of it lives, and it's why client feedback has a different failure mode from user feedback. User feedback is lost in volume. Client feedback is lost because it was said once, to one person, in a meeting.
There's a board that keeps this kind of thing attached to the account that said it, and the demo is open without an account.
Want somewhere to put all of this? Twenty eight feedback tools, the price and the unit each one bills on, read on one day.
The ten, and what each one means
| What the client wrote | What it usually means | Where it goes |
|---|---|---|
| "Just checking in on the timeline" | They have lost visibility and are worried | A roadmap they can read without asking |
| "Could we get a quick call about the report?" | Something in the report is wrong and they do not want to say so in writing | A call, then a written request afterwards |
| "This is great, one small thing" | The small thing is the message | A request, sized honestly |
| "How are other clients handling this?" | They suspect they are doing it wrong and want cover | An answer, then a request if the pattern is real |
| "We were expecting this to be included" | A scope disagreement, not a feature request | The contract conversation, not the backlog |
| "Our team finds it confusing" | One person on their team found it confusing | Ask which person and what they were doing |
| "Can you make it work like [the other tool]?" | They want an outcome and have named a solution | A request rewritten as the outcome |
| "No notes, looks good" | They have not looked | Nothing yet. Ask a narrow question |
| "We are reviewing our tools this quarter" | A renewal is at risk | The account conversation, today |
| "Any update on that thing we discussed?" | A promise was made in a meeting and never written down | Write it down, then answer |
"just checking in on the timeline"
The most common message in any client relationship and almost never about the timeline.
It means the client can't see what's happening and has started to worry. Answering the question fixes today.
Giving them a page they can look at without asking fixes it permanently, and it's the single thing that changes a client relationship most. A visible list, with states, that moves without them having to chase.
"this is great, one small thing"
The compliment is packaging. The small thing is the message.
Treat the second half at full weight, and resist the client's own sizing of it. Clients say small because they're being polite, not because they have estimated it. Rewrite it as a request with a situation attached and let the size be your judgement.
"can you make it work like the other tool?"
A named solution with the problem removed.
The reply is one question. What are you trying to do when you reach for that. The answer is almost always achievable a different way, and occasionally it reveals that the other tool solved a problem you didn't know they had.
Never build the named solution without asking. Half of these turn out to be a habit, not a requirement.
"we were expecting this to be included"
This is a scope disagreement, not feedback, and filing it as a feature request is how it turns into a bad renewal.
It belongs in the conversation about what was agreed, which is a different conversation with different people in it. If you file it on the backlog you've implicitly accepted that it should have been included.
"our team finds it confusing"
Almost always one person, relayed as a team.
Ask which person and what they were doing. Not because the client is exaggerating, but because the relay has already removed the part you need. Without the moment, the only thing you can do is redesign something that may have been fine.
"no notes, looks good"
The hardest one, because it looks like success.
It usually means they skimmed it. The fix is a narrow question they can answer in one line. Was the export column order right, or did the new filter cover the case from last month. A narrow question gets an answer. An open one gets "looks good".
"we are reviewing our tools this quarter"
A sentence with a deadline in it.
Everything else on this list can wait until Thursday. This one is the account conversation, today, and the feedback content of it matters less than the fact that it was said at all.
Where all of this should end up
One place, attached to the account that said it.
The failure that costs the most isn't mishandling any single message. It's that three clients asked for the same thing across four months, in three different channels, to three different people, and nobody ever put those next to each other.
A request list that carries who asked solves exactly that, and it does one thing more. When the same request has three accounts behind it and you know what those accounts pay, the ordering argument stops being an argument.
How do you do this without a tool?
A shared document with four columns, being what was said, who said it, the date, and the rewritten request. Add a line every time a client says something, including in calls.
The discipline is the hard part, and the thing a document can't do is let the clients themselves confirm that they want the same thing. You end up with your own notes about three conversations instead of three accounts on one request.
How does this product do it?
Requests live on a board, each one carrying the voters behind it. A voter carries whatever you know about them, including the revenue on the account, so a request with three paying clients behind it's visibly different from one with thirty anonymous votes.
The board can be public, so clients add their own requests and agree with each other's, or kept for your team while you file on their behalf. Nothing a visitor writes appears publicly until somebody approves it.
The feedback board page covers the board itself.
The voter list is where the accounts behind a request are kept, and internal feedback covers the other half of what a team hears.
14 days, a card at signup, then $9 or $39 a month.
What a board cannot do with this
It can't hold the things said in a call. Somebody still has to write those down before a request exists, and neither the voter list nor the board changes that. Ours also has no private board at any price, so anything a client would only say in confidence stays out of it.