Home › Topics › Time to Resolution › By Category & Priority

Resolution Time by Category and Priority: The Cuts That Matter

Wednesday, 11:40, at Northgate Retail. Lauren runs the desk for a head office and forty stores. Last month's figures are the best she has had: 485 tickets resolved, a median resolution time of an hour and a half, nine in ten done within forty business hours. She has the chart open when the regional director stops at her desk and says, pleasantly, "Store managers tell me IT takes a fortnight." Lauren shows him the chart. He looks at it for a while and says that it is a nice chart and that the store managers are not lying either. He is right about both. Nearly two hundred of the 485 tickets were account unlocks and password resets, done in minutes. Forty of the tickets were till and back-office hardware repairs in stores. Those took a median of six working days because every one waited for a part. The hour and a half is the median of the unlocks. The fortnight is the hardware. The desk has one number and two desks inside it.

A cut is the same figure, the median and the 90th percentile of resolution time, computed for only the tickets that share one attribute. That could be the same category, the same priority, the same department, the same channel, or, carefully, the same technician. The desk-wide figure is the mixture of all the cuts, weighted by how many tickets each one has. A mixture tells you about whichever ingredient there is most of. This article is part of our Time to Resolution series. This article is about the two cuts that mean the most, category and priority, and how to lay them out. It covers how to find the category that is dragging the whole number. It also explains why the cut is a question to go and answer rather than an answer to act on.

This article covers why the desk-wide number hides everything, then which cuts mean something and which do not. Next come the cut by priority and what it says about triage, and the cut by category, with the table. Then come the category that drags the whole number, in both directions, and reading the cut before changing anything. We cover the other cuts worth one look a quarter, then a short war story, and then the cut table to copy. All numbers are from the fictional desk at Northgate and are an example, not a benchmark.

Why the Desk-Wide Number Hides Everything

The desk-wide median is the median of the most common kind of ticket. On most desks the most common kind is small and quick. That is because the things that go wrong most often are the things that are easiest to put right. So the desk-wide median describes a password reset and calls it the desk. The slow work, the repairs, the new starters, the things that wait on a supplier or an approval, is a minority of tickets and therefore nearly invisible in a figure that gives each ticket one vote. Lauren's hour and a half was true and described nothing that any store manager had experienced. That is because store managers do not raise tickets for password resets; they phone the person at the next till.

This matters most when the number is used to decide something. A desk whose headline figure is the median of its easiest work can improve that figure without improving anything a requester would notice. It does that by getting faster at the easy work. It can watch the figure get worse while the desk gets better, by removing the easy work from the queue altogether. A desk might move password resets to self-service, which is a good idea and has its own series at Password Reset Self-Service. In that case, it loses two hundred very fast tickets a month and sees its desk-wide median leap, on the month it did the right thing. The number did not lie. It changed what it was describing without telling anyone, which is what mixtures do.

The cure is to report the cuts and let the desk-wide figure be a footnote. "Account tickets: median under half an hour. Store hardware: median six working days. Everything else: median three hours." That is three sentences, it takes thirty seconds to read, and the regional director would have recognised his store managers in the second one. The general case for reading several figures together rather than one at a time is made in Reading Metrics Together. Cutting is how that applies to one figure. The first two sections below are about which cuts are worth the thirty seconds.

The Cuts That Mean Something

A cut means something when it meets three conditions. The groups it separates are different kinds of work, each group has enough tickets to carry a median, and the attribute it cuts by is set reliably. Category and priority pass all three on most desks. Category separates work that is genuinely different: a repair is not a reset and will never be as fast. Priority separates work the desk promised to treat differently. Both are set on nearly every ticket. Both are worth checking at close rather than trusting from open, a discipline that Categorize at Close, Not Just at Open explains. That is because a cut by a category that was guessed at triage is a cut by the triager's first impression.

