Skip to content

Which Software Support Metrics Show Real Improvement?

Which Software Support Metrics Show Real Improvement?
Published

22 Sept 2026

Author
Yangjee Rai Shrestha

Yangjee Rai Shrestha

Which Software Support Metrics Show Real Improvement?
5:35
 
Table of Contents

Your support provider meets every SLA, and you still couldn't say whether the system is in better shape than it was last year. That's an awkward gap when your sponsor asks. Here's how to close it: four measures, what good looks like for each, and four steps you can start before your next monthly review. 

lightbulb-filament

Why we wrote this

When we take over support for a system, the first thing we ask for is the ticket history. The pattern is often the same: a long list of tickets closed on time, and a short list of faults that return every month. That's rarely anyone's fault; the reporting was set up to count work, and nobody went back to change it after launch.

It matters more as teams release more often, because each release is another chance for an old fault to return. We wrote this for whoever owns a live system and reviews its support provider, whether that's us or someone else. If your system is small and rarely changes, tickets closed may be all you need, and we say so below.
 

The report that looks fine

It's the monthly support review. The report opens on a green number: 140 tickets closed, every response inside the agreed time. Everyone nods.

Then you scroll down. The month-end reconciliation job failed again, and the partner integration timed out twice more.

Customers still can't export the large report without it hanging. They're the same three problems you raised in March, closed and reopened under new ticket numbers.
 
Nobody is slacking. But you can't tell your sponsor whether the system is healthier than it was six months ago, and the report doesn't help.
 
The short answer: Tickets closed measures activity, not improvement. Four numbers show whether your system is actually getting better: repeat incidents, time to recover, change failure rate and cost to run. You can baseline all four from data you already hold, and if they trend down quarter on quarter, support is working. 
 

Why a busy support team can hide a declining system

The usual answer is volume and speed: tickets closed, first response time, SLAs met. Most application support KPIs stop there. They're worth having, but they describe the support team's effort, not the system's health.

Here's the part most support providers won't say out loud. If you're measured on tickets closed, a permanent fix is bad for your numbers. Removing the root cause of a weekly incident deletes about 50 tickets a year from the report.
 
So a team can hit every SLA while the same fault returns every Tuesday. Nobody planned it that way; the reporting simply rewards closing, not preventing. 
 

The concession: measuring improvement takes real effort. Root causes have to be tagged by hand at first. Your numbers will probably look worse before they look better, because you'll start seeing what was always there. 

Four measures that show whether support is working

These are the software support metrics we'd put on any live system that changes often. Two come from DORA, the long-running research programme on software delivery performance. The other two are the ones your users and your finance team feel first. 

1. Repeat incidents

The share of incidents caused by something that has already caused an incident before. It's the clearest single sign of whether problems are being fixed or just closed. 

  • What it looks like: the same integration, job or screen appearing in the ticket list month after month, often under different titles.

  • What good looks like: the repeat share falls each quarter, and every repeat cause has a named fix with an owner and a date.

2. Time to recover

How long from the moment something breaks to the moment users are working normally again. It's often reported as mean time to recover (MTTR). DORA has since moved to failed deployment recovery time: "the time it takes to recover from a deployment that fails and requires immediate intervention."

  • What it looks like: a clock that starts at the first alert or customer report, not when someone picks up the ticket, and stops at service restored, not ticket closed.

  • What good looks like: you track the median and the worst case, and both trend down. The worst case matters more, because that's the one your sponsor hears about.

3. Change failure rate

The share of releases that need urgent fixing once they're live. DORA defines change fail rate as "the ratio of deployments that require immediate intervention following a deployment", usually a rollback or a hotfix. 

  • What it looks like: a release goes out Thursday, something breaks Friday, and the weekend goes on patching it.

  • What good looks like: the rate holds steady or falls while you keep releasing at the same pace. If it only drops because releases slowed down, that isn't improvement.

4. Cost to run

What it takes each month to keep the system working: support hours plus hosting, and the share of hours spent on manual, repeated work. Google's SRE book calls that work toil: manual, repetitive, automatable, and it "scales linearly as a service grows."

  • What it looks like: someone reruns a failed job by hand every morning, or the cloud bill climbs faster than your user numbers.

  • What good looks like: cost per user or per transaction is flat or falling as usage grows, and the manual share of support hours shrinks.

How to start measuring in four steps

You need an export, a spreadsheet and one person who owns the tagging. 

Step 1: Pull the last 90 days of tickets

Export every incident and support ticket from the last 90 days. Add your release log and the last three months of hosting bills. Ninety days is enough to show patterns without becoming a project of its own. 

Step 2: Tag each ticket by root cause

Tag by cause, not symptom, and mark any ticket whose cause has appeared before. Keep the list to six to ten categories. Integration failure, data issue, configuration, release defect, infrastructure and user how-to cover most systems.

Step 3: Set your baseline

