How to quantify feedback: counts, segments, and revenue weighting
"Customers keep asking for this" is an anecdote. "31 distinct accounts asked for this in the last quarter, two-thirds of them enterprise, representing $410k in ARR with one renewal at risk" is an input to a decision. The distance between the two is three mechanical passes over the same data, and each pass exists to defeat a specific bias.
A warning before the arithmetic: quantified feedback is evidence, not an oracle. The numbers describe your current customers' stated wants; they say nothing about strategy or about the customers you don't have yet. Use them to inform the argument, not to end it.
“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 NotionPass 1: counts — but only after deduplication
The raw count of mentions is the most misleading number in feedback. One frustrated champion who pings you weekly generates 12 mentions; 12 different accounts asking once generate 12 mentions; these are wildly different signals.
So the unit of counting is the distinct requester (or distinct account, in B2B), and the prerequisite is deduplication: recognizing that "let me download this as a spreadsheet," "CSV export when?", and Zendesk ticket #5521 are the same request. This is the tedious part, and it's why quantification usually dies as a manual practice — it requires aggregating every channel and clustering by meaning, not keywords. At low volume, a weekly 30-minute sweep into a spreadsheet works. At higher volume this is the step to automate; we build Modem, whose triage does exactly this clustering across chat, support, and call transcripts with the requester list preserved — and because the underlying context graph links the same person across identities, the champion who pings in Slack and also files tickets counts once, not three times — that disclosure noted, any tool or process that produces "distinct accounts per deduplicated theme" gives you the same foundation.
What you get from pass 1: a ranked list of themes by breadth. This answers "what do the most customers want?" — and nothing else.
Pass 2: segments — who is asking
The same count can mean opposite things depending on who's behind it. Break each theme's requester list down by the segments you already use:
- Plan tier: 19 requests for SSO from enterprise trials is a sales blocker; 19 from the free tier is a different conversation.
- Lifecycle stage: requests concentrated in accounts under 30 days old point at onboarding gaps; requests from years-old accounts point at scaling pains.
- Persona or industry: if every request for audit logs comes from fintech, that's a vertical signal, not a general one.
Segment breakdowns are standard practice in feedback analysis precisely because aggregate satisfaction numbers hide group differences (Sprinklr's guide covers the general method). Practically: your spreadsheet gains three columns, filled from your CRM. The question this pass answers: "is this everyone, or a specific kind of customer?"
Pass 3: revenue weighting — what the requests are worth
The final pass attaches dollars. For each theme, sum the ARR of the accounts requesting it, and flag the portion that's at risk (renewal in the next two quarters, flagged by CS, or explicitly framed as "we need this or we walk"). Weighting feedback by ARR and lifecycle rather than treating every mention equally is the core move here — a churn-risk enterprise account's request is not worth the same as an anonymous free-tier comment, a point Perspective AI's scoring guide makes well.
Two honesty rules keep this pass from lying to you:
- Represented, not attributed. $410k of ARR asking for a feature is not $410k that the feature earns or saves. Say "representing," never "worth."
- Don't let revenue erase breadth. A pure revenue sort makes your roadmap a service bureau for your three biggest accounts. Keep counts and dollars as separate columns and read them together; a theme that's top-three on both is your signal.
Putting the three numbers to work
The output is one table: theme, distinct accounts, segment concentration, ARR represented, ARR at risk. Each row is now a sentence you can say in a roadmap meeting: "CSV export: 31 accounts, mostly mid-market ops teams, $410k represented, one $80k renewal explicitly blocked."
From here, the table feeds directly into prioritization — it's the input layer that makes scoring frameworks honest, as covered in how to prioritize feature requests — and into loop-closing, since every row carries the list of people to notify when it ships. For tools that automate the revenue join specifically, see our revenue-prioritization roundup.
The smallest version this week
One theme, all three passes, by hand. Pick the request you think is your most-demanded feature, spend 45 minutes searching support, Slack, and call notes for every account that asked, then add plan tier and ARR from your CRM. You'll end up with one defensible row — and, fairly often, the discovery that the real count is half what everyone assumed, which is the fastest possible demonstration of why the counting has to be done.
