The Training and Time Case: A Week That Pays Itself Back

Monday, 08:35, at Wrenfield College. Sade has the week's first six tickets open and four of them are the same ticket. A teacher logs into a classroom computer, the profile takes eleven minutes to load, and the lesson starts without it. The desk has been fixing this one profile at a time for a year, thirty-odd times a month, at about half an hour each. Sade knows what the real fix is. It is a rebuild of the way the profiles are stored, which she has sketched twice on a whiteboard and never started. Starting it means five uninterrupted days and the queue has never once offered her five uninterrupted hours. When she raised it with Fiona, the bursar, the answer was reasonable and useless: "You already have the time; it's your week. Just prioritise it." Sade did not say what she thought, which was that the time she already had was the time the queue was eating.

A time investment is hours taken away from the queue now in order to get more hours back from the queue later. And the time case is the argument for being allowed to make one. It comes in three common shapes. One is a fix that needs a protected week. Another is a course or a shadowing day that closes a skill gap visible in the tickets. The last is a day to write the knowledge base articles that would answer the commonest questions before they become tickets. None of them costs a salary or a licence. That is why they are the asks most often waved through in principle and most often refused in practice. "You have the time" means "find it in the queue", and the queue is where the gap lives. This article is part of our Using Ticket Data to Justify Resources series. The article is about making the time case in hours returned, with the one thing the other cases do not need. That is a plan for who holds the queue while the hours are spent.

It covers what a time investment is and why it is refused, then the fix that needs a protected week. Next come the skill gap visible in the tickets, the knowledge base that needs a day, and the arithmetic of hours taken and hours returned. We turn to the cover plan, making the ask, and when the time case is the wrong case. We finish with a short war story and the time-investment case to copy, in that order.

What a Time Investment Is, and Why It Is Refused

A time investment is a loan from the present to the future, in hours. The desk stops doing thirty-five hours of tickets this week, and in return it stops receiving a hundred and seventy hours of tickets over the following year. Stated that way, nobody refuses it. It is refused in practice because the present is where the queue is, the queue is visible, and the future is a claim. The manager who says "just prioritise it" is not being obstructive. They are saying that the hours already exist in the desk's week. That is true in the sense that a technician is paid for them. It is false in the sense that the queue consumes them before anyone can choose.

The time case therefore has to prove three things that the headcount and tooling cases do not. First, that the hours taken will produce the hours returned, which is the arithmetic, in ranges, from the tickets. Second, the hours cannot be found inside an ordinary week. That is the capacity sum from Evidence Over Anecdote: a desk whose gap is never negative has no spare week lying about. Third, that the queue will be held while the hours are spent, so that the investment does not simply become backlog with a better excuse. The third is the one most time cases skip, and it is the one that gets them refused.

The ask is permission and cover, not money, and it usually goes to the desk's own manager rather than to finance. That makes it a shorter conversation and a more personal one. The person being asked is the person whose phone will ring when the queue is slower that week. Write the case for them: one page, in hours, with the week's cost on it in plain sight. A time case that hides the cost of the week is spotted by the first person who has ever covered a desk.

The Fix That Needs a Protected Week

The first shape is a repeat ticket with a known permanent fix that nobody has had the uninterrupted time to do. The source is a repeat ticket in the plainest sense: the same symptom, the same cause, arriving over and over, each occurrence fixed and none of them prevented. At Wrenfield the slow-profile ticket arrived thirty-five times a month, give or take five, at a sampled median of thirty minutes each. That is about seventeen hours a month of technician time spent fixing the same thing. The permanent fix was a rebuild of the profile storage with a test on two classrooms before rollout. Sade estimated it at thirty to forty hours of one person's uninterrupted attention.

The return is the tickets the fix removes, and it is never all of them, so say so. A rebuilt profile store would remove most of the slow-profile tickets but not the ones caused by a failing disk in one classroom. So Sade claimed twenty-five to thirty-two of the thirty-five. At half an hour each that is twelve to sixteen hours a month returned. Against thirty to forty hours invested, the payback is two to three months, and the first year returns somewhere between a hundred and ten and a hundred and sixty hours net. That is the sentence for the page. Getting the permanent fix done, with the things that stop it, has its own article at Getting the Permanent Fix Done. The time case is the argument for the hours that article assumes you have.

