Feature Request Templates: Submit, Triage and Reply

"Add dark mode" is a feature request. So is "I hike before sunrise and the bright map wakes my partner in the tent." The second one tells you who has the problem, when it happens and why it matters, and it might lead you to a better fix than the one asked for. A template helps users write the second kind. This post gives you three: one for the person asking, one for your own triage, and one reply for each status a request can reach.

The short version

• Ask users for the problem, not the solution: who they are, how often it happens, what they do today and what it costs them.
• Keep your own triage card short: sources, votes, revenue, duplicates, effort, decision.
• Reply at every status change, in plain words, and always give a reason when you say no.

Template 1: the feature request

This is what you show the person writing the request, as placeholder text, a help note under the form, or a set of fields in your own form. Five prompts are enough. More than that and people give up.

Then a title. Ask for a short name for the idea ("Offline maps"), not a sentence. Good titles make duplicates easier to spot and make the board easier to scan.

Why these five

• Problem stops you building the wrong solution. People describe the feature they imagine; the problem lets you find the best one.
• Who tells you which kind of user is asking, which matters when you weigh requests against each other.
• Frequency separates a daily annoyance from a once-a-year wish.
• Workaround shows how badly they want it. A painful workaround is a strong signal.
• Impact tells you what success looks like, which helps you know when you are done.

Template 2: the internal triage card

This one is for you. Fill it in when a request is worth a decision, usually when it climbs the vote count or when several duplicates point at it. Keep it next to the request, or in the issue you create from it.

Request:        Offline maps
Sources:        In-app board, 6 App Store reviews, 4 support emails
Votes:          248
Revenue behind: Sum of MRR of the voters
Duplicates:     "Download trails", "Use without signal" (merged)
Problem:        Hikers lose the map without signal
Effort:         Large (tile storage, download UI, sync)
Decision:       Approved, target next major release
Tracker link:   Issue in your tracker
Reply sent:     Yes, on Approved

If you want a scoring method on top, RICE prioritisation maps neatly onto this card: votes are reach, revenue is a fair stand-in for impact, and effort is already there. For getting requests from every channel onto one list before you triage, see Get your iOS feature requests into one list.

Template 3: a reply for each status

Every request moves through some of these six statuses: Pending, Approved, In Progress, TestFlight, Completed and Rejected. Each move is a chance to tell the people who asked what is going on. Short and honest beats long and polished.

Pending

Thanks for posting this. We read every request, and we will update this one when we have decided. In the meantime, votes from other users help us see how many people need it.

Approved

Good news: we are going to build this. We have not started yet, and we will update the status when we do. If you have details about how you would use it, add them as a comment.

In Progress

We have started work on this. Here is what the initial version will cover: [scope]. Here is what it will not cover yet: [out of scope].

TestFlight

This is now in our TestFlight beta. If you would like to try it before the App Store release, join here: [public TestFlight link]. Tell us what works and what does not.

Completed

This is out in version [x] on the App Store. Update the app and you will find it under [where]. Thank you for asking for it, and for your patience.

Rejected

We have decided not to build this, and we want to be clear about why: [reason]. [If there is one: here is what you can do instead.] We know this is not the answer you hoped for, and we are grateful you took the time to ask.

A rejection without a reason feels like being ignored. A rejection with a reason, even a reason the user disagrees with, earns respect. Good reasons are specific: "it would need an account system we do not want to add", "it conflicts with how we handle your privacy", "fewer than ten people have asked in two years".

How FeedbackKit fits in

FeedbackKit's ready-made submit form, from the Swift SDK, asks for a title, a description, a category (Feature Request, Bug Report, Improvement or Other) and an optional email address. It has no custom fields, so the five prompts in Template 1 go into the description. If you want them as separate fields, build your own form in SwiftUI and combine them before you submit (Swift docs):

let description = [
    "Problem: " + problem,
    "Who: " + who,
    "How often: " + frequency,
    "Workaround today: " + workaround,
    "Impact: " + impact
].joined(separator: "\n\n")

_ = try await SwiftlyFeedback.shared?.submitFeedback(
    title: title,
    description: description,
    category: .featureRequest,
    email: email
)

Once a request is on the board, users vote and comment inside your app, and a new request starts with its submitter's vote. Here is how the board looks, with sample data from a fictional hiking app:

Using the reply templates

FeedbackKit uses exactly the six statuses above, on every plan. Pro and up choose which ones a project uses. Voting stops on Completed and Rejected. You can post the replies from Template 3 as comments on the request, from the web dashboard or the admin apps for iPhone, iPad and Mac. Users see them in the app, marked as coming from your team.

Status changes can also send an email. The person who submitted the request is emailed, on every plan, when the new status is on the project's list and they gave an address. A new project's list is Approved, In Progress, Completed and Rejected. Choosing a different list needs Pro, and emailing voters who opted in needs Team. When you reject a request, you can add a reason. It is shown on the request in the app and included in the status email. Closing the loop with status emails explains the rules in full, and plans are on the pricing page.

Copy the templates, adjust the wording to sound like you, and use them for a month. Start free and put them to work on a real board.