Most IT service desks I’ve worked with measure success the same way: service level agreement (SLA) compliance. Hit 96%, put it on a slide, move on. The problem is that the number tells you almost nothing about what’s actually happening inside your ticket queues.
A ticket can close within the target after sitting blocked for two days because no one knew which infrastructure team owned the component. That’s not a healthy service – that’s a time bomb with a green status bar. The incident gets resolved “on time,” an engineer brute-forces a workaround at midnight, and the dashboard stays clean. Meanwhile, the underlying system rots quietly.
I think recognizing this isn’t a failure of SLAs as a concept in IT service management (ITSM). It’s just that SLA dashboards are autopsy reports. What we actually need are vital signs.
The Problem With SLA-Driven Service Desk Metrics
SLA metrics capture resolution and response times against fixed targets. They’re aggregate. They’re historical. And they tell you nothing about internal flow quality.
Here’s the pattern I keep seeing: a team optimizes for the clock. Response time looks great. Resolution time is within bounds. But the way they get there – escalation ping-pong, midnight heroics, workarounds instead of fixes – degrades the system underneath. The numbers stay pristine while the service gets sicker.
Five Flow Metrics That Reveal Service Health
1. Flow Efficiency: Active Work vs. Waiting Time
A ticket resolved in three days (and within the SLA) might involve six hours of actual labor. The rest? Sitting in “Awaiting Review,” “Awaiting Approval,” or just lost between queues.
Flow efficiency – the ratio of active work to total elapsed time – is the metric that tells you this. When it drops below 60%, you have a handoff problem, not a capacity problem. I’ve seen teams hire more people to solve what was really a queue design issue.
2. Backward Transitions: The Hidden Cost of Rework
This one is underrated. When a ticket bounces back from Level 3 to Level 2, or from “Ready for QA” back to “In Progress,” that’s pure waste. Every backward transition means someone has to re-read the ticket, re-understand the context, and re-triage.
The usual causes: incomplete initial work, a fix that didn’t actually fix, or requirements that changed mid-flight. If you’re seeing more than 15% of your tickets making at least one backward move, something structural is off.
3. Invisible Blockages: Detecting Hidden Wait States
Many teams don’t track “Blocked” status consistently – or at all. A service request sits “In Progress” while waiting on a network team that has no idea it’s in the queue. This invisible wait time is one of the best early warning signals for upcoming SLA breaches.
I don’t have a clean framework for measuring this yet. The best proxy I’ve found is comparing time-in-status distributions for statuses that shouldn’t have long dwell times. If “In Progress” has a fat tail, you likely have hidden blocks.
4. Reassignment Counts: A Signal of Ownership Gaps
Four or more reassignments on a single ticket is a diagnostic signal, not just an inconvenience. It usually means agents can’t identify the right system or team, not that the issue is technically complex.
The pattern: 30 minutes of actual work gets stretched across three days and four people, each spending time reading the ticket before passing it on. High reassignment rates point to knowledge gaps or unclear ownership – both fixable, both invisible in SLA reports.
5. Cycle Time Distribution: Why SLA Averages Mislead
Averages lie. A team with a 2-day average resolution time might have 80% of tickets close in 4 hours and 20% take 2 weeks. The average hides the “canary” tickets – the ones that take dramatically longer and usually point to undocumented dependencies, missing runbooks, or process gaps that nobody’s formalized.
Look at the full distribution. The tail tells the real story.
From SLA Dashboards to Flow-Based Observability
Flow metrics are leading indicators. A spike in backward transitions this sprint predicts a doubling of SLA breaches next month. Rising reassignment counts in a particular category mean your knowledge base has a gap that’s about to become a staffing problem.
The point isn’t to replace SLA tracking. It’s to complement it with signals that let you intervene before the damage reaches the customer. SLA compliance should be a natural byproduct of healthy flow – not the thing you optimize for directly.
How to Start Measuring Flow in Your Service Desk (Not Just SLAs)
If this resonates, here’s the most practical first step I can suggest: pick ten recently resolved tickets at random. Trace each one from creation to close. Note every status change, every reassignment, every time it sat waiting. Build an intuition for what “healthy” looks like in your specific environment before you try to measure it at scale.
Once you have that intuition, start pulling flow efficiency and transition data into your regular reviews alongside the SLA numbers. You’ll be surprised how quickly the team starts seeing patterns they’d been feeling but couldn’t articulate.
Release Management Apps is an Atlassian Gold Marketplace Partner building Jira-native tools for release orchestration and service delivery.
SLA Compliance FAQs
Flow metrics measure how work moves through a service process from creation to completion. Unlike SLA metrics, which focus on outcomes and deadlines, flow metrics help teams understand delays, bottlenecks, rework, ownership issues, and inefficiencies that affect service delivery.
SLA metrics are lagging indicators that tell you whether a target was met after the fact. Flow metrics are leading indicators that help identify issues before they result in SLA breaches. Together, they provide a more complete picture of service performance and operational health.
Flow efficiency measures the percentage of total ticket lifecycle time spent on active work versus waiting. It is calculated by dividing active working time by total elapsed time.
A low flow efficiency often indicates excessive handoffs, approvals, waiting periods, or queue delays rather than a lack of staffing capacity.
While benchmarks vary by organization and service type, many teams aim for flow efficiency above 60%. Consistently lower values may indicate process bottlenecks, excessive waiting, or poorly designed workflows.
Common causes include:
Incomplete troubleshooting or analysis
Poor ticket documentation
Incorrect categorization or routing
Failed fixes requiring additional work
Changing requirements during resolution
Lack of quality control before handoffs.
Invisible blockages are delays that are not explicitly tracked within the workflow. For example, a ticket may remain marked as “In Progress” while waiting for input from another team, vendor, or customer.
Because these delays are hidden, they can distort performance metrics and create unexpected SLA risks.
Organizations can analyze time-in-status distributions and investigate statuses with unusually long dwell times. Reviewing ticket timelines and identifying periods with no activity can also reveal hidden dependencies and blocked work.
Reassignment counts show how often tickets move between agents or teams. High reassignment rates often indicate unclear ownership, insufficient knowledge management, poor categorization, or ineffective routing processes.
There is no universal benchmark, but tickets requiring multiple reassignments should be reviewed. When a significant percentage of tickets are reassigned three or more times, organizations should investigate ownership clarity, routing rules, and knowledge gaps.
Averages can hide significant variation in service performance. A small number of tickets with extremely long resolution times can reveal process weaknesses, undocumented dependencies, or recurring bottlenecks that are invisible when only average performance is monitored.
Teams should examine cycle time distributions, percentiles, and outliers. Looking at the longest-running tickets often reveals systemic issues that require process improvements.
No. SLAs remain important for measuring customer commitments and service expectations. Flow metrics should complement SLA reporting by providing operational insights that help teams prevent SLA failures before they occur.
Flow efficiency is often the easiest starting point because it immediately highlights the balance between active work and waiting time. However, organizations should choose the metric that aligns with their most pressing operational challenge.
Start by reviewing a sample of recently resolved tickets. Map status changes, reassignments, waiting periods, and active work stages. This manual analysis helps establish a baseline understanding before implementing automated reporting and dashboards.
Most modern ITSM platforms can provide workflow history, assignment records, status changes, and lifecycle data. Organizations may need custom reporting, analytics tools, or process mining solutions to visualize flow metrics effectively.
Many teams review flow metrics during weekly operational meetings and monthly service reviews. The key is to use the data regularly enough to identify trends before they become customer-facing issues.
Organizations that monitor flow metrics often achieve:
Faster resolution times
Fewer SLA breaches
Reduced rework
Improved ownership accountability
Better resource utilization
More predictable service delivery
Enhanced customer satisfaction.
No. Flow metrics can be applied to any work management process, including IT service desks, DevOps teams, HR service delivery, facilities management, customer support, and enterprise workflow operations.
Many organizations focus exclusively on SLA compliance and resolution times. This can encourage teams to optimize for metrics rather than improving the underlying flow of work. Sustainable service improvement comes from understanding and removing friction within the process itself.
Yuri Kudyn
Yuri Kudyn co-founded Release Management Apps in 2018 – an Atlassian Gold Marketplace Partner building Jira-native tools for release orchestration and service delivery. He’s spoken at Kanban University events and consults on flow management in Atlassian ITSM environments. He believes in information radiators, not information refrigerators.
LinkedIn - https://linkedin.com/in/yuri-kudyn-5408223
Atlassian Marketplace - https://marketplace.atlassian.com/vendors/1216961/release-management
