The Self-Service Reset Project, Step by Step

Wednesday, 14:00, at Northgate Retail, in the small meeting room with the broken blind. Ines runs the four-person desk that supports a head office and forty-one stores. She has one sheet of paper: last month's reset count, 505 tickets out of 1,340, with 460 of them for named people. Across the table is Graham, the operations director, who has given her thirty minutes. He reads the sheet and turns it over to see if there is more. Then he asks the question every sponsor asks: "Why can't people just reset their own password, the way they do for everything else?" Ines has been waiting eight months for someone senior to ask that. She has the answer, and the answer is a project with a shape, and the shape is the point of this article.

A self-service reset project takes an organisation from "every password reset is a ticket" to "most password resets never reach the desk". It switches on a feature of the directory or identity system. That feature lets a user prove who they are and set a new password without a technician. The directory is the central list of accounts that every login checks. Self-service lives there, or in an identity tool that acts on it, and never in the help desk software. The desk runs the project because the desk feels the pain, but the configuring is done where the password lives. This article is part of our Password Reset Self-Service series. It is the plan from the first meeting to the Monday when the phone does not ring.

It starts with what to have in hand before step one, then the requirements, written before any approach is chosen. Next come the three generic approaches and how to choose between them, then where enrolment sits in the plan. After that: the pilot and what it must include, the rollout in waves, and the desk's job once it is live. It ends with a short war story and the one-page project plan to copy.

Before Step One: A Count, an Owner and a Sponsor

Do not start the project until three things exist, because a project that starts without them stalls at the first decision. The first is the count: one month of reset tickets, split by expiry, lockout, forgetting and shared accounts, with the Monday peak written down. That is the worksheet in Why Password Resets Dominate the Queue. The count is what you are promising to shrink, and the number you will be measured against. A project without a before number cannot have an after number, and a project without an after number is a feature somebody switched on once.

The second is a named directory owner who has agreed to do the configuring. On a small desk this is often the same person who runs the queue. That is convenient until it is the reason nothing happens, because the queue is always louder than the project. Name them anyway, and give the project a fixed slot in their week. The third is a sponsor with authority over the people who must enrol, because enrolment is the hard part. The desk cannot order a sales director's team to spend four minutes registering a phone number. Graham is the sponsor at Northgate. His job is one e-mail and the occasional nudge, and it is the most important job in the plan.

If the security of the organisation is owned by someone other than the directory owner, name them too. Involve that person from the requirements stage rather than at the end. Self-service reset puts a second handle on the door to every account, and the person responsible for the door will have views on the handle. Bringing them in late turns a design conversation into an approval argument, and approval arguments are where projects go to spend a quarter.

Requirements: What the Reset Must Do

Write the requirements before you look at a single approach, because every approach is persuasive on its own page and only the requirements tell you what it is missing. Most of the list is obvious once written down and invisible until it is. The user must be able to reach the reset from the one place they actually are when they need it. That is the login screen of a machine that will not let them in. A reset that is only reachable from a browser is no use to someone who cannot open a browser. It must handle an unlock as well as a reset, because the lockout share of your count will otherwise stay on the desk. It must enforce the same password rules as the directory, so that a self-set password is as good as a desk-set one. It must verify the user at least as strongly as the desk does today, and ideally more strongly. That is the subject of Security Trade-offs: Convenience Against Identity. And it must log every reset, with who, when and how they were verified, somewhere the desk can read.

Then the requirements that come from your own count and your own building. If a quarter of your staff work in stores on shared machines, the reset must work from a shared machine without leaving anything behind. If staff are off-site with laptops that only talk to the directory on the office network, the reset must either work off-site or stay manual. If it stays manual, the plan must say honestly that the reset will not work off-site. The desk will still see those tickets. Some users may have no work phone and no work e-mail other than the one they are locked out of. For them, verification cannot depend on either, or they cannot enrol. Each of these is a line in the count, and each line that the chosen approach cannot reach is a line that stays on the desk.

The table below is the requirements list Ines wrote at Northgate, sorted into must, should and nice. That is a sorting worth doing out loud with the security owner in the room. A must is something whose absence means the approach is rejected. A should is something whose absence must be compensated for by the desk. A nice is something you will mention to the sponsor and then forget. The list is shorter than people expect, and the musts are shorter still.

Choosing an Approach: Three Generic Routes

