Ask a support team what users think of the product and they'll tell you, in detail, with receipts. They know exactly which features are broken, which error messages confuse people, which billing edge case generates a ticket every Tuesday. It's a rich, specific, hard-won picture of the product. It's also a picture of maybe five percent of your users, and the five percent least like everyone else.
The people who open tickets are self-selected in a very particular way. Something broke badly enough, or confused them long enough, or mattered enough, that they were willing to stop what they were doing and describe the problem to a stranger. That takes a certain amount of investment in the outcome. Casual users don't bother. If something doesn't work, they close the tab and try again later, or they don't. The quiet middle of your user base, the people who log in, do the thing, and leave without a strong opinion in either direction, almost never contacts you. They're the majority and they're invisible.
This isn't an argument against listening to support. Support tickets are real problems from real users and they should get fixed. The trouble starts when the support queue becomes the de facto voice of the customer, because a product shaped entirely around the loudest, most invested, most frustrated slice of the audience drifts somewhere strange. You end up polishing the exact edges that generate tickets while missing the reason most people never engaged enough to file one. Sometimes the absence of tickets isn't contentment. It's someone deciding the product wasn't worth the effort of complaining about.
I've written before about the silent majority in your feedback data, and support is the sharpest version of the same problem. A ticket queue is voluntary response taken to its extreme. Not only does someone have to have a problem, they have to care enough to report it in prose. Whatever conclusions you draw from that queue are conclusions about the subset of users who both hit a problem and had the energy to tell you. The person who churned in week two without a word is not in there. Neither is the person who's mildly annoyed by something every day but has never mentioned it because it's not quite bad enough to bother.
So how do you hear from people whose defining trait is that they don't reach out? You can't wait for them to come to you, because not coming to you is the whole thing. You have to go and ask, on purpose, in a way that costs them almost nothing.
The first move is to lower the price of answering to near zero. A support ticket is expensive: open a form, describe the problem, wait for a reply, maybe get asked for more detail. A one-tap question inside the product, at a moment that's relevant, is cheap. A quiet user won't write you a paragraph, but they might tap one button and, if you're lucky, add half a sentence. That half a sentence from someone who'd never have opened a ticket is worth more than another detailed report from your most engaged power user, precisely because it's the voice you otherwise never get.
The second move is to ask at moments the quiet user is actually present for, rather than sending an email they'll ignore. These users don't reply to email surveys either, for the same reason they don't file tickets: replying is effort and they're not that invested. But they are inside the product doing things. A short prompt after they complete an action they came to do catches them while they're there, in the flow, with the context fresh. It's the difference between shouting into an inbox and tapping someone on the shoulder while they're already looking at the thing.
The third move is to stop treating non-contact as neutral. A user who never opens a ticket and never replies to a survey is still generating signal, just not the kind you can read as sentences. They log in less often. They stop using the feature they used to use daily. They downgrade. They let the subscription lapse without a word. This behavioural signal isn't biased the way self-report is, because it doesn't require the user to feel strongly enough to speak. It's quieter and vaguer, but it covers the people your surveys and your ticket queue both miss, which makes it the closest thing you have to hearing from the silent part of the base.
None of these fully solves it. The genuinely indifferent user is hard to reach by design, and some fraction of your audience will never tell you anything no matter how you ask. But the goal isn't a complete census. It's widening the aperture past the narrow slice that shows up in your support inbox, so that the loudest five percent stops standing in for everyone.
This is roughly why Qria exists as a single view rather than a form tool or a review monitor on its own. The structured prompts catch the quiet user in the product, the public reviews catch the ones who'd rather vent to Google than to you, and the AI reads across both and tells you what's actually recurring, instead of leaving you to weight one loud channel against another by gut. A ticket queue answers "what's broken enough to complain about." Pulling more channels together gets you closer to "what do the people who never complain actually think," which is a different and usually more important question.
For the wider version of this, the guide to feedback for SaaS products walks through how the pieces fit around each other. But the core of it is simple enough to state plainly. Your support queue is a minority report. Treating it as the voice of the customer means building for the people who complain and quietly ignoring the people who just leave, and the second group is almost always the larger one.
