You added the little speech bubble icon to the bottom corner of every screen. It's been three months. The feedback inbox has four entries. Two are bug reports about a flow that was fixed weeks ago. One is asking for a refund. One says "great app!" with a smiley face.
This is the standard outcome for in-app feedback widgets, and it doesn't usually mean your product is too good to need feedback. It means the widget design is wrong for the job.
The pattern that produces a near-empty inbox repeats across most SaaS products that ship an "always available" feedback button. Once you see the failure mode, you can stop expecting different results from the same setup.
Why nobody clicks the widget
Several things tend to be happening at once.
The widget sits in the same place on every screen. Within a week, regular users have stopped seeing it. The brain learns to filter out persistent UI elements that aren't part of the current task. The widget becomes wallpaper. That's banner blindness, and it's the default state most users settle into within their first few sessions.
The prompt is also too generic. "Got feedback?" reads as "fill out a form for me." There's no reason embedded in the question for the user to spend their time on it. They have no problem to solve by clicking it, and you haven't given them one.
The timing is wrong. A user clicking through a multi-step workflow does not want to stop and tell you what they think mid-task. The few users who do click the widget tend to do so when they're already frustrated, which is why the inbox skews towards complaints and bug reports.
It also feels one-way. Nothing happens after a user submits. No acknowledgement, no follow-up email, no sign that anyone read it. Users who tried it once and got silence don't bother again, and they tell colleagues.
And the friction is real. Click the bubble. A modal pops up. Pick a category from a dropdown. Type into a tiny box. Optionally attach a screenshot. Hit submit. Compare that to the cost-benefit calculation in the user's head: thirty seconds of effort, in exchange for the warm feeling that you might get around to reading it.
The result is the inbox you have. Mostly bug reports from power users, plus a handful of "great app!" comments from new users still in the honeymoon phase. The 95% of users in the middle, the ones whose experience you actually want a read on, never touch it.
What works better
The widget isn't the right shape for the job. What actually pulls feedback out of users looks closer to the opposite of "always available."
Contextual triggers help. A short prompt that appears right after a specific event. After a user completes their first export. After they cancel a recurring task. After they hit an error. The context gives the prompt meaning. You're not asking "any feedback?", you're asking "how did that export go?", and that's a much easier question to answer because the relevant moment is fresh.
Segmentation matters too. Don't ask everyone. Ask the cohort whose feedback you actually need this week. New users in their first session, users who haven't logged in for 30 days, users who just upgraded a plan. Each of those is a different question, and each one needs a different prompt.
Make the prompt time-bound. A prompt that appears for a week and then disappears stays salient. A prompt that lives in the corner forever does not. Users notice change. They tune out persistence.
Follow up when responses come in. Even an automated reply that says "got it, here's what we're doing with feature requests like this" changes the perception of whether responding is worth the effort. The first time a user gets a real reply, they become much more likely to respond next time.
And go lower friction than you think you can get away with. A one-question pulse with no required text field will outperform a 5-question survey. If you need depth, ask the depth question only of the users whose pulse response told you it was worth asking.
The trouble with always-on widgets
The strongest argument for an in-app widget is that it's "always available" if the user wants to give feedback. The problem is that the users who choose to give unprompted feedback are typically angry users or power users. Both groups are unrepresentative of your wider base. One is over-indexed on what's broken right now. The other is over-indexed on edge cases and advanced workflows. The post on why power users are bad feedback sources goes into this dynamic in more detail.
What you actually want is a read from the rest of the base. The quiet middle that uses the product, gets value from it, and doesn't have strong enough feelings to seek out a feedback bubble. The only reliable way to get a read from them is to ask, on a schedule, in a context that makes the question feel worth answering.
Qria is a useful tool for the structured side of this. Short forms, distributed through the right channel at the right moment, with an analysis layer that surfaces patterns across the responses. The in-app widget doesn't need to go away. It just needs to stop being treated as the whole feedback strategy.
What to do with the widget you already have
If you've already shipped a widget, you don't necessarily need to remove it. It's fine as a bug-report channel, since that's what it actually functions as in practice. The thing to stop doing is treating its inbox as a representative read on what users think. Rename it internally to "bug reports," route the items to the engineering team that fixes them, and run a separate, scheduled feedback program for the actual question of how users are finding the product.
The post on what to ask users after signup covers one specific case where a scheduled, contextual prompt does the work that a widget cannot.
