# How fast should you respond to customer feedback?

> Acknowledge blocking bugs within one business day, minor bugs within two, and ideas within a week. These are starting points, not standards. Reply on a fixed daily slot, and make the first reply confirm what you read and what happens next.

Source: https://escutaproduto.com/resources/feedback-response-time
Last updated: 2026-10-11

## Aim for the first reply, not the fix

The right response time is about the first reply, not the fix. Nobody expects a solution the same afternoon, but customers do expect to know that someone read their message. A short acknowledgment within a day or two does most of the work. The fix can take as long as it takes, and the status and notes keep the item moving while you work.

So the question to answer is how long a customer should wait before hearing from you at all. For a small team running one or more products, a sensible answer depends on the type of feedback, because a broken checkout and a feature idea carry very different costs of silence.

## What response targets should look like by type

Use these as starting points for your own team. They are recommendations you can adjust after a few weeks of practice, not industry standards, and they assume a team that checks the inbox on business days.

| Feedback type | First reply target | What the first reply does |
| --- | --- | --- |
| Bug that blocks the customer | Same business day | Confirms the problem and names the next check |
| Bug with a workaround | Within two business days | Confirms, asks for one detail if needed |
| Idea or feature request | Within a week | Thanks, says it is recorded, sets the status |
| Praise | Within a week, when you see it | A short thank you, no promise |
| Other or unclear | Within two business days | One clarifying question |

A bug that blocks someone is the only category where a same-day reply is worth protecting. Everything else can wait a little, as long as the wait is consistent and the customer is not left guessing.

## Why bugs and ideas need different clocks

A bug has a clock because the customer is stuck. Every hour without a reply is an hour they spend trying the same thing again, or deciding to leave. An idea has a different clock. The customer is describing a want, and a reply in three days is almost as useful as a reply in three hours, provided it says the request is recorded.

Treating both the same leads to two failures. If you give ideas the bug clock, you spend your mornings on things that will not change this month. If you give bugs the idea clock, a blocked customer waits while you finish a planning doc. Keep two clocks, one for blocking problems and one for everything else.

## A daily habit that keeps the targets honest

Targets only work if someone looks at the inbox on a schedule. Pick one or two fixed times each business day, and treat them like a meeting. A simple routine works well:

1. Open the inbox and filter by status new. That is everything nobody has answered.
2. Read the bug reports first and mark any that block a customer. Reply to those the same day.
3. Read the ideas and praise. Set each one to planned, closed or leave it new if you need more time, and add a note saying why.
4. Look for two or three identical messages. Group them in a note on the first item so the next reader sees the pattern.
5. Write the first replies you owe. Keep them short, and send them from your own email.

Ten or fifteen minutes is enough for most small teams. If the routine takes an hour, the inbox is probably too noisy, and the fix is a shorter widget form or better triage, not more hours. The weekly version of this routine is covered in [how to triage customer feedback](/resources/how-to-triage-customer-feedback).

## What the first reply should say

A good first reply does three things: it confirms what you read, it says what happens next, and it tells the customer what they can expect from you. It does not need to be long. Here is a template for a bug:

> Hi Priya, thanks for the report about the invoice page showing a blank total. I can reproduce it on Safari and I am checking the recent changes to that page now. I will write again by Thursday with what I find, even if the answer is not yet a fix.

Here is a template for an idea:

> Hi Tom, thanks for asking for CSV import on the projects list. I have recorded it with the other import requests, so it is not lost. I cannot promise a date, but I will set the status when we decide to plan it, and I will tell you then.

Both messages set a clear expectation and meet it. The second one uses a phrase that many teams skip: it tells the customer the request is recorded and that the status will change. Read more about wording in [how to reply to customer feedback](/resources/reply-to-customer-feedback).

## Checking your response times from the export

You do not need a reporting tool to see whether you are meeting your targets. Filter the inbox by status new on a given morning, and the count tells you what is still waiting. For a longer view, use the CSV export, which opens in Excel and Google Sheets. Sort the rows by date and count how many bugs stayed new past your target. A week of that count is usually enough to see whether the routine is working.

Do not chase a perfect number. The aim is to notice the slow weeks early, not to create a metric that rewards fast, shallow replies.

## Keeping the clock visible in Escuta Produto

In Escuta Produto the inbox shows each product's items with their type and status, and new is the status that means nobody has answered yet. Keep that filter as your daily starting point. When you send a first reply, set the status to planned or in progress if you have decided, so the next person sees the item has an owner. The status workflow is explained in [how to design a feedback status workflow](/resources/feedback-status-workflow).

For notification setup, so that new bugs reach your team's chat as they arrive, see [the notifications docs](/docs/notifications). A Slack or Discord alert with the excerpt and a dashboard link is often the difference between a same-day reply and a reply that comes three days later.

## Frequently asked questions

### How fast should you reply to a bug report?

Reply the same business day if the bug blocks the customer, and within two business days if they have a workaround. The first reply should confirm the problem and name your next check, even before you have a fix.

### How quickly should you respond to a feature request?

Within a week is a reasonable starting point. Thank the customer, say the request is recorded, and explain that you will update the status when you decide to plan or close it. A calm, honest reply matters more than speed here.

### How often should you check your feedback inbox?

Pick one or two fixed times each business day and keep them. A ten to fifteen minute routine that filters by new status and answers blocking bugs first is enough for most small teams.

### Does a fast first reply mean the issue is fixed?

No. A first reply only confirms that you read the message and say what happens next. Keep the item in progress while you work, and send a second message when there is a real outcome to share.