Pain Intensity Score: How to Rate Customer Pain

You can collect fifty complaints in one afternoon and still have no idea which one deserves your next three months. Every complaint arrives in a different shape: a rant, a polite feature request, a question, a joke. Without a consistent way to rate them, you pick the one that sounded loudest and hope it holds up under a real build.

A pain intensity score fixes that. It is a rating you apply to each problem you find, with the same rules every time, so two problems can be compared without arguing about feelings.

What a Pain Intensity Score Measures

A pain intensity score answers one narrow question: how much does this problem hurt the person who has it? It does not measure how clever your solution is, or how large the audience might be. Those are separate questions, and folding them into one number is where most scoring goes wrong.

Pain shows up in behavior, not in adjectives. Someone who writes “this is so frustrating” and moves on is telling you less than someone who describes a spreadsheet with four hundred rows, a manual copy-paste step, and a workaround they rebuilt twice.

So build the score from signals you can point to in the source text. If you cannot quote the line, you cannot score it.

The Five Signals I Score

Each signal gets a simple rating, and the ratings add up to the pain intensity score. Keep the scale small. Three levels per signal is enough for a decision you will make with your own judgment.

• How often it returns. Does the person mention this once, or does it come back in the same thread, the same week, the same year?
• Cost of the workaround. What are they already doing to survive it? Manual steps, paid tools, a script only they can maintain.
• Money already spent. Are they paying for something that half solves it, or paying a person to do it by hand?
• Emotional language tied to a task. “I dread Mondays” is weaker than “I rebuild the same report every Monday for two hours.”
• Switching intent. Are they asking for alternatives, comparing tools, or saying they would move if something existed?

Two of these carry more weight than the rest: money already spent and switching intent. Both are hard to fake in a passing complaint. If a problem scores high on those two, the other signals matter less.

How to Score by Hand

You do not need a tool to try this. Pick one narrow topic and run it through the steps below. Say the topic is invoice reminders for freelancers. These are the sorts of search terms that surface real threads instead of marketing copy:

• “chasing late payments”
• “client has not paid” site:news.ycombinator.com
• “invoice reminder” manual workflow
• “how do you handle overdue invoices”

Keep your own phrasing pain-shaped. A search for “best invoicing tool” returns vendor pages. A search for “client will not pay and I hate asking” returns people.

Then score what you find:

1. Collect twenty to forty posts and comments from the communities you can reach, and paste the raw text into one file.
2. Highlight every sentence that names a problem. Copy each one out word for word, with its link, and delete anything that is only a feature wish with no situation behind it.
3. Merge duplicates. Five people describing the same workaround are one problem, not five.
4. Apply the five signals to each merged problem on a three-point scale: low, medium, high.
5. Sort the list and read the top three. If the same problem sits near the top in two unrelated communities, that is a strong sign.
6. Write down what would make you drop the top problem. Keep that note. It becomes your counter evidence later.

Step six is the one people skip, and it is the step that keeps scoring from turning into a confirmation exercise.

Turning Scores into a Shortlist

A score by itself does not decide anything. What you want is a short list you can act on, which means adding a second axis: how many separate communities the problem shows up in.

• High pain, several communities. The strongest signal you will find. The problem hurts in more than one place.
• High pain, one community. Worth a closer look, but check whether that community is small or unusually technical before you commit.
• Medium pain, cheap to solve. Sometimes fine as a fast first product, as long as you accept the ceiling.
• Low pain, high volume. Be careful. A lot of noise about a small annoyance usually means the annoyance is tolerable.

If two problems tie, pick the one where the people describing it already spend money. A wallet is a better tiebreaker than a vote.

Three Scoring Mistakes to Avoid

The first is scoring the solution instead of the problem. “They asked for a dashboard” is not pain. It is a guess about a fix.

The second is counting mentions instead of people. One loud thread can look like demand all by itself. Group the posts first, then count distinct people.

The third is scoring inside a single subreddit or forum. Every community has blind spots, and a problem that appears in two unrelated places is worth far more than one that dominates a single corner.

FAQ

What scale should a pain intensity score use?

Keep it small. Three levels per signal is enough for a call you will make with your own judgment, and a small scale forces honesty. A ten-point scale invites precision you do not actually have.

How many posts do I need before the score means anything?

Enough that duplicates start showing up. If every post describes a different version of the problem, your topic is probably still too broad. Narrow it instead of collecting more.

Can I score pain from one community only?

You can, but treat the result as a lead rather than a conclusion. Cross-check the problem somewhere else before you commit months of work to it.

Do I need a tool for this?

No. The method works with a text file and twenty minutes. A tool earns its place once the volume passes a few hundred posts and you want the quotes pulled out and checked against the source text for you.

---

If you would rather skip the manual pass, this research tool does it for you: it gathers threads from Reddit’s public archive, Hacker News, Stack Overflow, and GitHub, merges near-duplicates into clusters, and keeps only quotes it can verify against the original text. A report takes two to four minutes and costs 2.99 EUR once. Two related reads: Spotting Recurring Complaints in a Sea of Posts and Evidence-Based Idea Validation: What Counts as Proof.