Enough tickets is the test most cuts fail. The desk's rule in this series is about thirty resolved tickets in a cell before the median of that cell is read. The rule is a working convention rather than a law of statistics. Its purpose is to stop anyone reading the median of eight tickets as a fact about a category. A category with eight tickets a month gets its cut rolled up over a quarter, or folded into a neighbouring category, or reported as a count with no median at all. The 90th percentile needs more than the median does, and a cell under thirty tickets should carry a 75th percentile or nothing. Write the count in every cell of the table, next to the median, so that a reader can see which cells are thin without being told.

Some cuts fail the first test, and they are tempting because the tool offers them. Cutting by day of the week produces a table in which Tuesday is slow this month and Thursday the next. That is because each day has a fifth of the tickets and the slow ones land where they land. Even if Tuesday were reliably slow there is nothing a desk can do about Tuesday. Cutting by requester produces a list of people, which is not a cut but a complaint. Cutting by hour of creation is interesting once and never again. The question to ask of any cut is whether, if the figure came back high, the desk would know what to do differently. Category and priority are the two where the answer is nearly always yes.

The Cut by Priority: Did the Urgent Ones Go First

The purpose of priority is to change resolution time, so the cut by priority is a test of whether priority is doing anything. If the median for the top priority is close to the median for the lowest, the desk is working tickets in the order they arrived and the priority field is decoration. That is more common than anyone admits and is the subject of Priority Is Not the Order of Work. If the top priority is much faster, priority is steering work, and the cut shows by how much. Where the tool runs service-level targets per priority on a business-hours schedule, as QuerySolv does, the cut by priority lines up directly against the promise made for that priority. That is the comparison the cut exists for. The targets themselves are designed in Priority Tiers That Are Realistic. This article does not redesign them; it only reads the cut against them.

Northgate's cut by priority for the month was this. Twelve top-priority tickets, median an hour and a half, nine in ten within four hours. Seventy at the second priority, median two hours, nine in ten within twelve. Three hundred and eighty at the third, median an hour and a half, nine in ten within forty. Twenty-three at the lowest, median twenty hours, nine in ten within ninety. Read quickly, the table says the top priority was no faster than the third, which would be alarming. Read slowly, it says the third priority is where the password resets live. The resets are fast whatever their priority, so the third-priority median is the reset median wearing a different label. The priority cut is confounded with the category cut, and on a small desk it usually is.

The fix is to cut within a cut, once there are enough tickets. Take the second and third priorities, remove the account category, and compare again. Northgate's third priority without resets had a median of four hours against the second priority's two. That is the gap priority is supposed to produce. The top priority's hour and a half against both is the right order. That is a table with three numbers in it and it answers the question the first table could not. The other thing the priority cut shows is the mix. Twelve top-priority tickets in 485 is a desk that reserves the top for real emergencies. A desk where a third of tickets arrive at the top priority has a triage problem rather than a speed problem. That is what The Everything-Is-Urgent User is about. Count the tickets at each priority before reading the medians, every time.

The Cut by Category: Where the Time Goes

The cut by category is the table that explains the regional director's fortnight. It has four columns that matter: the category, the number of tickets, the median, and the 90th percentile. A fifth column shows the total hours in the category. That is the count times the median as a rough guide or the sum of the resolution times if the spreadsheet has them. The column answers a different question from the median, as the next section shows. Northgate's table for the month is below, in business hours from created to resolved with no pauses, as the desk's definition card specifies.

CategoryTicketsMedian90th percentileRough total hoursWhat the numbers say
Account and password1800.4 h2 habout 70Most of the volume, almost none of the waiting; sets the desk-wide median
Software how-to951.5 h6 habout 140Quick, steady, short tail
E-mail and calendar603 h14 habout 180Moderate; tail is shared mailboxes that need a second person
Printers and till peripherals554 h20 habout 220Tail is anything that needed a site visit
Store hardware repair4048 h120 habout 1,900A twelfth of the tickets, most of the requester-hours; every one waited for a part
New starter setup3016 h40 habout 480Driven by when the request arrives relative to the start date
Network and connectivity255 h30 habout 125Small cell; read the quarter, not the month
All tickets4851.5 h40 habout 3,100The mixture; a footnote once the rows above are shown

