Cost per Ticket and Its Traps: A Diagnostic, Not a Target

Thursday, 09:40, at Redbrook Engineering. Priya, who runs the four-person desk, has an e-mail from Owen in finance, who has been reading the cost map she drew for him last month. "Thanks for this. By my arithmetic the desk's cost per ticket is about 1.1 hours. Could we set a target of 0.9 for the year end?" It is a reasonable e-mail from a reasonable person. Priya can think of three ways to hit 0.9 by the end of the month. One involves logging every phone call as a ticket. One involves closing tickets faster than they can be fixed. One involves two of her technicians doing something else on Fridays. None of the three would make anyone at Redbrook better supported, and all of them would make the number look wonderful.

Cost per ticket is the hours a desk spends divided by the tickets it handles. It comes in two honest forms. A loaded figure is every hour of ticket work over every ticket. A hands-on figure is the working time for one ticket of one type. How to calculate both, and why they must never be mixed, is the subject of What ROI Means for a Help Desk. This article does not redo the sum. This article is about what the number is for once you have it, which is diagnosis. It is also about what happens when it is used as a target instead, which is the subject of most of what follows. This article is part of our The Economics of Support series. In this series, every number is a worked example from a fictional desk, in hours, and never a benchmark.

It covers what the number is and where its calculation lives, and why it is a diagnostic rather than a target. Next come the things that move it honestly, including the one that makes a better desk look worse, and the three wrong ways to drive it down. Then come the companion figures it must be read beside and the read done on four quarters of a fictional desk. A short war story and the cost-per-ticket read to copy come last, in that order.

What the Number Is, and Where the Sum Lives

The loaded figure is one division: the desk's ticket hours in a month over the tickets it handled in that month. At Redbrook, from the cost map, the desk spent about four hundred and seventy hours on ticket work of every kind. That included the rework, the walk-ups and the overhead. The desk handled about four hundred and twenty tickets, which gives a little over 1.1 hours per ticket. The hands-on figure is per type, from a sample of timestamps. A password reset at Redbrook runs about ten minutes hands-on. A mapped drive runs about forty, and a new-starter setup two to three hours. Both figures are ranges when quoted honestly, because both move month to month for reasons that have nothing to do with the desk's quality.

The ROI article linked above owns both calculations, with a worksheet. And the commonest error it warns about is the one to carry into this article: mixing the two. A loaded figure applied to a quick ticket type makes every reset look like a morning's work. A hands-on figure applied to the whole desk makes the overhead disappear. Keep them labelled. Everything this article says about traps applies to the loaded figure, because that is the one that ends up in an e-mail from finance. The hands-on figure is a planning tool. Nobody has ever been asked to hit a target for it, which is one of its charms.

The division is trivially easy and that is the problem with it. A figure that takes two minutes to compute and fits in a sentence will be computed and put in sentences. Once it is in a sentence it starts to sound like a verdict. 1.1 hours is not a verdict. It is a ratio between two quantities that each have their own reasons for moving, and the ratio moves whenever either of them does. The whole skill of using cost per ticket is remembering that it is a fraction, and asking which half moved.

A Diagnostic, Not a Target

A diagnostic is a number whose job is to tell you that something changed and to send you looking for what. A target is a number someone is expected to move, and is judged on moving. Cost per ticket is a good diagnostic and a terrible target, for the same reason: it is easy to move. A diagnostic that moves easily is sensitive, which is what you want from a diagnostic. A target that moves easily is one that will be moved by the cheapest available means. And the cheapest means of moving cost per ticket are the three described below, none of which involve supporting anyone better. The figure cannot tell the difference between a desk that got more efficient and a desk that got better at counting. Only you can, by looking at what else moved.

The temperature on a thermometer is a diagnostic. If the reading goes up, you look for the fever. You do not put the thermometer in the fridge and declare the patient well. Cost per ticket has exactly this character. When it rises, the honest response is "something changed, find it". The finding takes an hour with the companion figures described later. When it falls, the honest response is the same. A desk that treats a fall as good news without asking why has stopped diagnosing and started celebrating. The two feel identical from the inside.

Owen's e-mail was not wrong to want the desk cheaper per ticket. It was wrong to want the number lower, which is a different wish. The difference is the subject of a whole article on Metric Gaming and Its Cures. Priya's reply took her most of a morning to write, and this article is a longer version of it. Her reply was that she would be glad to report cost per ticket every quarter alongside four other figures. She would not accept a target for it on its own, because she could hit any target he named by the end of the month. And he would not like how. He asked how. She told him. The target was withdrawn, which is the only good outcome a cost-per-ticket target has ever had.

