The Time Saved by Technicians: The Return Nobody Counts

Wednesday, 10:05, at Meridian Parts. Ravi is nine working days into his first support job and has just closed ticket 7714. A mapped drive had vanished from a laptop in purchasing. He closed the ticket in six minutes, with the internal runbook open on his second screen. Hana, who runs the desk, remembers the same ticket type two years ago, when Ben was new. The drive problem took him forty minutes and a walk across the office to ask her which server the share lived on. Nobody is going to report Ravi's six minutes. There is no counter for it, no article view, no ticket that failed to arrive. The ticket arrived, was worked, and was closed, exactly as it would have been without the runbook. And the thirty-four minutes that did not happen left no trace anywhere except in what Ravi did with the rest of his morning.

Technician time saved is the hours the desk gets back on tickets that still arrive. That is because the people working them have a written answer open rather than a memory to search or a colleague to interrupt. It comes in three forms. The first is faster resolution with a runbook or article in front of the technician. The second is consistency, meaning fewer reopens, fewer escalations and fewer "how do we do this again" interruptions because everyone does it the same way. The third is onboarding, meaning a new technician who is useful in days rather than weeks and a senior who gets those weeks back. This article is part of our Measuring Self-Service ROI series. It is about measuring the three honestly, with every number a worked example from the same fictional desk.

It covers why this return goes uncounted and why it is usually the larger one, then the three forms it takes. Next comes measuring faster resolution from a before-and-after sample, then measuring consistency from reopens, escalations and interruptions. After that comes measuring onboarding from the senior's hours and the first solo day. The honesty rules, the worked example as a table, a short war story and the technician time worksheet to copy follow, in that order.

Why This Return Goes Uncounted

Deflection leaves evidence and technician time does not, which is the whole reason one is reported and the other is not. A ticket that stops arriving shows up as a drop in a count that the ticket system produces every month. The method for crediting it is in Deflection Math Without Fooling Yourself. A ticket that arrives and is resolved faster produces the same closed ticket as before. It has a shorter gap between two timestamps that nobody is looking at. The desk feels the difference, as a calmer afternoon and a queue that empties by four. And feelings are not a line on a ledger. So the knowledge base's biggest return is reported, if at all, as "the team finds it useful". That is true and persuades nobody.

It is usually the larger return because most tickets cannot be deflected and all of them can be worked faster. A user can reset their own password and connect their own VPN. But they cannot restore a mapped drive to a server they are not allowed to see. Nor can they set up a new starter's accounts, or fix a printer queue that has stalled on the print server. Those tickets will arrive whatever the portal says, and at Meridian they were most of the queue by hours. A runbook that takes thirty minutes off each of thirty mapped-drive tickets a month is worth about fifteen hours. That is twice the cautious estimate for the VPN article's deflection, from a document no requester will ever read.

The return is also the one that compounds. Every runbook written makes the next new technician faster from their first week. And every ticket worked from a runbook is a chance to correct it, which is the refine-on-reuse habit. A knowledge base read only by requesters is a collection of answers. One read by the desk is the desk's memory. And a desk with a memory is one that does not slow down when its senior technician goes on leave. That argument is made for the one-person desk in Documentation as Your Second Person, and it scales up without changing.

The Three Forms, and What Each Looks Like

Faster resolution is the plainest form: the same ticket type, worked by the same desk, in less hands-on time. That is because the steps are written down in the order the screens appear. It is measured per ticket type as the difference between a before-sample and an after-sample of hands-on minutes, times the number of tickets of that type per month. It applies to internal runbooks, which the technician follows, and to public articles, which the technician links in a reply instead of typing eleven steps. A how-to question answered with "the steps are here" and a link is a ten-minute ticket turned into a three-minute one. And it teaches the requester where the answer lives.

Consistency is the quieter form, and it shows up in three counts that already exist. Reopens fall, because a ticket worked from the runbook is worked completely rather than from whichever steps the technician remembered. Escalations fall, because the runbook includes the step that used to need the server administrator. And interruptions fall, because the question "which server is the share on?" is answered by the page rather than by the person who answered it last time. Questions go to whoever answered the last one; they are loyal in that way, and the runbook is the only thing that breaks the loyalty.

