Same Issues, Different Month? Spot Recurring Complaints

By MCP Analytics Team

I was surprised to learn this about recurring complaints: most teams think they've fixed an issue when ticket volume drops, but they're not tracking whether it comes back three months later with a different phrasing.

Here's what matters: a 70% drop in "can't login" tickets doesn't mean you solved the login problem. It might mean users gave up, found a workaround, or started calling it "authentication error" instead.

The Red Flag: 'Didn't We Fix This Last Quarter?'

I hear this phrase in standups constantly. Someone spots a support ticket that looks familiar. The team did a fix. Ticket volume dropped. Everyone moved on. Yet here it is again.

Signal: This is pattern blindness, not coincidence.

Last month, I analyzed support data for a SaaS company. They'd "fixed" their checkout flow four times in eighteen months. Each time, complaints dropped for 6-8 weeks. Then they crept back up with slightly different wording:

Same root cause. Four different ticket categories. No one connected them because they weren't tracking complaint patterns over time.

What Makes a Complaint 'Recurring' vs. Coincidental

Not every repeated issue is a recurring pattern. Here's how I separate signal from noise:

Recurring complaint indicators:

Coincidental complaint indicators:

The one number that matters: if an issue category drops below 5% of total tickets but never hits 0%, it's not fixed. It's dormant.

Export Your Support Tickets: Fields That Matter

I've seen teams export every field their ticketing system offers. That's noise. You need four fields:

  1. Ticket creation date (group by month)
  2. Issue category or tag (your existing taxonomy)
  3. Free-text summary or subject line (catch what tags miss)
  4. Customer segment or plan type (find if it's plan-specific)

Skip ticket ID, resolution time, agent name, and custom fields. Those add context later, but they're not what reveals patterns.

Pro tip: Export 12-18 months of data minimum. Quarterly patterns won't show up in 6 months.

Grouping Complaints by Category Over Time

Here's my process. It takes 20 minutes:

Step 1: Create a pivot table with months as columns, issue categories as rows, ticket count as values.

Step 2: Add a simple line chart. Each category gets a line. You're looking for lines that spike, drop, then spike again.

Step 3: Filter out categories with fewer than 10 total tickets across all months. That's noise.

Step 4: Highlight any category where the max monthly count is 3x higher than the minimum monthly count. That variance signals something.

I ran this on our own support data at MCP Analytics. Found that "data connection timeout" appeared every 4-5 months like clockwork. Turned out it correlated with our infrastructure auto-scaling events. We thought we'd fixed it twice. We hadn't.

Real Case: 'Login Issues' Appeared Resolved But Came Back

Three months ago, I worked with an e-commerce platform. They'd rebuilt their authentication system in Q2. Login complaint volume dropped 85% in July and August.

Victory, right?

I pulled ticket data through October. Here's what actually happened:

The team celebrated in August. But I looked at the free-text summaries. In July-August, the complaints were "can't remember new password format." In October, they shifted to "login button doesn't respond on mobile."

Signal: The auth rebuild introduced a mobile-specific bug that took 3 months to surface because mobile users are patient and retry before complaining.

When we filtered tickets by device type (a field they weren't analyzing), the pattern was obvious: desktop login issues dropped permanently. Mobile login issues actually increased.

When a Fix Creates a New Complaint Pattern

This is the pattern I see most often: you solve Problem A, but your solution introduces Problem B. The total complaint volume might even drop, so you think you won.

Example from a client in October:

I only caught it because I was reading ticket summaries, not just counting categories. The word "search" appeared in both old and new complaints, but they were tagged differently ("performance" vs. "data accuracy").

Skip to the bottom line: Track complaint keywords across categories, not just category counts. A single keyword appearing in multiple categories signals a recurring root cause.

Setting Alerts for Issue Resurgence

I don't have time to manually check complaint patterns every week. Neither do you. Here's my alert setup:

Alert 1: Comeback complaint

Trigger when any issue category that dropped below 5 tickets/month rises back above 10 tickets/month. Something you thought was fixed is back.

Alert 2: Keyword spike

Track top 20 keywords in ticket summaries. Alert when a keyword's monthly count jumps 50%+ compared to its 3-month average. New language = new problem or new phrasing of old problem.

Alert 3: Category shift

If total complaint volume stays flat but distribution across categories changes significantly (one drops 30%, another rises 30%), that's a fix that created a new problem.

I built these alerts in our analytics tools because manual checking is unreliable. I forget. Priorities shift. Alerts don't.

Communicating Findings to Product/Engineering Teams

Engineers hate vague problem descriptions. "Users are still complaining about login" gets eye rolls. Here's my template:

Issue: [Specific complaint category]
Frequency: Appeared in [X] of last [Y] months
Volume trend: [Chart showing spikes and drops]
User segment: [Plan type, device, region, etc.]
Trigger pattern: Spikes after [releases/events/dates]
Sample tickets: [3-5 ticket IDs with direct quotes]

I used this format last week. The engineering team immediately recognized the trigger pattern ("spikes 2-3 days after each bi-weekly deploy") and traced it to a specific migration script that wasn't idempotent.

Three things you need to know about presenting recurring complaints:

  1. Show the time series chart. Numbers alone don't communicate rhythm.
  2. Include actual customer quotes. "Card declined" could mean ten different things.
  3. Connect it to releases or events. If you can't, it might not be a product issue.

Quick Wins and Easy Fixes

Not every recurring complaint needs a major engineering effort. I've found quick wins by:

TL;DR: Some recurring complaints are UI/UX problems disguised as bugs. Fix the interface, not the code.

The Bottom Line

If you're answering the same support questions month after month, your fix isn't working. Either the root cause is still there, your fix created a new problem, or users don't know about your solution.

Track complaint frequency over time. Group by category and keyword. Set alerts for resurgence. Read the actual ticket text, not just the tags.

I've saved teams hundreds of hours by showing them they're fixing the same issue repeatedly under different names. The pattern is only visible when you look at the time axis.

Want to run this analysis on your own support data? We built tools at MCP Analytics that automatically detect recurring complaint patterns and alert you when "solved" issues come back. Upload your ticket export and see patterns in minutes, not hours.

Or start simple: export your last 12 months of tickets. Plot them by month and category. Look for spikes that repeat. That's your recurring complaint list.

Your support team already knows which issues keep coming back. Now you can prove it with data and track whether your fixes actually work.