Support desk recovery

Help someone regain account access

Use this workflow as a site owner or authorized support administrator. Keep support notes in your approved ticketing system; Awthy is not a recovery-case management system.

1. Establish which site and account the person needs.
2. Verify ownership using your store's approved process. A remembered browser or screenshot is not proof.
3. Check whether the user can use an unused backup code or email recovery.
4. If an administrative reset is necessary, record the ticket reference, reason, authorized actor, and decision.
5. Use the supported administrator reset action or have an authorized server operator use WP-CLI user reset.
6. Ask the user to enroll a replacement factor and save new backup codes. Confirm they can sign in before closing the request.

For an administrator or shop manager, follow your higher-risk reset approval process before changing their factors.

Example: a customer with a lost phone and working mailbox should first use email recovery. A customer who also lost mailbox access needs ownership verification before an administrator resets access.

Resolve a Hub ownership conflict

If reconnecting a site reports a different owner, stop generating claim codes. Check the company, license, and full site URL with the requester. Collect those non-secret details and the displayed error code for Awthy support. Reconnecting is not a self-service ownership transfer.

Never request claim codes, Hub cookies, install secrets, provider credentials, passwords, authenticator secrets, recovery codes, private keys, payment-card details, or government documents in an Awthy support note.

Help with a failed backup or restore

1. Confirm the requester can access the company and site involved.
2. Ask for the site host, point timestamp, job reference, and displayed error code.
3. For a download, check recent sign-in, recovery permission, and whether the point is complete and retained.
4. For a scheduled copy, check the destination's authorization and its own delivery status.
5. For a restore, identify the failing stage and keep the destination isolated until the operator resolves it.
6. Follow Backups and storage or Restore a WordPress site for the next action.

Do not request archives, database dumps, portable configuration, signing material, or raw request headers. Preserve the original retained point and any existing private archive while investigating. Never overwrite the client's only verified copy to test a fix.

Expected result: the person has a specific next action, and support has enough non-secret context to locate the failure without taking possession of site data.