The Ten Fixes You Repeat Every Week, and How to Find Them

Monday, 08:50, at Tollgate Foods. Marta has been on the desk eleven months and is on her third ticket of the morning. "My shared drive has gone again." She knows the fix without reading past the subject line. Open a command window on the user's machine. Remove the broken mapping and map it back to the file server. Tell the user to close and reopen their folder. Four steps, about twelve minutes including the walk to the packing office and the conversation about the weekend. She did the same four steps on Friday for someone in dispatch, and on Thursday twice. Nobody at Tollgate thinks of this as a problem. It is just Monday.

A repeat fix is a fix whose steps are the same every time, whoever reports the symptom and whoever does the fixing. It is the raw material for everything else in this series. A fix that is the same every time can be written down. A fix that is written down can be turned into a script. A script can become a button. The candidate list is the one page where you collect the repeat fixes you have found, count them, and decide which one to script first. This article is part of our Scripted Fixes & One-Click Remediations series. It is about that first page: finding the fixes, counting them, and choosing well.

It starts with why repeat fixes hide in a queue and three ways to find them in the tickets. Next come the ten fixes most desks repeat and the test for a fix that is boring enough to automate. Then it covers what stays off the list and scoring the candidates so the first script is the right one. A short war story comes next, followed by the candidate list to copy. It ends with what to do with the list once it is full.

Why Repeat Fixes Hide

Repeat fixes hide because each one is small, and because they never arrive wearing the same words twice. "My shared drive has gone" is one ticket. "Can't get to the S drive" is another. "The folder with the price lists isn't there" is a third, and it is the same fix as the first two. It was closed by a different technician, on a different day, in four minutes, with a resolution note that says "fixed". No single ticket is worth noticing. The total is a day a month, and nobody has ever seen the total.

The queue makes it worse by rewarding speed. A technician who can clear a drive mapping in four minutes clears it in four minutes and moves on. The queue has nineteen other tickets in it and the fast fix feels like winning. Writing down that it happened for the eighth time this month feels like losing four minutes. The desk gets very good at the fix and never gets round to the count. That is how a team of three can spend forty hours a quarter on a problem that none of them would describe as a problem. Repeat fixes are the only kind of work that gets more invisible the better you are at it.

The other reason they hide is that they are spread across people. On a desk of four, each person does the drive remap twice a week and thinks of it as an occasional thing. Eight a week, across the desk, is not occasional. The person who would notice the pattern is the one reading every ticket, and on most small desks nobody has that job. The finding methods below exist to give someone that job for two weeks without making it anyone's full-time job.

Three Ways to Find Them in the Tickets

The quickest method is a tally sheet, and it beats every report for the first two weeks. Put a sheet of paper, or a shared note, where every technician can reach it. Use one line per fix in plain words: "remap shared drive", "restart print spooler", "clear cached credential". Every time anyone does a fix that they have done before, they add a mark. After two weeks you have a ranked list that no report in your ticketing tool would have given you. The tool records the symptom the user described. The tally records the fix the technician did. Those are different things, and the second one is what you are automating.

The second method is to read the resolution notes for verbs. A resolution note is the line a technician writes when closing a ticket to say what fixed it. When the desk writes them properly, the repeat fixes are already sitting there under "restarted", "re-mapped", "cleared", "re-registered" and "reconnected". Search the last three months of closed tickets for each verb and read what comes back. The notes will be uneven, because people were in a hurry, but even "restarted spooler, ok" is a countable thing. If the notes are too thin to count, that is a finding in itself. The closing-tickets series in this library is where to fix that before the next count. If you run QuerySolv, every ticket keeps its complete event history. The resolution note you are searching for is still attached to the ticket months later, under whichever technician closed it.

The third method is to categorise at close rather than at open, which turns the count into a report. When the technician closes a ticket, they set the category to what the ticket turned out to be, not what the user said it was. "Shared drive missing" becomes a category of its own, and in a month you can count it. The discipline, and why open-time categories lie, is in Categorize at Close, Not Just at Open. For the purpose of this article you only need the one habit, applied to the fixes you suspect. Problem management reads the same tickets for a different reason, which is to ask why the drive keeps unmapping. Finding the Repeat Tickets covers that reading. This series asks a humbler question, which is how to make the fix take eight seconds while the problem is being looked at.

The Usual Suspects

Most desks repeat the same handful of fixes, and the list below is a starting point for the tally sheet rather than a prediction. Your desk will have two or three that are nowhere on it and will be missing two or three that are, and the only way to know is to count. The minutes column is a typical hands-on time for the manual fix, including finding the machine and talking to the user. It is a guess you should replace with your own.

Notice what the list does not contain. There is no "free up disk space", because clearing files is a different kind of fix with its own rules. It has its own article in Disk-Space Sweeps. There is no "reset the user's password", because that belongs to the identity system and to self-service, not to a script on a desk. And there is nothing that needs a decision halfway through. Every row is a fix a technician could describe in one breath to a colleague, which is the first sign that it will survive being written down.

