A single structured way for Fin to sort sensitive account recovery requests into the right path the first time
Losing access to an account is one of the most sensitive situations a customer can bring to support: it's high-stakes, often urgent, and the right answer depends entirely on who's asking and why. A student asking on behalf of someone else needs a different response than the actual account owner. Someone claiming ownership of an account they don't control needs a different, much more careful response than someone who just needs to update the email on file. And an account belonging to someone who has passed away needs to be handled with real care, not a generic script. This project builds a single, structured way for Fin to correctly sort an account recovery request into the right path immediately, rather than leaving that judgment call to whoever happens to pick up the conversation.
The value is about getting a sensitive situation right the first time. For the customer, it means not having to explain their situation multiple times to different people before someone understands what they actually need. For the support team, it means a consistent, defensible standard for handling requests that carry real risk if mishandled, someone impersonating an owner, or a grieving family member getting a cold, generic response. For the company, it closes a gap where account recovery has historically been handled inconsistently depending on who happened to be on shift.
Covers every distinct account recovery scenario: the account owner has passed away, someone is claiming ownership of an account they don't currently own, the owner has lost access to the email on file, a student or non-owner is asking on behalf of an account they don't control, the owner can still access their email and just needs routine self-service help, and cases where the owner only needs a cancellation or refund without needing account access at all. Anything that doesn't clearly match one of those scenarios routes to a clarification step rather than being forced into the wrong path.
In draft, not live yet. The full scenario logic is built: seven distinct paths, each routing to its own dedicated sub-procedure, with a fallback clarification step for anything that doesn't cleanly match. No usage data exists yet since it hasn't shipped. Once it goes live, the plan is to first establish what current manual handling looks like as a baseline, so the actual before/after impact can be measured the same way it was for the request-routing work, rather than asserting improvement without evidence.
None written yet. Nothing to document until the procedure goes live and has real usage data behind it.