The Tooling Case: Rework Hours, the Gap and the Trial

Wednesday, 11:05, at Stonebridge Insurance. Lena is looking at two tickets side by side. Ticket 7731 was raised by Amira in claims nine days ago, about a policy document that would not print. It was closed on day four as "no response from requester". Ticket 7802 was raised by Amira in claims five days ago, about a policy document that would not print. It begins "I replied to your last message, did you not get it?". She did reply. The reply arrived in the shared mailbox the ticketing tool reads from and failed to match the ticket. It became a new one, which sat unassigned while the old one was closed. Lena has seen this pair of tickets, with different numbers and different names, about once a week for a year. Marcus, the IT manager, has told her twice that a new tool is "not a priority this year". She has never been able to tell him, in a number, what the old one is costing.

The tooling case is the argument for replacing or upgrading the desk's ticketing tool, built from the desk's own tickets rather than from a brochure. It has to prove three things. First, the current tool costs the desk a measurable number of hours in rework every month. Second, the cost shows up in specific tickets a reviewer can open. Third, a trial of a better tool on the desk's own work removed it. It is the hardest case in this series to keep honest, because the people selling tools will offer to write it for you. The version they write is their case rather than yours. This article is part of our Using Ticket Data to Justify Resources series. It builds the case in hours with no product names and no prices in it, because the hours are what the desk can prove.

It covers what the tooling case has to prove, rework defined and tallied, and the specific gap in tickets. Next come separating the tool's faults from the process's, the trial run fairly, and the migration cost in hours. Then it covers why the case stays in hours and leaves prices to finance. It finishes with the one page, a short war story, and the tooling case one-pager to copy.

What the Tooling Case Has to Prove

The tooling case differs from the headcount case in where the lost hours go. In The Headcount Case the gap between hours needed and hours available becomes backlog, evenings and shortcuts. In the tooling case the hours are not missing; they are spent, on doing the same work twice. The desk is not short of people. It is short of the hours its people lose to hunting for a reply and re-keying a ticket. They also lose hours to merging two that should have been one, and counting the month by hand because the tool cannot. Those hours are called rework, and the whole case is a measurement of them.

The three things to prove are, in order, the rework in hours a month, the specific tickets where it happened, and the trial result. The hours are the size of the problem. The tickets are the proof it is real, because a reviewer can open ticket 7731 and see for themselves that a reply became a new ticket. The trial is the proof that the proposed fix fixes it, measured on the same tickets with the same yardstick. A case with the first and not the second is an estimate. With the first two and not the third it is a complaint with a number on it. All three, and it is a case.

The case also has to prove something harder, which is that the rework belongs to the tool and not to the way the desk uses it. A desk with no triage rhythm and no note-writing habit will lose hours in any tool. A reviewer who has met that desk will assume this is that desk. A section of this article is given over to separating the two. And the honest answer is usually that some of the rework is the process. And that part comes out of the case and gets fixed for nothing.

Rework, Defined and Tallied

Rework is any minute a technician spends because of the tool rather than because of the ticket. Reading a ticket again because the notes from last time are in a separate document. Searching the shared mailbox for a reply that did not attach to its ticket. Re-keying a request that came in by phone because the tool has no quick way to log one. Merging two tickets that are one problem, and apologising to the requester for the duplicate. Working out who owns a ticket because the tool shows a group and not a name. Counting the month's tickets by hand because the tool has no report. Each of these is a small number of minutes. Each happens many times a month. Nobody has ever added them up, which is why the tool has been "not a priority" for a year.

Add them up with a tally sheet for two ordinary weeks. Every technician keeps a sheet, on paper or in a shared document, with one line per incident. Each line records the date, the ticket, which category of rework it was, and the minutes it cost. The minutes are estimated on the spot rather than reconstructed later. Agree the categories in advance, from the list above plus whatever the desk's tool does to it specifically. Keep them to six or eight so the sheet stays quick. Two weeks is enough to see the pattern and short enough that people will actually do it. A technician asked to tally for a quarter stops after nine days and backfills, which produces a confident sheet about nothing.

