What ROI Means for a Help Desk: Hours as the Honest Currency

Thursday, 15:10, at Meridian Parts. Hana runs the four-person support desk and has been invited to the budget meeting for the first time. She took that as a compliment until the operations director turned to her. "The knowledge base. Your team spent most of a quarter on it. What did it actually save us?" Hana said "a lot", then "it's hard to put a number on". And then, because the room was waiting, she said "probably a day a week across the team". She had no idea whether that was true. On the walk back to the desk she realised that every piece of evidence she needed was sitting in the ticket system. It had been for a year. Nobody had added it up because adding it up felt like marketing.

Return on investment, or ROI, is what you got back from something compared with what you put into it. For a support desk the thing put in is technician hours. The thing got back is also technician hours: the ones you no longer spend on tickets that stopped arriving, or that now take six minutes instead of forty. That is the whole idea, and it is simpler than the phrase makes it sound. This article is part of our Measuring Self-Service ROI series. It does the adding up honestly, in hours. Every number is a worked example from a fictional desk rather than a statistic from anywhere.

It covers what ROI means when the investment is a knowledge base or a self-service portal. Next comes why hours are the honest currency and money is somebody else's arithmetic. Then it covers cost per ticket as two different numbers and why mixing them is the commonest error. It explains how to work each one out at a desk of any size. Next come what to count and what never to count, and where self-service fits into the sum. A short war story and the cost-per-ticket worksheet to copy follow, in that order.

Return on Investment in Plain Words

ROI answers one question: was this worth doing? To answer it you need two figures, what it cost and what it gave back, measured in the same units over the same period. A knowledge base article that took four hours to write and saves the desk eight hours a month has paid for itself in a fortnight. It returns eight hours a month after that. A portal that took a hundred and twenty hours to set up and saves ten a month pays back in a year. The difficulty is entirely in being honest about the second figure. That is because "hours saved" is a number nobody can point at. Numbers nobody can point at grow when left alone.

The phrase comes from finance, and like most things from finance it is simpler than it sounds and asked about at the worst possible moment. In finance the units are currency and the period is a year. For a desk the units are hours and the period is whatever you have clean data for, usually three months before the change and three months after. Converting hours to money happens last, once, by whoever owns the hourly rate. Everything before that step is counting, and counting is the desk's job.

The question matters because a desk that cannot answer it loses the argument by default. The knowledge base, the portal and the self-service password reset all cost technician time up front. The only reason to spend that time is that it comes back with interest. If nobody measures whether it came back, the next request to spend a quarter on documentation will be judged on how the last one felt. Documentation always feels like the thing the desk did instead of answering tickets. Hana's "probably a day a week" was a guess dressed as a figure. The honest version, it turned out, was more persuasive and smaller.

Hours Are the Honest Currency

Measure in hours because hours are the thing the desk actually has. A technician's week contains a fixed number of them. Every ticket consumes some. Every hour not spent on a ticket is available for something else: a project, a runbook, the next ticket, going home on time. When you say "the VPN article saved us twelve hours last month", a manager can picture that: a day and a half of one person. When you say the same thing in currency, the manager's first question is where the money went. The honest answer is that it went nowhere because nobody's salary changed. That ends the conversation badly.

Hours also stay true. A figure in currency depends on an hourly rate. And the rate depends on who set it, whether it includes overheads, and whether it is the technician's cost or a notional value of their output. Hours have no such problem. Twelve hours is twelve hours whether the desk is in a hospital or a haulage firm. The figure you quote this year can be compared with the one you quote next year without anyone adjusting for anything.

There is one more reason, and it is the one that protects you. A figure in hours is a claim about the desk's own work, which the desk can defend from its own records. A figure in currency is a claim about the organisation's finances. The desk cannot defend that claim at all. And the person across the table almost certainly understands those finances better than you do. Stay in the territory where your evidence lives. The spreadsheet will happily multiply hours by a rate for anyone who asks; multiplying is its one talent and its only character flaw.

Cost per Ticket: Two Numbers, Not One

Cost per ticket is the hours the desk spends to handle one ticket. The first thing to know is that there are two honest versions of it. They answer different questions and must never be added together. The first is the loaded figure: every hour the desk spent on ticket work in a month, divided by every ticket it handled. This includes the triage, the follow-ups, the chasing, the walk-up that became a ticket after the fact, the ten minutes of reading before the work began. The second is the hands-on figure: the time a technician actually spends working one ticket of a particular type. That runs from picking it up to resolving it, with the waiting time taken out.

