Feature Request Clarification Questions and Reply Template

Read the original request and its discussion first. Write a one-sentence understanding of the task and mark the detail that is still unknown. If the customer has already explained the workaround, do not send a form that asks them to repeat it. A focused question should help the owner decide whether to investigate the problem, check an existing capability, or bring a clear need to review.

For a solution-only request, ask for a recent attempt: 'The last time you prepared this report, what did you need to do and where did the process slow down?' For an unclear outcome, ask what the recipient must be able to do with the result. Those answers can distinguish repeated filter setup from distributing a file, even when both customers ask for the same scheduled-report feature.

Keep impact concrete. Ask how often the task occurs, who performs it, what remains possible, and what the workaround costs in the customer's own terms. Record an estimate as an estimate, with its source. Do not turn 'every Monday' into a measured time saving or infer product-wide demand from one detailed conversation.

Acknowledge the suggestion and reflect only what you know. Then select the smallest unanswered question that could change the next review step. The reply below includes two prompts, but remove either if it is already answered or unnecessary. Asking for a small recent example is usually easier to respond to than asking a customer to design a complete specification.

Offer the established private support route when the example needs account details or confidential files. A public request can retain a safe problem summary while the evidence stays in an internal record. Avoid requesting a full customer dataset when a description of the task is enough. Do not require the customer to justify the same problem in several channels.

State the next review action only if someone owns it. Receiving more detail does not mean the feature is approved or scheduled. If you promise a progress checkpoint, name a realistic checkpoint and retain it in the owner's queue. Otherwise, describe how the answer will inform review without implying a release date.

This fictional exchange concerns an imaginary analytics product. A customer writes, 'Can you add a scheduled report every Monday?' The reviewer does not know whether the difficulty is preparing the content, remembering the task, or delivering it to someone else. Asking 'Would a weekly email help?' would test the reviewer's proposed answer before establishing the customer's actual obstacle.

The reviewer instead asks about the last Monday report. The customer says they rebuild the same date and team filters, download a file, check it, and add a short explanation before sending it to a colleague. Their main frustration is recreating the filters. They still want to review the file before anyone receives it. This answer weakens the assumption that automatic email delivery is the required outcome.

Reflect that distinction and invite correction: 'It sounds as though you want to reopen the same report settings, then check the output before sending it. Have I understood that correctly?' If the customer confirms, retain scheduled delivery as their original suggestion and record reusable settings as a candidate response. Neither confirmation proves that saved filters will solve the problem; the next step could be checking the current product workflow or reviewing a small prototype.

Another account may need unattended delivery to a different system. Keep that task separate even if its request uses the same title. A shared feature name is not enough evidence to merge distinct needs, and one conversation does not establish how common either need is.

The handoff should preserve the customer's original wording, your confirmed interpretation, and what remains uncertain. Link the source rather than replacing it with a polished summary alone. Distinguish observed behavior, customer statements, estimates and your hypotheses. That makes it possible for the next reviewer to challenge the interpretation without asking the customer to start again.

Stop clarifying when you have enough context for the next owned decision, rather than waiting for a fully specified feature. A reviewable problem can still have unknown reach, implementation cost or technical feasibility. Give those gaps to the appropriate internal owner. The customer does not need to supply your engineering estimate or prove the size of your addressable audience.

If no answer arrives, keep the request and mark the evidence gap. Silence is not evidence that the need has disappeared. Decide whether the team can investigate from existing sources or should leave the item awaiting context. If you contact the customer again, explain the specific missing detail and use the existing communication policy rather than repeatedly sending the entire questionnaire.

In Feedbackly, a request can retain a public-safe title and description, discussion, votes and visible status. Keep private source references and this detailed handoff in your internal planning record. Under review, Planned, In progress and Completed describe public progress; they do not automatically represent evidence confidence or create custom clarification fields. Review a copied reply before posting it, then use the weekly review to decide the next action.