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.
- Add a numeric custom field (call it
DemandorRequest 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. - 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.
- 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.
- 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”
Linear issue, quotes attached
insight report in NotionWatching the field drift: Faraday Systems
Naomi Estrada leads product at Faraday Systems, a twelve-person team building field-service scheduling software for HVAC and plumbing contractors: the app that tells a technician which job is next and shows a dispatcher every truck on a map. Six months ago she set up a Demand field on the backlog project, seeded from a spreadsheet of every open request she could find.
The first month, it worked the way she'd hoped. A support ticket came in from a dispatcher at a mid-size plumbing company:
Support ticket, RidgeAir Plumbing: "Is there any way to see which techs are running behind before the customer calls to complain? We're always finding out too late."
Naomi searched the backlog and found DISPATCH-88, "surface at-risk jobs before ETA slips," already sitting at Demand: 2. She bumped it to 3. Clean.
Three weeks later, a similar request landed in the sales team's Slack channel during a renewal call, worded as "our dispatcher wants a warning before a job runs late." Nobody on the sales side knew DISPATCH-88 existed, so it never got connected. A second version of the same ask arrived by email from a different account a month later, forwarded to Naomi, and this time she remembered the ticket number and bumped it herself.
When Naomi pulled her sorted-by-Demand filter for the next planning cycle, DISPATCH-88 showed Demand: 4. The real number, once she went back through Slack by hand, was five. The Slack message from the renewal call had reached the team through a channel nobody thought to check against the backlog, and only luck caught the one after it.
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
This is the layer Modem is built for. 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 can update fields and add comments on the linked issue directly, which means the tally can land on the same Demand field you already built and sort by, kept current 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, that gap is the size of the problem this guide describes.