The loaded figure answers "what does this desk cost per ticket, all in?". It is the right number for the overall sum. If the desk handles fewer tickets, this is roughly what each one no longer costs. That is because the overhead travels with the ticket. The hands-on figure answers "what does this kind of ticket cost to work?". And it is the right number for choosing what to document first. A ticket type that takes forty hands-on minutes and arrives thirty times a month is a better target than one that takes five minutes and arrives fifty. At Meridian Parts, the fictional desk this series uses for its arithmetic, the loaded figure came out at about 1.2 hours per ticket. The hands-on figure for a password reset came out at about ten minutes. Both are true. Using the first for the second would make every reset look like a morning's work.

The commonest error in a help desk ROI figure is mixing the two, nearly always in the flattering direction. Tickets avoided are counted at the loaded figure when the ticket type was a quick one. So forty avoided resets become forty-eight hours instead of seven. The second commonest is quoting either figure as a single point. Both move month to month, with volume, with leave, with the odd week where half the desk was rebuilding a server. So the honest form is a range: "between 1.0 and 1.3 hours loaded, between eight and twelve minutes hands-on". A point looks precise. A range is precise about how precise you are.

Working Out the Loaded Figure

Start with the desk's hours, because they are the firmest number you have. At Meridian Parts, four technicians were contracted for about a hundred and fifty working hours each in the month Hana chose. That was after subtracting the leave on the calendar. It gives six hundred hours of desk. Not all of that is ticket work. Hana went through the team's calendars. She estimated the hours spent on projects, meetings, training, patching and the Tuesday stock-take of the equipment cupboard. She reached about a hundred and sixty. That leaves four hundred and forty hours for ticket work of every kind: triage, the work itself, chasing requesters, chasing suppliers, and logging the walk-ups.

Next, the tickets. The ticket system said the desk had closed three hundred and eighty tickets in the month. Hana added nothing to that number, which is itself a decision. A desk whose walk-ups are not logged as tickets is dividing its hours by a count that is too small. That makes each ticket look more expensive than it is. Meridian's desk had logged walk-ups for a year, after a bruising experience of the kind described in The Seven Ways Support Quietly Fails. So the count was reasonably honest. Four hundred and forty hours over three hundred and eighty tickets gives about 1.16 hours per ticket, which Hana wrote down as "about 1.2".

Then do it twice more, for the two previous months, because one month is an anecdote. Meridian's figures came out at 1.05, 1.16 and 1.31. The last was from a month with two people on leave and the same number of tickets. So the loaded figure Hana carried into every later sum was "1.0 to 1.3 hours per ticket". The table below shows the three months side by side. The only estimate in it is the non-ticket hours. And that is the one to be openly rough about, because it is the one somebody will question.

Write the oddities down as you go. Month three's figure is higher not because the desk got slower but because the overhead of running a desk does not shrink when two people are away. A reader who sees "1.31" without the note will conclude something about the desk. A reader who sees the note will conclude something about August.

Working Out the Hands-On Figure

The hands-on figure is measured per ticket type, from a sample. That is because no desk has clean time records for every ticket. Pretending otherwise is the first step toward a number nobody believes. Pick a type and pull twenty recent tickets of it. For each one, find the time the technician started working it and the time they resolved it. Subtract any stretch where the ticket was waiting on the requester or a supplier. Most ticket systems keep enough timestamps for this: the claim, each status change, each reply. If you run QuerySolv, the event history on each ticket already holds every one of those moments. In that case, the sample is a matter of reading rather than reconstruction. In any tool, where the timestamps are thin, a technician with a stopwatch on the next ten tickets of that type is better evidence than a guess.

Use the middle value, not the average, and quote the spread. Twenty mapped-drive tickets at Meridian ran from twelve minutes to two hours and ten. The last took that long because the drive turned out to be a permissions problem on a server that had been renamed. The average was dragged up by that one ticket to fifty minutes; the median, the value in the middle when you line them up, was thirty-eight. The honest statement is "typically thirty to forty-five minutes hands-on, with the occasional one that runs to hours". And that is the sentence that goes into the sum, with the range carried through rather than collapsed to a point.

Do this for the five or six ticket types that make up most of the queue, and no more to begin with. At Meridian those were password resets and unlocks, VPN connection failures, mapped drives, printers, "how do I" questions about the office software, and new-starter setups. The sample took Hana an afternoon. The result was a table of hands-on ranges that told her, before any deflection was measured, which types were worth an article. These were the ones where tickets per month multiplied by hands-on hours came to the biggest number. That ranking is the whole reason to have the hands-on figure, and it is why the figure must be per type. A single desk-wide hands-on average answers no question anybody asks.

