How to ask a clarifying question about vague feedback

Ask one question that changes what you do

A vague message is a message you cannot act on yet. "It does not work" tells you that someone is unhappy, but not where, when or how. A clarifying question closes that gap, and the best one is the question whose answer would change your next step. Before you write anything, decide what you would do with each possible answer. If the answer would not change anything, do not ask it.

This keeps the conversation short. The reporter sees that you have a reason for the question, and you avoid a list of six questions that nobody will answer. A single good question, sent from your own email, gets far more replies than a form with ten fields.

Ask one question at a time

When you have several gaps, resist the urge to list them all. A message with five questions feels like homework, and most people answer the first one, skim the rest and do not reply at all. Pick the question that matters most, ask it, and wait for the answer. If you still need more, ask the next question in your next reply.

The one exception is when two questions are really one. "Which page were you on, and what did you click?" is one question about the same moment. "Which page, which browser, which plan and which date?" is four questions, and it reads like a survey.

Examples of questions that work

The questions that get answers are specific, easy to answer in a sentence, and tied to a moment the reporter remembers. Compare these:

Vague question	Question that works
Can you tell me more?	Which page were you on when the total went blank?
What browser are you using?	Are you on Chrome or Safari, and which version if you know it?
Is this still happening?	Did the export fail again today, or only the one you tried yesterday?
What did you expect?	When you clicked save, what did you expect to see on the screen?
Can you send details?	Could you send the name of the project you were exporting?

The working questions point at something concrete. They ask for a name, a page, a click or a moment, and each one gives the reporter an easy way to answer. Avoid questions that ask for an opinion when you need a fact, and avoid questions the reporter cannot answer without a developer tool.

Give a reason for the question

People answer questions more readily when they know why you are asking. A reason takes one sentence and changes the tone from interrogation to help. "I want to reproduce this on the same page you used" tells the reporter what their answer will do. "To investigate, I need more information" tells them nothing.

Here is a template that asks one question, gives the reason and thanks the reporter for what they already said:

Hi Omar, thanks for telling me the import stopped partway. That helps. I want to reproduce it on the same kind of file, so the one thing I need is the name of the file type you imported, such as CSV or XLSX. Could you reply with that when you have a moment?

Keep the reporter engaged

Engagement comes from three habits. First, make the next step easy. A reply that needs one word is more likely to get an answer than one that needs a paragraph. Second, show progress. If the answer helps you find the cause, say so: "That narrows it down to large files, which is useful." Third, thank the person for the part that worked, not for the whole message, because specific thanks reads as attention.

Do not chase with the same question. If the reporter has not answered after a reasonable wait, send one short nudge that says what you still need and that you can close the item if they prefer. That gives them a clear choice. A second and third reminder without new information feels like pressure and often ends the conversation.

Know when to stop asking

There is a point where another question costs more than it returns. Stop when you can act, even if the action is only to write a note and set a status. Stop when the reporter has answered twice and still cannot give you the detail, because at that point the honest move is to tell them what you tried and what you will do next.

If you stop without an answer, say so in the internal note. Write what you asked, what you received and why you stopped. A teammate who reads the item later should not have to ask the same questions again.

Templates for the three common gaps

For a missing page or step, ask where the problem happened:

Hi Ines, thanks for the message about the blank total. Which page were you on when you saw it? I can check the same page and see what the total should show.

For a missing sequence, ask what the reporter did:

Hi Ines, thanks for reporting this. When you clicked save, what happened next? Did the page reload, or did nothing change? Either answer will help me find the cause.

For a missing time, ask when it started:

Hi Ines, thanks for telling me the export failed. Did it start failing today, or was it working last week? That tells me whether to look at a recent change or an older one.

Asking follow-ups from the Escuta Produto inbox

In the Escuta Produto inbox, each item shows the message, the page URL, the browser and any metadata you passed. Read those first. Many clarifying questions answer themselves, because the page URL already tells you where the problem happened, and you only need to ask about what the page cannot show, such as the exact step or the time.

Write the question from your own email to the address on the item. If the item has no address, you cannot ask, so note what you would have asked and set the status to new or closed. For the reply patterns that come after you have the answer, read how to reply to customer feedback. The steps for a bug once you can reproduce it are in how to follow up on bug reports. The widget fields that prevent vague messages in the first place are in the widget docs.