There isn't a clean answer to how often to ask for feedback. The question shows up in slightly different forms a lot: weekly or monthly, after every transaction or only sometimes, before churn or after onboarding. People ask it as if there's a number, and there isn't one. What there is, is a decent set of principles for thinking about it.

What "fatigue" actually is

The concept of survey fatigue gets thrown around as if it's a function of frequency. It mostly isn't. People aren't tired of being asked for feedback because they were asked too often, they're tired of being asked because nothing visibly happened the last time they answered. A customer who fills in a form, gets a generic thank-you, and continues to experience the same problem on their next visit isn't going to fill in the next form. They've concluded that the feedback channel isn't real.

This matters because the obvious response to declining response rates is to ask less frequently, when the actual problem is that the asking isn't paired with anything happening as a result. Cutting frequency without addressing the underlying issue lowers response rates faster, because now even the people who would have responded are forgetting that you ask at all.

If response rates are dropping, the first question is whether feedback you've already received has visibly changed anything. Low response rates are feedback too goes further on that.

The two cadences that matter

For most businesses, there are really two distinct rhythms going on, and conflating them creates problems.

Post-interaction feedback is the one most teams default to: someone visits, books, buys, completes a session, and you ask them right after. The natural cadence is "every interaction" but with caveats. Not every interaction is suitable to follow up on. A customer who's already received three messages from your booking system in two days doesn't need a fourth asking how things went. A regular who comes in every week doesn't need a feedback request every week, even if the form is short.

The right answer is usually a rule rather than a frequency. Examples:

  • Every first-time customer gets asked
  • Repeat customers get asked once per quarter
  • Sensitive interaction types (a hospital visit, a complaint resolution, a difficult appointment) skip the automated request entirely

The frequency falls out of the rule. It varies per customer based on their relationship to your business, which is closer to how it should work.

Periodic check-ins are the cadence most businesses skip entirely. These are the ones that aren't tied to a specific transaction. They ask the broader questions: is this still working for you, has anything changed, are you getting what you came for. These are the questions that catch satisfied customers who are quietly drifting away before the churn shows up in the numbers.

A reasonable cadence for periodic check-ins is two to four times a year, depending on the business. A SaaS company might run a quarterly check-in with active users. A hotel might send a longer check-in to past guests once a year. A gym might do a six-month "are we still serving you well" message to long-term members. The point isn't the exact number. The point is that it happens at all, because for most businesses it doesn't.

What happens when you over-ask

The cost of asking too often shows up in a few ways. The first is response quality: someone who gets a feedback request after every micro-interaction will start clicking five stars without reading, just to make the message go away. That data looks fine. It tells you nothing.

The second is goodwill. Customers don't track the exact number of times you've asked, but they do form an impression of "this place sends a lot of email." That impression bleeds into the rest of your communication: marketing, transactional, useful updates. The feedback request that costs you a customer isn't usually the feedback request itself, it's the cumulative weight of being a business that messages too much.

The third is the asymmetric one: the customers most likely to respond to a high-frequency cadence are the ones who already love you or already hate you. Everyone in the middle, which is most of your customers, opts out. You end up with feedback from the extremes and a quiet majority you can't see.

What happens when you under-ask

Under-asking is the more common mistake, but it's harder to spot because nothing breaks visibly. The business assumes things are fine because complaints are rare, but it doesn't have a structured way to find out whether they actually are. By the time problems show up in customer count or revenue, the lag is months long.

A useful test: if the most common path for a customer to give your business feedback is to write an unprompted Google review or to leave without saying anything, you're probably under-asking. The unprompted Google review is selection bias on top of selection bias, and silent leavers are by definition impossible to learn from in the moment.

The setup most businesses end up with

A pragmatic shape for most businesses, allowing for plenty of variation, looks something like this:

  • A short post-interaction feedback request, triggered automatically, with rules that exclude high-frequency repeat customers and sensitive interaction types
  • A separate periodic check-in, sent two to four times a year, asking the relationship-level questions rather than the transaction-level ones
  • A clear way to see what came back and act on it, because the asking is only as useful as what you do with the answers

Qria is built around that distinction. Post-interaction forms collect the transactional feedback. The AI summary surfaces the patterns across responses without anyone having to read every one. The structure makes it easier to send the right kind of question at the right kind of moment, instead of one form for everything every time.

The number you should care about isn't how often you ask. It's whether what you learn from asking changes what you do. If it does, you can probably ask more often than you think. If it doesn't, the frequency is the smaller problem.