Protected means protected. A fix that needs thirty-five hours does not take thirty-five hours when delivered as seven Friday afternoons. Each afternoon starts with an hour of remembering where the last one ended. It finishes with the queue pulling the technician back an hour early. In my experience a fix in fragments takes about half again as long as the same fix in one run. Some of them never finish at all, which is the war story at the end of this article. Ask for the week. Offer the five Fridays only as the fallback, and price the fallback honestly at fifty hours rather than thirty-five.

The Skill Gap Visible in the Tickets

The second shape is a kind of ticket the desk cannot finish itself, or finishes slowly, because nobody on it has the skill. The tickets show it in three ways. Tickets of one type are escalated to an outside supplier or another team far more often than any other type. Tickets of one type take several times the desk's median hands-on time. Or tickets of one type bounce between two technicians, each doing a little and handing it on. The ticket's own history will show that as a chain of handoffs. The escalation rate and the handoff chain are visible in most tools' standard reports and in the event history on each ticket, as they are in QuerySolv. So the gap is a filter rather than a hunch.

At Wrenfield the gap was wireless networking. Eleven tickets a month, on average, went to the network supplier because nobody on the desk could read the controller. Each one cost the desk about an hour and a half of coordination, chasing and relaying. There was also a wait of about two working days before the supplier looked at it, during which a classroom's wireless stayed broken. The desk's own hours came to about sixteen a month; the waiting cost fell on the teachers and the students. And the way to count that kind of cost is in The Cost of Waiting. Sade estimated what a technician could handle with a three-day course and a day shadowing the supplier's engineer. Her estimate was eight or nine of the eleven in-house, at about forty-five minutes each.

The arithmetic: the training is about thirty hours of one technician's time, including the shadowing and a few hours of practice. The return is eight to nine escalations a month that no longer need an hour and a half of coordination. Instead they need forty-five minutes of fixing, a saving of about six to seven hours a month on the desk's side. Add the two days of waiting removed from each one, which is the larger benefit and the one the bursar will understand immediately. The payback on the desk's own hours alone is four to five months, longer than the fix. That is normal: training pays back more slowly and keeps paying for longer.

One rule about this shape, because it is the one that touches people. The skill gap belongs to the desk, not to a technician. And the tickets are evidence that nobody on the desk has the skill, not that one person lacks it. Who gets the training is a coaching decision made with the person. Any per-technician figure that informs it, such as how long each person's network tickets took, is for that conversation and never for a ranking. Do not read a per-person figure at all from fewer than a few hundred tickets of that type per person, which on a small desk means never. The case names the gap and the training. It does not name a weakness.

The Knowledge Base That Needs a Day

The third shape is the day nobody has to write the ten articles that would answer the desk's commonest questions before they arrive. And it is the cheapest investment in this article and the one most often never made, because the day for it is always next week. The source is the ticket list sorted by how often the same question is asked. At Wrenfield the top ten questions from staff mostly covered three subjects. These were printing to the new copiers, connecting a personal phone to the wireless, and the first login on a new laptop. Together, the top questions accounted for about sixty tickets a month at a median of fifteen minutes each. That was fifteen hours a month of answering questions whose answers had not changed in a year.

The investment is a day, seven or eight hours, to write the ten articles from the resolution notes the desk already has. The articles follow the shape in The First Twenty Articles. Add about an hour a month to keep them true. The return comes in two separate streams that the case keeps apart. One is tickets that stop arriving because the requester found the article. The other is tickets that still arrive and take less time because the technician has the runbook open. The honest arithmetic for the first stream is in Deflection Math Without Fooling Yourself, and it insists on a low and a high count. Sade claimed that between fifteen and thirty of the sixty tickets would stop arriving, four to eight hours a month. She claimed the rest would take ten minutes instead of fifteen, another two to three hours. Six to eleven hours a month, for a day, pays back inside the second month even at the low end.