Read the table one column at a time, and read the count column first. The count says where the volume is: account tickets are more than a third of the desk's work by number. The median says what a typical ticket in the category is like: under half an hour for an account ticket, six working days for a store repair. The 90th percentile says how bad the tail in that category gets: two hours for accounts, fifteen working days for a repair. The rough total says where requesters spend their waiting, and it reverses the count: the smallest row but two holds more than half the hours in the table. Four columns, four different rankings of the same seven rows, and the regional director and Lauren were each reading one of them.

The "what the numbers say" column is the one to write yourself, every month, in one line per row, because it is where the reading happens. A number in a cell is a fact; a sentence beside it is a finding, and findings are what the next section and the one after are about. Resist the urge to colour the cells. A red cell for the hardware row says "bad" when the honest reading is "waits for parts, as repairs do". A desk that colours its own table red learns to look away from it.

The Category That Drags the Whole Number

A category drags the desk-wide number in one of two directions, and the two are confused constantly. A large, fast category drags the desk-wide median down. Northgate's account tickets are a third of the volume at under half an hour. They are why the desk-wide median is an hour and a half rather than the four hours it would be without them. A small, slow category drags the 90th percentile and the average up. The forty store repairs, under a tenth of the volume, supply most of the tickets above forty hours and nearly all of the hours in the total. The first kind of drag flatters the desk, and the second kind alarms the director. Neither is a verdict on the desk, because both are a fact about the kind of work.

Find the dragging category with two sums. For the median, remove each category in turn and recompute the desk-wide median. The category whose removal moves it most is the one setting it, and it is almost always the biggest fast one. For the tail, sort the month's tickets by resolution time, take the slowest tenth, and count how many belong to each category. The category that is over-represented in the slow tenth, relative to its share of all tickets, is the one making the tail. At Northgate, store repairs were eight in a hundred of all tickets and about seven in ten of the slowest tenth. That is the drag, found in two minutes with a sort and a tally.

Knowing which category drags the number is not the same as knowing what to do about it. The distinction is the reason the next section exists. Store repairs took six working days because parts took five to arrive, and no amount of attention to the desk changes a courier. What the drag tells you is where to look. It tells you something else that is easy to miss: that the desk-wide number is not a number about the desk. It is a weighted mixture of categories, and it will move whenever the mix moves, with no change in anyone's work. Report the rows. Let the mixture be the last line, in smaller type, for the people who insist.

Remember: a cut is a question, not an answer. Before acting on any cell, check that it holds enough tickets, that the attribute is set reliably, and that nothing else differs between the groups. Then read the ten slowest tickets in the cell and let them tell you what the number meant.

Reading the Cut Before Changing Anything

A cell in the table that looks bad has produced a question. The discipline is to answer the question before acting on the number. There are three checks, and they take an hour, which is less than any change will take. The first is the sample: thirty tickets in the cell, or roll the quarter. The second is the attribute. Open ten tickets from the slow cell and confirm they are what the category says they are. That is because a slow category is sometimes a category that triage uses for "not sure", and a cut by "not sure" is a cut by nothing. The third is the confounder: ask what else the tickets in the cell share. One store, one month, one supplier, one technician on leave, one priority, one new system. A cut by category where every slow ticket is also from the same site is a cut by site that happened to be labelled by category.

Then read the slow tickets themselves, which is the only step that produces a cause. Take the ten slowest in the cell and read their histories: where did the time go, and was anyone waiting for anything? The method, and the four causes that nearly every slow ticket turns out to have, is the subject of Outlier Analysis: The Ten Slowest Tickets. The method is the bridge between a number in a cell and a change worth making. Northgate's forty store repairs, read this way, included about thirty that had waited on a part from a single supplier. About ten had waited for a technician to be in that town. Those are two different problems with two different fixes, and the cell said "48 h" about both of them.

