ITSM Dashboard Metrics That Matter: The Second Reading Most JSM Teams Miss

Most service desk dashboards are built to be reassuring. I've come to think that's the problem.

I spent an hour last month looking at a JSM dashboard with the manager who owns it. Internal IT, about 40 agents, three projects, the usual mix of incidents, requests and a small change queue. Her executive dashboard was almost entirely green. SLA compliance: 94%. Backlog rate: 9% — low, healthy, the kind of number you put on a slide. MTTR: trending down for two quarters straight.

And her customers were unhappy. Loudly. The CIO had started forwarding complaint emails, and nobody on her team could square that with the board, because the board said everything was fine.

It took about twenty minutes to find it. The backlog rate was low — but the closure rate had quietly dropped from around 96% of inbound to roughly 71% over the same two quarters. The queue wasn't healthy. It was frozen. New work came in, old work sat, and the ratio happened to stay flat because both numbers moved together. Nine percent of "not many tickets" looks identical to nine percent of "we've stopped finishing things." The dashboard couldn't tell the difference. Neither could she, because the dashboard was the only thing she was reading.

Every metric on that board had a second reading. The first reading is what the chart shows you — the obvious one, the one the tile is built to deliver. The second reading is what the metric implies: the non-obvious consequence, the thing that flips the diagnosis. This piece walks the metrics worth putting on a JSM service desk dashboard, the second reading behind each one, and the rule for reading the whole board so the green cells stop lying to you.

Why a board full of green can still describe a service that's failing

Let's be fair first: dashboards aren't broken, and the metrics on them aren't wrong. Backlog rate, MTTR, SLA compliance, first-contact resolution — these are sensible things to measure, and a service desk that measures none of them is flying blind. The problem isn't the metrics. It's what happens to a metric the moment it becomes a target.

There's a law for this — Goodhart's Law — and it's one of those ideas that sounds like a party trick until you watch it eat a team alive: when a measure becomes a target, it ceases to be a good measure. The moment "keep the backlog under 10%" is the goal — on a slide, in a standup, in a bonus formula — the backlog number stops describing the service and starts describing the team's relationship to that number. People aren't even being cynical about it; reclassifying a ticket, pausing an SLA clock, splitting one messy problem into five clean "resolved" ones all feel locally reasonable. The aggregate just stops meaning what you think it means.

Service-management circles have a name for the result: watermelon metrics — green on the outside, red on the inside. An SLA at 95% while the people the SLA exists to protect are furious. It usually gets blamed on gaming, but I think that lets the dashboard off the hook. The deeper issue is that the board was built to answer "are we hitting our numbers?" — which is a different question from "is the service getting better or worse, and where?" The first question produces a reassuring chart by construction. The second produces an uncomfortable one on purpose. Most exec dashboards answer the first.

And there's one more thing, the one that actually does the damage day to day: every metric on the board is read in isolation, one tile at a time, when its meaning only resolves against a complement. Backlog rate is meaningless without closure rate. A falling MTTR is meaningless without the leading indicators underneath it. A created-vs-resolved ratio of 1.0 is meaningless without knowing whether you have any slack. Read alone, each tile gives you the first reading. Read in pairs, you get the second.

What "the second reading" actually is

It's a habit, not a tool. You read every metric on the board twice. The first time, you read what it measures — the obvious reading, the one the chart hands you. The second time, you read what it implies — the consequence the number is consistent with, the thing that has to be true elsewhere for this to be good news.

Put plainly:

• First-order reading — what the metric measures. The obvious value. The one the dashboard prints, the one you screenshot.
• Second-order reading — what the metric implies. The non-obvious consequence. The one that flips the diagnosis when you check it against the metric that should move with it.

A green metric, on its own, isn't a verdict. It's a question.

A green metric isn't a verdict. It's a question: what would have to be true elsewhere for this to be good news — and is it?

The diagram below is the whole move. One number, two readings, and a fork: the first reading is the one the tile is built to give you; the second reading is the one you have to go and check.

The metrics that matter — and the second reading behind each