There are three generic ways to give users a reset without a technician, and most organisations end up with the first, so start there. The first is the directory's own self-service. Most directories, and every cloud identity service that sits in front of one, include a self-service reset feature. It is already licensed, already connected to the password, and needs only to be switched on, configured and enrolled. Its strength is that there is nothing to buy and nothing new to patch. Its weakness is that it does only what the directory's maker decided it should. The gap is usually at the login screen or around unlocks, so check both against the musts before assuming it is enough. Ask the directory owner to find the feature. It is very often sitting there, which is a sentence with no comfort in it for the desk that has been doing four hundred resets a month.

The second is a dedicated reset tool, a separate product that is given the right to change passwords in the directory. It provides its own enrolment, verification, login-screen link and reporting. Its strength is coverage: these tools exist to fill the gaps in the directory's own feature. So they usually do the unlock, the login screen, the off-site case and the departmental report. Its weaknesses are that it costs money and it is another system to keep updated and secure. It is also a system with the right to change every password in the building, which the security owner will rightly want to inspect. Choose it when the directory's own feature fails a must and the gap is wide. Do not choose it because its demonstration was good; every demonstration is good.

The third is a staffed or kiosk route: no software at all, or very little, but a different place for the reset to happen. Reception verifies the person against a photo badge and uses a limited tool to reset. A kiosk by the entrance with a fixed account lets a locked-out user reach the self-service page they could not reach from their own machine. A store manager with a verified identity resets for the store's shared accounts. This is not self-service in the strict sense, but it takes the ticket off the desk. It solves two specific problems the other routes struggle with. One is the user with no phone and no second e-mail. The other is the shared machine that cannot run anything new. Most organisations use it as a supplement for one group rather than as the answer for everyone.

The choice is made by holding each route against the musts and the count, not by preference. Put the four lines of the count beside the three routes and ask, for each line, "does this route take that ticket off the desk?" At Northgate, the directory's own feature took the expiry and forgetting lines for head office. It failed the store machines because it could not be reached from the shared login screen, and it did not unlock. Ines chose the directory's feature for head office and a kiosk per store for the shared machines. She accepted that unlocks would stay manual for a quarter. During that time, she would find out whether the unlock share fell on its own once stale devices were cleaned up. That is a normal answer. The plan is rarely one route.

Where Enrolment Sits in the Plan

Enrolment is the step in which each user registers the proof they will later use to reset. That might be a phone number, a second e-mail address, an authenticator on a phone, or whatever the approach supports. It is the step the plan must be built around rather than the step that comes after the technical work. A self-service system that nobody has enrolled in removes nothing from the queue; it is a reset ticket with an extra page in front of it. The enrolment campaign, the new-starter step, the stragglers and the number to watch each week are the whole of Enrolment Is the Whole Project. This article leaves them there. Here, the plan needs three things from enrolment: a start date that is before the pilot, a target number for each rollout wave, and a line in the sponsor's e-mail.

Decide early whether enrolment will be voluntary, nudged, or forced, because the plan's dates depend on it. Voluntary enrolment is announced and left alone, and it reaches the people who were going to enrol anyway. Nudged enrolment is announced, reported by department, and chased by managers, which is where most organisations end up. Forced enrolment prompts the user at login until they complete it. Some approaches support this. It gets the number up fastest at the cost of a fortnight of mild resentment. Northgate chose nudged for head office and forced for new starters. The mild resentment lasted a week. The reset tickets had lasted eight years.

The Pilot: Thirty People and a Bad Monday

Pilot with the desk first, then with one department whose manager likes you, and do not call anything a pilot that has not survived a Monday. The desk goes first because technicians will find the configuration problems in an afternoon and will describe them accurately, which users will not. The friendly department goes second because the pilot's job is to find what ordinary users cannot do. That needs ordinary users, about thirty of them. They need a manager who will nudge them to enrol and will tell you plainly when the instructions made no sense. Choose a department with a mix of desk-bound and mobile staff if you can. Choose one that includes someone who has never read an instruction in their life, because you will roll out to a building full of them.

The pilot runs for at least one full expiry cycle for the pilot group, or four weeks, whichever is longer. That way, it includes at least one real expiry and at least one real forgotten password. A pilot that only tests the enrolment page tests the easy half. You want to watch a user who is actually locked out, on a Monday, find the reset, prove who they are and get in. You also want to watch at least three who cannot, so that you learn why. The things pilots find are nearly always the same. The link on the login screen is missing on one model of machine. The verification message arrives at a phone number the user entered wrongly. The password rules are explained in words no user understands. And the user who succeeded then phoned the desk anyway to ask whether it had worked.