What Moves It Honestly

The mix of tickets moves it more than anything the desk does. A month heavy with password resets and "how do I" questions has a low loaded figure, because the denominator fills with ten-minute tickets. A month heavy with new-starter setups and a server fault has a high one. Nothing about the desk changed. The reset tickets are not a sign of efficiency and the server fault is not a sign of waste. They are what arrived. Any reading of cost per ticket starts by asking whether the mix moved. And the ticket type counts for the month answer that in a minute.

Self-service and automation move it in the direction nobody expects, which is up. When Redbrook's identity team switched on a self-service password reset, about a hundred ten-minute tickets a month stopped arriving. The desk's hours fell by about seventeen, the ten minutes each. The ticket count fell by a hundred. Four hundred and fifty-three hours over three hundred and twenty tickets is about 1.4 hours per ticket, up from 1.1. The desk was unambiguously better, with the same people, the same work, and a hundred fewer people a month waiting for a reset. Cost per ticket rose because the cheap tickets left and the expensive ones stayed. Every successful deflection programme does this, and every desk that runs one should warn finance before the number moves. (Warn them twice. The first time they will nod.)

Leave, hiring and the odd month move it too, and in the dull direction. A month with two technicians away has nearly the same overhead and fewer handling hours spread over nearly the same tickets, so the figure drifts. A new technician's first quarter costs hours and produces few resolved tickets, so the figure rises until they are useful. A month with a migration in it is not a month at all for this purpose. None of these are findings. All of them are footnotes, and the honest report carries the footnote next to the figure, as the ROI article's worksheet does with its "oddities noted" line.

The one honest way the desk itself moves the figure down is by removing waste. That includes rework, unlogged walk-ups made into logged ones and then prevented, and the overhead of a bad habit. When the cost map's removable lines shrink, the numerator falls and the denominator holds, and the figure drops for a reason you can name. That is the only fall worth celebrating. And the test of it is that the companion figures either hold or improve at the same time. Everything else that lowers the number is one of the three traps.

Wrong Way One: Inflate the Count

The first wrong way is to make the denominator bigger without making the work bigger, and the ticket count is wonderfully easy to inflate. Log every phone call as a ticket, including the ones that were "is Dev in?". Split a new-starter setup into six tickets, one per system. Let the monitoring tool open a ticket for every alert and auto-close them in a batch. Open a ticket for every walk-up, which is right, and also for every corridor question that was answered in a sentence, which is padding. The hours barely move. The count climbs. The figure falls, and a reader who sees only the figure concludes that the desk got cheaper.

The trap is hard to see from inside because some of it is good practice. Logging walk-ups is the first thing the cost map tells a desk to do. It does raise the count honestly, because those were real requests that were real work. The line between honest logging and padding is whether the thing logged consumed technician time that belongs in the numerator. A ten-minute walk-up does. A "yes, he's at lunch" does not. Splitting one piece of work into six tickets does not create work. It creates records, and the records are the cost. A desk that wants to pad its count will always find a defensible reason for each extra ticket. The sum of the defensible reasons is a fifth more tickets and the same work.

The detection is the ticket count itself read against the handling hours. If the count rises and the hours do not, something is being logged that was not being worked. Read a sample of the new tickets. If most of them took under three minutes and have no resolution note worth the name, the count is inflated. Redbrook's walk-up logging raised the count by about a sixth. The handling hours rose by about a twentieth. Priya wrote under the figure "count now includes logged walk-ups, which were previously unrecorded; the fall in cost per ticket is a correction, not an improvement". That sentence is what honesty looks like on a report. It is one line, and it changes what the number means.

Wrong Way Two: Starve the Work

The second wrong way is to make the numerator smaller by spending less time on each ticket than the ticket needs. Close the ticket on the first plausible fix without confirming it worked. Answer the "how do I" question with a link rather than a sentence. Skip the resolution note. Stop asking the second question that would have found the real cause. Each ticket takes fewer minutes. The figure falls. And the tickets come back, reopened by requesters whose problem was not fixed. Or they are raised again by the next person to hit the same fault that nobody wrote down. The time comes back too, as rework, which the cost map counts and the cost per ticket figure quietly absorbs as more tickets.

