Automate the First Ten Tickets

The fourth password reset of the day arrives at 14:10, by phone, from someone who is polite about it and has every right to be. You open the directory console, find the account, and set a temporary password. You tick the box that forces a change at next login. You unlock it because it locked itself on the third wrong guess, read the temporary password out slowly, and wait while they type it. Eight minutes. The mail server, which only you can fix, has been showing a queue warning since 13:50 and is waiting its turn.

Nothing about that reset needed you. It needed a process, and it got the most expensive resource in the building instead, four times by mid-afternoon. This article is part of our One-Person IT series. It is about the ten kinds of ticket that make up most of the queue on nearly every small desk, and how to make them stop needing a person.

It covers how to find your ten from a three-month census, then the ten most desks find, with the automation level that fits each. Next come the three tiers of automation (self-service, one-click and proactive) and the honest cost, a day to build each and a week to trust it. What not to automate yet, a war story about new-starter accounts and a ten-ticket worksheet finish the article.

Find Your Ten

Most of the queue is ten things. Not ten tickets: ten kinds of ticket, which between them account for sixty to eighty percent of what arrives on a small desk, every month, in nearly the same proportions. The rest is the long tail of real problems that needed a technician. The ten are not problems. They are chores wearing ticket numbers.

Find yours with a three-month census. A census is a count of every ticket by category over a fixed period, done once. The categories are tidied first so that "password", "pwd reset" and "locked out" count as one thing. If your ticket tool reports volume by category, run it for ninety days and you are done. If not, export the list and count in a spreadsheet; it takes an hour, and it is the most useful hour of the quarter.

Here is the shape of one. Tomas runs IT alone at Bluewater Bank's regional office, fifty-two staff. His ninety-day census found 388 tickets. After tidying the categories, the top ten started with password reset or unlock, 71; printer not printing, 44; access to a shared folder, 39; software install, 31. Next came mailbox full, 26; VPN not connecting, 23; "the internet is slow", 22. Last came new starter or leaver, 21; disk space on a laptop, 18; and meeting room screen, 17. That is 312 tickets, four in five of everything he logged. He had expected the top ten to be big. He had not expected them to be the job.

Then add the second number, minutes per ticket, because count alone misleads. Tomas's resets took eight minutes each, so 71 of them cost nine and a half hours in the quarter. His 21 new-starter tickets took about two hours each, forty-two hours, the biggest number on the page from one of the smallest counts. Count times minutes is the column to sort by. It is also the column nobody in the budget meeting has ever seen, because until the census it did not exist.

The census only works if the walk-ups were logged. A desk that handles resets at the door and never writes them down will census the e-mail and conclude that resets are rare. The ticket-for-everything rule from Running Support Solo is the precondition; the ten cannot be found in a queue that holds only the half of the work that arrived politely.

The Ten Most Desks Find

The list below is the ten that most small desks find. Yours will differ in the details and agree in the shape. Each row names the ticket, the automation level that fits it, and the first thing to build. The automation level is how far the ticket can be pushed away from a technician: to the user, to a script, to an article, or to a job that runs before anyone notices.

Two things stand out. The first is that the first thing to build is almost never the automation. It is the list, the form, the article or the threshold the automation needs. A solo desk never had time to make that because the tickets kept arriving. The second is that five of the ten are solved by an article a user can follow. That means half the list can be built with a text editor and no permission from anyone.

The Three Tiers of Automation

There are three tiers, and the right one depends on who has to act. Self-service is the user doing it without the desk: a reset tool, a software catalog, an article they follow. One-click is the technician doing it in one action instead of twenty: a script that creates the account, clears the queue, or grants the folder. Proactive is a job that runs before the ticket exists: a disk cleanup at a threshold, a spooler restart at six every morning. Self-service removes the ticket, one-click removes the time, and proactive removes the problem.

Self-service is the biggest win and the hardest sell, because it asks the user to do something, and the thing has to be easier than phoning you. That is the entire design rule. A reset tool that takes four screens and a second factor the user never registered is not self-service; it is a slower route to the phone.

One-click is where a solo desk should start, because it needs no permission from anyone and pays back the first week. A script is a saved sequence of commands that does by itself what you would otherwise do by hand. The first version of each of yours is the list of the clicks, written down, in order. That document is already most of the win. The script is the document with the typing taken out.