Write the exit criteria before the pilot starts, because afterwards every criterion will look negotiable. Something like this: eighty percent of the pilot group enrolled. Every pilot user who tried a reset either succeeded or produced a ticket that explains why not. No reset was granted to the wrong person. The log shows every reset. The instructions were followed successfully by three users who had not seen them before. Those five lines decide whether the rollout starts. If the pilot fails them, fix and re-run the pilot rather than rolling out and fixing in public. A rollout that fails in public is the thing people remember when you ask them to enrol in anything again.

The Rollout: Waves, Messages and the Cut-Over

Roll out in waves by department, not all at once, and let each wave's enrolment number decide when the next begins. All-at-once rollouts put every confused user on the desk in the same week. That is the week the desk is also learning the new tool. The resulting fortnight is worse than the resets were. A wave of one or two departments at a time, each given a fortnight to enrol before the next starts, keeps questions to a trickle. The desk can answer them well. Each wave gives every department a story from the department before it. That is a better advertisement than anything the desk can write.

Each wave gets the same three messages, in the same order. First comes the sponsor's e-mail, short, saying what is changing, why it is good for the reader, and that their manager will be asking. That is the only message with authority in it, and it should be the sponsor's words, not the desk's. Next comes the desk's how-to, a knowledge base article with a picture of each step. It is written to the standard in The Anatomy of a Followable Article, and linked from the sponsor's e-mail. Then comes the reminder, a week later, to the people the enrolment report says have not done it, sent to their manager rather than to them. The how-to must be reachable by a user who is locked out. That means it must not sit behind the login they have lost. If you run QuerySolv, a knowledge base article can be published so that everyone can read it, not only signed-in agents. That choice is the whole difference for this one article.

The cut-over is the day the desk starts pointing reset callers to self-service rather than doing the reset. Time it away from any shutdown, any expiry wave you know of, and any week the sponsor is on leave. The cut-over is not a switch; it is a change in what the desk says on the phone. For the first month: "I can reset that for you now, and next time you can do it yourself from the login screen; have you enrolled?" Once the enrolment number is high: "let me walk you through the self-service page while we are on the phone". Then the manual reset becomes only for the people who genuinely cannot. The desk keeps doing resets throughout. It does fewer each week, and it does each one as a lesson. That transition, and the discipline of never refusing a reset to someone who is stuck, is the part of the rollout most plans forget to write down.

The Desk's Role Once It Is Live

The desk does not leave the reset business when self-service goes live; it changes business, from doing resets to running the system that does them. Four jobs remain, and each needs a name against it. The manual reset for everyone who cannot or has not yet enrolled, done to a fixed verification standard and logged in the ticket, which is The Manual Reset, Done Safely, for the Rest. The enrolment chase, which is a weekly look at the report and a message to the managers whose numbers are lowest. The "self-service failed" ticket is a new type the desk must recognise and treat as a bug report about the system rather than as a reset. The user tried, something went wrong, and the something is the thing to fix. And the measurement, monthly, of resets against the before number, with the residual tickets read for what they say.

Update the desk's own intake to match. The automatic acknowledgement for a reset ticket should carry the self-service link and a one-line "if you can, try this first; if you cannot, we will do it for you". A locked-out user who e-mailed from their phone may well be able to reset from the same phone. Where the ticket arrives by web form, the form can show the link before the user submits, which is the technique in Deflection at the Point of Submission. The knowledge base article becomes the most-read page the desk owns. That means it gets a named owner and a review every time the login screen changes. The desk that treats the reset project as finished on go-live day will be doing manual resets for the half of the company that never enrolled. It will have spent a project to get there.

A Short War Story: The Browser-Only Reset at Redbrook Engineering

At Redbrook Engineering, an IT manager called Callum switched on the directory's self-service reset in a week and sent one all-staff e-mail. Callum announced in the management meeting that the reset problem was solved. There had been no requirements list, no pilot, and the enrolment number was a guess. The reset page could be reached only from a browser. Redbrook's engineers worked on domain laptops whose login screen offered no link to it. So a locked-out engineer had no way to reach the page they were being told to use. The ones who tried from their phones found a page that asked for the second e-mail address none of them had registered. Enrolment stalled at about a fifth of staff, and reset tickets fell by a handful and then rose. After three months the management meeting recorded the project as a failure and moved on. The cost was the three months, a licence for a feature that was switched off again, and the credibility of the next request. When Callum proposed a proper project a year later the first question was "didn't we try that?" A requirements list with the login screen on it would have taken an afternoon. The pilot would have found the missing link in a day. The project failed before it started, in the week it felt like it was going well.

