Why Password Resets Dominate the Queue: One Desk's Arithmetic

Tuesday, 08:35, the day after a public holiday, at Meridian Parts. Dev has been on the desk eight months and knows what the queue will look like before he opens it. Nine new tickets since Friday. "Locked out." "Password expired, can't get in." "Says my password is wrong but I haven't changed it." "Can someone reset me, I'm in the warehouse and the scanner won't log in." Two tickets about other things, which he reads first, out of a kind of loyalty. The phone starts at 08:41. By ten past nine he has done seven resets. Each one was a call, a question about the requester's start date, a change in the directory, a temporary password read out slowly twice, and a one-line note. The two other tickets are still open. One of them is the finance export that has been failing since Thursday.

A password reset ticket is any request whose fix is to set a user's password to a new value or to unlock an account that the directory has locked. The directory is the central list of user accounts that every system checks when someone logs in. On most Windows networks it is the domain, and the desk resets passwords by changing them there. Reset tickets are the most common single ticket type on almost every support desk I have seen. They are the one type that a well-run project can remove from the queue almost entirely. That is because the fix can be handed to the user. This article is part of our Password Reset Self-Service series. It is the arithmetic that makes the case for the rest of the series.

It covers why resets are the commonest ticket and the three places they come from, expiry, forgetting and lockout. Next comes the calendar that bunches them on Mondays, after holidays and at month start. Then come a worked example of one desk's month and the cost of a single reset in minutes, for the technician and for the user. After that come what the reset load does to every other ticket and why self-service reset is a directory feature and not a help desk one. Last come a short war story and the reset-volume worksheet to copy.

The Commonest Ticket on Almost Every Desk

Everybody in the organisation has a password, and everybody is capable of forgetting it, which is the whole reason resets dominate. Most ticket types belong to a subset of people. The finance export fails for finance, the label printer fails for the warehouse, and the video-call camera fails for whoever has that model. A password failure belongs to everyone with an account, from the managing director to the Saturday temp. It belongs to them again every time the password expires. No other ticket type has that reach. The desk at a company of two hundred and sixty people supports two hundred and sixty accounts that can each go wrong on any morning.

A reset is also the ticket the requester cannot postpone, which is why it arrives by phone and arrives now. A broken report can wait until after the meeting. A locked account is the meeting, because the person cannot open their calendar to find out where it is. The requester is standing at a screen that will not let them in, with a queue of their own work behind it. They are not going to raise a web form and wait for the response target. They are going to phone, and if the phone is engaged they are going to walk over. That urgency is real, and it is the reason resets jump every other ticket in the queue without anyone deciding they should.

The third reason is that resets cannot be batched. Ten printer tickets about the same printer are one problem with ten requesters, and a desk that notices this fixes the printer once. Ten reset tickets are ten separate people, each needing their own verification, their own change and their own handover. No amount of noticing turns them into one piece of work. A reset is small, interruptive and unimprovable by cleverness at the desk, which is the worst combination a ticket type can have. The only thing that makes it cheaper is not doing it.

Where Resets Come From: Expiry, Forgetting and Lockout

Nearly every reset ticket starts in one of three places, and it is worth telling them apart because the self-service project treats them differently. The first is expiry. Most directories enforce a maximum password age, so that a password set on a given day stops working a fixed number of days later. The user must choose a new one. Expiry is predictable, in the sense that the directory knows the date in advance. It is the source of the "password expired" ticket. The user was warned by a small notice in the corner of the screen for a fortnight and reasonably ignored it. The warning appears while the user is busy doing something else. That is its only setting.

The second source is forgetting, which is a plain human event with a pattern. People forget a password they set recently and have typed fewer than a dozen times, which is why the week after an expiry change is itself a source of resets. They forget after two weeks of leave, because a password lives in the fingers, not the head, and the fingers have been on a beach. They forget the one password they use least: the finance system they log into monthly, the building system, the one with different rules from all the others. Forgetting is not carelessness. A person with eight passwords, three of which change every few months, is being asked to do something memory is bad at.

