A feedback receipt that promises an answer, not a feature

A customer can deserve a clear answer even when a product team cannot accept the request. Here is a proposed feedback receipt for keeping that distinction visible.

Use five fields:

• Need: what the person was trying to accomplish, in words they recognize.
• Evidence: the example supplied, with private details removed.
• Decision owner: one named role responsible for deciding the next step.
• Response date: when the person will hear back, even if the decision is still open.
• Outcome: investigate, try a bounded change, defer with a reason, or decline with a reason.

Fictional example: a member cannot find their saved posts. The support owner confirms the problem description; the product owner checks whether the navigation or the explanation needs changing. “We will respond by Thursday” is an update commitment. “We will ship a new menu by Thursday” is a delivery commitment and should not be implied by the first.

A useful reply might be: “We understood that returning to saved posts took too many steps. We are comparing a clearer label with a navigation change. Mira owns the decision. We will update you Thursday, including if we need more time.”

Let the person correct the receipt before treating it as an accurate account of their need. Keep the decision owner responsible for closing the loop; offering feedback should not automatically assign the customer more work.

To try this, review five fictional requests and ask: can a new teammate identify the need, owner, next update, and actual promise? Which field tends to disappear when teams get busy?