Notice what the last column does to intuition. The password resets are the loudest ticket type on the desk and the one everybody complains about. And they are worth about as many hours as the mapped drives, which arrive a third as often and that nobody complains about at all. The VPN failures, which felt like a nuisance, are the biggest line. Hana had been about to spend her documentation effort on the resets because they were annoying. The table said to start with the VPN, and the table was right, which is the kind of thing tables do when nobody is looking.

What to Count

Count technician hours that were spent and are now not, on tickets that exist in the system, over a period long enough to be ordinary. Each of those three conditions is load-bearing. The hours must be technician hours, because those are the ones the desk can verify from its own records. They are also the ones that become available for other work. The tickets must exist. An avoided ticket is only evidence when you can show the type it belonged to arriving less often than before. The before and after must both be in the ticket system. And the period must be ordinary, because a before-period that happened to include a mail migration will make any after-period look like genius.

Count requester waiting time too, but on its own line, never added to the technician hours. Requester waiting time is how long the person who raised the ticket went without the thing they asked for, from opening to resolution. When a self-service article answers the question in four minutes instead of a ticket answering it in two days, that is a real and large benefit. It is simply not the desk's hours. Report it separately, as "median wait for this type fell from two working days to under ten minutes", and let the reader value it. A desk that adds requester hours to its own saving has discovered a way to be worth more than the company.

Count the effort, every time, on the cost side. Writing the article, testing it on a real user, the quarterly review, the screenshots redone when the software changed its menus: all of it is technician hours. All of it belongs in the sum. An ROI figure that counts the return and forgets the investment is not an ROI figure. It is a wish. The habit of counting effort is also what keeps the self-service programme honest later. That is when it is time to decide which articles to stop maintaining, the subject of the last article in this series.

What Not to Count

Do not count article views as tickets avoided. A view is a person opening a page. Some would have raised a ticket and now will not; some were technicians checking the steps. Some were the author admiring the formatting; some were one frustrated person opening it four times because it did not help. The relationship between views and avoided tickets is real and it is the subject of its own article, Measuring What Got Deflected. But the one thing it is never is one-to-one. A desk that reports "four hundred tickets deflected" because an article had four hundred views has reported its page statistics with a different label.

Do not count minutes nobody can use. If an article shaves ninety seconds off a ticket that arrives ten times a month, the arithmetic says fifteen minutes saved. The reality says nothing happened, because fifteen minutes scattered across a month in ninety-second pieces is not time anyone does anything with. Hours become real when they come in blocks a person can plan around. A mapped-drive runbook that turns forty minutes into six, thirty times a month, frees most of two working days. Two working days is a project. Report the small savings if you like, but keep them apart from the big ones.

Do not count productivity across the organisation. The temptation is enormous. If the portal saved every one of six hundred staff ten minutes a month, that is a hundred hours. That is more than the desk saved itself, and the slide practically writes itself. Resist it. Nobody can verify it. The person across the table will know it for what it is, which is a number chosen for its size. The desk's credibility is the only asset the ROI figure has. Spend none of it on a line you cannot defend from a ticket.

And do not count the before-period you wish you had. Suppose the quarter before the knowledge base went live was abnormal, because of a migration, a merger, or a flood in the server room. Say so and pick a different quarter, or quote the drop as a range that admits the uncertainty. The honest baseline is the dull one. I once compared a knowledge base's first quarter against the three months in which we had replaced every laptop in the company. The figure suggested the articles had removed a third of the desk's workload. They had removed about a tenth. The laptops had removed the rest by no longer being eight years old.

Where Self-Service Fits in the Sum

Self-service, meaning a knowledge base, a portal, a password reset the user can do alone, returns hours to the desk in two ways. They are measured differently. The first is deflection: tickets that stop arriving because the answer reached the person first. Deflection is counted in avoided tickets, from a drop in a ticket type that you can show in the ticket system. That is multiplied by the cost per ticket of that type, within a range. The sum itself, with its counting rules, is laid out in Deflection Math Without Fooling Yourself. The second is technician time: tickets that still arrive but take less to resolve because the runbook is open on the second screen. It also covers new technicians who are useful in days rather than weeks. Technician time is counted in hands-on minutes before and after, per type. And it is usually larger than the deflection and almost never measured, which is why The Time Saved by Technicians gets an article of its own.

Both sides draw on the same two numbers from this article. Both sit on the same ledger against the same cost line: the hours spent writing, testing and maintaining the articles and the portal. That is the structure of every honest self-service ROI, and it fits on one page. The page itself, with the before, the after, the hours and the ask, is laid out in Proving It to Management in One Page. Everything in this series is a way of filling in that page without fooling anyone, the desk included.

