The system broke it. Why is the user fixing it?

You're scanning a packet of crisps for your meal deal and the self-checkout stops you, and the screen tells you what happens next: scan the packet again, remove the unexpected item, or wait for a member of staff.

Self-checkouts are annoying, but at least they usually tell you who can sort the problem. Sometimes that's you, sometimes it's a member of staff. A lot of software detects whatever the failure is, then leaves the user to work out who can actually do anything about it.

Who should make the first move?

Three experiments into self-service failure tested who should make the first move after different kinds of failure.

• Customer-caused error → Customer starts recovery
• Technology-caused failure → Employee or system starts recovery

That only tells you who should make the first move. It does not tell you who can actually clear the blocked state.

Identity verification makes that problem particularly obvious.

GOV UK treats the One Login app as one route, not the ONLY route. The page also offers prove your identity in another way.

A retry can leave someone else stuck

The person completing the verification is not always the only person left waiting.

For example, a reservation can remain pending on Airbnb while identity verification is incomplete, blocking those dates so other guests can't book them. The verification step belongs to the guest, but the resulting state also lands on the host's calendar.

That does not automatically make the block wrong but it does mean the product review cannot stop at Can the guest retry?. A retry for the guest is only half a recovery if the host's calendar remains blocked.

Host's can't complete the verification or clear the calendar state. So who can?

This is where recovery design becomes more than an error message. You are deciding who carries the delay, who can release the state and whether the product starts that recovery itself.

But support cannot always save you

The obvious answer is to give support more power. But that is not always safe.

GitHub makes that boundary explicit in its account-recovery guidance. People can recover through methods prepared before failure, including recovery codes, passkeys, security keys and previously verified devices. If those methods are gone, support cannot simply switch off two-factor authentication.

Giving support a hidden override would weaken the security promise for everyone. In this case, recovery has to be designed before the failure, not handed to support afterwards. The product has to make recovery setup part of account setup, explain the consequences clearly and give people a realistic way to keep those recovery methods safe.

So let the user retry is not much of a recovery strategy. When a self-service flow fails, I would check three things:

1. What actually failed? Was it a correctable mistake, the system, its data, or something you still cannot confidently identify?
2. Who controls the blocked state? The person seeing the error may not be the person with the authority to release it.
3. Should an override exist at all? If not, recovery has to be prepared before the failure happens.

You will not always know the cause with certainty, and the answer will not always be a human override. Those questions stop every exception from becoming the same lazy instruction to retry, start again or contact support.

If your system caused the failure, the user should not also have to work out your internal recovery process, that's part of the products responsibility.