Here is the working set: the ITSM dashboard metrics actually worth a tile on a JSM service desk board, the first reading each one hands you, the second reading it's hiding, and the metric you have to read it next to before the first reading means anything. The last row is the one most teams never put on a dashboard at all — and it's the one that tends to change the most minds.

None of these are exotic. Backlog, age, MTTR, SLA, created-vs-resolved are on most JSM boards already. The shift isn't adding metrics — it's reading the ones you have against the column on the right.

How to read a JSM dashboard: pair every metric with its complement

The rule is short: read every metric on the board twice — once for what, once for so-what — and never let a number sit on an exec dashboard without the complement that tells you whether it's real. Backlog and closure rate. Created and resolved, with the ratio called out. Age distribution and a stale-ticket count. Lagging KPIs and the leading ones that predict them. It's twice the tiles and half the false comfort — and the false comfort was the expensive part.

Two practical moves make it stick:

1. Look at the green cells, not the red ones

If you go hunting for trouble on a dashboard, the red cells are the wrong place to start. The breached SLAs, the spiking incident count, the one team with a visible backlog — those already have an owner; somebody's in a meeting about them; they're priced in. The trouble is in the green cells nobody reads twice — specifically in the gap between what a green metric measures and what it implies. A red board is a team that knows it has a problem. A green board is a team that's about to find out it had one.

2. Get an outsider to read the board cold

Take the reassuring dashboard into a room with someone who isn't responsible for those numbers — a frustrated customer, a different team's lead, your own future self in six months — and have them read it without context. Every place they go "wait, but…" is a green cell with a second reading you've been skipping. Two minutes, one outsider; it's the cheapest review you'll ever run.

The decision tree below is the test you run on any green tile.

What this means for JSM teams

If you run service management on Jira Service Management, you start with a real advantage on the first reading and a real gap on the second. Out of the box, JSM gives you queues, SLA goals, the Workload and SLA dashboards, and the Atlassian reporting widgets — and they are good at exactly the obvious version of each metric. Backlog: there. SLA compliance: there, with a clean traffic light. Resolution time: there, trending.

The complement view is the part JSM's native widgets mostly don't do. Closure rate next to backlog rate — you have to build it. Created-vs-resolved with the ratio and the slack called out — you have to build it. Age distribution with a stale-ticket sweep before the chart is trustworthy — you have to do the sweep. Status dwell time — that lives in the issue changelog, not in any default report, and JSM's status categories (To Do / In Progress / Done) collapse exactly the detail you need to see where work goes idle. And "Resolved" in a JSM workflow can mean a dozen different paths through your statuses — the default SLA report averages them all together, which is precisely what hides the activity-path reading: the one path that quietly beats your runbook.

So for a JSM team, the second reading isn't automatic — it's reporting work. Pull closure rate and throughput from the same issue data that feeds the backlog tile. Plot created and resolved as two series and annotate the ratio. Build the age histogram, and run the 90-days-plus sweep first. Reconstruct status dwell time from the changelog. Cluster closed issues by their status sequence and read SLA per cluster. That's the work that turns a JSM dashboard from "are we hitting our numbers?" into "is the service getting better, and where?" — and it's the work a dedicated JSM reporting layer exists to do, because the native widgets stop at the first reading.

The honest tradeoff

The second reading costs you something, and it's worth being straight about what. It's slower — you can't skim a paired board the way you skim a wall of green tiles. It requires judgment — "is the complement healthy?" isn't a threshold you can RAG-colour and walk away from. It doesn't compress into a single status for the steering committee slide. And every so often it will tell your exec that the green board they've been presenting was wrong, which is not a fun conversation. A dashboard you can read in ten seconds is a dashboard that's hiding something — that's the trade.

But the alternative is the thing I watched in that QBR room: a manager with a board full of green and a CIO forwarding complaint emails, with no way to connect the two — because the connection was a second reading nobody had taken. A red board is a team that knows it has a problem. A green board, read once, is a team that's about to find out it had one. I'd take the red one.

The next step is small. Open your current dashboard, pick the three greenest tiles, and write down the complement for each — the metric that tells you whether the green is earned. Then go check. If you get stuck on one because you can't name the complement, you've found the first thing to fix.