At Stonebridge, three technicians over two weeks tallied just under twenty-three hours of rework between them. That scales to about fifty hours a month. Lena wrote it down as forty to sixty, because two weeks is a sample and a sample has a wobble. Hunting for detached replies was the largest category at about eighteen hours a month. Working out ownership was second. The monthly count by hand was a steady four hours, done by Lena herself on the first Monday of each month. She did it with a cup of coffee and a spreadsheet, which she had come to think of as a tradition. (It is not a tradition. It is a report the tool should have been producing.)

The Specific Gap, in Tickets

The hours are the size of the problem; the tickets are the proof. For each rework category, the case names the tickets from the last quarter where it happened, with numbers. That way, any reviewer can open three of them at random and see what the desk saw. At Stonebridge, Lena pulled the quarter's closed tickets and found thirty-eight pairs like Amira's. In those pairs, a requester's reply had become a new ticket and the original had been closed as unanswered. Lena also found six tickets that two technicians had both worked on the same morning without knowing. And twenty-one phone requests had been logged as a one-line ticket the next day, or not at all, because logging one took longer than the fix.

Each gap also has a cost to the requester. And the case says what it was, in plain words, because a reviewer who runs a department will recognise it. Amira's print problem took nine days and two tickets to reach a technician who could read both. The six doubly-worked tickets each produced two different answers to the same person. The unlogged phone calls were work the desk did and could not show, which is the volume undercount that undermines every other case the desk will ever make. The table below is the shape of this section on the one page.

Keep the list honest and short. Four or five gaps with ticket numbers behind them beat fifteen without. A gap that happened twice in a quarter is not a gap. It is a Tuesday. The reviewer will test the list by opening tickets, and every one they open should show exactly what the row says. One row that does not survive the test discounts the rest, which is the same rule that governs every table in this series and is no kinder here.

Separating the Tool From the Process

Some of the rework on the tally sheet belongs to the way the desk works and would survive a change of tool. And the case has to take it out before anyone else does. The test for each category is one question: if the desk kept the current tool and changed its habits, would this rework go away? If the answer is yes, it is process. Technicians who do not write notes in the ticket will not write them in a new ticket either. A desk with no triage rhythm will have unowned tickets in any tool, which is a failure described, with its cure, in Keeping Tickets From Hiding. A new tool installed on an old process is the old process with a nicer font.

At Stonebridge the note-keeping category was half process. The tool had no internal note, which was the tool's fault. But two of the three technicians had also stopped writing notes anywhere, which was not. Lena split it, kept the half the tool caused in the case, and fixed the other half with a one-page note standard before the case was presented. The split cost her about five hours of claimed rework. It gained her a case in which every remaining row was the tool's. A reviewer who tried to say "isn't this just how you work?" found that the desk had already asked itself that. The desk could show the answer.

The process fixes also give the case a before-and-after of their own, which is worth a sentence on the page: "we changed our note habit in March and the re-reading rework fell by about five hours a month; the remaining rework in this table is what the habit could not reach". A desk that has visibly fixed what it could fix for free is believed when it says the rest needs a tool. A desk that has not is told to try harder, and should be.

The Trial, Run Fairly

The trial is where the case stops being a complaint and becomes a prediction that has already come true once. The method belongs to Designing a Fair Trial and its series. The series starts from requirements rather than demonstrations and runs candidate tools on the desk's real work. The tooling case borrows that method and adds one thing. The rework tally runs during the trial too, with the same categories and the same sheet. Take twenty or thirty real tickets from the last quarter, including at least five from the gap table. Work them through the trial tool as they would have been worked. The reply arrives: is it attached? The phone call comes in: how long to log it? Two technicians open the same ticket: what do they see?

