How to follow up on a bug report

Acknowledge it within a working day

A bug report is a small emergency for the person who wrote it. They lost time, maybe a sale, and they are not sure anyone noticed. A quick acknowledgement tells them the report arrived and someone is looking at it.

Keep the first reply short. Say you read it, say what you will check next, and say when you will write again. "I am trying to reproduce this today and will write again tomorrow" is enough. Do not promise a fix at this stage. You do not know the cause yet.

Ask for the one detail you are missing

Most bug reports arrive with less than you need. Before you ask the customer for anything, check what is already there. The widget saves the page URL and the browser's user agent automatically, so you may already know the page and the browser. Read the metadata too, because plan and app version often narrow the problem.

If something is still missing, ask one question. "Which browser are you using?" is answered by the user agent in most cases, so ask for what the report does not show. A typical gap is the step before the failure.

Hi Ana, thanks for the report about the export failing on the reports page. I can see you were on Safari, which helps. One thing I still need: what did you click just before the error appeared? That will let me reproduce it.

Use the context you already have

Context turns a vague report into a checkable one. Use these in order:

1. The page URL. It tells you which screen and which route.
2. The browser. It narrows the problem to one engine, or rules it out.
3. The metadata. A plan, an app version or a team name can point to a single release or account.
4. The message. Read it once for the symptom, then again for any clue about timing.

With those four, a report usually becomes something you can check. Without them, the follow-up turns into a long string of questions the customer may stop answering.

Say what you are doing, not what you hope

Tell the customer your next step. "I am checking whether the change in the last release affects the reports page" is specific and honest. "We are fixing this soon" is a promise you may not keep.

If the investigation stalls, write again anyway. A short "still looking, nothing new yet, I will update you Thursday" keeps the thread alive. Silence is what makes customers leave.

Report the fix and ask for a retest

When the fix is live, write to the customer who reported it. Say what was wrong in plain words, what you changed, and how they can check it. Then ask them to confirm.

Hi Ana, the export on the reports page is fixed and live now. The problem happened when a report had no date range, and that case now works. Could you try the same export once more and tell me if it works for you? Thanks for the detail about Safari, it pointed us to the right place.

Keep the message to what the customer needs. Do not describe every line of code. A bug report answer that reads like a changelog wastes their time.

When you cannot reproduce it

Sometimes you cannot make the bug happen. Do not close the report with a shrug. Write back, say what you tried, and ask for one more detail. Name the browser version, the account type or the step before the error, and ask whether the problem still happens. Then decide.

If you still cannot reproduce it, say so and set the item to closed with an internal note listing what you tried. Keep the door open: tell the customer to write again if it returns, with the page URL and the time it happened. A reopened report with a timestamp is much easier to diagnose.

Report a bug that affects many customers

When one problem hits many people, do not write a long reply to each one. Send a short update to everyone who reported it, from your own email: what is broken, who is affected, what you are doing and when you will write again. Keep the same update for each person so the team answers consistently. When the fix is live, follow up with each reporter, because a shared update does not tell them the fix worked for their case.

Following up on a bug in Escuta Produto

Open the item in the product inbox and read the message, the page URL, the browser and the metadata before you write anything. Set the status to in progress while you work on it, so the rest of the team knows someone has it.

Send the follow-ups from your own email, to the address saved on the item. Record each message as an internal note. When the fix is live and the customer has confirmed it, set the status to done. If the fix is for a whole group of reports, search the inbox for the same words to find the others, because Escuta Produto has no merge feature, and you will want to follow up with each of them.

For the broader weekly routine that puts bugs first, see how to triage customer feedback. For the reply wording, how to reply to customer feedback has templates for each kind of message. If the same bug keeps arriving without details, check the widget docs for how the form is set up on your site.