How to Respond to Feature Requests: Real Replies to Copy
Shayan, Founder14 min read
Every feature request gets one of six answers: we are building it, not now, tell me more, no, it already exists, or it shipped. A reply works when it says which of the six it is, gives the reason in a sentence, and says what happens next. Of 35 declines sent by staff on public boards this year and last, 17 give no reason at all.
Nearly all the reply templates on the pages that rank for this question are invented, and they share a vocabulary. Across 20 of those pages, a thank-you for taking the time appears on 12, a version of "I can see how" on 8, "pass it along" to the team on 4, and "right now" on 8. Customers recognise the pattern. One Hacker News user described the reply they get from a tool they use, in August 2022: "hey, great that you'd be interested in this feature! It's not something we are planning to build! why not add it to our suggestions board though - the more people who vote on it the more chance we might consider this in the future!" and added, "of course nothing on the suggestions board is ever implemented." The same person wrote what they would rather hear: "sorry, your use case is an edge case and not something we support; you could try doing X or Y but what you're attempting is outside our typical use and not on our roadmap."
The replies below are real. They come from staff on the public boards and forums of 14 companies, among them ClickUp, Ahrefs, Retool, Glide, Descript, Supabase, Vercel, Zapier, and Airtable, 97 replies as the boards stood on October 31, 2026, plus the 58 maintainer and vendor replies collected for the feature requests guide and a few replies quoted on the ranking pages. Each answer gets the replies that hold up, some that do not, and a template in plain words.
1. We are building it
A short yes is enough when it is true. Glide's CEO, on a deep-linking request in September 2019: "Yes! Deep linking is planned." A ClickUp staff member on its mobile board, on a request with 4,430 votes, in October 2026: "Offline task editing is almost done! You'll be able to make changes with no connection and they'll sync once you're back online. No firm date yet, but it's close."
A longer yes is needed when the plan has conditions. Retool's product team, on public app sharing, in September 2026, named the quarter and the catch: "Public links for the new app builder are something we plan to ship in Q4", then "To set expectations, we're currently planning to make Public Apps available to Enterprise customers first, before considering expansion to other plans. In the meantime, if you need to share an app outside your organization, you can add people as External Users."
Of the 97 replies, 13 name a date, quarter, or version, and 8 say outright that there is none ("No ETA yet", "I can't give you a timeline", "No ETA on if/when"). Ghost's staff said "Nice - we're definitely going to do this!" to a nested-tags request in April 2018, "This is now in progress" that November, and in February 2019 "this actually ran into a few technical challenges and got put on pause at the end of last year." The thread was closed in 2020, still planned. Ghost never gave a date, and the yes still aged badly; a missed date would have aged worse.
Yes, we're building this. [One sentence on what it will do.]
I can't give you a date yet; when it's in beta I'll post here
and you'll get an email. Until then, [the workaround, if any].2. Not now
Not now is the most common answer among the 97 replies, 22 of them. Eleven say it in words, and ten of the eleven carry a time qualifier: "not something we've been able to fit into our roadmap for this quarter", "not on our immediate roadmap right now", "we don't have plans to add private submodules or SSH submodules at this time".
A status label without words gets read as never. ClickUp moved a 636-vote request to "not on the roadmap" in December 2025 with a template reply ("While this isn't something we're planning to add to our roadmap right now, we truly appreciate your input"), and nine days later a second staff member had to walk the label back: "Just to clarify, the new status only means it's not on our immediate roadmap right now, not that we'll never do it." On the board's 9,018-vote request for undo, which carries the same label and no staff text among its recent activity, the comments read "to not even be on the roadmap with 9,000+ upvotes (!!) is very uh... surprising lol" and "8 years and 9k+ upvotes. Undo is a core basic functionality, how is it not considered for the roadmap at all?"
The not-now that holds up names what is ahead of the request. A Retool team member, on developer dark mode, in January 2023, even with its "on our radar": "Currently, this is not something we've been able to fit into our roadmap for this quarter, but it's definitely on our radar. For reference, a lot of our resources for the next quarter will be dedicated to some larger planned projects (for example, revamping the table)." Ten months later, when a user checked in, the same person answered: "Unfortunately, we had several large scale projects that were prioritized over this feature this year. That said, we are still tracking feedback and requests for this feature [...] Really wish I had better news". No ranking page has a template for that second message, the update when nothing has changed.
Not now. [What we're working on instead, in one sentence.]
I've linked your request to [the existing one / the board], and
you'll get an email if its status changes. If [the condition that
would change the answer], tell me here.3. Tell me more
Ask when the answer could change what you build. Ahrefs's Tim Soulo, on a rank tracker request in September 2020: "what is the use case for that? And where do you want to see this data in the interface?" ClickUp staff, on a 2,792-vote formula-fields request, read the request back before answering: "It seems like you have three asks here", then the three in a list (slow formula fields, no calculations on aggregated fields, formula fields everywhere), then "Is that an ok summarization?" On a request for muting channels, the same team pointed at the setting that existed and asked the better question: "Was there anything you could share on why you thought this functionality didn't exist? Was it hard to find?"
Jitbit's Max Al Farakh wrote in 2014 that "50% of all feature request can be solved using existing features", and Frill's co-founder gave a similar figure in August 2026: "Most of the requests that look useless are just missing one sentence of context. We ask one question back, and about half of them turn into something we can actually act on." Buffer's chief happiness officer, quoted by Help Scout, recommends asking customers what they are ultimately trying to achieve: "We can learn a lot from those kinds of conversations, if they're willing to indulge us".
From the outside, a question followed weeks later by a no looks like a delay. ClickUp staff asked for use cases on a subtask-template request in July 2025, then a month later told the thread the capability already existed and moved it to "not on the roadmap". On another, a staff member asked which part of the flow was "the biggest time sink" in early December 2025, and the post went to "not on the roadmap" on December 30. Ask only when the answer can still change.
Quick question so I get this right: what are you trying to get
done when you need this, and what do you do today instead? A
sentence or a screenshot is plenty.4. No
Thirty-five of the 97 replies decline: 14 give a product or business reason, 4 explain only why the thread is being closed, and 17 give no reason at all. The ones without a reason are concentrated in community-manager and support replies ("We'll pass this onto our team for future consideration."), and every decline from Descript, Glide, and Supabase has one.
The reason can be short. Supabase's kiwicopple, on a request to host TimescaleDB, in February 2021: "I reached out to the founders of TimescaleDb. Unfortunately their license won't allow it because we're a hosted platform. I understand their stance - they have their own hosted platform." Descript, closing a request after a change of architecture: "We've since moved to full cloud-based file storage so this is not something that will be considered any time soon." Glide's community team, on bringing back push notifications, gave the reason and three alternatives: "the push notification issues with PWAs in iOS are a blocker. They're caused by dependencies beyond our control. That's why we kept the feature in beta but ultimately deprecated it." Slack, on Twitter, to a user who wanted threads turned off: "We're afraid we won't be providing an option to turn them off. We'd encourage adopting some best practices around them."
The companies that write about this agree on the shape. Basecamp, on its company blog in 2018: "If we're not going to do it, we tell the customer so. This sets expectations up front and lets the customer know if they need to explore an integration, use a workaround, or consider switching to a different product." Raycast's Thomas Paul Mann, in 2021: "If we receive a suggestion that we won't build, we let them know. We want to set the right expectations. If they share our opinion and adopt the tool, that's great. If they stop using the tool, that's fine as well." The customer's side of the same policy, from a review of a Basecamp reply that said no and gave a workaround: "She gave me an answer that I really didn't want to hear, but gave me a work-around that was elegant enough that I forgot to be sad I didn't get what I asked for."
No, we won't be adding this. [The reason, in one or two sentences.]
What you can do instead: [the workaround, integration, or other
tool]. If [the thing that would change our mind] changes, the
request on the board is where we'll say so.5. It already exists, or someone already asked
Eight of the replies point at a feature the requester missed. ClickUp, closing a 56-vote request: "You can change today's Inbox to be sorted by oldest first or newest first!" Descript, closing one with a help-center link and the answer: "It's not in launch items specifically - it's a setting in Descript menu tray / screen recorder button." When the thing exists on a higher plan, say so plainly, as Ahrefs did: "It is possible to export more than 150K keywords with an Enterprise plan".
Duplicates get merged, and the reply says what the merge does for the person. A ClickUp staff member on its mobile board: "We are working on this right now actually as part of another request. I will merge these so you can keep up to date with task view changes." A Zapier community moderator, on a request that had been raised before: "I have added your vote for it so you'll get an email the second it becomes available. No ETA on if/when you can expect to see this implemented but we'll be sure to come back to this thread with any updates in the meantime." None of the 37 top-ten pages across six searches for this topic has a reply for a duplicate.
Thanks, this one's already on the board as [link]. I've merged
yours into it so your vote counts there and you'll get the email
when its status changes. Nothing else to do on your side.Good news, this exists: [where to find it, in one line, with a
link]. If that isn't quite what you meant, tell me what's missing.6. It shipped
Of the 19 shipped replies, 17 say what shipped, 12 say where to find it or which version, and 3 name the person who asked. The best are short and specific. Ahrefs, on a request with 66 votes: "Export to Google Sheets is now available in all Keywords Explorer and Site Explorer reports!" ClickUp's calendar lead, to one of the people who had asked on a 4,066-vote thread, opened with "Hey Alejandro" and went on: "you can now see all your GCal events in ClickUp and find those empty time blocks to schedule tasks into. Your workflow should work end-to-end now." Airtable's staff, to the person who asked for email confirmations: "Thanks @kuovonne, and great idea! This is now implemented".
Some arrive late. Ahrefs, in April 2020: "Oops. Forgot to update you guys. We have released two reports". Another Ahrefs closure, in July 2020: "This feature to add keywords to Rank Tracker from Keywords Explorer has been added some time ago." Ghost's firm confirmation of a release came seven weeks after it, to a user who had asked the day it shipped. The shipped message is the easiest of the six to write and the easiest to forget.
You asked for [the request, named]. It's live: [what it does, one
sentence], under [where to find it]. [One caveat, if there is one.]
Thanks for asking for it.The seventh message: taking a yes back
The ranking pages have no template for the message that reverses an earlier yes, and the boards show it is needed. ClickUp moved a 1,319-vote QuickBooks integration from "planned" in 2019 to "future" in August 2025 with "We've updated the status of this request to reflect the current progress. There is no current estimate". Atlassian paused a 2,798-vote request it had accepted, in April 2023: "As part of the difficult decisions that have been made to prioritise the most critical work for our customers, we've had to put this work on pause for the next few quarters." ClickUp's calendar lead opened a 2026 update with an apology for a status someone had set by mistake: "excuse us 🙈 for the incorrect change of status that recently happened to this task. I can assure you we are very much actively working on this."
If the plan changes, the message says so, says why, and says what the status means now. A label changed with no sentence beside it produces comments like the ones on the undo request.
Status changes without words
Of 135 Canny posts across ClickUp, Ahrefs, Descript, Framer, and tl;dv, 88 had a status history, and in 28 of those the ten newest activity items held no staff text; 40 of the 87 visible status changes had an empty comment. Six of ClickUp's most-voted requests, between 2,197 and 9,018 votes, had no staff words in view. Zapier's community team, on threads that had been closed automatically, explained: "topics auto close after a certain time frame and truly isn't done out of ill intent."
The label carries the routine work. Buffer tells requesters "We'll notify you when a feature goes from being 'Planned' to 'In Progress' to 'Complete'." Zapier ties the vote to the email: "your vote ensures you're emailed if that changes." Dropbox: "Follow ideas to get updates when statuses change". The sentence beside the label is where the reason goes, and it lives on the request page, since the status email itself carries no note.
The status change is the reply.
On a UserJot board, changing a request's status emails everyone who posted, voted, or commented, and a new comment from your team emails the person who asked. Free to start.
Replying from the inbox
Many requests arrive in a support conversation, and that is the reply the Hacker News user above was quoting. On UserJot, the widget holds the board and, with Conversations on (in beta, on every plan), the chat. When a customer asks for something in chat, Juno, the support agent, searches the public feedback board, shows them the matching request, and once they confirm, adds their vote or files the request. The support reply then has something to point at: the request, its status, and, when they left an email, the message that follows when the status changes.
From the board side, a new comment from your team on a request emails the person who posted it, and a status change emails everyone who posted, voted, or commented. Internal comments stay with the team. Admins can post a request on behalf of a customer who wrote in by email, so the not-now and the no both end with a link to the request. Marking a request Planned or In Progress puts it on the public roadmap with no second step.
What to leave out
The phrases to cut: "I'll pass this along to the product team" with nothing after it, "we'll keep it on our radar" (Enterpret's guide, from August 2026, calls it "a decline with extra steps"), "stay tuned" with nowhere to tune to, and a thank-you paragraph in front of a one-line no. The Hacker News user above: "As a customer I'm much more likely to cancel a service if I get Vague! Happy! Pointless! customer service interactions rather than honest responses."
Leave out the date unless you would bet on it. Leave out "other customers have asked" unless you give the number; the board does that for you. Leave out the apology for the answer, and keep the apology for the delay. Which of the six it is, why, and what happens next, in three sentences.
Frequently asked questions
How do you respond to a feature request?
Say which of six answers it is: building it, not now, tell me more, no, already exists, or shipped. Give the reason in a sentence. Say what happens next and where the person will hear about it. Most of the replies above from ClickUp, Ahrefs, Glide, and Supabase fit in a few lines.
How do you respond to a customer about a feature request you will not build?
Say no, give the reason, and give the path that exists: a workaround, an integration, or another tool. Basecamp's policy is "If we're not going to do it, we tell the customer so", and the customer review of one such reply praised the workaround more than it minded the no.
Should you give a date?
Only one you would bet on. Of 97 staff replies on public boards, 13 named a date, quarter, or version, and 8 said there was none. Ghost's "definitely going to do this" from April 2018 was paused at the end of that year, and the thread closed in 2020. "No firm date yet, but it's close" from ClickUp is the honest middle.
What do you say when the feature already exists?
Where it is, in one line, with a link, and an invitation to say what is missing if that was not the request. ClickUp's "You can change today's Inbox to be sorted by oldest first or newest first!" closed a 56-vote request in one sentence.
How do you respond to a duplicate feature request?
Merge it into the existing request and say what the merge does for the person: the vote counts there and the status email will reach them. Zapier's "I have added your vote for it so you'll get an email the second it becomes available" is the core of the reply.
How do you tell a customer their feature request shipped?
Name the request, say what shipped and where to find it, and send it to everyone who voted and commented. Of 19 shipped replies on public boards, 17 said what shipped and 3 named the person who asked. "Oops. Forgot to update you guys" is the failure to avoid.
Should you reply to every feature request?
Reply to every one with a status, and in words when the status needs a reason. Raycast's team reads and answers each message; Basecamp's reads every one and does not promise a reply; Obsidian's does not reply and says so. What customers complain about is silence on a request with votes behind it, and a label with no sentence beside it.
What should a feature request reply never say?
"I'll pass this along" with nothing after it, "on our radar" without what is ahead of the request, a date you are not sure of, and a paragraph of thanks before a one-line no. The canned replies that work are the ones that say what happens next; the canned responses post has more on which to keep.
