Why Password Tickets Dominate the Help Desk Queue

Monday, 08:40, at Ashgrove Housing. Nadia has been running the desk for three weeks and has two technicians, Callum and Rosa, who have been there considerably longer. Fourteen tickets have arrived since eight o'clock. Nadia reads the subject lines while her coffee goes cold: "Locked out". "Can't log in". "Password not working on laptop". "My phone keeps asking me to sign in". "Locked out AGAIN". "Forgot password after holiday". "Finance system won't take my password". "New starter can't log in". Eleven of the fourteen are the same ticket wearing different clothes. The other three include a printer and a broken chair that somebody has decided is an IT matter. The last is the one she actually needs to read, from the finance manager, about the month-end run that will not start. Callum is on the phone doing a reset. Rosa is on the phone doing a reset. The finance manager's ticket is twenty minutes old and nobody has opened it.

A password ticket is any ticket whose cause is a credential. The person does not know their password, a system will not accept it, or the account has been locked because something tried it wrong too many times. The password ticket is the commonest ticket on almost every desk I have seen. And it is common for reasons that have nothing to do with the people raising it. This article is part of our Password & Lockout Tickets series. And it is the one that explains the shape of the problem before the rest of the series takes it apart.

It covers the four costumes the password ticket wears. Then come the expiry policy and the wave it sends, and why one person has several passwords and does not know it. Next are the old password cached on a phone or in a saved session, and the Monday, holiday and first-day-back peaks. What the load does to every other ticket and how to count the tickets honestly follow. Then come a worked month at Ashgrove Housing, a short war story, and the census sheet to copy, in that order.

The Four Costumes of the Password Ticket

The password ticket arrives in four forms. The desk needs to tell them apart before it does anything. The fix for each is different and the wrong fix makes the next ticket. The first is forgotten: the person does not know the password and needs a new one. The second is expired: the person knew it, but the policy has retired it on schedule. And the system is asking for a new one at a moment they did not choose. The third is locked: the person may know the password perfectly well. But the account has been locked because too many wrong attempts arrived, from a person or from a device. The fourth is changed and broken. The person changed their password, correctly, and something else that had the old one saved has now stopped working or started locking the account.

The subject line almost never says which costume it is. "Can't log in" covers all four. "Locked out" is usually the third but is often the second, because an expired password and a locked account look identical from the sign-in screen. The table below is the sorting step: what the person says, what is usually true, and the first question that tells the four apart. A desk that sorts first does one reset. A desk that resets first sometimes does three, because it reset a password that was never the problem and created the changed-and-broken ticket for tomorrow.

Expiry Policy: The Ticket the Calendar Sends

An expiry policy is a rule in the directory that retires every password after a set number of days and makes the person choose a new one. The directory is the central list of accounts that the computers, the mail service and most of the other systems check when someone signs in. Expiry exists so that a password which has leaked quietly stops working eventually. Whether that is still the right trade is a decision for the organisation's security function, its auditors and its insurers, not for the desk. The desk's job is to know the policy, know when its waves land, and bring the ticket count to the people who own the rule.

Expiry sends tickets in waves, and the waves are predictable. A large group of accounts may have been created or reset in the same week: a laptop rollout, a merger, a forced change after an incident. In that case, their passwords expire in the same week every cycle. The desk then gets a wave of expired tickets on a schedule nobody wrote down. The wave is worse than the number suggests. A person who changes their password at the prompt then walks into the changed-and-broken costume. The phone, the tablet and the saved session still hold the old one. One expiry wave therefore produces an expired ticket today and a lockout ticket tomorrow. The policy was set, in most organisations I have seen, by someone who has since left, for reasons recorded nowhere. It is still sending tickets.

The honest thing to say about expiry is that it is where a great many password tickets come from and that the desk cannot change it alone. The desk can count the expired tickets separately from the forgotten ones and note when the wave lands. It can take that count to the conversation that The Layered Plan That Makes Password Tickets Rare describes. A number beats an opinion in that meeting, and the desk is the only place the number exists.