The cruelty of this trap is that it lowers the figure twice. The rushed first attempt costs fewer hours, so the numerator falls. The reopen or the repeat is a second ticket in many tools, or a reopened one with more hours, so the denominator rises or the hours spread. Either way the figure improves while the desk does the same job twice and the requester waits through both attempts. A desk under a cost-per-ticket target will drift into this without anyone deciding to, because every individual shortcut looks like efficiency. The reopens arrive a week later with somebody else's name on them.

The detection is the reopen rate and the repeat rate, read beside the figure. A fall in cost per ticket with a rise in reopens is a desk working faster and worse. And it should be read as a worse desk, because the requester is the one paying the difference. How to count reopens so that two people get the same number belongs to Measuring Reopens Honestly. The read only needs the direction. In QuerySolv and in most tools a requester's reply reopens a resolved ticket. So a rushed close shows up as a reopen rather than vanishing. That is what makes this trap detectable at all. The tension between speed and quality has its own article in Speed Versus Quality. Cost per ticket is where that tension turns into a number that rewards the wrong side.

Wrong Way Three: Move the Cost Somewhere Else

The third wrong way is to make the desk's hours smaller by making somebody else's hours bigger. Staff the desk thinner and let the queue wait. The hours fall, the tickets eventually get handled, and the requesters absorb the difference as waiting time. That time is not on the desk's books. Push the first-line questions to a departmental "super user" who is not on the desk's payroll. Insist that every request come through a form so detailed that the requester does half the diagnosis. Each of these lowers the loaded figure, and each of them moves cost from the one place it was being counted to several places where it is not.

Waiting is the usual destination, and it is the largest line on the cost map precisely because it is the easiest place to hide cost. A desk that goes from four technicians to three with the same tickets will show a lower figure within a quarter, if the three are not drowning. That is because the overhead shrinks with the people and the tickets still get done, later. The requesters' waiting hours rise by far more than the desk's hours fell. That is because a ticket that waits two days instead of two hours costs its requester the whole of the difference. And there are more requesters than technicians. The arithmetic of that, and why it dwarfs the desk's own hours, is in The Cost of Waiting. Here the point is simpler: a cost that moved is not a cost that fell.

The detection is the median time to resolution and the backlog age, read beside the figure. A fall in cost per ticket with a rise in how long requesters wait is cost being moved, not saved. And the honest report says so in those words. There is also a softer sign, which is the shadow channel. Departments stop raising tickets because the queue is slow and start phoning a favourite technician directly. That lowers the count and the hours together and hides a department's worth of support from every figure the desk has. When the count falls and nobody can say why, ask the departments. One of them has left.

Reading It With Its Companions

Cost per ticket read alone is a rumour. Read beside four other figures, it is a finding. The four start with volume by ticket type, which shows whether the mix moved, and the reopen rate, which shows whether the work is being starved. The median time to resolution and the backlog age together show whether cost is being moved to waiting. Satisfaction where you have it shows whether the requesters noticed. The idea of reading a metric only in company, and the scorecard the five sit on, belong to Reading Metrics Together. The table below is that idea applied to this one number. If you run QuerySolv, the standard reports already put volume, backlog by age, resolution times and the reopen rate beside each other. In that case, the companions are a matter of reading rather than building. In any tool, they are the four reports to open before the figure is quoted.

Every row in the table takes a few minutes to check and most months land on the dull rows, which is fine. The table's purpose is to stop the two readings that are made without checking: that a fall is good and a rise is bad. Half of each column says the opposite. A figure that can mean its own opposite depending on company is not a bad figure. It is an ordinary one, and the company is the whole method.

The Read, Worked on Four Quarters

Here is Redbrook's loaded figure over four quarters, as a worked example from a fictional desk, with the read done on each. In the first quarter the desk spent about four hundred and seventy hours on ticket work and handled about four hundred and twenty tickets. That gives 1.1 hours. Nothing to read; it is the baseline. In the second quarter the technicians began logging walk-ups. Hours rose to about four hundred and seventy-five, tickets to about four hundred and ninety: just under 1.0. Reopens flat, wait flat, volume up across every type by about the same share. Reading: a counting correction. Priya reported the fall with a footnote and refused the credit, which cost her nothing and bought her the next two quarters.