The knowledge base may let an article be visible to the desk alone or to everyone, as it does in QuerySolv and most tools. Where it does, the ten articles can be written once as runbooks and then trimmed into user guides. That is how a day produces both streams. Say in the case which articles are which. A reviewer who hears "ten articles" will picture ten public pages and wonder why five of them have no deflection figure. Five of them were never meant to; they make the remaining tickets faster, and that is a different line on the page.

Hours Taken, Hours Returned: The Arithmetic

All three shapes share one sum. Hours invested, once, plus any recurring upkeep. Hours returned per month, as a range with the cautious count on the left. Payback in months, which is the investment divided by the monthly return, done at both ends of the range. And the first-year net, which is twelve months of return less the investment and the upkeep, also at both ends. The table below is Wrenfield's three cases laid out that way, and it is the shape of the second section of the one-pager.

Read the right-hand column with the left-hand column in mind. The profile fix returns the most and costs the most. The articles return a great deal for almost nothing. The training returns least on the desk's own hours and most on the thing the desk cannot count. That is a classroom with working wireless two days sooner. All three are good investments, and the case says so. It then asks for them in the order that fits the queue. The day comes first, because it is a day. The week comes when the cover plan allows, and the training when the course runs.

Keep the ranges. A reviewer will ask for a single figure, and the honest answer is the middle of the range with the range beside it. A fix that was going to remove "about thirty tickets a month" and removes twenty-six has succeeded. One that was going to remove "thirty-two" and removes twenty-six has, in the reviewer's memory, fallen short. Ranges are not hedging. They are the shape the truth has before the fix is done.

The Cover Plan: The Part That Is Not Hours

The cover plan is the paragraph that says who holds the queue while the hours are spent, and what will be slower, and by how much. It is the difference between a time case and a wish. For a protected week it has four parts. The first part is who covers. At Wrenfield, the second technician held the queue alone for the week. Sade took the first hour of each morning for anything that could not wait. The next part is what the cover does: triage-only. That means every new ticket is read, acknowledged with a person's reply and given an owner within the hour. Anything that will take more than a few minutes is scheduled for the following week unless it stops a lesson. Then comes which week: a quiet one, chosen from the desk's own volume pattern over the last year. At a college that is not the first week of term. The last part is what the requesters are told: a short notice that routine requests will take a few days longer that week, and why.

Then the cost of the week, in the open. At Wrenfield the capacity sum said one technician on triage-only would fall about forty hours behind the ordinary week's work. That is about eighty tickets at half an hour, most of them deferred rather than lost. Recovery would take two to three weeks with the profile fix already removing eight tickets a week from the load. Writing that on the page is uncomfortable and it is what gets the week approved. The bursar can see that the desk has thought about her phone. A protected week with no cover plan is a normal week with a sign on the door.

For the training shape the cover plan is smaller, three or four days of one person away, and the same four parts apply. For the knowledge base day it is a morning's notice and an afternoon's triage-only, and most desks can simply do it. The point is the same at every size: the case names the cost of the time as precisely as it names the return. The person approving it is the person who will pay the cost, and they can tell when it has been left off.

Making the Ask

The page has five parts. The first is the source, in tickets, with the numbers that show it is a repeat and not a run of bad luck. Next comes the investment in hours and what exactly will be done with them. Then comes the return as a range with the payback. The last parts are the cover plan with the cost of the week, and the ask with a date and a promise to report back. The page goes to the manager who owns the desk's time. The sentence to say when handing it over is the whole case in one breath: "I am asking for the queue to be about forty hours slower in the week of the ninth, held at triage-only by Dan, in exchange for twelve to sixteen hours back every month after it, and I will show you the ticket count at three months."

Report back whether or not the week is granted, because a time case has one advantage over the others: its results arrive fast. A profile fix done in week one shows up in week three's ticket count. Put the before figure on the page now, promise the after figure for a named month, and deliver it unprompted, in the shape After the Decision describes. A desk that has shown one week paying for itself is given the next week without a page. (It should still write the page. The habit is the point.)

When the Time Case Is the Wrong Case

Sometimes the tickets say the problem is not a week's worth. If the capacity sum shows a persistent gap of half a person or more, a protected week does not close it. The week defers the gap, and the desk comes back from the week to a larger backlog and the same gap. That is a headcount case, and the time case should be made after the hire, when the surplus exists to spend. If the repeat ticket's permanent fix lies with a supplier or another department, the week will be spent chasing them. In that case, the right ask is a decision from above rather than hours from the desk. If the knowledge base already holds the articles and nobody reads them, another day of writing will not help. In that case, the problem is portal adoption, which is a different case with its own series in this library.

