How to prioritize a Jira backlog by customer request count

Jira doesn't have a field for "how many customers asked for this." There's no number on an issue that goes up when a fifth customer files the same request, and no default way to sort the backlog by it. The closest native option is Votes, and Votes counts people who click a button, not customers who asked. A teammate humoring a customer on a call and the customer who needs the feature both register as one vote each, with no way to tell them apart later.

So teams that need real demand-based ranking build it themselves: a custom numeric field, a convention for who bumps it and when, and a saved filter sorted by that field. It's the same fix Atlassian's own community guidance on backlog scoring lands on: set a Demand value on each item "based on how many related customer requests were received," as one factor in a wider scoring model. Here's how to build that field properly, and where the manual version stops being trustworthy.

Why Votes and linked issues don't answer it

Two Jira mechanisms look like they'd solve this, and both fall short in a specific way:

• Votes are anonymous-ish and per-person. Anyone with project access can click it, the count shows on the issue, and it's the nearest thing to a built-in tally Jira has. But it counts clicks, not companies. One enterprise account with three people voting looks identical to three free-tier users from three unrelated companies.
• Linked "duplicates" work if your team has the habit of linking every repeat report back to the original instead of just closing it as a dupe. The linked-issues panel then becomes a rough count. It only covers requests that already became separate Jira issues, so anything reported through a support ticket or a Slack thread that never got filed just isn't there.

Neither mechanism was built to answer "rank my backlog by demand" across dozens of issues at once, which is the actual job. That takes a field you can sort a whole backlog on, not a count you check one issue at a time.

Building a Demand field that survives contact with a real backlog

The setup itself is simple. The discipline around it is what most teams get wrong the first time.

1. Add a numeric custom field (call it Demand or Request Count) to the issue types you prioritize: Story and Bug, usually not Sub-task. Jira admins add this from project settings under Fields, and it takes one field to keep the whole backlog sortable on it.
2. Seed it at the actual count, not zero, when you triage a new request. If three customers already mentioned the same problem before it became a ticket, the field starts at 3, not 1.
3. Write down who bumps it and when. The field only stays honest if support, CS, and sales know to increment it the moment a request matches an existing issue, rather than filing a duplicate or saying nothing.
4. Save a filter sorted by the field, descending. That filter, not the raw backlog, is what planning meetings should open first. It puts the issues with the most attached demand at the top without anyone re-counting by hand.

“we need SSO before rollout”

“any update on single sign-on?”

“SSO came up twice on this call”

↓ classified + deduped into

SSO requests

8 accounts asking · quotes kept

filesLinear issue, quotes attached

writesinsight report in Notion

answersyour agents

Where the manual field stops working

The field itself never breaks. What breaks is the assumption that everyone who hears a request will think to search Jira before answering it and bump the right issue if they find a match. That assumption holds fine when one or two people own intake. It stops holding once requests arrive through support, sales, Slack, and calls, handled by different people who each think their channel is the whole picture.

Three ways this shows up in practice:

• Undercounting is silent. A missed bump doesn't error out; the field just reads low forever, and a low number looks like low demand instead of a missed sync.
• The count trails the request. Someone has to notice the match exists before the field can move, so the field is always at least one triage cycle behind reality.
• Sorting by Demand only ranks what got filed. A recurring request that never crossed the threshold into a Jira ticket doesn't show up in the sort at all, no matter how many times it's been asked.

Past a handful of intake channels, this is the point where teams stop trusting the manual field enough to plan around it, roughly the same threshold covered in how to prioritize feature requests, where the scoring framework only holds up once the inputs feeding it are complete.

Where Modem picks it up

We built Modem for the counting work the manual Demand field can't do on its own. Modem reads the projects you connect in Jira alongside Slack, support tickets, and calls, and matches different phrasings of the same request (a support ticket, a Slack message, a line in a sales call) to one topic instead of relying on someone recognizing the overlap by hand. Every distinct company attached to that topic counts once, so the number reflects accounts asking, not messages sent or votes clicked. Modem's Jira integration lets the agent update fields and add comments on a linked issue when you ask, which means the tally can land on the same Demand field you already built and sort by, without anyone doing the matching manually.

Disclosure: Modem is the product this site sells, so read the recommendation with that in mind. Judge it against the specific gap above, whether your team's intake channels have outgrown a person's ability to catch every match, not against the pitch. Below that threshold, the field-and-discipline setup earlier in this guide is a sufficient answer on its own, and it costs nothing but an afternoon of admin time. The tradeoffs against other tools built for this exact problem are covered in the best tools to turn customer feedback into Jira tickets.

Ask three people the same question

If you don't have a Demand field yet, the setup takes an afternoon: a numeric custom field on your Story and Bug types, seeded from whatever count you can reconstruct by hand today, with a saved filter sorted descending.

Once it exists, run this check before trusting it in a planning meeting: pick one issue near the top of the sorted filter and ask three people on your team, separately, how many customers they think asked for it. If their answers don't match the field, the spread between their guesses and the number in it is the size of the problem this guide describes.