The third source is lockout. The directory counts failed login attempts. After a set number within a set window, it refuses the account for a period or until an administrator unlocks it. Lockout is a security control against guessing, and it is a good one, but it fires on honest mistakes too. It fires most often on a mistake the user did not make. A phone, a tablet or a mail client still holding the old password will try it repeatedly in the background. The directory will lock the account every time the user unlocks it. That produces the ticket that comes back three times in a morning and the quietly furious user who has typed their new password perfectly each time. I have unlocked the same account four times before thinking to ask about the phone. The phone was in a coat pocket, doing its job.

A fourth, smaller source is the account that is nobody's. Examples are the shared login for the warehouse scanner, the generic reception account, and the service account that runs a scheduled job and expires with everything else. These are a minority of tickets and a majority of the awkward ones, because the person asking is not the owner. Self-service cannot help an account that has no single owner to enrol. Keep them in your count separately. They need a different fix, usually a named owner and an exemption from expiry with a compensating control. That is a conversation for the security owner rather than the desk.

The Calendar: Mondays, Holidays and the First of the Month

Resets do not arrive evenly, and any count that ignores the calendar will undercount the pain. The first spike is Monday morning, for two reasons that stack. Passwords that expired over the weekend produce their tickets at 08:30 on Monday, all at once, because nobody tried to log in on Saturday. And two days without typing it is enough for a recently changed password to slip, so Monday also carries the forgetting load. A desk that sees forty resets a week may see fifteen of them before ten o'clock on Monday, which is a different problem from eight a day.

The second spike is the first working day after any holiday, and it scales with the length of the break. A long weekend produces a bad Tuesday. A fortnight's shutdown produces a day in which the desk does nothing else until lunch. That is because the forgetting rate climbs with every day away and the expiry notices that appeared during the break were seen by nobody. The day after a shutdown is the one day of the year when a desk of three should probably be a desk of five, and never is. That is because it is also the day everyone else is catching up.

The third rhythm is set by the expiry policy itself, and it is subtler. If a large group of people set their passwords on the same day, their passwords will all expire on the same day every cycle thereafter. So will their tickets. The group might all have joined in the same intake. Or a policy change might have forced everyone to reset at once. Many desks have a week in each cycle that is noticeably worse and have never worked out why. The reason is usually a reset-everyone event a year or two earlier that nobody connected to the pattern. The directory remembers. The desk forgot, which is fair, since remembering dates is what the password was for.

Write the calendar down before you count, because it tells you which weeks to count. A reset count taken over a quiet fortnight in the middle of a cycle will say resets are a nuisance. The same count over a month that includes a holiday and the expiry wave will say they are the queue. Both are true, and the project needs the second number, because the second number is what the desk has to staff for.

A Worked Example: One Month at Meridian Parts

Meridian Parts is a fictional distributor with two hundred and sixty staff and a three-person desk. Its directory policy expires passwords every ninety days with a lockout after five wrong attempts. Dev counted every reset ticket for one calendar month that included a public holiday, which is the honest kind of month to count. He used the subject line and a quick read, because the desk's categories had not been set up to tell a reset from any other account problem. Tagging the tickets after the fact took him an afternoon. The point of the exercise was to get a number the desk could defend. The numbers below are his, invented for this example and shaped like the real ones I have seen.

The month held 412 reset tickets out of 1,090 tickets in total, so a little over a third of everything the desk touched was a password. Of the 412, expiry accounted for roughly 170, lockout for 110, plain forgetting for 95, and shared or service accounts for the remaining 37. The Monday after the holiday alone carried 48 resets, and the four ordinary Mondays averaged 31 each; the other weekdays averaged around 14. Those four numbers, the total, the split by source, the holiday Monday and the ordinary Monday, are the ones the project will use. They came from one afternoon with a spreadsheet. Nothing about it needed a report that did not exist. The table below sets them out the way the worksheet at the end asks for them.

Two things in the table matter more than the total. The first is that 375 of the 412 tickets, everything but the shared accounts, belong to a named person. That person could in principle reset their own password if the directory let them and they had enrolled. That is the removable share, and it is the number the self-service project is really about. The second is that the removable share is not uniform. Expiry can be cut even before self-service by giving people a better warning. Lockout needs the stale-device conversation as well as a self-unlock. Forgetting needs only the enrolment. The project plan in The Self-Service Reset Project, Step by Step takes these three apart on purpose.

The Cost of One Reset in Minutes