Proactive is the quiet tier, and it is the one that makes the count go down rather than the minutes. A disk cleaned at eighty-five percent never becomes a ticket. Proactive jobs need a monitoring signal and a safe action, and the action has to be one you would be happy to find had run while you were on leave. Fewer things qualify than you would like. Start with the two that do.

The article the user follows belongs to self-service even though nothing is automated, and it is the cheapest automation there is. An article is a short, numbered set of steps for one problem, written for the user and kept where they can find it without asking. A good one has the symptom in the title, under ten steps, and one closing sentence: if this did not work, open a ticket and say which step failed. That sentence turns a failed article into a ticket with data in it.

The First Five: Identity and Access

The password reset is first because it is the most frequent, the most interruptive, and the one with the best-understood fix. Do not build the reset tool first. Build the enrollment: every user registers a second factor during one campaign with a deadline and a manager's name on it. Then the tool, which sits in front of the directory and lets a registered user reset or unlock without the desk. Then the article, three steps. Tomas's seventy-one became nine in the quarter after enrollment, and the nine were people who had not enrolled.

The security point is real and short. A reset tool is a way of proving identity without a password. So the second factor has to be one you would accept over the phone from a stranger claiming to be the finance director. If you would not, do not accept it from the tool. Eight minutes a reset, by hand, was never the secure option either. It was the familiar one.

The new-starter account is the one-click tier's best case. By hand, a new starter is a directory account, a mailbox, four group memberships, a home folder and a laptop from the cupboard. Each step is done from memory in a different console. The work takes two hours spread across a day. As a form plus a script, it is a form the hiring manager fills in a week ahead. The fields are name, start date, role, manager, which of five standard roles to copy. A script reads the form and does the clicking. The approval field is the win nobody expects. The clicking never asked for approval, because there was nowhere to put it.

Shared folder access is the same shape. The request names the folder; the folder has an owner; the owner approves; the script grants the group. The first thing to build is the list of folders and owners, and the first thing the list reveals is that nine folders have no owner and two have an owner who left. Fix that first; a script that grants access to an ownerless folder has automated a decision nobody is making. The folder list is a security control dressed as a convenience.

Software install from an approved list is self-service with a catalog. A catalog is a short list of applications the organization has agreed anyone may install, packaged so that installing them takes a click and no administrator password. The cost is the list, signed off once, and the packaging. Anything not on the list is still a ticket, now rare enough to deserve a human look.

The Second Five: Devices and Dead Ends

The printer is a one-click fix that becomes proactive once you trust it. The one-click version is a saved command that restarts the print spooler and clears the stuck job. Test it on a printer nobody depends on, then on the one that generates the tickets. The proactive version runs the same restart at 06:00 every day. I have broken a printer queue with a script that was meant to fix it, on a Monday, at 08:50. Test on the quiet one. Then test again.

Mailbox full is proactive plus an article. The proactive half is a warning sent at eighty percent with the article attached. The article is three things to delete in order: sent items older than a year, the deleted items folder, and attachments over ten megabytes. The ticket count does not go to zero. It goes to the people whose mailbox is full of things they are required to keep, which is a different and much more interesting ticket.

Disk space on a laptop is the same pattern: a threshold alert, a cleanup job, and an article for the rest. The job removes what is safe to remove (temporary files, old update caches, the installers in the downloads folder). The point of the alert is that the ticket arrives from the monitoring at eighty-five percent rather than from the user at ninety-nine, on the morning of the presentation. A ticket that arrives early is a chore; the same ticket late is an emergency.

The VPN client reinstall and the meeting room screen are the article tier, and they are the two that most reward a good article. The fix is always the same and the user is always somewhere you are not. The VPN article has the two settings that matter and a screenshot of each. The meeting room article has six steps, names the cable, and lives on the wall next to the screen.

"The internet is slow" is the dead end of the ten, because it is a symptom with thirty causes, and most tickets about it will only ever be a conversation. Automate the conversation. The article asks for three checks before the ticket is opened. Check whether it is one site or every site, one machine or the whole room. Then check what the speed test says from the wired port in the meeting room. A ticket that arrives with those answers takes ten minutes; one without them takes forty. The queue cannot tell those two tickets apart. You can.