Measure the rework per ticket in the trial against the rework per ticket in the tally, and report both in the same units. At Stonebridge the tally had shown about nine minutes of rework per ticket in the current tool. Nearly all of it was in the four categories the tool caused. Across the trial set the same categories cost about two minutes per ticket, most of it learning the new screens. Scaled to the desk's volume that is a saving in the region of thirty-five to fifty hours a month. That matched the tally's range, as it should, because it was measuring the same thing from the other end. The trial also showed what did not change. The process half of the note problem was exactly as bad in the new tool, which was the point of having separated it.

A word about who is writing this. The publisher of this library sells a self-hosted help desk, QuerySolv, which comes with a free trial, as most help desk tools do. The only honest advice from that position is to run the trial on your own tickets, with your own tally sheet, whichever tools you shortlist. That advice also means believing the sheet rather than any page a vendor wrote, this one included. A trial you ran on your own work is evidence. A case study from someone else's desk is an anecdote with a logo.

The Migration Cost, in Hours

The hours the new tool saves are only half the sum; the other half is the hours it costs to get there. And a case that omits them will be asked for them by the first reviewer who has ever changed a system. The one-off cost includes setting the tool up, deciding what history to bring across and bringing it. It also includes retraining the technicians and the requesters, and the fortnight of running both tools while the old one drains. Why migration cost belongs in the decision, and how to estimate it without a project plan, is in Migration Cost Is Part of the Decision. The tooling case takes the estimate from there and states it as a range of hours.

At Stonebridge the estimate was sixty to ninety hours one-off. That included about twenty for setup and the department mailboxes. Another twenty were for deciding to bring across only open tickets and the last quarter's closed ones and doing so. Another ten were for retraining three technicians and writing the one-page guide for requesters. The rest were for the dual-running fortnight, when every ticket is checked in two places. Against a recurring saving of forty to sixty hours a month, the one-off cost pays back in about two months on the cautious end and inside one on the optimistic end. That sentence, with its range, is the one that belongs on the page. Then comes the recurring administration of the new tool, which is never zero. At Stonebridge it was about three hours a month for the person who looks after it, against the four hours of hand-counting it replaces.

Be honest about the dip. For the first month after a change the desk is slower, not faster, because everyone is learning. A case that promises the saving from day one will be contradicted by its own first report. Put the dip on the page as the desk's estimate. And the first report back, described in After the Decision, will show the dip and then the recovery, which is exactly what the page predicted. Predictions that come true are the whole of a desk's credibility, and the easiest way to have them come true is to predict the dip.

Hours, Not Prices

The desk's page contains no price, and this is a discipline rather than an omission. The licence cost and the hosting cost are finance's expertise. So is the question of whether a once-per-installation licence or a per-agent subscription suits the organisation. Finance will attach them to the hours in minutes. The desk's expertise is how long the work takes and where the hours go. The moment a price appears in the desk's document the argument moves onto ground where the desk is the amateur. Give finance a sum they can finish, with a blank column labelled "cost" if it helps, and let them finish it.

The hosting model does deserve one line in hours, because it moves hours between budgets. A self-hosted tool costs the organisation the hours to run a server and apply updates. A cloud tool moves those hours to the vendor and costs the hours of whatever the organisation does about its data living elsewhere. Both are legitimate choices with different hour profiles. The tooling case states the hours of each option it shortlisted, without a recommendation on the money, and lets the people who own the money decide.

If a reviewer insists on a single cost figure in the desk's own document, provide the hours. Ask them to supply the rate, in writing, so that the arithmetic is theirs and the inputs are yours. It is a small thing. It is also the difference between a case that is argued about and a case that is checked.

The One Page

The page has six parts. First come the rework in hours a month as a range and the gap table with ticket numbers. Next come the process rework the desk has already fixed and what it saved, and the trial result in the same units. Finally come the migration cost and the payback in months, and the ask with a date and the promise to report back. The tally sheets, the trial notes and the full ticket list sit behind it as the appendix. The format for a page a senior reader will finish belongs to the Reporting to Leadership series. The tooling case follows it rather than inventing one. The conclusion comes first, the date the data was taken is on the page, and no chart needs explaining.

