Avoid sending a draft unexpectedly when connectivity returns

What to change

Agree whether offline attempts are retained for deliberate retry or queued, and make that behaviour explicit before any later sending occurs.

A worked example

Illustrative example

A visitor is told their offline attempt remains unsent and activates Retry after reconnecting, using the reviewed current answers rather than an unseen earlier snapshot.

How to check the result

Accept when reconnection behaviour matches the communicated choice and visitors can understand and control any pending send operation.

A mistake to avoid

Automatic recovery is not automatically helpful when it performs an action the visitor believes they have postponed or abandoned.

Your action checklist

Use these checks to prepare a discussion with your team or supplier. Tick a check when you have recorded the decision or evidence, rather than when a feature has simply been promised.

Decisions to recordAttempt a fictional submission while offline, then change an answer or navigate to review. Reconnect and observe whether the site takes an action automatically.Ask the supplier to demonstrate the intended queue or retry model, including how a visitor can cancel any pending attempt where supported.Compare the eventual submitted values with the state the visitor understood they had approved. A queued older version must not silently masquerade as the edited draft.

Evidence, open questions and decisionsNext action and responsible role

Entries stay in this page and are not submitted to Kay & Co. Download your notes before leaving; the page does not save them.