The 5 Ways to Prioritize Feature Requests From Support, Sales, and CS at Once

The hard part of prioritization is rarely finding the requests. It is that three functions arrive at the same meeting with three different lists, each one honestly derived, and each one optimized for a different outcome. Support wants the thing generating tickets. Sales wants the thing blocking deals. CS wants the thing a renewing account keeps raising. All three are right, and the roadmap has room for one.

The five ways to resolve this are normalizing the requests into one taxonomy, weighting by outcome rather than by source, separating frequency from concentration, making the tradeoff explicit rather than arithmetic, and publishing the decision back to all three functions. The first two are mechanical. The last three are where most teams actually fail.

Why three lists is a structural problem, not a coordination one

Each function sees a biased sample and has no way to know it. Support sees users who hit friction and filed, which skews toward existing customers and high-frequency workflows. Sales sees prospects explaining why they did not buy, which skews toward competitive gaps and enterprise checkboxes. CS sees the accounts they cover, which skews toward whoever is loudest in a QBR.

None of those samples is wrong. Each is a partial view presented with equal confidence, which is what makes the meeting unresolvable by discussion. Adding a scoring framework on top does not fix it, because the frameworks operate on the lists rather than on the underlying population. The approach to prioritizing feature requests from reviews and tickets handles the two-channel version of this; the three-function version adds an organizational dimension the mechanics alone will not settle.

The 5 ways

1. Normalize into one taxonomy before comparing anything

The first failure is linguistic. Support files it as "bulk export timing out," sales as "reporting limitations," CS as "cannot get data out for their BI team." Those are one request, and in three lists they are three.

Deduplication by hand is where most of the meeting goes, and it is also where the count quietly breaks, since whoever consolidates decides what merges. An adaptive taxonomy resolves this upstream by learning categories from the feedback itself across every channel, so the same underlying request lands in the same theme regardless of which function phrased it or how.

Until this step is done, no comparison across the three lists means anything.

2. Weight by outcome, not by source

The second failure is political. Whichever function argues best gets weight, which produces a roadmap that tracks internal influence rather than customer need.

The fix is to agree, before the meeting, on what the requests are being scored against: revenue at risk, revenue blocked, ticket cost, or adoption. Once outcome is the unit, a sales request and a support request become comparable without anyone conceding the argument. Quantifying how feedback impacts revenue is the version of this that survives a finance conversation.

3. Separate frequency from concentration

Two requests with identical counts can carry entirely different exposure. Sixty mentions spread across trials is a different decision from eleven concentrated in accounts renewing this quarter.

Source-based lists cannot show this, because they are grouped by who reported rather than by who is affected. A customer context graph ties each request to the revenue, segment, and named accounts behind it, which turns the frequency-versus-concentration question into a lookup rather than an argument. This is usually the step that changes the answer.

4. Make the tradeoff explicit rather than arithmetic

A scoring model produces a ranked list, which looks like a decision and is not one. The reason three functions disagree is that they are optimizing different things, and no weighting scheme resolves a genuine conflict of objectives. It only hides which one lost.

The more honest move is to state the tradeoff: this quarter weights expansion revenue over support cost, so the sales-originated request goes first and the ticket-driver waits. That is a decision people can disagree with productively. A composite score is one they can only relitigate.

5. Publish the decision back to all three functions

The reason the same request returns next quarter is usually that nobody told the function who raised it what happened. Support re-escalates because it is still generating tickets. Sales re-raises because the deal is still open.

Closing that loop, including on the requests that lost and why, is what stops the list regenerating. It is also what makes the next meeting shorter, because the functions arrive already knowing which arguments were heard.

How to run it

Normalize first. Score against one agreed outcome second. Check concentration third, since it changes more decisions than frequency does. State the tradeoff in a sentence. Send the result back to all three.

The decision rule: settle the unit of comparison before the meeting, not during it. Three functions can agree on a ranking they dislike if they agree on what is being measured. They cannot agree on anything if each is measuring a different thing and calling it priority.

FAQ

How do you compare a sales request against a support request?

Convert both to the same outcome unit before comparing. Revenue blocked and support cost are both expressible in money, which makes them comparable in a way that request counts are not. The comparison fails whenever each function is allowed to argue in its own native metric.

Should feature requests be weighted by who reported them?

Weight by the customer affected, not by the internal function that relayed it. Source-based weighting encodes which team is most persuasive, and it double-counts requests that arrive through several functions at once.

What if the three functions genuinely disagree on priority?

That is usually a signal that the company has not decided what it is optimizing this quarter. Escalate the objective rather than the feature. Once the objective is settled, the ranking generally resolves itself without further debate.

How does Enterpret unify requests from support, sales, and CS?

Enterpret ingests from 50+ channels including tickets, calls, and CRM notes, and applies an adaptive taxonomy that learns the product's own categories, so the same underlying request lands in one theme no matter which function phrased it. The customer context graph then attaches revenue, segment, and account context to that theme, which is what lets frequency and concentration be compared on the same basis.

If every roadmap review starts with three conflicting lists, see how Enterpret unifies customer feedback across every channel.

‍