Boring Enough to Automate

A fix is boring enough to automate when it passes five tests, and the tests are worth running on every candidate before it goes anywhere near a script. The first test is that the steps are the same every time: not similar, not "the same apart from", but the same. If Marta's drive remap is sometimes a remap and sometimes a permissions problem that looks like a remap, it is two fixes, and only one of them is a candidate.

The second test is that no judgement is needed in the middle. A fix that goes "restart the service, then look at the log and decide" has a human in the middle, and a script cannot be that human. The deciding part can be scripted later, once you know what the decision is and how often it goes each way. For now, a fix with a decision in it fails the test. The third test is that running the fix when it was not needed does no harm. Remapping a drive that is already mapped does nothing. Restarting a spooler that was working costs the user their print queue, which is a small harm. It is the sort of thing you need to know about before the script exists. Ending a process that was busy saving a file is a larger harm, and it moves that candidate down the list.

The fourth test is that the check is something a machine can read. "The drive is mapped" is a fact a script can test. "The user says it looks right now" is not. If the only way to know the fix worked is to ask the user, the fix can still be scripted. But in that case, the script cannot know whether it succeeded. That limits how far it can go in this series. The fifth test is the easiest and the most honest: nobody on the desk would be sad to lose it. The fix is dull. Nobody learns anything doing it for the ninth time. If a technician says "actually I quite like doing that one", listen, because it usually means the fix has a hidden decision in it that they enjoy making. A truly boring fix has no fans.

What Stays Off the List

Anything that touches user data stays off the list, however often you do it. Deleting files, moving mailboxes, removing accounts, emptying folders: these may be routine, and they may be repeated. They are still not candidates for a scripted fix, because the cost of being wrong is somebody's work. The rules for what a script must never do are in Guardrails: What Scripts Must Never Do. The candidate list has a column for the question so that you ask it before falling in love with the saving.

The fix you do not understand stays off the list too. Every desk has one: "if I do these four things in this order it works, and I have no idea why the third one matters." That fix is a candidate for understanding, not for scripting. A script that encodes a ritual will keep performing the ritual after the reason for it has gone, and nobody will know. Find out why the third step matters. Then, if it is still four steps, script it. The fix often turns out to be two steps once someone understands it, which is a saving before a single line is written.

The fix that is hiding a problem worth solving permanently is the hardest call. If the shared drive unmaps for forty people a month, a script that remaps it in eight seconds is a good thing to have and a bad thing to stop at. The script buys time; it does not buy the right to stop asking why. Put the fix on the candidate list, script it, and open a problem record beside it. That way, the permanent fix is being pursued while the button is doing the daily work. The button is the splint. Somebody should still be looking at the leg.

And one-offs stay off the list by definition. A fix you have done twice in a year is a runbook, not a script, and the time you would spend scripting it will never come back. The candidate list has a count column precisely so that the fix that feels frequent, because it was awful both times, does not outrank the fix that is actually frequent.

Scoring the Candidates

The score is frequency times minutes, and nothing cleverer than that. Take the count from the tally sheet or the ticket search for the last four weeks. Multiply by the hands-on minutes for the manual fix. You have minutes per month that the desk spends doing the thing by hand. Divide by sixty for hours. That number, written beside each candidate, is the entire case for scripting it, and it is a number the desk lead can read without explanation.

Tollgate's tally sheet, after two weeks, doubled for the month, looked like this. Drive remap: eleven a fortnight, so twenty-two a month, at twelve minutes each, which is two hundred and sixty-four minutes, or about four and a half hours. Print spooler restart: five a fortnight, ten a month, at eight minutes, eighty minutes. Cached credential after a password change: seven a fortnight, fourteen a month, at twelve minutes, a hundred and sixty-eight minutes. Stuck application: three a fortnight, at six minutes, thirty-six minutes a month. The drive remap is the clear first candidate. Before the count, Marta would have told you it was the credential one. The credential one involves a longer conversation and she remembers the conversations.

Two things adjust the raw score, and both are judgement, so write them down as words rather than hiding them in the arithmetic. The first is interruption. A fix that arrives as a phone call in the middle of something else costs more than its minutes. The technician has to put down what they were doing and pick it up again. A fix that arrives as a ticket that can wait until the next gap costs roughly its minutes. Note "interrupts" beside the ones that do. The second is risk, which is the answer to the third test above: what happens if the fix runs when it was not needed, or on the wrong machine. Note "harmless" or "loses print queue" or "could close unsaved work" beside each. A high score with a bad risk note is not the first script. It is the third, after you have learned how your scripts behave on two harmless ones.