The Honest Cost

Budget a day to build each one and a week to trust it. The day is the form, the script, the article or the threshold, plus the test on the quiet printer. It also includes the runbook note that says what it does and how to turn it off. The week is the period in which you check, every morning, that the thing did what it was meant to and nothing else, before anyone is told it exists. Ten tickets is ten days and ten weeks, which across a quarter is one protected afternoon a week.

Do not build all ten. Build the top three by count times minutes, run them for a month, and recount. Tomas's top three were new starters, resets and folder access, about seventy hours in the quarter between them. After the form, the enrollment and the folder list, the next census put the same three at under twelve hours. The hours that came back went to the two projects that had waited since spring. The other seven are still on his worksheet: two done since, five in the Can wait lane with a date, which is where honest work goes when the month is full.

The cost that is hardest to see is the first version being wrong. The form will ask for the wrong fields. The script will handle the common case and not the one with the apostrophe in the surname. The article will miss the step so familiar you forgot it was a step. None of that is failure; it is the week of trust doing its job.

The article level has the lowest cost and one tool requirement: somewhere the user can search without an account, and somewhere the technician keeps the matching reply. A knowledge base the requester can search without logging in covers the user's side. A predefined reply, a saved answer the technician inserts into a ticket in one action, covers the desk's. QuerySolv has both, and by design it has neither a scripting engine nor a self-service password reset for requesters, because requesters have no passwords to reset. The scripts and the reset tool live with your directory, where they belong.

What Not to Automate Yet

Do not automate anything with a security decision in it until the decision has been written down and someone other than you has agreed to it. A security decision is any step where a person judges whether a request should be granted: who may have access to the finance folder, whether this caller is who they say they are. Automating the step does not remove the decision. It makes it once, silently, at build time, and applies it forever to cases nobody imagined.

The reset tool is the example. The script that resets a password is trivial; the decision about what proof of identity is acceptable is not. The organization has to make it, in writing, before the tool exists. The same is true of folder access (who approves), software installs (who signed the list), and leaver accounts. Leaver accounts look like the mirror image of new starters and are not. Disabling the wrong account at 17:00 on a Friday is a different kind of mistake from creating one. Build the leaver script last, and have it wait for a second person's click.

Do not automate the thing you have done fewer than ten times, either, because you do not yet know its shape; the first ten by hand are the specification. And do not automate the ticket that is really two tickets, like "new starter" on a desk where half the starters are contractors with different accounts. Split the category first, then automate the bigger half. The queue is happy to hide two problems under one label. It has no reason to tell you.

A Short War Story: New Starters at Northgate Retail

Dana ran IT alone for Northgate Retail's head office, and new starters arrived by e-mail from whichever manager remembered, usually the Friday before the Monday. Each one took her about two hours of clicking across four consoles, interrupted, and the missing pieces surfaced on the starter's first morning as walk-ups. She built a form with eight fields, one of which was the approving manager. She also built a script that read the form and created the account, the mailbox, the groups and the home folder in eleven minutes. In its first week the form refused two requests, because the manager field was blank and the script would not run without it. Both turned out to be starters nobody had agreed to yet. The clicking had never once asked.

The lesson Dana took from it was not about the eleven minutes. It was that the form was a control and the clicking had been a habit. The organization had been relying on a habit to decide who got an account. The question on the form was the point.

The Ten-Ticket Worksheet

Fill this in from your census, and put a date in the Built column only when the week of trust is over. The Owner column is who acts once it exists: the user, the technician, or the job. If your ten are not these ten, cross them out and write yours.

Sort the sheet by count times minutes once, do the top three, and come back in a month to re-sort. The sheet is also the first page of the case for a second person, because "I automated the top three and the queue still grew" is a sentence with numbers behind it. That case is built in When to Hire the Second Person. The articles themselves belong in the knowledge base described in Documentation as Your Second Person. The ten do not leave. They are a list that gets shorter and then refills, which is what a queue does.

The fourth password reset of the day still arrives at 14:10. It goes to the tool, and the tool asks for the second factor. The user is back in by 14:12 while you are in the mail server, which is where you were needed. Nobody phoned.

Frequently Asked Questions