Change one thing, and measure the cell again a month later. The temptation when a cut shows a slow category is to do several things at once: a loan pool, a new supplier, a visit rota, a form change. Do them all and the cell improves and nobody knows which one did it, which means nobody knows which one to keep paying for. The discipline of one change a month with the measurement after is the subject of the last article in this series, Improving Resolution Time Without Rushing Anyone. Here it is enough to say that a cut is how you choose the cell, not how you fix it. (A cut that is acted on the day it is read has a name. It is called a reorganisation.)

Other Cuts Worth One Look a Quarter

The cut by department or site is worth a quarterly look on any desk that serves more than one building, because it finds the slow site. The slow site is nearly always slow for one reason that nobody at the desk can see from the desk. Where departments each carry their own service levels, as they do in QuerySolv, the cut by department can be read against each department's own promise rather than against the desk's. Where they do not, read it against the desk-wide figure and look for a site that is far from the rest. Then, before concluding anything about the site, cut it by category, because the war story below is what happens when you do not.

The cut by channel is worth a look when the desk has more than one door. Tickets that arrive by phone and are logged after the fact will show a resolution time near zero, which is a start-stamp problem rather than a speed problem. Tickets that arrive by web form with all the fields filled will often resolve faster than e-mail tickets about the same thing. That is because the first contact did not have to ask for information. The channel cut usually says more about intake than about resolution, and the intake side of it belongs to Triage by Channel. Read it once a quarter, and expect to learn about forms rather than about speed.

The cut by technician is the one that gets desks into trouble, and the rules for it are firm. It is for coaching, never for ranking. It uses medians, never averages, because one supplier ticket on one person's list would make that person look slow for a quarter. It is read only once a technician has resolved at least thirty tickets in the period. It is read within a category, never across the desk. That is because the technician who takes every store repair will have a median twenty times the technician who takes every unlock. That is the rota, not the people. A per-person figure that meets all four tests is a prompt for a conversation about which tickets were slow and why. One that does not is a number about the rota with a name attached. Putting it on a wall screen is how a desk teaches itself to avoid hard tickets.

A Short War Story: The Slow Site at Ashgrove Housing

At Ashgrove Housing, the desk lead, Femi, cut the quarter's resolution times by office. Femi found that the south office had a median three times that of the other four, and everyone at the desk knew why. The south office had the oldest laptops in the organisation, and a request to replace them early had been on the capital list for a year. The replacement budget was approved on the strength of the cut. The order was a week from being placed when Femi, filling in the cut table for the following month, cut the south office's tickets by category. Femi found that the laptops had nothing to do with it. The hardware category at the south office had the same median as everywhere else. The whole of the gap was new starter setups, which took three working days there and three hours at the other offices. The south office's HR coordinator, who was new, had been sending starter forms on the afternoon before each start date. Fourteen new housing officers in the quarter had spent their first day or two without a laptop. That was roughly a hundred lost working hours plus the hours of the colleagues who lent them screens. The fix was a sentence in the offer-letter process asking for the form a week ahead. The laptop order was cancelled and the money went elsewhere. A cut tells you where to look, and the second cut tells you what you are looking at. Acting between the two costs exactly as much as the thing you were about to buy.

The Cut Table

The table below is the cut as a form, one copy per month for category and one for priority, with the same columns in each. The count comes first in every row, because it decides whether the rest of the row may be read. The "last quarter" columns are the trend, and a cell with no trend yet is marked as such rather than left blank. The "read" column is a tick that means the three checks and the ten-ticket read have been done for that row. A row with a finding but no tick is a row where the number is still a question. Fill in the one-line reading for every row, including the dull ones, because "unchanged, as expected" is a finding too.

RESOLUTION TIME CUT TABLE — ONE MONTH, ONE PAGE
Desk: ______________________   Month: __________   Cut by: category [ ]  priority [ ]  department [ ]
Clock: business hours, created to resolved, no pauses   Definition card version: ____

                        THIS MONTH                          LAST QUARTER          READ   ONE-LINE READING
