canned responses for password reset requests
Three canned responses for password reset requests that close tickets fast while staying secure: one for self-service reminders, one for locked-out users, and one for suspected account compromise. Use when building the authentication macro set, training agents on identity verification, or cutting handle time on reset tickets. Not for MFA troubleshooting, SSO configuration, or password policy writing.
TL;DR
Most password reset tickets need one of three replies: point them at self-service, walk a locked-out user through verification, or lock the account down when something smells wrong. The macros below handle all three, with identity verification baked in so agents never hand out access on a vibe. Keep resets boring and secure, not clever.
The query
canned responses for password reset requestsUse this when
- Password resets are eating a big chunk of queue time
- Agents are inconsistent about verifying identity before resetting
- You need a macro set for authentication requests
- Self-service reset exists but customers still write in
Not for
- MFA and two-factor troubleshooting
- SSO or identity-provider configuration
- Writing your password complexity policy
- Suspected data-breach communication
Steps
1. Pick the right of the three macros
Self-service reminder for anyone who can reset it themselves. Guided reset when they say self-service failed. Lockdown when the email or story doesnt match the account.
Expected output: the agent selects a macro in seconds, not paragraphs.
2. Verify identity before any manual reset
Match two things from the account record, never one. Full name plus order number, or account email plus phone on file. If they cant produce two, you dont reset.
Expected output: no manual reset without two verified identity points.
3. Send the link, never the password
The reset always goes to the email on file, never to the address they wrote from if it differs. This one rule blocks most social-engineering attempts cold.
Expected output: reset links only ever land at the address of record.
4. Close with what to expect
Tell them the link expires in [timeframe] and what to do if it never arrives. Most "it didnt work" follow-ups are just expired or filtered links.
Expected output: fewer reopen tickets about missing reset emails.
Ready-to-use macros
MACRO 1, SELF-SERVICE:
You can reset that yourself in about a minute. Hit "Forgot password"
on the sign-in page and the link will land at the email on your account.
It expires in [timeframe], so use it when it arrives.
MACRO 2, LOCKED OUT:
No problem, I can get you back in. To keep the account safe I need to
verify two things: your full name as it appears on the account, and
either your last invoice number or the phone number on file. Once those
check out, the reset link goes to the email address we have on record.
MACRO 3, SUSPICIOUS:
I want to be careful here because the details dont line up with the
account. Ive temporarily locked sign-in to protect it. Please write
back from the email address on the account, or we can verify identity
another way that works for you.Variant phrasings
password reset email template for support
Macro 1 above. Keep it short, the link does the work, not the email.
support script for locked out accounts
Macro 2. Two identity points, link to the address of record, then a clear expiry note.
what to say when a password reset looks suspicious
Macro 3. Lock first, explain warmly, give them a path back in.
Why it happens
Resets feel trivial so agents wing them, and winging identity checks is exactly how account takeovers happen. Canned macros standardize the security boundary so "just help me get in" cant talk an agent out of verifying. Boring and secure beats helpful and breached.
Edge cases
- Email on file is dead: fall back to a documented alternate verification path, never just trust the new address they give.
- VIPs who hate verification: the rules dont bend for titles. Offer a video call as a fast verification lane instead.
- Bulk reset requests from one sender: treat as suspicious until proven otherwise.
- The user is clearly the account owner but flustered: slow down, be kind, still verify both points.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_1au1nb3pLJWB1Nop9tcp8A
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.