In the third quarter the self-service reset went live. Hours fell to about four hundred and fifty-five, tickets to about three hundred and ninety: close to 1.2. Volume down almost entirely in one type; median wait for that type fell from most of a day to a few minutes; reopens flat; satisfaction for resets up. Reading: the cheap tickets left. Priya had sent Owen a note a month before saying the figure would rise and why. When it did, the conversation was about the hundred people a month who no longer waited for a reset rather than about the number. The note was four sentences. It did more work than any report that quarter.

In the fourth quarter the figure rose again, to about 1.3, with the same mix and the same count. Reopens had risen by half. Two technicians had been covering a project. The tickets they did pick up were being closed on the first plausible fix. The fixes were coming back. Reading: rework, and a real finding. The cure was the closing conversation, not a target. By the next quarter the reopens were back where they had been and so was the figure. Four quarters, four movements, four different meanings, one of which mattered. A desk reading the figure alone would have celebrated the second quarter, panicked in the third, and missed the fourth.

A Short War Story: The Falling Number at Bluewater Bank

At Bluewater Bank, a desk lead called Tomas was given a target to cut the desk's cost per ticket by a fifth within the year. He hit it in four months, by having every phone call logged as its own ticket and every password reset done at the counter recorded separately. He also had every "how do I" question closed with a link to an article rather than an answer. The figure fell on schedule and was praised in the quarterly review. Over the same four months the reopen rate rose by about half. The branches began phoning the regional IT lead directly because the desk's answers had stopped answering anything. The rework, when someone finally counted it, came to about forty technician hours a month that had not been there before. The target having been met, the following year's target was set a fifth lower again. Tomas spent most of that year rebuilding the branches' trust in a desk that had, by its own headline figure, never been better. A number made into a target stops measuring the desk and starts measuring the desk's willingness to hit it.

The Cost-per-Ticket Read

The sheet below is the read as a form, one copy per quarter. And it is filled in before the figure is quoted to anyone. Section A is the figure and its two halves, so that the reader can see which half moved. Section B is the companions, which take a few minutes each from the standard reports. Section C is the reading, chosen from the table above, and it is one line. Section D is the sentence that goes in the report, which always carries the reading beside the figure. Section E is the checklist that stops the number travelling alone. The sheet is deliberately short, because the figure is quick to compute and the read should be quick to do. The point is that it is done every time, not that it is thorough once.

THE COST-PER-TICKET READ — ONE QUARTER
Desk: ______________________   Quarter: ____________   Prepared by: ______________

A. THE FIGURE AND ITS HALVES
   A1 Ticket hours this quarter (all ticket work, from the cost map) ... ____ h
   A2 Tickets handled this quarter (same counting rule as last time) ... ____
   A3 Loaded hours per ticket (A1 over A2) .............................. ____
   A4 Last quarter's figure ............................................. ____
   A5 Which half moved: hours ____  count ____  both ____  neither ____
   A6 Counting rule changed since last quarter? ____  How: ______________________

B. THE COMPANIONS (direction since last quarter)
   B1 Volume by ticket type: which types moved, and which way ..... ______________________
   B2 Reopen rate ........................................ up / flat / down
   B3 Repeat faults (same cause, new ticket) ............. up / flat / down
   B4 Median time to resolution .......................... up / flat / down
   B5 Backlog older than thirty days ..................... up / flat / down
   B6 Satisfaction, where measured ....................... up / flat / down
   B7 Any department quieter than usual? ____  Which: ______________________

C. THE READING (one line, from the companion table)
   C1 ________________________________________________________________________
   C2 Is this a finding, a footnote, or a correction? ______________

D. THE SENTENCE FOR THE REPORT
   "Cost per ticket was ____ hours this quarter, against ____ last quarter.
    The change is because ______________________________________________,
    and the figures that confirm this are ____________________________."

E. BEFORE THIS LEAVES THE DESK
   [ ] A1 uses the same definition of ticket hours as last quarter
   [ ] A2 uses the same counting rule, or A6 says what changed
   [ ] Every companion in B was read, not assumed
   [ ] The figure is never quoted without C1 beside it
   [ ] No target has been accepted for A3 on its own
   [ ] If self-service or automation went live, finance was warned before the rise

Priya's reply to Owen, in the end, was a copy of this sheet for the quarter just gone. It had the sentence in section D filled in and the companions beside it. He read it, asked what a reopen was, and withdrew the target in the same e-mail. The figure went on being reported every quarter, in company. Nobody at Redbrook has since been asked to make it smaller, only to say what it means. That is the whole of what a diagnostic is for.

Frequently Asked Questions