A single reset costs the desk about six minutes of technician time when it is done properly. The "properly" is doing a lot of work in that sentence. Pick up the call or the ticket and find the account: one minute. Verify that the person asking is the person who owns the account, by whatever the desk's standard is: two minutes, more if the standard involves a call back or a manager. Make the change in the directory: one minute. Hand the temporary password over safely and talk the user through changing it on first login: one minute, often two. Write the one-line note in the ticket saying who asked, how they were verified, and what was done: one minute. Six minutes, and no step can be skipped without either weakening the verification or losing the record. That is the argument of The Manual Reset, Done Safely, for the Rest. A reset done in two minutes is a reset done without one of those steps, and the step missing is nearly always the verification.

Six minutes multiplied by 412 is a little over forty-one hours a month. At Meridian that is more than a full working week of one technician out of a desk of three. That is the direct cost and it is the smaller one. The larger cost is the user's. It runs from the first failed login to the first successful one. It includes finding the number, phoning, waiting, being verified, typing the temporary password and choosing a new one. A reset costs the requester twenty to forty minutes of a working day. During that time they can do nothing that needs a login, which in most jobs is everything. At Meridian that is somewhere between 140 and 270 hours of staff time a month. It is spread across the whole company in slices too small for anyone to notice and too many for anyone to ignore. The desk sees the forty hours. Nobody sees the two hundred.

There is a third cost, which is the interruption. A technician who has done seven resets between 08:41 and 09:10 has not merely spent twenty-nine minutes on resets. They have spent the rest of the hour recovering the thread of the finance export they were reading at 08:40. They will be interrupted again at 09:25. Reset calls arrive at the pace of people arriving at their desks, which is to say in a steady drizzle with the occasional downpour. A drizzle is the hardest weather to work in. The arithmetic of the time technicians get back when a ticket type disappears, including the interruptions, is worked through in The Time Saved by Technicians. For the worksheet here, count the six minutes and note the drizzle. The drizzle does not fit in a cell.

What the Reset Load Does to Every Other Ticket

The reset load damages the rest of the queue in a way that no single ticket shows. The finance export that had been failing since Thursday was not urgent by any sensible priority grid. It was also the only ticket that morning that needed a technician to think. It waited until 10:30 because the desk was doing the one kind of work that needs no thought at all. On a desk where a third of the tickets are resets, the technicians spend a third of their time on the ticket that teaches them nothing, fixes nothing permanently and will come back next cycle. The queue is busy, the numbers are good, and the hard tickets age in the gaps.

Response targets make this worse rather than better. A reset arrives by phone, is answered within the minute and is resolved within ten. That makes the desk's response and resolution averages look excellent, because a third of the sample is a ticket that takes ten minutes. The remaining two thirds, the ones that take two days, are hidden inside an average they cannot move. Reset-heavy desks routinely report first-contact resolution figures that would be the envy of any other desk and backlogs that would alarm it. Both numbers are honest. A desk that wants to know how it is doing on the work that matters needs to look at its numbers with resets taken out. That is one more reason to be able to count them.

The quiet cost is to verification. A technician doing their fourteenth reset of the morning, with three people holding, will verify the fourteenth caller less carefully than the first. That is not because they are careless but because they are human and the queue is visible. An attacker who wants a password reset for someone else's account will phone on a Monday at nine. The reason that works is not that the technician is foolish. It is that the desk has been built to make the reset fast. Volume and safety pull against each other on this one ticket type, and the only way to have both is to take the volume somewhere else. That is what the directory's self-service feature is for.

Why This Is Not a Help Desk Feature

Self-service password reset is a feature of the directory, or of an identity system that sits in front of it, and never of the help desk tool. The distinction decides who runs the project. The directory is the thing that holds the password. The only system that can let a user change it without a technician is the one that holds it, or a tool that has been given the right to act on it. Both of those are owned by whoever administers the directory. The help desk tool receives the ticket, holds the record, and reports the count. It cannot reset anything, and no amount of configuring it will change that. If the people who own the directory and the people who run the desk are the same two technicians, as they are at Meridian, the distinction is academic until the day it is not.

