What Is a Feature Request? How SaaS Teams Log, Triage, and Document Them

TL;DR

• A feature request is a customer, prospect, or teammate asking your product to do something it doesn't do yet, or to do something it already does in a different way.
• Most requests fall into four types: new features, improvements to existing features, integrations, and "this should work differently" requests that might turn out to be bugs.
• Teams that handle requests well follow one routine. They log every request in one place, triage on a fixed schedule, and write down what they decided.
• Writing down why you said "no" to a feature request saves you from having the same debate again.

Imagine this: a customer asks your support team whether they can export reports to CSV. The same week, a sales rep hears the exact same request on a call with a prospect, and your CEO gets a DM about it from an old contact. Then three weeks later, someone in a planning meeting remembers that request and asks, "Didn't we already decide on this?" Nobody can find or remember the answer, so the whole discussion starts over.

That's what happens when feature requests live in inboxes, call notes, and people's memories. Below, you'll learn what a feature request is, the types you'll see most, and a simple routine for logging, sorting, and documenting requests so each conversation only has to happen once.

What Is a Feature Request?

A feature request is a suggestion from a customer, prospect, or teammate asking a product to add something new or change how something works. It describes a need the person has, usually framed as the solution they'd like to see, and it gives product teams direct input on what to build next.

Feature requests get mixed up with a few other kinds of input, so it's important to know the differences:

• A bug report says something is broken, like the button doesn't save or the page won't load.
• A feature request says something is missing or should work differently.
• General feedback is an opinion, like "the dashboard feels cluttered," while a feature request points to a direction, like "allow me to hide the widgets I don't use."
• A user story is something your product team writes, often by combining several requests into one clear statement of what a user needs.

Types of Feature Requests

The type matters because it changes who looks at the request first. A new feature is a product decision, an integration usually needs an engineering opinion, and a "should work this way" request might turn out to be a bug that never needed a product discussion at all.

Why Feature Requests Matter for SaaS Teams

In a subscription business, customers decide whether to stay every time they renew. Feature requests are one of the clearest signals you'll get about what they need to keep getting value from your product, and requests come in without you running a survey or booking an interview with your customers.

Requests are most useful when you look at them together. If support, sales, and a handful of long-time customers all ask for CSV export in the same quarter, that's a pattern, and you can plan around a pattern.

There's a problem, though. A feature request is the customer's proposed solution, and the problem behind it is what you should act on. A customer asking for CSV export might only need to get monthly numbers into a finance spreadsheet, and a scheduled email report could solve that with less work. So when a request comes in, write down what the person asked for and what they're trying to get done, because the second part is more useful most of the time.

Where Feature Requests Come From

• Support chats and tickets: customers mention what they wish the product did while asking for help with something else.
• Sales calls and demos: prospects ask whether the product can do something, and the answer can affect a deal.
• Customer success check-ins: account managers hear about missing features during regular conversations with existing customers.
• In-app prompts and feedback forms: users submit ideas while they're using the product.
• Community threads: customers suggest ideas in public and other customers add their support.
• Internal teams: engineers, designers, and people in other departments spot missing features in their own work.

All these requests are important, but they're only useful if they end up logged in the same place.

How to Log Feature Requests

The most important rule is that every request goes into one place. It doesn't matter much whether that's a shared page, a feedback board, or a table everyone can edit. What counts is that a request mentioned in a support chat and the same request mentioned on a sales call end up next to each other, where someone can see they're the same thing.

Note: Give every entry the same set of fields so requests can be compared later:

• The problem, in the customer's words: what they're trying to do and what's stopping them.
• The solution they asked for: the feature as they described it, even if you suspect it's not the right fix.
• Who asked: the person and the type of account they're on.
• The source: support, sales, a check-in, the community, or an internal team, with a link back to the original conversation when you have one.
• The date: when the request came in.
• The status: where it stands right now, which stays "new" until someone triages it.

Before you add a new entry, check whether the log already has the same request. If it does, add the new person's name and what they said to that entry instead of making a new one. Over time, one entry with many names on it shows you how many people want the same thing, and that's much harder to see when the same request is scattered across lots of entries.

How to Triage Feature Requests

Triage is where you sort the pile and decide what happens to each request. Two things keep it working: a named owner, usually someone on the product team, and a fixed slot on the calendar so requests don't pile up for months. Once you have both, work through new entries in this order:

1. Merge duplicates. Combine entries that describe the same need, even if people used different words for it.
2. Check that it fits your plans. Ask whether building it would move the product toward the goals you've already set. A request can be popular and still be the wrong one to build if it pulls you in a different direction.
3. Size the demand. Look at how many people asked, which accounts they're on, and which channels the request came from.
4. Size the effort. Get a rough size from engineering, such as small, medium, or large. You don't need a detailed estimate at this stage.
5. Assign a status. Use a short, fixed list: planned, under review, not now, or declined. "Not now" means the idea is sound but the timing is wrong. "Declined" means you don't plan to build it.

If you want a more formal way to score requests against each other, our guide to product management frameworks and when to use each one covers common scoring methods.

How to Document Feature Request Decisions

Making a decision on a feature request is half the job. The other half is writing it down somewhere your whole team can find it months later, after the person who made the decision has moved on to other work. It's also the easiest step to skip, which is why the same requests keep coming back to the same meetings.

When You Say Yes

Once you decide to build a requested feature, write a short page (spec page) that explains what you're building and why. Keep the first version to a page or less and cover the basics:

• The problem you're solving, written from the customer's side
• Who asked, with a link back to the entry in your request log
• What you'll build, in simple terms
• What's not included in this version, so nobody assumes it is
• Open questions engineering or design still need to answer

Linking the spec page back to the request's entry in your log is important because, when the feature launches, you can see exactly who asked for it and notify them. When the spec grows past a single page, our guide on how to write a product requirements document walks you through the full format.

When You Say No or Not Now

A declined request needs two things written next to it: the reason, and what would make you revisit this request. Something like this works:

• Declined: CSV export. Most of these requests came from teams who wanted monthly numbers in a spreadsheet, and the scheduled email report covers that. 
• Revisit if: customers start asking for raw data access for their own analysis.

That short note does a lot of work. It helps the support team answer the next customer who asks for an update without pinging the product team. Sales now knows not to promise the feature on a call. And when someone raises the idea again, the discussion starts from the reason instead of from zero.

Keep a Decision Log

Put every triage decision on one page that anyone in the company can find. A simple table is enough:

The log becomes the first place people check before raising a request in a meeting. Over time, it's also a record of how your product thinking has changed.

Use Version History When Decisions Change

Decisions rarely stay the same. A "not now" can become "planned" after a big customer signs, and a planned feature can get cut when priorities change. When that happens, update the decision log instead of starting a new one. Version history keeps earlier versions of the page and highlights what changed, so you can always trace how a decision got to where it is.

How to Follow Up With Customers on Their Feature Requests

The person who asked for a feature would want to know what happened to it. And because your log records who asked, you can tell them directly when the feature launches. In your release notes, you can also mention that the feature came from customer requests.

For requests you're not building, a short, honest reply works better than silence. Keep a template your support and sales teams can adapt:

The reason for not building the requested feature should come straight from your decision log. That way, every customer hears the same answer, and nobody on your team has to guess why the decision was made.

Where Should You Keep Feature Requests?

There are two jobs here, and they don't have to happen in the same tool:

• The first job is intake: dedicated feedback boards are built for collecting requests, letting customers vote on them, and showing a public status.
• The second job is memory: a wiki is where the reasoning lives, including the spec pages and a decision log that records why each decision was made.

Many teams use both. The board gathers what customers want, and the wiki keeps what the team decided and why.

What to Look for in a Request Log

Whatever you use to keep your request log, it should have:

• One shared place that everyone on the team can add to
• The same fields on every entry
• A fixed list of statuses
• An easy way to spot and merge duplicates
• A link from each request to its spec page
• Version history, so you can trace changes to a decision
• Permissions that control who can edit

Keep Everything for One Feature in One Place

As a feature moves forward, the information about it starts to spread out: the original requests, the spec page, the decision notes, and later the release notes. A feature is much easier to follow when all of that stays together. Create one parent page for each planned feature, with sub-pages underneath for each part. Anyone on the team can then open the parent page and see the whole story.

This is how product teams can set it up in Docmost:

• You can add an inline base (a table-style database inside the page) to track the original requests as rows or move them through stages on a Kanban board. Bases is a paid edition feature.
• Comments let your team discuss decisions on the page itself.
• Version history keeps earlier versions of every page.

For a wider look at your options, see our roundup of the best documentation tools for product teams.

Common Feature Request Mistakes

• Building the request instead of fixing the problem. Customers describe the fix they can picture. Before you build it, check whether a simpler change would solve the problem behind it.
• Logging requests without a status. A log full of entries with no status (a label like planned or declined) turns into a wish list nobody trusts. Every entry should show where each request stands.
• Declining without writing down the reason. If the reason for declining a request is only in someone's head, the same request comes back, and the debate starts over every time.
• Leaving requests in chat threads. A request mentioned in a team chat and never logged is a request you'll lose. Make it a habit to move it into the log the same day.

Frequently Asked Questions

1. What Should a Feature Request Include?

A useful feature request includes the problem in the customer's own words, the solution they asked for, who asked and what kind of account they're on, where the request came from, the date, and a status. The problem matters most, because it lets your team judge whether the requested feature is the best way to solve it.

2. How Do You Prioritize Feature Requests?

Start by merging duplicates, then weigh each request on how well it fits your product plans, how many customers want it, and how much work it would take. Some teams add a scoring framework to compare requests more consistently, but a clear owner and a regular triage slot matter more than the method you pick.

3. What's the Difference Between a Feature Request and a User Story?

A feature request is raw input from a customer or teammate, usually describing the solution they'd like. A user story is written by the product team, often in the form "As a [type of user], I want [goal] so that [reason]." One user story can combine several related requests into a single statement of what users need.

4. Who Should Own Feature Requests: Product, Support, or Sales?

Everyone who talks to customers should log requests, but the product team should own triage and the final decision. Support and sales are responsible for capturing requests accurately, with the customer's words and a link to the original conversation. One named person on the product team should run the triage sessions so nothing waits without an owner.

5. How Long Should You Keep Declined Feature Requests?

Keep them. A declined request with its reason written next to it is useful long after the decision, because it answers the question the next time someone asks. If your log gets crowded, move old declined entries to a separate archive page instead of deleting them, so the reasoning is still there if the question comes up again.

6. Should Customers See the Status of Their Feature Requests?

Showing customers a status, such as planned or under review, can build trust and cut down on repeat questions to support. Many teams share the status publicly and keep the detailed reasoning internal, since that reasoning can include customer names, deal context, and strategy you want to keep private.

Keep Your Feature Requests and Decisions in One Place With Docmost

Your feature request log, spec pages, and decision log all work better in one shared space your whole team can search. If you'd like to see how product teams use Docmost for this, contact our sales team.