Onboarding is the form with the biggest single numbers and the fewest measurements. A new technician without runbooks learns the desk by asking. And every question costs the asker a wait and the answerer an interruption, for weeks. With runbooks for the top ten ticket types, the same technician works those types unaided inside a fortnight. And the senior's hours go back to the senior's own work. The cost of a missing runbook is paid mostly by the most experienced person on the desk, in pieces too small to log. That is why no desk has ever had a line in its budget for it.

Measuring Faster Resolution

Take a before-sample and an after-sample for each ticket type that has a runbook or article, twenty tickets each, and compare the middle values. The before-sample is twenty tickets of the type from the months before the runbook existed, with the hands-on minutes read from the timestamps. Measure from the claim to the resolution, with any waiting time on the requester taken out. The after-sample is twenty tickets from after the runbook had been in use for a fortnight. That is because the first fortnight is the desk learning to use it and is not representative in either direction. The method for reading hands-on minutes from a ticket, and why the median rather than the average, is in What ROI Means for a Help Desk.

Multiply the minutes saved per ticket by the tickets of that type per month, and quote the result as a range from the spread of the two samples. Meridian's mapped-drive tickets ran at a median of thirty-eight hands-on minutes before the runbook and seven after it. That was a saving of about thirty minutes each, on twenty-eight to thirty-six tickets a month. That meant fourteen to eighteen hours a month, which Hana widened to ten to twenty because both samples had wide middles. The printer runbook saved about eight minutes each on twenty-two to thirty tickets, three to four hours a month. The new-starter checklist saved about forty minutes on each of four to eight setups, three to five hours. The how-to articles, linked rather than retyped, saved about eight minutes on thirty-five to fifty-five tickets, five to seven hours.

Use a control type here too, exactly as in the deflection sum: a ticket type with no runbook, sampled before and after the same way. If the control type also got faster, the desk got faster for some other reason: a new technician settling in, a quieter quarter, a tool change. In that case, that share comes off every runbook's saving before it is claimed. Meridian's control was the "application error" type, which had no runbook and ran at about the same hands-on time in both samples. Without the control, every improvement on the desk is the knowledge base's, and the knowledge base did not hire Ravi.

Measuring Consistency

Count reopens, escalations and interruptions for the runbook's ticket types before and after, and cost each at the hands-on minutes it takes. A reopen is a ticket the requester sends back after it was marked resolved, usually with "it's happened again" or "that didn't fix it". Most ticket systems count them, since a requester's reply to a resolved ticket reopens it in most tools. Meridian's mapped-drive type had five reopens a month before the runbook and one after. Each cost about twenty-five minutes to pick up and rework. That meant a saving of about an hour and a half a month. Measuring reopens properly, including the ones that hide as new tickets, is the subject of Measuring Reopens Honestly; the worksheet takes the count that method produces.

Escalations are counted the same way: tickets of the type that were handed to a more senior person or another team, before and after, at the minutes each handoff cost both people. The mapped-drive runbook included the permissions check that used to need the server administrator. Escalations for the type fell from about six a month to one, at roughly forty minutes each across both people. That meant a saving of three hours or so. Interruptions are the hard one, because nobody logs them. Tally them for one week: every "quick question" to the senior about a documented type, with its rough minutes. Meridian's senior counted nineteen in a week before the runbooks and four in a week six months later. Each took about five minutes, including the minute it takes to get back to what you were doing. Call it an hour a week, four a month.

These numbers are small individually and real in total, and the honest report says both. Consistency at Meridian came to roughly eight hours a month across the documented types, which is half the faster-resolution figure and would not justify a runbook on its own. It justifies the runbook's upkeep, which is the point. A runbook that is kept accurate stays consistent. And one that drifts out of date produces reopens of its own, because everybody follows the same wrong step. The senior's time spent answering "how do we" was recorded nowhere, which the desk had described, in its last annual review, as "mentoring".

Measuring Onboarding

