All writing

April 15, 2026

What 8 Months of Support Tickets Taught Me About $7,000 in Wasted Engineering Time

Written with Claude

As domain lead for four product areas at RealPage, I owned the quality and SLA metrics for a team of eight analysts. We handled technical support cases across the Onesite property management platform — lease management, maintenance workflows, payment processing, and reporting.

After about three months in the role, I noticed something that support leads almost always notice eventually: the same tickets kept coming back.

Not identical tickets. But tickets with the same root cause. The same confusing workflow. The same missing feature. The same edge case the product had never handled cleanly. We resolved them. We closed them. Two weeks later, the same issue from a different client.

Most support teams log this as a chronic pain and move on. I ran SQL on it instead.

Building the Query

I had eight months of case history in the system. Each case had a category, a resolution type, a time-to-resolve, and a set of tags analysts applied during triage.

The first query I built was simple: group cases by root cause category, count occurrences per month. What I wanted to see was whether the patterns were consistent — true recurring issues — or just clustered around software releases and one-off events.

They were consistent. Four categories accounted for roughly 60% of recurring case volume. Month after month, across different clients, different analysts, different products — the same four things.

The next query assigned a cost.

Quantifying Engineering Cost

Support teams think in tickets. Engineering teams think in hours and quarterly roadmaps. To get a product team's attention, you have to speak in their units.

Here is the calculation I used:

SELECT
  root_cause_category,
  COUNT(*) AS case_count,
  AVG(resolution_hours) AS avg_hours,
  COUNT(*) * AVG(resolution_hours) AS total_analyst_hours,
  COUNT(*) * AVG(resolution_hours) * 45 AS analyst_cost_usd,
  COUNT(*) * 2 AS estimated_eng_touch_hours,
  COUNT(*) * 2 * 85 AS estimated_eng_cost_usd
FROM support_cases
WHERE created_date >= DATEADD(month, -8, GETDATE())
  AND is_recurring = 1
GROUP BY root_cause_category
ORDER BY estimated_eng_cost_usd DESC

The hourly rates I used were conservative internal estimates — not exact, but defensible. The point was not precision. The point was order of magnitude.

The top four categories combined had generated approximately $7,000 in recurring engineering-adjacent effort over eight months. That is the cost of writing workaround documentation, escalating edge cases, building one-off client scripts, and engineer time spent on tickets that should not have existed.

The Presentation

I brought this to the quarterly product planning discussion. Not as a complaint — as data.

The framing mattered. "We keep seeing these tickets" is a support team gripe. "Here are four categories of recurring cases representing $7,000 in engineering-equivalent effort over eight months, with a projected annual run rate of $10,500, all of which would be eliminated by these specific product changes" is a business case.

Product teams are not unsympathetic to support pain. They are just working from a prioritization framework that weighs features against each other, and support pain rarely comes with numbers attached. When it does, it moves up the list.

What Changed

Four feature enhancements made it into the annual roadmap directly tied to this analysis. Three of the four top recurring categories effectively disappeared from our case volume within two quarters of those features shipping.

The fourth is still there. Some problems are harder than they look.

The Pattern

This is a replicable approach. If you are in a support, operations, or quality role and you have eight or more months of case history, you almost certainly have a version of this story in your data.

The steps are:

  1. Pull your case history and tag recurring issues consistently.
  2. Build a simple query grouping by root cause category.
  3. Assign a conservative cost estimate per category (analyst hours + escalation touches).
  4. Frame the output as a business case, not a complaint.
  5. Bring it to the roadmap discussion before priorities are set.

Support data is product insight. Most teams treat it as a queue to be cleared. It is actually a longitudinal record of where your product is failing the people who depend on it. Turning that record into a roadmap conversation is one of the most direct ways a non-engineer can influence what gets built.