"I can't log in" describes a symptom, not a remedy. The client may have forgotten a password, opened an expired invitation, changed email addresses, lost a multifactor device, created a duplicate profile, reached a disabled subscription, or encountered a platform outage. Treating every report as a password reset can make the real problem worse.
Portal recovery is an identity and access task. It should not expose coaching records or weaken account protection for the sake of a quick reply. This guide covers routine administration; the platform owner sets security policy and handles suspected compromise.
Capture the symptom without collecting secrets
Open a support ticket with the client reference, report time, affected portal, last successful access if known, device type, and the exact error wording. Ask which step fails: invitation acceptance, username lookup, password reset, multifactor challenge, account loading, or access to a particular program.
Never ask for a current password, temporary password, one-time code, recovery code, or full screenshot of the portal. A screenshot can reveal messages, progress data, or other private material. If the error wording alone is insufficient, provide instructions for cropping or use the platform's own event logs.
Set urgency by impact. One missed check-in is different from evidence that an unknown person entered the account. Security signals leave the normal help queue immediately.
Identify the failure before choosing a fix
Check the service status and recent platform notices first. A broad outage should receive one approved status message, not dozens of individual account edits.
For a single client, compare the account ID, login email, invitation state, subscription state, and last successful authentication event. Look for a second profile created under another address. Confirm whether the reported issue affects login itself or only the entitlement to a coaching program.
Do not change contact details simply because a message arrives from a new address. An email-change request and a login-recovery request are separate operations, even when they arrive in the same conversation.
Use the approved identity route
The business should document how it verifies a client who cannot use the normal authenticated portal. Apply that method consistently and record only that the check passed, failed, or needs owner review. Avoid copying identity documents or answers into the ticket.
If verification fails, stop. Explain that staff cannot change the account through that channel and route the person to the approved alternative. Repeated pressure, conflicting personal details, a sudden address change, or a request to bypass multifactor authentication may indicate takeover.
Household members, assistants, employers, and coaches do not automatically have authority to recover someone else's account. The owner decides whether delegated access exists and how it is represented in the platform.
Prefer the platform's native reset event
Send a fresh system-generated invitation or reset link after identity verification. Do not create a password for the client or send a credential in plain text. Record the reset event ID, issue time, expiry, destination reference, and delivery result.
Invalidate older invitations and tokens where the platform supports it. Several active links create confusion and increase the chance that a forwarded message remains usable. If the client reports that the new link is expired, confirm its event rather than repeatedly issuing more links.
Ask the client to complete the reset directly. Staff do not need to watch the new password being entered, and the ticket does not need proof of its content.
Handle multifactor recovery as a separate control
A lost phone or authenticator is not a reason to switch off multifactor authentication indefinitely. Follow the security owner's recovery method, which may use saved recovery options, a verified device, or an additional identity step.
Record who approved any MFA reset, which factor was removed, and when the client enrolled a replacement. Do not place recovery codes in the support ticket. A temporary exception should have an expiry and a named reviewer.
If staff cannot distinguish device loss from takeover, escalate. The appropriate response may include invalidating sessions or reviewing account events, but only authorized security personnel should make that decision.
Repair duplicates without merging blindly
Duplicate profiles often appear when an invitation goes to one address and the client later signs up with another. Before merging or deleting anything, compare membership entitlement, coaching assignment, messages, billing reference, uploaded files, and program history.
Choose the surviving profile under an approved rule. Preserve a before-state and list what must move. A merge can expose one person's records to another if the profiles only look similar, so name-based matching is not enough.
After an authorized repair, verify the login email, coaching program, plan status, and historical records from the client's view. Keep the retired profile reference so a later support agent understands where missing events went.
Escalate signs of account takeover
Unexpected contact changes, unfamiliar successful logins, repeated resets the client did not request, a new MFA device, or coaching data appearing under the wrong profile are incident signals. Stop routine recovery and use the business's security response path.
Preserve timestamps and event references without exploring private content. Notify the system owner, restrict further support actions, and send only approved client communications. Do not attempt access merely to prove that a weakness exists.
The incident owner decides session revocation, credential resets, investigation, notifications, and any external obligations. The support queue should point to the incident record rather than becoming a second uncontrolled investigation file.
Verify access without asking for private proof
Ask the client to confirm that they can sign in and see the expected program name. They should not send a screenshot of messages, measurements, photographs, or coaching notes. If entitlement is still missing, compare the program assignment and subscription event rather than issuing another password reset.
Check that old tokens are invalid, duplicate profiles are resolved or clearly marked, and a replacement multifactor method is active when relevant. Close the ticket with the fault category, approved recovery events, delivery results, client confirmation, and any remaining restriction.
Review the queue weekly for repeated invitation failures, confusing email-change routes, duplicate creation, and reset messages that bounce. Those patterns point to product or process work, not careless clients.
The FTC recommends that businesses know what personal information they hold, keep only what is needed, protect it, dispose of it securely, and prepare for incidents. CISA recommends strong unique passwords and multifactor authentication. Those principles support native reset tools, individual staff accounts, narrow support permissions, and prompt offboarding. The listed sources were checked October 1, 2026.
A fitness virtual assistant can classify reports, maintain the queue, send approved reset events, chase delivery failures, and confirm restored access. Identity exceptions, MFA bypasses, profile merges, suspected compromise, and security policy remain with the operator. Include this workflow in the broader Fitness VA task list so support speed never replaces account control.