Bugs & support
How to answer "is this on the roadmap?" without a support queue
· 4 min read · By the Sikia team
On this page
- Why do roadmap questions take so long to answer?
- How do you answer roadmap questions consistently?
- What should you say for each status?
- Should you give dates?
- How do you say no?
- How do you get fewer roadmap questions in the first place?
- What if you don't know the answer?
- Common mistakes
- Doing this with Sikia
- FAQ
"Is this on the roadmap?" is the question that never stops coming. Each answer takes a minute, but the minutes add up, and when different teammates answer from memory, users get different answers.
Why do roadmap questions take so long to answer?
The answer usually lives in someone's head or in a private tracker. Whoever sees the question has to find the right person, check the status, then write a reply that doesn't overpromise. The fix is to make the answer something anyone on the team can look up and link in seconds.
How do you answer roadmap questions consistently?
- Keep one source of truth. A public roadmap built from the statuses of real requests, not a separate slide that drifts out of date. The public roadmap guide covers how to set one up.
- Give every item a stable link. The best answer to "is X coming?" is a link the person can follow.
- Define your statuses. Write one sentence on what each status means and share it with the team.
- Use a standard reply per status. Not word for word, but the same substance from everyone.
- Let the asker follow the item. A vote or follow means they'll be told when it moves, so they don't have to ask again.
What should you say for each status?
| Status | What it means | Example reply |
|---|---|---|
| Not on the board | Nobody has asked yet | "Not yet. I've added it here: [link]. Vote on it and you'll hear when it moves." |
| Open | Requested, not decided | "It's been requested but isn't planned yet: [link]. Your vote counts toward that." |
| Planned | Decided, not started | "Yes, it's planned. No date yet. Follow it here: [link]." |
| In progress | Being built | "We're building it now: [link]. You'll get a note when it's out." |
| Shipped | Released | "It shipped in 2.4. Here's how to use it: [changelog link]." |
| Closed | Decided against | "We've decided not to build this, because… Here's what you can do instead." |
Should you give dates?
Only if you're confident and willing to post an update when the date slips. For most small teams, "now, next, later" or a rough quarter is the honest limit. If you did give a date and you're going to miss it, say so in the same thread before the user has to ask.
How do you say no?
Directly, with a reason and an alternative when there is one. Suppose @jonas asks whether a fictional habit-tracker app will add a social feed:
"Not something we plan to build. We want to keep the app private and quick to use. If you want accountability, you can share a weekly summary link with a friend."
A clear no costs less goodwill than a vague "it's on our list" that never moves.
How do you get fewer roadmap questions in the first place?
- Pin the roadmap link in your Discord and Slack channels, your help menu and your docs.
- Keep a short FAQ for the questions you get every week, such as "Is there an Android app?"
- Link the roadmap item from every changelog entry, so readers learn where to look.
- Tell voters when things move. People who get updates stop asking. See how to close the feedback loop.
What if you don't know the answer?
Say you'll check, log the question against the request, and reply in the same thread once you know. Guessing is how teams end up with conflicting answers in public. If these questions arrive in chat, see how to collect customer feedback in Slack.
Common mistakes
- Answering "it's on our list" without saying which list or what that means.
- Keeping the real roadmap private while making public promises.
- Forgetting to follow up when a status changes.
Doing this with Sikia
In the Slack and Discord channels it listens to, Sikia recognizes questions like "is X on the roadmap?" and answers in the thread from the current roadmap. There are also /sikia ask and /sikia status slash commands. When you publish a changelog entry, Sikia emails everyone who voted for the requests it ships and replies in the original Slack or Discord threads.
FAQ
What if a request isn't on the roadmap at all?
Add it as a request, share the link, and tell the person how they'll hear about progress. That turns a dead-end question into a vote.
Who should answer roadmap questions?
Anyone on the team, as long as they answer from the roadmap rather than from memory. Shared reply templates keep the substance consistent.
Should you share your internal roadmap?
No. Share the public one built from user-facing requests. Internal work, security fixes and unannounced launches stay private.
Do this without the spreadsheet
Related guides
- Roadmaps & changelogsHow to run a public roadmap users trustUsers trust a public roadmap that is current, honest about uncertainty and tied to what they asked for. Show only what you're committed to, use a few clear statuses instead of exact dates, review it every couple of weeks, and tell voters whenever their item moves.
- Closing the loopHow to close the feedback loop with usersClosing the loop means telling users what happened to their feedback at each step: you heard it, you decided, and you either shipped it or won't. Record who asked and where for every request, merge duplicates without losing anyone, and use short templates so each reply takes seconds.
- Collecting feedbackHow to collect customer feedback in SlackRoute feedback into one internal Slack channel with a fixed posting format, and capture requests from customer channels yourself instead of sending customers to a form. Move each request into a tracker with the customer's exact words, who they are and a link, review weekly, and reply in the original thread when it ships.