How should a customer resume an unfinished long form?

Choose which unfinished work deserves recovery

A customer spends time describing a service need, checks a document, and returns to find the form blank. The business loses an enquiry, but automatically saving every keystroke is not the answer. Decide first which journeys are long enough to justify draft recovery and which fields would cause harm if left on a shared device. A short contact form may only need to preserve entries after validation fails; an application with multiple documents or a long explanation may need an explicit Save draft action. Write down the interruption the design should survive: a mistaken tab close, a browser restart, a lost connection, or a session timeout.

Define the draft as a separate state from a submitted application. A draft may be incomplete, outdated or unverified; it must not trigger staff fulfilment, payment, or a promise that an application was received. Tell the customer what was saved, when it was saved, where they can resume, and what remains to submit. Use distinct wording for Saved on this device and Saved to your account if those are genuinely different mechanisms. A spinner or green tick should not claim success before the storage operation completes. When saving fails, say so while preserving the current visible entries for another attempt.

Choose a minimum field set rather than copying the entire form by default. A customer might safely resume a service description but reasonably expect an identity number, payment details or uploaded document to vanish after leaving. Review each field against its purpose, sensitivity and whether the user could re-enter it. File inputs are particularly different from ordinary text; a page generally cannot silently restore a local file selection as if the customer had chosen it again. If a draft needs an attachment, design an authenticated server upload with a visible status, retention and deletion path, or ask the customer to select the file again.

Match storage to the recovery promise

Browser sessionStorage is scoped to an origin and a browser tab session; it is useful for surviving some navigation or reloads within that session, but should not be sold as a durable return-later service. localStorage persists across browser sessions for the origin and has no built-in expiry, so a forgotten draft can remain on a family computer until the application removes it or the browser clears it. Browser storage can also be unavailable or throw errors under policy or quota constraints. Treat it as a convenience layer with tested failure behaviour, not as a guaranteed archive of a consequential customer application.

For a journey that must continue on another device or after reauthentication, an account-bound server draft is usually easier to define and audit. The server must check the signed-in identity on every read and write, associate the draft with the correct customer and journey, and use a retention rule. Decide whether anonymous visitors can save a draft; if so, design a safe claim process rather than assuming that possession of a URL is sufficient for private records. A draft link sent by email has its own expiry and disclosure risks. State the actual recovery promise in the interface and support material, not a stronger promise inferred from the word autosave.

Do not put session tokens in localStorage as a shortcut for a draft feature. A draft is business data; authentication state is a separate security decision. If browser script can read a token, injected script may also read it. Keep the existing session design and handle expired sessions explicitly. The WCAG re-authentication criterion describes continuing an authenticated activity without losing data after a session expires; it is Level AAA, so avoid calling an untested design compliant merely because it shows a warning. The practical test is whether a customer can sign in again and still inspect and submit the previously entered work.

Make saves, edits and deletion understandable

Decide when a save is attempted: after a pause in typing, when moving between sections, through an explicit button, or a combination. A debounce reduces repeated writes, but it also creates a window in which the latest sentence has not been saved. Display last successful save time or a clear unsaved state, and keep the Submit action separate. If a write is still in flight when the customer closes the tab, a page-exit event is not a dependable last-chance archive. Test the actual closure and offline cases instead of relying on a lifecycle callback to rescue every final keystroke.

A restored draft is a proposal to continue, not permission to overwrite what the customer has just typed. On return, show the draft date and enough context to identify it, then offer Resume or Start fresh where appropriate. If the user has changed information in another tab or device, avoid silently replacing newer work with older work. A server draft can carry a revision or update timestamp so the interface detects a conflict and asks the customer which version to keep. Ensure that the conflict choice is understandable in both languages and that the older version is not deleted before the user chooses.

Define deletion as carefully as saving. On successful submission, remove or close the matching draft so an old form does not reappear and invite a duplicate application. Provide a visible Discard draft action and explain its effect before deleting substantial work. When an account is closed or the published retention period ends, include drafts in the disposal job and any necessary audit. For a browser-only draft, clear the relevant key after submission or discard, and remember that clearing one device does not remove another device’s server copy. Support staff need a way to distinguish a saved draft from an accepted submission.

Rehearse a long service application

Consider a home-service company asking for an address, access notes, preferred appointment period and photographs. A customer begins on a phone, stops to check building rules, and returns the next evening. The business decides to save text to an authenticated server draft but asks the customer to select photographs again unless a secure upload has completed. The first screen on return says when the draft was last saved and that no booking has been submitted. The customer reviews the address and appointment preference because availability may have changed. Only the final Submit action creates an enquiry record for staff.

Run a failure rehearsal with a real test account, not a description of a happy path. Enter a long note, turn off the connection just before a save, close and reopen the tab, and compare the recovered text with the last successful timestamp. Repeat with the session expired, with browser storage blocked, and with the same draft open in two tabs. Verify that the interface never claims a failed write succeeded and that a customer can still copy visible text if saving is unavailable. Test with keyboard and screen reader as well as touch, including whether status updates interrupt typing.

Check the support consequence as well. If the customer calls to ask whether the application arrived, staff should see a clear distinction between an unsent draft and a received enquiry, without exposing unnecessary draft content to everyone on the team. A confirmation reference belongs to the submitted state, not the autosave state. If saving relies on a third-party form vendor, verify its actual draft retention, access controls, exports and deletion behaviour before promising recovery. A local test in one browser cannot establish a vendor-wide service guarantee.

Set a promise the team can keep

Write one short product rule before implementation: which fields save, to which store, after which event, for how long, and under whose account. Add what the customer sees when saving fails, when the draft expires and when the session ends. Have design, engineering and support agree on those sentences before building the interface. This exposes conflicts early, such as a design promising return on any device while the implementation only uses sessionStorage. It also gives QA a concrete acceptance test rather than a vague instruction to check autosave.

Keep the first release proportionate. If most enquiries take only moments, a reliable submit flow and preservation after validation errors may be the better use of effort. If customers routinely pause to gather documents, pilot account drafts on that journey and inspect where recovery fails. Use actual support cases and test observations to improve the design; do not claim a conversion uplift without measurement. The success condition is modest but valuable: customers know whether their work was saved, can resume the permitted portion, and never confuse a draft with an accepted request.