A support team cuts ticket volume by forty percent in one quarter and puts it on the slide. Everyone nods. What the slide does not say is that the help link moved below the fold, the contact form now requires an account, and the chat widget only loads after a five-second delay on mobile. The tickets did not go away. The door did.
Nobody lied. Every number on the slide is true. The number answers "how many people reached us through the channel we still measure" — which is not the question anyone in the room thought they were asking, because the question in the room was "are fewer people having problems." Those are different questions, and the second one has no dashboard.
That is the feedback layer: the part of the customer's experience that never becomes a message, and therefore never becomes a number.
Feedback is a sample, and the sampling frame is permission
Every piece of feedback you have ever received arrived through a filter with at least four gates. The person had to notice the problem. They had to be able to describe it. They had to believe describing it was worth their time. And they had to have a channel that was open to them at that moment.
Each gate removes a different population, and the removals are not random.
People who notice are not a cross-section: the ones with the most fragile workflows notice everything, and the ones who use the product twice a year notice nothing at all — including, sometimes, that it stopped working. People who can describe it are disproportionately the ones with technical vocabulary, which means your best feedback comes from users whose problems are already half-solved. People who believe it is worth their time are the ones who still think you might fix it — which is to say, the ones who have not yet given up. And the channel being open is a property of your design choices, which you changed last quarter for good reasons.
A survey with a three percent response rate is not a survey of your users. It is a survey of the three percent of your users who answer surveys, which selects for patience, for loyalty, and for a relationship with the product that most of your users do not have.
The people who leave do not file a ticket
The single most informative event in most products is a user quietly stopping. No complaint, no cancellation survey, no angry email — just a last session in March and nothing after. That event is almost never in the feedback system, because the feedback system is built to receive messages, and leaving is not a message.
It is worse than that. The exits are correlated with exactly the things you most need to know. A person leaves because of a problem they could not articulate, or because the product did not do a thing they never thought to request, or because their company changed shape and the tool no longer fit. All three are invisible from inside the ticket queue. You learn that they left, if you learn at all, from a revenue report months later, stripped of the reason.
So the feedback you have is a sample drawn from the population that stayed. That is a survivorship sample in the most literal sense, and it has a predictable bias: it over-represents the problems that are annoying but tolerable, and under-represents the problems that are fatal. The annoying-but-tolerable ones generate tickets. The fatal ones generate silence.
Closure is a property of your queue, not of their problem
Ask any support organization what fraction of tickets are "resolved" and you will get a number near ninety percent. Ask what "resolved" means and the definition will be some version of "the ticket left the queue." Replied to, closed by the customer, auto-closed after seven days of inactivity.
None of those definitions contain the sentence "the problem stopped happening for the person who reported it." A ticket can be closed because the agent answered a different question, because the customer gave up on the thread, because the automation fired, or because the customer churned and no longer cares. All four look identical in the report: resolved.
This is the same collapse as elsewhere in this series — a distribution of outcomes squeezed into one bit — but the cost is different here. A closed ticket closes the question. It tells the next person who reads the queue that this failure mode has been handled, which is a claim about the world made from a claim about a database row.
The cheap fix is a second timestamp, seven days after closure, asking one question: is it still happening? The answer arrives late, from a small number of people, and it disagrees with the closure status often enough to be worth having. Most teams do not do it, not because it is expensive, but because it converts a clean metric into a messy one.
Feature requests are constrained by imagination and by billing
Users ask for what they can imagine, and they can only imagine what fits the shape of the product they already have. Nobody requests the removal of a bug. Nobody asks for the thing that would make their workflow unnecessary. Nobody writes "please make this faster in the specific case where my data has a shape you have never seen" — they write "make it faster," which routes to a different team.
There is also a billing constraint. Users on a metered plan ask for fewer features, because every feature is a potential line item. Users on a flat plan ask for more. The same person with the same problem will file a different request depending on which side of a pricing page they sit on, which means your feature request backlog is partly a map of your pricing model, not your product's gaps.
None of this makes requests worthless. It makes them evidence of a specific thing: what articulate, currently-paying, imaginatively-constrained users believe would help. That is one input among several, and it is routinely treated as the only one because it is the only one that arrives pre-formatted as a number.
Deflection is not resolution
Self-service is usually sold internally as efficiency: fewer tickets per user. Sometimes it is. Sometimes it is a transfer of work from your support team to your customer, and the metric cannot tell the difference, because both look like a ticket that did not happen.
The distinguishing question is not "did the ticket happen" but "did the person get what they came for." A knowledge base article that answers the question in thirty seconds and a help center that dead-ends after four clicks produce the same ticket count and opposite outcomes. The first is deflection. The second is a wall.
You can see the difference, but only if you instrument the path rather than the outcome: search-then-exit, article-then-return-within-a-day, form-started-and-abandoned, session-end-on-help-page. These are non-events, and non-events are the hardest things to count because nothing arrives to be counted. The event you need is the absence of the event you expected.
Two practices that cost almost nothing
Write the denominator under every voice-of-customer number. Not "94% satisfaction" but "94% satisfaction, 3.1% response rate, respondents are 4x more likely to be on the annual plan." The number is not wrong. It is a fraction, and you cannot interpret a fraction without both halves.
Close the loop on a sample, not on the queue. Pick fifty closed tickets a quarter, contact the person seven days later, ask one question: still happening? The result is not a metric. It is a correction to a metric, and corrections are what keep the metric honest.
And one that costs a little more: count the exits. Every cancelled subscription, every expired trial, every account that went quiet for sixty days. Not to send a survey — the people who leave rarely answer surveys, which is the point — but to keep a separate register of the population whose feedback you will never receive. The register's value is that it exists at all. A team that knows the size of its silence makes different decisions than a team that believes its silence is satisfaction.
The uncomfortable part
Feedback volume is a function of the friction in giving feedback. Reduce the friction and you will hear more; increase it and you will hear less. Neither change tells you anything about the underlying reality, but both change the dashboard, and the dashboard is what gets managed.
This means that every improvement to your feedback channel is also a change to your measurement, and every change to your measurement looks like a change in the world. The team that cuts the contact form to reduce spam has also cut its own ability to hear about the spam's opposite: the real problem.
The deeper issue is that silence is ambiguous. It can mean "fine" or "gone," and the two are indistinguishable from inside a system that only counts messages. You cannot resolve the ambiguity with better analysis of the messages you have. You resolve it by going and looking at the people who did not send one — and accepting that some of them will be fine, some will be gone, and you will never know the exact ratio.
Friday exercise
Pick one source of "user voice" — the ticket queue, the NPS survey, the feature request board, the churn survey. Write four lines under it:
- Eligible. Who could have been heard from, in principle?
- Responded. Who actually was, and what do they have in common that the others do not?
- Absent. Who cannot appear in this channel by construction — the churned, the silent, the ones without the vocabulary, the ones whose problem has no category in your form?
- Non-event. Name one exit that leaves no message at all, and say how you would count it.
Then find one person who left in the last quarter and ask them, once, why. Not a survey. A sentence in an email. If the answer surprises you, the feedback layer was doing what feedback layers do: hiding the part of the population that had already stopped talking to you.
The gap between what users say and what users experience is not a communication problem. It is a measurement problem, and the measurement has a frame, and the frame is the door you built.
If your team reports a number that is really a sample of the people who were able to speak — a ticket count, a three-percent survey, a "no complaints" line in a review — say so in the comments. We keep a one-page worksheet that records who could be heard, who was actually heard, who is structurally absent, and where the people who leave without a message go, and I will send it over. No form, no email list.
Top comments (0)