Several Credentials Per Person

Most people have more passwords for work than they know. And the desk sees the gap between how many they think they have and how many they have. There is the directory password, which opens the computer and the mail. There is the finance system, which was installed before the directory existed and has its own list of users. There is the HR portal, hosted elsewhere, with its own rules about length and its own expiry. There is the VPN, which may or may not use the directory, and the authenticator app that goes with it. There is the badge system, the warehouse scanner, the clinical system, the old line-of-business application that three people use and one person understands. Each has its own password, its own expiry and its own idea of what a good password looks like.

The person experiences all of this as "my password", singular. When the finance system rejects them, they conclude their password is broken and ask the desk to reset it. They mean the directory password, which was fine. The desk resets the directory password, which does not help the finance system and does break the phone. Now there are two tickets. This is credential sprawl, the slow accumulation of separate logins across systems that were bought at different times by different people. It is a cause of password tickets that no amount of user training fixes. The person cannot be expected to carry a map of the organisation's purchasing history. A typical member of staff at Ashgrove has a directory password, a finance password, and a password for the thing nobody remembers installing.

The desk's defence is a list. Every system with its own credential, who resets it, and whether its expiry is on a different clock. The list belongs in the knowledge base where technicians can see it, and the first question for any "password not working" ticket is "which system?". Over time the list is also the evidence for single sign-on, the layer that collapses several credentials into one. The census at the end of this article is where the list gets its first entries.

The Old Password Cached Somewhere Else

A password does not live only in the person's head. The phone's mail app has it saved. The laptop at home has it saved. The browser remembered it. The mapped drive to the shared folder reconnects with it every morning. A tablet in a drawer, used once for a conference, checks for mail with it every hour. When the person changes the password, correctly, at the prompt, none of these are told. They keep offering the old password, politely and repeatedly, and every offer counts as a wrong attempt against the account. After a handful of attempts the account locks. The desk unlocks it. The phone tries again. Twenty minutes later the ticket says "locked out AGAIN", in capitals, and the person is certain the desk did something wrong.

This one mechanism, the cached credential, is responsible for a large share of lockout tickets on every desk I have run. It is invisible to the person because they did not do anything. They changed their password because the computer told them to. The phone in their pocket is doing the rest. It is also the reason that a reset done carelessly makes the next ticket. A reset without a warning about the phone is a lockout scheduled for the following morning. The whole subject of finding the device, the six places it hides and the order to check them, belongs to The Lockout That Keeps Coming Back. For the census, what matters is that a lockout caused by a device is a different ticket from a lockout caused by a person mistyping. The two are counted apart. One points at the reminder that goes out with every password change. The other points at nothing much, since people mistype.

Mondays, Holidays and the First Day Back

The password ticket keeps a calendar, and the desk should know it. Monday morning is the first peak. There have been two days without typing the password. A phone has synced all weekend with whatever it had. The whole organisation signs in within the same forty minutes. Where an ordinary weekday brings a steady trickle, Monday brings a wave between eight and ten, and the wave is almost entirely passwords. The first working day after a public holiday is the same wave, taller. The first week of January, or whatever the long break is where you are, is the tallest of the year. Two weeks is long enough to forget a password that was changed the week before the break. And the expiry wave that was due during the break lands on everyone at once.

There are smaller peaks the calendar also sends. New starters produce a cluster in their first week. The welcome e-mail with the first password may have been lost. Or the account was created with a typo in the name, or the finance system was never told they exist. The day after any forced change, whether from an incident or a policy update, is a wave of changed-and-broken. The first of the month is a wave on desks whose finance or HR system expires passwords monthly. And the week the laptops come back from the summer, on any desk with a seasonal workforce, is a wave of forgotten. The queue knows what day it is better than most of the people in it.

Knowing the calendar does two things for the desk. It lets you roster for the peak. That way, the finance manager's ticket is read on a Monday morning by someone who is not on the phone. Knowing the calendar also lets you measure the peak as a ratio: the average Monday against the average other weekday. That is one of the cleanest measures of how much of the problem is the cached credential and the weekend. The measuring article in this series explains this.