The honest time case says which of these it is not. "This is not a headcount problem: the ordinary gap is about ten hours a month and the fix removes more than that" is a sentence that pre-empts the obvious alternative and tells the reviewer the desk has read its own numbers. A case that cannot say that sentence should be rewritten as the case it actually is.

A Short War Story: The Five Fridays at Larkspur Print

At Larkspur Print, a technician called Callum asked for a week to rebuild the print queue configuration that generated about forty tickets a month. He was given, as a compromise, "Friday afternoons until it's done". The first Friday went on setting up a test environment. The second began with forty minutes of working out what the first had done. It ended an hour early when a customer order failed to print and the queue reclaimed him. By the fifth Friday the test environment had been borrowed for something else. By the eleventh the company had replaced the printers, which fixed the problem for reasons unrelated to anything Callum had done. The eleven afternoons came to about fifty hours of work, and the fix never landed. Callum asked the following spring for a week to rebuild the file server permissions. His manager said, reasonably, "the last one took three months and we never finished it". The week had never been refused. It had been granted in pieces, and a week in pieces is not a week.

The Time-Investment Case

The template below is the one page for any of the three shapes; tick the shape at the top and leave the lines that do not apply blank. Section one is the source and it must contain ticket counts, not impressions. Section two is the arithmetic from this article, both ends of every range. Section three is the cover plan, and a page with section three empty is not finished. Section four is the ask, and section five is the report-back promise with the before figure already filled in. The before figure exists today and writing it down is what makes the after figure mean something.

THE TIME-INVESTMENT CASE — ONE PAGE
Desk: ______________   Prepared by: ______________   Data as at: ____________
Shape:  [ ] a fix needing a protected block   [ ] training for a skill gap   [ ] a knowledge base day
Ask in one line: ____________________________________________________________

1. THE SOURCE, IN TICKETS
   Ticket type or question: ______________________________
   Tickets a month over the last six months: ____ / ____ / ____ / ____ / ____ / ____
   Median hands-on time each: ____ min      Escalated to others: ____ a month, waiting about ____ days each
   Hours a month this currently costs the desk: ____ h
   Why it has not been fixed inside an ordinary week: ______________________________

2. THE INVESTMENT AND THE RETURN
   What will be done with the hours: ______________________________
   Hours invested, once: ____ to ____ h        Recurring upkeep: ____ h a month
   Tickets removed or shortened per month: ____ to ____ of ____
   Hours returned per month: ____ (cautious) to ____ (full)
   Payback: ____ to ____ months                First-year net: ____ to ____ h
   Benefits not counted in hours (waiting removed, lessons not lost): ______________________________

3. THE COVER PLAN
   When: the week or days of ____________, chosen because ______________________________
   Who holds the queue: ______________      Mode: triage-only / normal / ______________
   What is protected: ______________________________ (the person is not in the queue)
   What will be slower, and by how much: about ____ h of work deferred, roughly ____ tickets
   Recovered by: ____________               Requesters told on: ____________ by ______________

4. NOT THE WRONG CASE
   Ordinary capacity gap is about ____ h a month, so this is / is not a headcount problem because: ______________
   The fix is within the desk's control:  yes / no (if no, the ask is instead: ______________)

5. THE ASK AND THE PROMISE
   Ask: ______________________________  decision needed by: ____________
   Before figure, today: ____ tickets a month, ____ h a month
   After figure to be reported on ____________ and again on ____________, to ______________

Sade's page went to Fiona with the week's cost in section three in a sentence that began "Dan will be alone on the queue". Fiona asked whether the desk could stand it. The page said it could, for one week, in the second week of half-term, which is the quietest the college gets. The profile rebuild took thirty-four hours of the thirty-five. The slow-profile ticket count was six the following month. Sade sent the before-and-after on the first of the month with no covering note, because none was needed. The next time she asked for a week, Fiona's reply was one line, and it was "which week".

Frequently Asked Questions