Measure onboarding by two numbers per new starter: the senior hours spent shadowing and answering questions, and the working days until the starter handled the top ten ticket types unaided. Both need a before, which means the last new starter. The figures for that person are usually reconstructable from memory and the calendar to within a few hours. That is accurate enough as long as the report says it was reconstructed. Meridian's previous starter, Ben, had been paired with Hana for most of six weeks, which she put at about forty hours of her own time. Ben had worked the top ten types alone from about week seven. Ravi, with runbooks for all ten, took twelve hours of Hana's time and was working them alone by day nine.

Report the senior hours as the saving and the earlier solo day as its own line, never added. The twenty-eight senior hours saved are real desk hours, freed from the most expensive person on it, and they belong in the sum. Ravi being useful four weeks earlier is also real and is not a saving in the same sense, because Ravi was being paid either way. It is a line that says "the new starter worked unaided from day nine rather than week seven", and a manager can value it. A desk that adds four weeks of a new starter's hours to its own savings has counted the salary budget as a return. And the finance director will notice.

Onboarding is per event, not per month, so keep it out of the monthly totals and show it beside them. A desk that hires one person every two years cannot claim fourteen hours a month from it. It can say "the next new starter will cost the senior about twelve hours rather than forty, and will be working unaided within a fortnight". That is a sentence any manager who has ever waited for a new hire to become useful will read twice. A new technician needs a login, a desk, and a document that answers the question they are about to ask. Most desks provide two of the three on day one.

The Honesty Rules

Do not count the same hour twice. A ticket that was deflected is not also resolved faster, because it was not resolved at all. It belongs in the deflection sum and nowhere else. A how-to question answered by a link is a faster resolution. The same question answered by the article before the ticket was raised is a deflection. The two are different tickets, and the counts must come from different places. The simplest guard is that the technician-time sum only ever looks at tickets that were closed. And the deflection sum only ever looks at tickets that were not opened.

Do not count minutes that arrive in pieces nobody can use. Thirty minutes off each mapped-drive ticket, thirty times a month, arrives in half-hour blocks and becomes two working days that a technician can plan a project into. Ninety seconds off each of two hundred password tickets arrives in ninety-second pieces and becomes nothing, however the arithmetic reads. Report the first in the sum. Report the second, if at all, as a sentence, and keep the two apart. The sum is for hours a person gets back; it is not for hours the spreadsheet can find.

Separate the runbook's effect from the technician's. People get faster at tickets with practice. A before-sample from a technician's first month against an after-sample from their sixth measures the technician, not the document. Sample the same people at comparable experience where you can. Use the control type where you cannot. And when the runbook is new and so is the technician, say so and quote a wide range. I once timed my own mapped-drive tickets before and after writing the runbook. I found the runbook had made me slower, because I had written it in the order I thought about the problem rather than the order the screens appeared. The fix took twenty minutes. The measurement was the only reason I knew to make it.

The Worked Example as a Table

The table below is Meridian's technician-time sum for one month, with the four documented ticket types, the consistency lines and the onboarding line. All are in hours and all as ranges. The effort line underneath is what the documents cost. The mapped-drive and printer runbooks, written to the pattern in Writing the Runbook, took about four and three hours. The new-starter checklist took six. The ten how-to articles took about an hour and a half each. Upkeep ran at about two hours a quarter across the set. The net is between roughly twenty and forty hours a month. That is more than the VPN article's cautious deflection and about equal to its generous one, from documents nobody outside the desk has ever seen.

Read the table for its shape rather than its totals. One ticket type, the mapped drive, carries half the result, because it was slow, frequent and had a single cause the runbook could address. That is the shape of every technician-time sum I have seen. One or two documents do most of the work and the rest add consistency. The onboarding line sits apart because it is a different kind of number. And it is the line the operations director at Meridian read first, because he had sat through Ben's six weeks.

A Short War Story: The Mentoring Budget at Redbrook Engineering