What the Load Does to Everything Else

The cost of a password ticket is not the ticket. A reset done properly takes a few minutes, and even a desk doing dozens a day can afford the minutes. The cost is where the minutes fall. Password tickets arrive by phone and by walk-up more than any other kind, because the person cannot sign in to use the form. A phone call interrupts whatever the technician was doing. The finance manager's ticket about the month-end run is not delayed by the time the resets took. It is delayed because nobody could hold a thought for long enough to read it. Twenty resets spread across a morning do not cost twenty times six minutes. They cost the morning.

There is a second cost, to the people who raise the tickets, in the time between the lockout and the call back. There is a third cost, to the desk's reputation. A desk that is always on the phone doing resets is seen as a desk that does resets. The arithmetic of minutes per reset is already worked through in Why Password Resets Dominate the Queue in the self-service series. That article also works through what a month of resets costs the desk and the organisation in hours. This article leans on it rather than repeating it. The point here is narrower: the load is large and it lands at the worst times. Nobody will act on it until it has been counted.

Counting Them Honestly

Most desks have no idea how many password tickets they get, and the reason is that the tickets hide in three ways. They are logged under a general category because the technician was on the phone and picked the first option. They are not logged at all, because a reset done at the counter in ninety seconds did not seem worth a ticket. That is the unlogged walk-up doing to this count what it does to every other. And they are labelled by symptom, "can't log in", "laptop problem", so that a search for the word password finds a third of them. A desk that reports password tickets as one in twelve has usually measured how often technicians typed the word. In that case, it has not measured how often the cause was a credential.

The honest count is a census: one month, every ticket, read and sorted by cause rather than by category or subject line. The cause is in the resolution note, if the desk writes them, and in the technician's memory if it does not. That is why the first census is slow and every one after it is fast. The causes are the four costumes, split where the split points at a different fix. They include expired on schedule, forgotten, locked by a device, locked by typing, and changed and broken. They also include a second system with its own password, a new starter who never received one, and cause not recorded. The last bucket is not a failure of the census. It is a measurement of the desk's notes, and it shrinks on its own once technicians know the census is coming.

The count is reported as two numbers, the password tickets and all tickets, in that order: "196 of 540". Never report it as a percentage on its own. The rules for what counts as a ticket at all are one per contact, merged duplicates counted once, and walk-ups logged. Those are the rules in Counting Tickets Properly. If you run QuerySolv, the requests from the web form, e-mail, chat and the phone all land in one queue as ordinary tickets. So the census is a filter over one month rather than a hunt through separate mailboxes. In any tool, the hard part is the same: reading the cause rather than the label. Do the first census by hand. It is the only way to find out what the labels have been hiding.

A Worked Example: One Month at Ashgrove Housing

Nadia ran the census for the month after that Monday. The numbers below are hers, from a fictional desk. They are given so the shape is clear rather than as anything to compare your own desk against. Ashgrove Housing has about four hundred staff, many of them housing officers who work from a laptop and a phone and sign in from tenants' homes. The desk logged 540 tickets in the month, once Callum and Rosa had started logging the counter resets, which they had not been doing. Of the 540, 196 had a credential as their cause: a little over a third. That was the largest single kind of ticket on the desk by a distance. The second largest, printers, was under forty.

By cause, the 196 broke down as follows. There were 61 expired on schedule, most in one week that turned out to be the anniversary of the laptop rollout. Another 48 were forgotten, not expired. There were 39 locked where a device still held the old password, 31 of them phones. Another 12 were locked by mistyping, with no device involved. There were 22 where a second system, almost always the housing management application, had its own password on its own clock. There were 9 new starters who never received a first password or received one with a typo in the account. Finally, there were 5 whose cause the ticket did not record. The Mondays averaged fourteen password tickets against seven on the other weekdays. The Tuesday after the bank holiday brought thirty-one, which is the day Nadia had been reading subject lines with cold coffee.