The Project Plan

The plan below is one page, seven phases, each with an owner, a date, and an exit criterion that decides whether the next phase begins. Fill in the names before the dates, because a phase with a date and no name slips. A phase with a name and no date gets done eventually, which is worse. The before number at the top is the count from the worksheet. The target at the bottom is a range, not a point. The residual depends on the shared accounts and the people who cannot enrol, and you do not yet know how many of those there are. Give the plan to the sponsor with the first phase already done, which is the count. A plan that arrives with one box ticked is a project, and a plan with none is a proposal.

SELF-SERVICE RESET PROJECT — ONE PAGE PLAN
Organisation: ______________________   Desk lead: ____________   Sponsor: ____________
Directory owner: ____________   Security owner: ____________   Plan date: ________

BEFORE NUMBER (from the reset-volume worksheet)
   Reset tickets per month: ______   Removable share: ______   Busiest Monday: ______

PHASE 1 — COUNT AND CASE            Owner: ________   Done by: ________
   [ ] One month counted and split by source      [ ] Sponsor has the one-line case
   Exit: sponsor has agreed the project and named the directory owner

PHASE 2 — REQUIREMENTS              Owner: ________   Done by: ________
   [ ] Must / should / nice list written           [ ] Security owner has reviewed it
   [ ] Groups that cannot use the main route listed: ______________________
   Exit: requirements signed by desk lead and security owner

PHASE 3 — APPROACH                  Owner: ________   Done by: ________
   [ ] Directory's own feature checked against every must
   [ ] Gaps listed; second route chosen for each gap: ______________________
   [ ] Verification method agreed with security owner: ______________________
   Exit: approach chosen; every line of the count has a route or is marked "stays manual"

PHASE 4 — BUILD AND ENROLMENT START Owner: ________   Done by: ________
   [ ] Feature configured and logging confirmed    [ ] Login-screen route tested on every machine type
   [ ] How-to article written and reachable without logging in
   [ ] Enrolment campaign started (see enrolment plan)   Enrolment mode: voluntary / nudged / forced
   Exit: desk team enrolled and each technician has reset their own password successfully

PHASE 5 — PILOT                     Owner: ________   From: ________   To: ________
   Pilot group: ______________________ (about thirty people, one manager, one full cycle or four weeks)
   [ ] Enrolment in pilot group reached ______ %     [ ] At least ______ real resets observed
   [ ] Every failed attempt explained                [ ] No reset granted to the wrong person
   [ ] Instructions followed by three people who had not seen them
   Exit: all pilot criteria met; fixes applied; re-run if not

PHASE 6 — ROLLOUT IN WAVES          Owner: ________   First wave: ________
   Wave 1: ______________   target enrolment ______ % by ________
   Wave 2: ______________   target enrolment ______ % by ________
   Wave 3: ______________   target enrolment ______ % by ________
   [ ] Sponsor e-mail per wave   [ ] Manager reminder after one week   [ ] Cut-over script agreed for the desk
   Exit: every wave above target; desk pointing callers to self-service by default

PHASE 7 — THE DESK AFTERWARDS       Owner: ________   Review monthly from: ________
   [ ] Manual-reset verification script in use      [ ] "Self-service failed" ticket type recognised
   [ ] Weekly enrolment chase owner: ________        [ ] Monthly before/after sheet owner: ________
   Target: reset tickets per month between ______ and ______ by month ______

RISKS (one line each)
   ______________________________________________   Owner: ________
   ______________________________________________   Owner: ________

Ines left Graham's meeting with phase one ticked and a sponsor, and the plan on her wall had dates by the Friday. The pilot found that the store kiosk needed a second cable. It also found that the how-to said "credentials" where it should have said "password", which the store staff told her in exactly those terms. The rollout took eleven weeks across the waves. The Monday phone still rings at Northgate, but it rings for the finance export now, which is a ticket Ines's desk can actually fix. The rest of the series is each phase of the plan at full length.

Frequently Asked Questions