Work out the four numbers from those 90 days and write them down with the date. Don't set targets yet. The first job is an honest starting point. 

Step 4: Review monthly

Spend 30 minutes each month on the same four numbers, plus the top three repeat causes and who is fixing each. Judge the trend each quarter, not the single month. One bad release can swing a month on its own.

If an outside provider runs your support, ask them to bring these four numbers to the next review. How they respond will tell you a lot.

What the numbers looked like for EML

EML-1

EML's result was 65% faster resolution and 40% lower manual cost. Map those against the four measures and they land on two directly.

Faster resolution sits closest to time to recover. Lower manual cost maps to the manual share of cost to run. That's the full result as reported, and we're not adding to it. 
 
What follows is how results like these are typically produced, not a description of EML's specific work. Recovery usually gets faster when repeat causes are fixed at the root and the remaining incidents have written runbooks. Manual cost usually falls when the jobs people rerun by hand every day are automated or removed.
 

The useful pattern for your own review: repeat incidents and change failure rate are leading measures. Time to recover and cost to run lag, so expect them to move a quarter or two after the first two. 

What drives the effort

Getting these measures in place isn't free, and the effort depends mostly on the system you have: 

icons8-recruiting-1-1

System age

Older systems carry older dependencies and more undocumented behaviour. Root causes take longer to find.
icons8-medal-1-4

Number of integrations

Each integration is another place for incidents to start, and some causes sit with a third party you don't control.
Document-2

Documentation

Time to recover depends heavily on whether anyone can quickly find how a part of the system works.
monitor

Existing monitoring

If nothing records when an outage starts, add that first. Google's SRE book says monitoring and alerting let a system "tell us when it's broken". Until then, no baseline is trustworthy.
 

How we approach it

icons-salesforce

NEXUS Sustain

Improvement reporting focuses on measures like these four, so you see the trend, not just the ticket count. We support systems regardless of who built them, so the baseline can start from your existing ticket history.

Each quarter, we set out what the numbers point to. It names the repeat causes worth fixing at the root and the improvements worth building next. Sustain itself doesn't cover new features, so the brief gives you a clear case to take to whoever builds them, us or anyone else.
 

Check your own problem

Answer these three questions for this quarter:
 
  1. Do you know what share of your incidents were repeats?
  2. Do you know how long your last serious outage took to recover, from first alert to users working normally?
  3. Do you know what share of last month's releases needed a rollback or hotfix?

 

If you'd like a second view on what your support numbers are telling you, book a call. You'll leave with the two or three things worth fixing first. 

Frequently Asked Questions

Can we track these measures ourselves?

Yes. A ticket export and a spreadsheet are enough to start. The hard part is tagging root causes consistently, so agree the categories first and have one person check the tags each month.

What is a good repeat incident rate?

There's no universal benchmark worth trusting, because it depends on the system's age, its integrations and how you define a repeat. The useful number is your own trend. Fewer repeats each quarter, with a named fix for every repeat cause, is what good looks like.

Do we need new tools to measure this?

Usually not. Your ticketing system, release log and hosting bills hold most of what you need. Tools help once the habit exists, but buying one first tends to produce dashboards nobody reviews.

What is mean time to recover (MTTR)?

Mean time to recover is the average time from something breaking to users working normally again. DORA now uses a closely related measure called failed deployment recovery time. Start the clock at the first alert or customer report, not when someone picks up the ticket.

What is change failure rate?

Change failure rate is the share of releases that need urgent fixing once they're live, usually through a rollback or a hotfix. It's one of the DORA software delivery measures. Read it alongside how often you release, because a lower rate only counts if the release pace holds.

Are SLAs the right application support KPIs?

Only partly. SLAs and tickets closed show how quickly and how hard the support team works, not whether the same problems stop coming back. Report repeat incidents, time to recover, change failure rate and cost to run alongside them, so you can see both effort and improvement.

How long does it take to see improvement?

Building a baseline from 90 days of existing tickets is a modest job for one person once the root cause categories are agreed. Repeat incidents and change failure rate usually move first. Time to recover and cost to run tend to follow a quarter or two later, so judge progress over several quarters.

What drives the effort of improving software support?

The main drivers are the system's age, how many integrations it has, how well it's documented and whether monitoring records when outages start. Older systems with many integrations and thin documentation take longer to diagnose. Fixing repeat causes at the root takes more effort up front but reduces the support hours spent on the same faults.

Should we change support providers if our numbers look bad?

Not straight away. Share the baseline with your current provider and give them a quarter to come back with named fixes for the top repeat causes. If the trend still doesn't move, you have a clear case for a change, backed by your own numbers.
 
 
Topics:

Want a second opinion before you decide?

Book a free 30-minute Fit Call. Whether it’s an AI idea, a new build or a system that’s slowing down, we’ll tell you what’s worth doing, what we’d drop, and whether we’re the right fit at all. No commitment. No pitch deck.
Book a Free Fit Call