Write the decision down when it comes, whichever way it goes: what was asked, what was decided, by whom, and on what numbers. A tooling decision is revisited more often than a headcount one, because tools are easier to change than people. The desk that can show what the last decision rested on is the desk that is not asked to rebuild the case from nothing in a year's time.

A Short War Story: The Brochure at Harbourview Clinic

At Harbourview Clinic, a desk lead called Joel made the case for a new ticketing tool on the strength of the vendor's brochure. It promised a large saving of agent time. Joel also relied on a demonstration in which the vendor's own tickets flowed beautifully. The practice manager approved the case. The migration took about eighty hours over a difficult month. Six months later the desk's rework was, by Joel's own later tally, almost unchanged. The reply-matching problem the brochure had promised to fix had never been the clinic's largest cost. The largest cost was that nobody wrote notes in the ticket. And the new tool had a splendid internal note field that nobody wrote in either. Joel asked for a second technician the following year, with a careful capacity sum. The practice manager said, not unkindly, "the last thing you asked for was going to save all this time". The case was deferred. The tool had not failed. The case had been the vendor's, and a vendor's case is about the vendor's tickets.

The Tooling Case One-Pager

The template below is the page, with the tally sheets and the trial notes as its appendix. Sections one and two come from the two-week tally and the quarter's ticket list. Section three is the process rework the desk fixed before asking. That section is on the page because a reviewer should see that the desk did its own work first. Section four is the trial in the same units. Section five is the migration arithmetic, and section six is the ask. Nothing on the page has a currency sign, and the "cost" column in section five is left blank on purpose for finance to complete.

THE TOOLING CASE — ONE PAGE
Desk: ______________   Prepared by: ______________   Data as at: ____________
Ask in one line: ____________________________________________________________

1. REWORK IN THE CURRENT TOOL
   Tally period: two ordinary weeks, ________ to ________, ____ technicians
   Rework tallied ____ h, scaled to ____ to ____ h a month
   Rework per ticket in the current tool: about ____ min

2. THE SPECIFIC GAPS (last quarter)
   Gap                                   Tickets   Hours a month   Cost to the requester
   ______________________________        ______    ______          ______________________
   ______________________________        ______    ______          ______________________
   ______________________________        ______    ______          ______________________
   ______________________________        ______    ______          ______________________
   Ticket numbers behind each row are in the appendix.

3. PROCESS REWORK ALREADY FIXED (not in the case)
   What we changed: ______________________   on: ________   saving about ____ h a month
   Rework that remains after the fix, and why the tool causes it: ______________________

4. THE TRIAL
   Method: ____ real tickets from last quarter, including ____ from the gap table,
   worked through the trial tool with the same tally categories.
   Rework per ticket in the trial tool: about ____ min  (current tool: about ____ min)
   Saving at the desk's volume: ____ to ____ h a month
   What the trial did not change: ______________________

5. MIGRATION AND PAYBACK (hours)                              Cost (finance to complete)
   Setup and mailboxes ................ ____ h                 ________
   History brought across ............. ____ h                 ________
   Retraining and guides .............. ____ h                 ________
   Dual running ....................... ____ h                 ________
   One-off total ...................... ____ to ____ h
   Recurring administration ........... ____ h a month (current tool: ____ h a month)
   Expected dip: first month about ____ h slower
   Payback: one-off total divided by monthly saving = ____ to ____ months

6. THE ASK AND THE PROMISE
   Ask: ______________________________  decision needed by: ____________
   Reported back: rework per ticket and hours a month at three months and six months, to ______________

Appendix: tally sheets, ticket list by gap, trial notes

Lena's page went to Marcus with thirty-eight pairs of ticket numbers in the appendix. He opened four of them before he had finished the first section. He asked what the desk had done about the notes, and the answer was on the page. The decision went through finance with the cost column filled in by someone who knew the budget, which Lena did not and had never pretended to. The first Monday of the month after the change, she made the coffee and then remembered there was nothing to count.

Frequently Asked Questions