Question handling
What to say when somebody cannot get a password reset to work
Almost nobody asks how to reset a password before trying. By the time the question reaches a chat widget the person has already clicked the link, waited for an email that never arrived, or found that the address on the account is one they lost access to two jobs ago. The useful answer addresses the failure, not the happy path.
What they are really asking
They want to be signed in within the next two minutes, and they are asking because one specific step in your reset flow has already failed them once.
- i forgot my password
- how do i reset my password
- i didn't get the reset email
- the reset link says it has expired
- reset link not working
- i can't remember which email i used
- i signed up with google can i set a password
- how long is the password reset link valid
- i reset it but it still won't let me in
- how do i change my password without logging out
The material that answers it
An assistant is only as good as the document behind it, and for this question the document usually exists but is written in the wrong shape. What each one has to contain to be answerable:
| Your reset flow written screen by screen | Not a link to the reset page, but the sequence: which page, which field, what arrives, what the email looks like, what to click, what happens next. The person asking has usually already found the page and got stuck one screen past it, so a link is the answer that helps least. |
|---|---|
| The sender address and subject line of the reset email | The single most valuable line in this whole set, and almost nobody publishes it. If the assistant can say which address the email comes from and roughly what the subject says, the visitor can search their spam folder for it instead of requesting five more. |
| Link expiry and single use rules | How long a link lives, whether requesting a second one invalidates the first, and what the expiry message actually says. The most common cause of a link that will not work is a newer link having killed it, and that is invisible unless you write it down. |
| Which sign in methods your product supports | Whether an account created through a linked sign in provider has a password at all, and whether one can be added later. People who signed up with a provider button do not remember doing so, and they are asking to reset a password that has never existed. |
| What happens when the address on the account is unreachable | The recovery route, what proof you ask for, and how long it takes. This is where the reset conversation actually ends for a meaningful share of the people who start it, and it needs a written process rather than an improvised one. |
How to handle it
Answer with the flow, not with the link
The assistant should be able to say what happens at each step and what the person should see, because that lets them tell you which step went wrong. A reply that says visit the forgot password page tells somebody who is already on the forgot password page nothing at all.
This is the argument for indexing a written walkthrough rather than relying on the reset page itself being crawled. The page contains a form. It does not contain a description of what the form does next.
Name the three places it usually fails, before being asked
The email landing in spam or in a filtered folder, the link having expired or been superseded by a second request, and the account being tied to a sign in provider rather than a password. A good answer covers all three in a couple of lines and lets the visitor recognise their own case.
This is unusual for support content: pre-empting the failure is more useful than describing the success, because the success needed no help.
Never accept a password or a code in the conversation
The assistant must not ask for a current password, a new password, a reset code or a one time code, and the indexed material must not contain any instruction that reads as asking for one. If a page says send us your details and we will sort it out, the assistant will repeat it, and a support channel that teaches customers to paste credentials into a chat box has created a habit somebody will exploit later.
It is worth writing the negative into the material explicitly: state that the team will never ask for a password or a code. That way the assistant can say it, and the sentence does useful work every time it appears.
Stop the moment it becomes an identity problem
Everything above is a technical explanation of a public process, and an assistant is good at it. The moment the answer depends on proving that this person owns that account, the conversation has changed category and no amount of good material will help.
The handover should say so plainly: this needs somebody who can verify the account, here is what they will ask for, and here is where to send it. Naming the proof in advance saves an entire round trip.
When it stops being an answer
The address on the account is gone
An old work address, a closed provider, a domain that lapsed. There is no self service answer to this anywhere, and an assistant that keeps suggesting the reset flow is making the person angrier with every reply.
Recognise it early and route it. The assistant should collect the account identifier, the address they can be reached at now, and the address they think the account uses, because those three facts are what the person handling it will ask for first.
The reset works and sign in still fails
That usually means the problem is not the password: an account lock after repeated attempts, a second factor, a lapsed subscription, or an organisation policy. None of these can be seen from published material, and guessing between them wastes the visitor's time and yours.
Anything that reads like somebody else's account
Requests to reset the password on an address the person cannot receive mail at, requests on behalf of somebody unavailable, urgency attached to a request for access. Even when the explanation is entirely innocent, and it usually is, this is not a decision to leave to a support widget.
How this one goes wrong
The confident walkthrough of a flow you no longer have
Reset flows get rebuilt more often than the documentation describing them, and old help articles rarely get deleted. An assistant reading both will happily describe a screen that was removed a year ago, and the visitor will conclude they are on the wrong site rather than that your content is stale.
The cost is not one bad answer. It is a person who cannot get into an account, has been given directions that do not match what is in front of them, and now has to reach a human anyway, having spent five minutes finding out. Delete the superseded articles rather than leaving the assistant to choose between them, and set the caution level so a weak match returns your fallback instead of the closest old page.
The same question, trade by trade
The pattern above holds everywhere. The wording, the escalation line and the material behind it do not, so there is a page per trade.
- For a medical practiceA patient online account opens a medical record, so access is reissued after an identity check at the desk rather than by email.
- For a pharmacyMost pharmacy password resets fail on an old email address or a check made once at the counter, not on the reset link itself.
- For a insurance brokerA portal used annually collects stale addresses, so the reset link arrives somewhere the customer can no longer read.
- For a recruitment agencyA candidate area, a timesheet system and a client approval login all look alike from outside. Getting the reset pointed at the right one.
- For a online storeThe mail is usually delivered and filtered. Where it lands, how long the link lasts, and why the shop is told nothing either way.
- For a universitySelf service reset works only where recovery details were set at enrolment. Everyone else needs an identity check no widget can perform.
- For a online courseTwo addresses, one purchase. Why resetting the password rarely helps when a course was bought at one email and is read at another.
- For a SaaS companyIf sign in is federated there is no password to reset. What the assistant can explain, and why it can never send a link itself.
- For a developer tools companyRotating a credential without dropping traffic, and the first move when a token turns up in a public commit. Neither is a password reset.
- For a fintech appReset questions look trivial until you notice the asker is unverified. What chat explains, and every step it must never perform.
- For a healthtech appRecovery codes, a second step and the phone the app trusts. Why nobody in a chat window can reissue a way in, and what can be explained.
Questions
- Can the assistant send a reset email itself?
- No. It does not write into any system, so it cannot trigger a reset, unlock an account or change an address. It answers from your material and, when somebody asks for a person, collects a name, an email and a message and sends that to the address you nominate.
- What is the single highest value thing to publish here?
- The sender address of your reset email. It costs one sentence, it turns a wait into a search of the spam folder, and it removes the most common reason people request the same email four times.
- Is it safe to let a chat assistant discuss account security at all?
- It is, provided the indexed material never asks for credentials and the assistant answers only from that material. Retrieved pages are treated as data rather than as instructions, so a page containing something that looks like a command is ignored rather than followed.
- How should the refusal be worded for this?
- Name the constraint rather than apologising. Something along the lines of: I cannot see your account or reset anything, but I can explain the steps and pass your details to the team who can. That leaves the visitor with a route rather than a dead end.
Keep reading
- Handling account access problemsLocked out, wrong email, a colleague who left, no admin remaining. Identity cannot be checked in a widget, so explain, collect, hand over.
- Handling data deletion requestsA deletion request is a request with a clock on it, not a question. The characteristic failure is silence, so it always has to reach a person.
- Handling accessibility requestsTwo different things arrive as one message. A published accessibility statement answers the first. The second is a request, and it needs a person.
- Every question typeHandling patterns for the questions every support inbox gets.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.