The desk's role in the reset problem is four things, and each is a real job. First, the count, which is this article: the desk is the only place where every reset is recorded, so the desk produces the number. Second, the project, which the desk usually runs because the desk is the one that feels the pain, even though the directory owner does the configuring. Third, the manual reset for everyone who cannot or has not yet enrolled, done safely and logged. Fourth, the measurement afterwards, month by month, which is in Measuring the Drop and Keeping It Down. If you run QuerySolv, the volume reports give you the monthly total straight away. Working out which of those tickets were resets, and which source each came from, is still the desk's afternoon with a spreadsheet. It is an afternoon well spent.

Being clear about the boundary protects the project from a predictable failure, which is somebody asking the help desk vendor whether the tool "does password reset". It does not, whatever the tool, and a desk that spends a month waiting for an answer to that question has lost a month. The ticket is the symptom. The password is in the directory. The project belongs where the password is, and the desk's job is to make the case, run the plan and count the result. Nobody ever had a reset ticket fixed by a ticketing feature, and nobody ever will.

A Short War Story: The Second Technician at Tollgate Foods

Tollgate Foods was a food wholesaler with three hundred staff and a two-person desk. The desk lead, Marta, asked for a third technician on the grounds that the queue was out of control. The finance director asked, reasonably, what the queue was made of. Marta did not know; the desk had never categorised resets separately. Her best guess in the meeting was "a lot of password stuff". The hire was deferred for a quarter while someone found out. When Marta finally tagged a month of tickets by hand, 390 of the 980 were resets, 360 of them for named individuals. The directory's own self-service feature had been sitting unconfigured for three years. The self-service project ran over the following four months. The reset count fell to under seventy. The third technician was never hired, because the two who were there had got back a working week a month. Marta later said that the single most expensive thing the desk had ever done was not count. The queue had been telling her the answer for three years; nobody had asked it in numbers.

The Reset-Volume Worksheet

The worksheet below is the count Dev did, laid out so you can do it in one afternoon and defend it in one meeting. Pick a month that includes at least one public holiday and, if you know when the expiry wave falls, that too. Tag every ticket whose fix was a reset or an unlock, then split by source, using the subject line and the resolution note. Where the note does not say, mark the source as unknown rather than guessing. The cost lines use six minutes per reset for the desk and a range for the user. You should replace both with your own timings once you have watched a few. Fill in the Monday lines from the same month, because the peak is what the desk staffs for. The peak is what disappears first when self-service lands.

RESET-VOLUME WORKSHEET — ONE MONTH, ONE PAGE
Desk: ______________________   Month counted: ______________   Counted by: ____________
Month includes a public holiday:  [ ] yes  [ ] no     Expiry wave falls in this month:  [ ] yes  [ ] no  [ ] unknown

1. THE COUNT
   All tickets in the month: ______
   Reset or unlock tickets: ______        Share of all tickets: ______ %
   Directory expiry policy: passwords expire every ______ days   Lockout after ______ wrong attempts

2. BY SOURCE (from subject line and resolution note)
   Expired password:            ______
   Locked out:                  ______    of which a stale device was the cause: ______
   Forgotten (not expired):     ______
   Shared or service account:   ______
   Source unknown from the note: ______
   Removable share (everything except shared/service): ______

3. BY DAY
   Resets on the busiest Monday: ______   (holiday Monday if there was one)
   Average resets per ordinary Monday: ______
   Average resets per other weekday: ______
   Resets arriving by phone or walk-up rather than form or e-mail: ______

4. THE COST
   Desk minutes per reset (measured, not guessed): ______   default 6
   Desk hours per month on resets: resets x minutes / 60 = ______
   User minutes per reset, low / high: ______ / ______     default 20 / 40
   User hours per month, low / high: ______ / ______

5. THE LINE FOR THE MEETING
   "______ of our ______ tickets last month were password resets, ______ of them for
   named people who could reset their own. They cost the desk ______ hours and the
   company between ______ and ______ hours. The directory can do this for us."

Next step: project plan started  [ ]   Directory owner named: ____________   Date: ________

Dev's worksheet went to the IT manager with the line at the bottom filled in. The directory owner, who was also Dev, was named on the Thursday. The manager's first question was whether the help desk tool could do it. The second, after Dev explained, was how long enrolment would take. That second question is the right one, and it is the subject of the rest of this series. The worksheet does not shrink the queue. It makes the queue tell the truth about itself, in a number a finance director can read. That is where every self-service project that actually finished has started.

Frequently Asked Questions