One last point about scale. A one-person desk handling forty tickets a month has a loaded figure. It has a hands-on figure for its top three types and an ROI for every hour it spends on documentation. A ten-person desk does too. The arithmetic does not get smaller; the sample does, so the ranges will be wider, and you quote them wider. A solo administrator who can say "the printer article saves me between three and six hours a month, and I know because I timed them" has a better ROI figure than most desks ten times the size.

A Short War Story: The Six-Digit Saving at Tollgate Foods

At Tollgate Foods, a desk lead called Marta was asked, at the end of the knowledge base's first year, what it had been worth. She built the figure the way a vendor's slide deck would have. She counted tickets avoided at the loaded rate, plus the hours every one of five hundred staff had saved by not waiting for a ticket. She multiplied the sum by an hourly rate she found in a planning document, all in currency, to six digits. The finance director, Ewan, read it and asked which budget line had gone down by that amount. He was told none had, because nobody's salary had changed and nobody's output had been measured. He did not say the figure was wrong. He said "I see". From that meeting on every number the desk produced was taken to be about half true, including the honest ones. The following year's request for a fourth technician, which the real backlog figures justified, was deferred twice while finance asked for the workings. Marta rebuilt the case in hours only, from tickets, with the effort on the cost side and the savings as a range. It was approved, fourteen months after it should have been. A desk's ROI figure is spending the desk's credibility, and credibility, unlike hours, does not come back on a schedule.

The Cost-per-Ticket Worksheet

The worksheet below produces the two numbers this article is about and keeps them apart. Section A is the loaded figure for the whole desk, done for three months so the range is real. Section B is the hands-on figure for one ticket type, from a sample. You fill in one copy of it per type you care about. Section C records the requester's waiting time on its own line, so that it is reported and never added. The rules at the bottom are the ones that stop the figure lying, and they are there to be ticked, not read. Fill it in once a quarter and keep the old copies. The trend across worksheets is worth more than any one of them.

COST-PER-TICKET WORKSHEET — ONE PAGE, HOURS ONLY
Desk: ______________   Period: ______________ (one calendar month)
Prepared by: ______________   Date prepared: ______________

A. LOADED HOURS PER TICKET (what the desk costs, all in)
   A1 Technicians on the desk this month ......................... ____
   A2 Working hours per technician this month
      (contracted hours, minus leave and sickness) ............... ____
   A3 Total desk hours (A1 times A2) ............................. ____
   A4 Hours not spent on tickets: projects, meetings, training,
      patching, admin (estimate from calendars; say it is rough) . ____
   A5 Ticket hours (A3 minus A4) ................................. ____
   A6 Tickets handled this month (closed, plus walk-ups logged) .. ____
   A7 Loaded hours per ticket (A5 divided by A6) ................. ____
   A8 The same figure for the two previous months ................ ____  ____
   A9 Range to quote (lowest to highest of A7 and A8) ............ ____ to ____

B. HANDS-ON HOURS PER TICKET, FOR ONE TYPE (one copy per type)
   Ticket type: ______________________________
   B1 Tickets sampled (aim for twenty recent ones) ............... ____
   B2 For each: hands-on minutes from first touch to resolution,
      with waiting time on the requester or a supplier taken out
      (list on the back; use timestamps, or a stopwatch on the next ten)
   B3 Middle value (median) of the list, in minutes .............. ____
   B4 Lower quarter and upper quarter, in minutes ................ ____ / ____
   B5 Hands-on hours per ticket (B3 divided by 60) ............... ____
   B6 Range to quote (B4 divided by 60) .......................... ____ to ____
   B7 Tickets of this type per month, three-month range .......... ____ to ____
   B8 Hands-on hours per month for this type (B6 times B7) ....... ____ to ____

C. REQUESTER WAITING TIME (reported on its own line; never added to A or B)
   C1 Median time from opened to resolved for this type .......... ____
   C2 Tickets of this type per month ............................. ____

D. RULES (tick each before the figure leaves the desk)
   [ ] Every figure is in hours; whoever owns the hourly rate applies it
   [ ] Loaded and hands-on figures never appear in the same multiplication
   [ ] Requester waiting time stays in section C
   [ ] Three months used, not one
   [ ] Walk-ups are in the ticket count or the gap is stated
   [ ] This month's oddities are written below

Oddities this month: ______________________________________________________

Hana filled in section A for three months and section B for six ticket types in the fortnight after the budget meeting. The two tables above are what came out. She sent the operations director one paragraph: the loaded range, the top three types by hands-on hours, and a sentence about what would follow. The sentence said the deflection and the technician time would follow in a month, measured the same way. He replied "good, thanks", which from him was a speech. The knowledge base had not yet been shown to be worth anything. What had been shown was that the desk could count, and that turned out to be the harder thing to prove.

Frequently Asked Questions