Row                     n     median   90th pct   hours      median   90th pct
______________________  ____  ______h  ______h    ______     ______h  ______h    [ ]    __________________________
______________________  ____  ______h  ______h    ______     ______h  ______h    [ ]    __________________________
______________________  ____  ______h  ______h    ______     ______h  ______h    [ ]    __________________________
______________________  ____  ______h  ______h    ______     ______h  ______h    [ ]    __________________________
______________________  ____  ______h  ______h    ______     ______h  ______h    [ ]    __________________________
______________________  ____  ______h  ______h    ______     ______h  ______h    [ ]    __________________________
______________________  ____  ______h  ______h    ______     ______h  ______h    [ ]    __________________________
All tickets (footnote)  ____  ______h  ______h    ______     ______h  ______h

RULES FOR READING A ROW
   [ ] n under thirty: median marked "small sample"; 90th percentile left blank; quarter rolled up instead
   [ ] ten tickets opened and confirmed to belong to the row before the row is read
   [ ] confounders checked: one site ____  one month ____  one supplier ____  one person on leave ____
   [ ] slowest ten in the row read and their causes tallied (outlier review sheet)

THE DRAG
   Row setting the desk-wide median (remove each row in turn; largest move) ........ ______________________
   Row over-represented in the slowest tenth of all tickets ......................... ______________________
   Share of the slowest tenth that row supplies .................................... ____ in ____

THE ONE ROW CHOSEN FOR ACTION THIS MONTH
   Row: ______________________   Cause found in the ten slowest: __________________________________
   One change proposed: ___________________________________   Measure again on: __________

PER-PERSON CUT (only if done)
   [ ] within one category, not across the desk   [ ] medians only   [ ] every person has at least thirty tickets
   [ ] used for coaching conversations; not displayed; not ranked

Lauren filled in the category cut that afternoon and took it, rather than the chart, to the regional director the following week. He read the store hardware row and asked what the parts supplier's promised delivery time was. He discovered that nobody had ever asked the supplier for one. That was a question for his side of the organisation rather than hers. The desk-wide median stayed at an hour and a half and nobody has mentioned it since. The hardware median is now four working days, for reasons the last article in this series will explain. The store managers say IT takes about a week, which Lauren has decided to count as praise.

Frequently Asked Questions

How many categories should the cut table have?
Use as many as have at least thirty tickets a month, which on a small desk is usually five to eight. Fold the rest into an "other" row that carries a count and no median. If your category tree has forty leaves, cut by the top level of the tree, not the leaves. The leaves are for finding repeat problems, not for resolution-time reporting. A table that does not fit on one page will not be read.
Should the cut table show the median or the 90th percentile?
Both, with the count beside them, because they answer different questions. The median says what a typical ticket in the row is like and the 90th percentile says how bad the row's tail gets. For a row under thirty tickets, show the median marked as a small sample and leave the percentile blank until the quarter is rolled up. Never show an average in a row.
Our categories are a mess. Do I fix them before cutting?
Cut first by the top level you have, then open ten tickets from the slowest row and see whether they belong there. If most do, the cut is usable and you can tidy the tree later. If they do not, the cut is telling you about triage habits rather than resolution time. In that case, fixing the categorisation at close is the first change to make. A rough cut read honestly beats a perfect tree you will never finish.
Should I cut resolution time by technician?
Only within a category, only with medians, only once each person has at least thirty resolved tickets in the period, and only for a coaching conversation that nobody else sees. Across the desk, the cut measures who got the hardware tickets, not who is slow. Displayed or ranked, it teaches people to pick the quick tickets and leave the hard ones, which makes every other number on the desk worse.
A category has eight tickets this month and a median of three days. Is that a problem?
It is eight tickets, and three days may be one supplier delay and seven quick ones or eight slow ones. The median of eight cannot tell you which. Read the eight tickets, which takes twenty minutes, and roll the category up over the quarter before printing any figure for it. If the quarter's thirty or so tickets still show three days, it is a finding; if not, it was a month.
How often should I run the cut?
Run it monthly for category and priority, because those feed the tail review and the improvement plan. Run it quarterly for department, channel and technician, because those move slowly and the monthly cells are too thin. Always show the previous quarter beside the current month so that a cell can be read as a trend rather than a snapshot. Mark the first three months under any new definition as a new baseline.

From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.