At Redbrook Engineering, the desk's senior technician, Aisha, was also the only person who knew how the engineering licence server, the drawing archive and the site VPN fitted together. When a new technician called Jonah joined, none of it was written down because Aisha had never had time. That was because she was answering questions. Over Jonah's first two months she later estimated she had spent around sixty hours standing behind his chair or answering "sorry, quick one". In the same period the backup rebuild she was supposed to be leading slipped by six weeks. The operations manager raised that with her in a meeting as a performance concern. Jonah, meanwhile, had resolved the licence-server tickets three different ways in his first month. Two of those came back as reopens, because each time he had asked a different person. Aisha wrote runbooks for the top twelve ticket types over the following quarter, at about forty hours in total. That was less than Jonah's first two months had cost her. The next new starter, nine months later, worked the twelve types unaided from her second week and asked Aisha eleven questions in total. Aisha counted, because by then she knew what the count was worth. The hours a missing runbook costs are paid by the most experienced person on the desk, in pieces too small to log. And the budget line they come out of is called the senior's own project.

The Technician Time Worksheet

The worksheet below produces the three forms of technician time for one period and keeps them apart from each other and from deflection. Section A is faster resolution, one row per documented ticket type, with the control type underneath. Section B is consistency, from counts the ticket system already keeps plus the one-week interruption tally. Section C is onboarding, per new starter, reported beside the monthly figures rather than inside them. Sections D and E are the effort and the totals. The rules at the end are the ones that stop the sum lying, and the sum does not leave the desk until each is ticked. Fill it in quarterly, from the same samples each time, and keep the old copies for the trend.

TECHNICIAN TIME WORKSHEET — ONE PAGE, HOURS ONLY
Desk: ______________   Period: ______________   Prepared by: ______________

A. FASTER RESOLUTION (one row per ticket type with a runbook or article)
   Type               Tickets/month   Before: median    After: median      Minutes      Hours/month
                                      hands-on minutes  hands-on minutes   saved each   (low to high)
                                      (20 sampled)      (20 sampled, skip
                                                        the first fortnight)
   ________________   ____            ____              ____               ____         ____ to ____
   ________________   ____            ____              ____               ____         ____ to ____
   ________________   ____            ____              ____               ____         ____ to ____
   Control type (no runbook): ______________  before ____ min  after ____ min
   If the control also got faster, take that share off every row above.

B. CONSISTENCY (documented types only)
   Reopens per month:        before ____  after ____  at ____ min each ... ____ h/month
   Escalations per month:    before ____  after ____  at ____ min each ... ____ h/month
   Senior interruptions, one-week tally:
                             before ____  after ____  at ____ min each ... ____ h/month

C. ONBOARDING (per new starter; report beside the monthly totals, never added)
   Senior hours spent shadowing and answering:  last starter ____   this starter ____
   Working days to first solo day on the top ten types:  last ____   this ____
   Senior hours saved per starter ........................................ ____

D. EFFORT
   Documents written: ____ at about ____ h each ............ ____ h once
   Upkeep per quarter ____ h, so per month .................. ____ h

E. TOTALS
   Gross hours per month (A plus B, low and high) ........... ____ to ____
   Net hours per month after upkeep ......................... ____ to ____
   Payback of the writing effort at the low net rate ........ ____ weeks

F. RULES (tick each before the figure leaves the desk)
   [ ] Same ticket type definition in both samples
   [ ] After-sample skips the fortnight after publication
   [ ] Control type sampled the same way
   [ ] Only minutes that arrive in usable blocks are in A
   [ ] No ticket that stopped arriving is counted here (that is deflection)
   [ ] Onboarding is reported per starter, outside the monthly total
   [ ] Reconstructed figures are marked as reconstructed

Hana filled the worksheet in for the quarter on a Friday afternoon, using the samples she had already pulled for the cost-per-ticket work. The figure she took to the operations director was "between twenty-five and forty-four technician hours a month, net, from the internal runbooks and the how-to articles, plus about twenty-eight senior hours saved per new starter". He asked whether that was on top of the VPN figure. It was. Ravi, who by then had been on the desk for three months, had added two steps to the mapped-drive runbook and corrected one. That is the other thing a runbook does when somebody is counting.

Frequently Asked Questions