Write responses users love

The most underrated part of running a feedback program isn't collecting feedback - it's responding to it. Every response is a chance to build trust or erode it. This lesson gives you templates and principles for responding well, fast.

The acknowledgment principle

Every post deserves a response. Every single one.

Silence is the worst possible response. It tells users their feedback went into a void. Even a two-sentence acknowledgment changes the dynamic from "did anyone see this?" to "they're listening."

You don't need a detailed response for every post. You need a response. The bar is low: "Thanks for sharing this. We've logged it and will review it during our next planning cycle." That's enough.

How quickly? Within 48 hours for most posts. Within 24 hours during your first two weeks after launch. The initial response time sets user expectations for the entire program.

Templates for every status

These are starting points. Adapt the tone to match your brand, but keep the structure.

Acknowledging a new post (Open → Under Review)

Thanks for submitting this! We've seen it and we're evaluating how it fits with our current priorities. We'll update the status as we make a decision.

Adding to the plan (Under Review → Planned)

Good news - we've decided to build this. It's now on our roadmap. We don't have a specific timeline yet, but we'll update this post when work begins.

Starting work (Planned → In Progress)

We've started working on this. We'll update here when it's ready.

Shipping it (In Progress → Complete)

This is live! [Brief description of what shipped and where to find it.] Thanks to everyone who voted and commented - your feedback directly shaped this.

Saying no (any status → Closed)

We've decided not to pursue this, and I want to explain why. [Specific reason: doesn't align with product direction, low demand relative to effort, solved by an existing feature, etc.] We know this isn't the answer you were hoping for. If your needs change or you find a workaround, we'd love to hear about it.

Saying later (any status → Under Review, staying there)

This is on our radar but not in our current plan. We're focused on [current priority] right now. We'll revisit this in [timeframe or next planning cycle] and update the status then.

Saying no gracefully

Closing a post is the hardest response to write. Here's what makes a good one:

Be specific about why. "We've decided not to build this because our data shows only 2% of users would benefit, and the engineering effort is significant" is infinitely better than "This doesn't align with our vision." Vague rejections feel dismissive. Specific ones feel respectful.

Offer alternatives when they exist. "You can achieve something similar by using [existing feature] with [workaround]." Even partial solutions show you understood the underlying need.

Don't apologize excessively. One "We know this isn't the answer you were hoping for" is enough. Over-apologizing sounds insincere.

Leave the door open. "If this becomes more pressing for you, resubmit and we'll re-evaluate." Needs change. Products change. Today's no might be next year's yes.

Celebrating shipped work

This is the payoff for the entire feedback program. When you ship something that users requested, make it count:

1. Change the status to Complete. Every subscriber gets notified automatically.
2. Leave a comment. Thank the users who contributed. Be specific: "This shipped because 40 of you voted for it and the discussion in the comments helped us nail the design."
3. Link the changelog entry. If you published a changelog post about the feature, link it. This connects the feedback loop from request to delivery.

Don't rush this step. It's the moment that turns passive users into active advocates. When someone sees "the thing I asked for got built and they told me about it," they come back and contribute more.

See Changelog for how to create and link changelog entries.

Private comments for coordination

Not every conversation should be public. Use private comments to:

• Discuss whether to accept or reject a post with your team
• Share internal context (customer tier, related support tickets, technical constraints)
• Coordinate who will write the public response
• Flag posts that need a senior decision

The public comment is the polished output. Private comments are the messy, honest internal discussion. Keep them separate.

See Private comments for how to use them.

When to pin a response

Pinning marks a comment as the official response. Use it for:

• The definitive answer on a post (especially after discussion)
• Status explanations that provide important context
• Workarounds or alternative solutions

Don't pin acknowledgments or "thanks for submitting" comments. Pin the comment that someone arriving at this post for the first time needs to read.

Common mistakes

Writing too much. A three-paragraph response to a one-sentence feature request is overkill. Match the length of your response to the complexity of the post.

Being defensive. "We actually already have this feature" is a bad response to a feature request, even if it's true. Try "This is available in [location] - let us know if it doesn't quite cover your use case."

Using corporate speak. "We're committed to continuously improving the user experience" says nothing. "We're building a CSV export this month" says everything.

Forgetting to follow up. If you said "We'll update this post when work begins," actually do it. Broken promises are worse than no promises.

What's next

You're responding to feedback like a pro. Now keep things organized as volume grows. Next: Merge and organize.