Each number points somewhere. The 61 expired point at the policy and its wave, which is a conversation with the security lead and the auditor. The 39 device lockouts point at a reminder that goes out with every change, which is a template and a day's work. The 22 second-system tickets point at one application and a list. The 48 forgotten point at self-service reset, the largest project of the lot. The 12 mistyped point at nothing, and the 5 unrecorded point at the resolution note. Nadia did not fix any of it that month. She had a number, by cause, with a date on it. And the next five articles in this series are what she did with it.

A Short War Story: The Overstaffed Desk at Coppermill Brewing

Coppermill Brewing is a regional brewer with three sites and a desk of three. The finance director proposed not replacing a technician who was leaving. The grounds were that the monthly ticket report showed only one ticket in twelve under "password". The desk therefore spent most of its time on "real work" that two people could absorb, according to that argument. The desk lead, Ines, could not argue with the report, because it was her report. So she ran a census of the previous month by hand. She found that the technicians had been logging phone resets under "general" and logging counter resets not at all. She also found that 312 of a corrected 760 tickets had been credentials. The leaver was replaced, four months late, after a quarter in which the remaining two technicians worked roughly eighty hours of overtime. During that quarter, the finance system's upgrade was postponed because nobody had a free afternoon to test it. The report had been accurate about the labels and wrong about the work. A ticket nobody counts is a ticket nobody can remove, and it will be counted against you instead.

The Password-Ticket Census

The sheet below is the one Nadia filled in, for one month, by hand the first time and from a filter after that. Section one is the whole and the share, reported as two numbers. Section two is the sort by cause, done from the resolution note rather than the subject line, one cause per ticket. It keeps "not recorded" as an honest bucket rather than guessing it away. Sections three and four give the calendar and the channel, which are where the roster and the self-service case come from. Section five turns the two largest causes into the first two lines of the layer plan. Section six is the sentence for the monthly report. Fill it in once, date it, and keep it; the measuring article in this series turns it into a monthly line.

PASSWORD-TICKET CENSUS — ONE MONTH, BY CAUSE
Desk: ______________________   Month: ______________   Counted by: ______________
Public holiday in the month:  [ ] yes  [ ] no
Expiry wave or forced change in the month:  [ ] yes  [ ] no  [ ] unknown

1. THE WHOLE
   All tickets logged this month, every channel, walk-ups included: ______
   Tickets whose cause was a credential: ______
   Reported as: "______ of ______ tickets"

2. BY CAUSE  (read the resolution note, not the subject; one cause per ticket)
   Expired on schedule ................................. ______
   Forgotten, not expired .............................. ______
   Locked: a device still held the old password ........ ______
   Locked: mistyped, no device involved ................ ______
   Changed it, and something else stopped working ...... ______
   A second system with its own password ............... ______
      which systems: ______________________________
   New starter never received one, or account wrong .... ______
   Cause not recorded in the ticket .................... ______

3. BY DAY
   Average on an ordinary Monday: ______   Average on another weekday: ______
   Busiest single day: ______ on ______   Reason, if known: ______________

4. BY CHANNEL
   Phone: ______   Walk-up: ______   E-mail: ______   Form or portal: ______   Chat: ______

5. WHAT THE TWO LARGEST CAUSES POINT AT
   Largest cause: ______________   Points at: ______________   Owner: ____________
   Second cause: ______________   Points at: ______________   Owner: ____________

6. THE LINE FOR THE MONTHLY REPORT
   "______ of our ______ tickets this month had a password or lockout as the cause;
    the largest single cause was ______________."

Nadia took her line to the operations director with the census attached. "196 of our 540 tickets last month had a password or lockout as the cause; the largest single cause was the expiry wave from the laptop rollout." He asked whether the desk was doing something wrong. She said the desk was doing resets, correctly, at the rate the policy and the phones were generating them. She also said that the way to have fewer was not to do them faster. He asked what the way was. That is the rest of this series.

Frequently Asked Questions