Internal support reporting

The queue today

What is open right now and what needs attention first. Everything here is a snapshot, not a trend, so it is the part to act on rather than analyse.

Work in progress

open tickets by status, and how long they have sat there

How to read this

Reading a row: The bar is that status measured against the largest one. The figure is how many open tickets sit there, then how long they have been there.
In this status: The median working time each group has been sitting in its current status, not its total age. It answers "how long since anything actually happened to these".
Why it matters: Work in progress should mean work actually being worked on. A large In Progress column is a second backlog under a more comfortable name, and everything in it moves slower for being there. Finishing beats starting.
Needs history: Counts always work. Time in status comes from the issue history, so it needs a pull without JIRA_SKIP_HISTORY.

Outcomes by month raised

Open past the target

oldest first. Excludes blocked, requires decision and ready for review

Keeping up

Whether the work arriving is being cleared. A single busy month means nothing on its own, so watch the line: a queue that rises for several months running will not come back down by itself.

Created against closed

raised in each month against closed in each month, whenever they were raised

How to read this

Created: Tickets raised that month.
Closed: Tickets resolved that month, whenever they were raised, split by whether they met the target. This is throughput, so it is not the same grouping as the cohort chart above.
Net: Created minus closed, above each pair. Violet and positive means the queue grew that month. Green and negative means you got ahead of it.
Filtering: Every legend item is a switch. The axis rescales to what is left, and the label says "filtered" while anything is hidden. The net figure only appears when created and closed are both showing, because it is a comparison between them.
Open at month end: The blue line is the running total of those nets, so it is the size of the open queue at the end of each month. It is the same axis as the bars. Its last point is today's open count, which is how you can check this chart against the tiles at the top.

Speed and quality

How well the work that does get done goes: whether it hit the target, how long it took, how quickly anyone replied, and whether the fix held. The three figures below cover the current quarter, and the charts underneath give the history.

Hit rate over time

share of closures that met the target, grouped by when they closed in SLA out of SLA

How to read this

What it counts: Every ticket resolved in that period, whenever it was raised. Each bar is the whole period, split by whether it met the target. Switch between months and quarters with the control above.
Why by closure date: Grouping by when a ticket was raised flatters recent periods, because only the quick ones have finished yet. Counting closures gives a complete denominator.
n: How many tickets closed in that period. Orange below five, where a percentage means very little. Quarters hide a thin month inside a healthy looking bar, so check both.
The other view: The cohort chart at the top already shows this by month raised: it is the green share of each bar.

Time to resolve

working days, log scale, so the 48 hour line stays visible next to a 30 day bar median, the middle ticket mean, the average

How to read this

Median: The middle ticket that month. Half were faster, half slower.
Mean: The average, which a few very slow tickets drag upwards. When the mean towers over the median, a handful of stuck tickets is doing it and most were fine. When the two bars meet, the whole month was slow.
n: How many resolved tickets each pair is built on. Orange below five, too few to read as a trend.
Months marked *: Still have tickets open. Only finished tickets can be timed, so those months count their quick wins and not their stragglers, and will get worse rather than better.

Time to first reply

how long before anyone answered median, the middle ticket slowest tenth, nine in ten beat it

How to read this

First reply: Working time from raised to the first comment by somebody other than the requester. Not a status change: this is the point the person who asked actually heard back.
Median against slowest tenth: The median is the middle ticket: half were faster, half slower. The slowest tenth is the point nine out of ten tickets beat, which is closer to what people remember. A large gap means most requests are answered fast and a minority are left.
Silent: Tickets that month nobody ever replied to. They cannot appear in a median of reply times, so they are counted separately at the top. Click the figure to list them.
Log scale: Replies range from minutes to months, so a linear axis would flatten everything below a week into the baseline.

Reopen rate over time

share of closures that had already bounced back at least once

How to read this

What counts as a reopen: The ticket was moved out of a closed status at least once, so an earlier fix did not hold. Which statuses count as closed is set by JIRA_DONE_STATUSES in the pull, and defaults to Done.
Grouped by when it closed: The pull counts reopens but does not date them, so a ticket is attributed to the period it finally closed in. Read it as "of what we closed then, how much had bounced".
The dashed line: The average across everything resolved, so a period reads as better or worse than usual rather than just as a number.
Why it matters: It is the counterweight to every speed metric on this page. Closing faster is only an improvement if the tickets stay closed.

Outcomes by month raised

Where it comes from

The volume worth removing rather than serving faster. A category or a requester holding a large share is usually a system problem wearing a support ticket as a disguise.

What the tickets are about

total tickets in each kind of request, and how many are still open closed open

How to read this

Reading a row: The bar is that category measured against the largest one, so the widest bar is always full. The paler part is closed, the solid part is still open. The percentage is that category's share of all tickets in scope, not its share of the bar.
How it is worked out: Keyword matching on the ticket summary, first match wins, done in the browser. It is crude, and a large uncategorised share is expected. The point is to see which kinds of request dominate, not to classify every ticket correctly.
What to do with it: A category worth a third of your volume is a candidate for removing rather than speeding up. Access requests in particular tend to be group membership problems, not support problems.
Fixing the rules: The keyword list is CATS near the top of the script in this file. Editing it needs no re-pull, just a refresh.

Who raises them

total raised by each person, and how many are still open closed open

How to read this

Reading a row: The bar is that person measured against the biggest requester. The paler part is closed, the solid part is still open. The percentage is their share of all tickets in scope.
What to look for: One or two people generating a large share usually means a training gap, a badly configured tool on their machine, or a team routing all of its requests through one person. All three are cheaper to fix than to keep serving.
Not a performance measure: A high count is not a complaint about the person. Somebody raising thirty access requests is usually reporting a provisioning problem, not creating one.
Needs a pull with reporter: If every row says "not recorded", the pull predates the reporter field being kept. Re-run jira_pull.py.