There is also a quiet rule about which to script first, and it is not the top of the list. Script the second or third candidate first if the top one carries any risk. The first script you write will teach you how your desk writes scripts. That lesson is cheaper on a fix that cannot hurt anyone. The first script is a rehearsal with a payoff. The same thinking runs through the workflow automation series in this library. There it applies to the whole ladder of automation from acknowledgements to routing to remediation. A scripted fix sits on the top rung of that ladder, and the lower rungs are easier to fall off.

A Short War Story: The Wrong First Script at Northgate Retail

Ola ran a desk of two at Northgate Retail and kept the candidate list in his head, which is where lists go to be reordered by feeling. The fix he hated most was re-adding a label printer at the goods-in desk. It was a fiddly eight-minute job he did about twice a week and resented every time. So he spent a long Friday scripting it, and it worked beautifully. Meanwhile the store-manager laptops lost their drive mapping after every weekend. It was a four-minute fix that Ola and his colleague did between them about forty times a month. They never thought of it as the same ticket, because it came in under eleven different subject lines. A new starter put a tally sheet on the wall six months later. By then, the drive remap had cost the desk roughly sixteen hours a month for half a year, against the label printer's hour and a bit. The lesson Ola wrote on the sheet was short: the fix you hate is not the fix you do.

The Candidate List

The list below is one page, and it stays one page: ten lines is plenty. If you have more than ten repeat fixes the first ten will keep you busy for a quarter. Fill the count column from the tally sheet or the ticket search, not from memory. Fill the minutes column by timing the next three manual fixes and taking the middle one. Answer the three yes-or-no questions honestly before computing the score, because a "yes" in the data column removes the line regardless of how good the score looks. Keep the list where the desk can see it, and re-count it every quarter. The ten fixes change as the estate changes and as the scripts remove the old ones.

CANDIDATE LIST — REPEAT FIXES (one page, re-counted each quarter)
Desk: ______________   Counting period: ____ weeks from ________
Counted by: ______________   Source: tally sheet / resolution notes / categories

#   Symptom, in the ticket's words     The fix, in one line
1.  _________________________________  _________________________________
    Count in period: ____  Minutes by hand: ____  Hours a month: ____
    Same steps every time?  Y / N    Decision in the middle?  Y / N
    Touches user data?      Y / N    Harmless if run when not needed?  Y / N
    Interrupts the technician?  Y / N    Risk if wrong: ___________________
    Score (hours a month): ____    Rank: ____    Owner: ______________

2.  _________________________________  _________________________________
    Count in period: ____  Minutes by hand: ____  Hours a month: ____
    Same steps every time?  Y / N    Decision in the middle?  Y / N
    Touches user data?      Y / N    Harmless if run when not needed?  Y / N
    Interrupts the technician?  Y / N    Risk if wrong: ___________________
    Score (hours a month): ____    Rank: ____    Owner: ______________

(repeat the block to line 10; one line per fix, never per symptom)

RULES
  A "Y" for touches user data removes the line. Open a change instead.
  A "Y" for decision in the middle parks the line until the decision is understood.
  A "N" for same steps every time means it is two fixes; split the line.
  First script: the highest-scoring line whose risk note reads "harmless".
  Problem record opened for any line counted more than ten times: ______________

NEXT RE-COUNT DUE: ________

Marta's list at Tollgate had six lines after the first count, which is normal; the other four arrived over the following quarter as people got used to adding marks. The drive remap sat at the top with a risk note of "harmless", so it went first. The credential fix went second with the note "user must sign in again; tell them". Neither script took longer than an afternoon to write once the list had said which to write.

From the List to the First Script

Once the list has a ranked top line with a harmless risk note, the next step is to write that fix down as a procedure before anyone writes a line of script. The procedure is the thing a colleague could follow at a user's desk without you; the script is the same procedure with the human removed. Writing the procedure first catches the hidden fourth step, the one that everybody does without noticing. It is a lot cheaper to discover that step on paper than in a script that runs on fifty machines. The shape of that procedure, and the discipline of check-then-act that makes it safe to automate, is the subject of Turning a Fix Into a Script Safely.

Keep the candidate list alive after the first script ships, because the list is also how you will know the script worked. The line for the drive remap should show a count that falls towards zero for manual fixes while the script's own log shows the runs instead. If the manual count does not fall, the script is not being used. That is a different problem and a common one. The count that fell is the first entry in the ledger that the last article in this series is about. It starts here, on a sheet of paper, with a mark against "remap shared drive" at ten to nine on a Monday.

A solo administrator can do all of this in a lunch hour a week and should, because nobody else is going to count for them. The solo version of the same exercise, with a smaller list and a bigger payoff per line, is in Automate the First Ten Tickets. For a desk of two or more, the tally sheet is the fastest way to turn four people's "occasionally" into one true number. The number will be bigger than anyone expected. It always is.

Frequently Asked Questions