A visitor reaches the last step of an enquiry from your ChatGPT ad and notices that the service selection is wrong. They go back, correct it and return to find the project description empty. The form has turned a sensible review into repeated work.
Keeping progress is more than saving every field indefinitely. Some answers should survive movement through the form; others become irrelevant when an earlier choice changes. The task is to define a coherent draft that remains understandable and accurate while the visitor edits it.
Map the journey’s actual exits
List the ways someone can leave a step: the form’s Back link, the browser’s Back button, a help link, a language switch, a page refresh and closing the tab. These actions can behave differently even when the visible page looks similar.
Separate temporary navigation within the enquiry from returning days later. A form can reliably preserve answers between steps without supporting a saved application across devices. Do not use “Your progress is saved” unless you can explain what that statement covers.
For each exit, record the expected return point and which answers remain. This small map gives designers, writers and developers a common definition of success. It also reveals links that unexpectedly take the customer out of the task before they have a usable way back.
Preserve the information that still belongs to the request
Contact details and the customer’s own description often remain useful when they revisit an earlier step. Requiring them again can create frustration and inconsistent versions. W3C’s redundant-entry guidance explains the accessibility principle of avoiding unnecessary repeated entry within a process, including relevant exceptions.
That criterion does not require storing answers between sessions. Within the same process, previously supplied information should be populated or available to select when it is needed again, unless an exception applies, such as security or information that is no longer valid. Returning after closing the session is a separate product decision; do not present cross-session saving as a requirement of this criterion.
Apply that principle carefully to the business workflow. A previously entered address may still be correct after changing an appointment preference. A delivery address may become irrelevant after choosing a digital service. The correct behaviour depends on the relationship between the answers.
Treat uploaded files explicitly. A filename remaining on screen does not prove the file is still attached and available for submission. If the browser or service requires another selection, say so clearly and preserve the rest of the work. Do not make the customer discover the missing file only after sending.
Review a changed dependency
Imagine a hypothetical ChatGPT ad for office furniture with optional assembly. At the first step, the customer selects assembly. A later step asks about stairs and access to the room. The customer goes back and changes the request to delivery only.
The contact details should normally remain. Whether the stairs answer still matters depends on the delivery offer: doorstep delivery may not need it, while delivery to the room may. The form should follow that actual distinction, rather than blindly keeping or deleting everything associated with assembly.
A hidden answer can cause operational mistakes if it still reaches the receiving team as active information. A discarded answer can cause needless repetition if the person switches back. Decide whether to retain a temporary value for convenience, and separately decide whether it belongs in the final submission. Those are different design choices.
Going back to change the delivery method
- Step 1: assembly
The customer chooses assembly and describes stairs.
- Back: changed choice
The customer now selects delivery only.
- Forward: relevant answers
Retain contact details; review whether stairs still matter.
Checkpoint
Show the consequences of significant edits
If changing an earlier choice removes substantial work, explain that before the change is final where practical. The warning should identify what will be affected. “Changing the service clears your equipment details” is more useful than “Some information may be lost.”
Avoid a warning for every minor edit. Repeated generic alerts train people to dismiss them. Focus on changes that genuinely invalidate a section or discard a difficult-to-recreate attachment or description.
After the edit, present a review that highlights the current request. The customer should not need to remember which answers were entered under the previous choice. The multi-step form guide covers how the steps themselves are organised; this review checks the integrity of the answers moving between them.
Set a deliberate lifetime for unfinished work
A draft has a storage location and a lifetime, whether the design acknowledges them or not. Ask the implementation owner what is kept in the current page, browser session, local device or server. The customer-facing explanation should match the chosen behaviour without exposing unnecessary technical detail.
Preserving a private project description on a shared device indefinitely may create problems. Clearing everything after a brief navigation may make the form unusable. Choose a proportionate approach based on the information and the service, then make important limits visible.
Where a save-and-return feature exists, explain how the visitor resumes and what expires. Where it does not, avoid implying that opening the same campaign link on another device will restore the request. The return-visit guide deals with broader destination continuity, which is distinct from retaining an unfinished form.
Exercise the form as an editing task
Do not test only a perfect forward sequence. Enter a recognisable fictional description, make a supported choice, move forward, go back and change it. Use both navigation controls. Repeat after refreshing and following a help link.
Inspect the final record, not just the screen. Confirm that retained fields are submitted correctly and that answers no longer relevant to the current request are not treated as active. Include a case where the customer changes their mind twice, because that exposes values that appear preserved but are stale.
A sending failure is another transition worth checking, using the submission-delay guidance. Returning from an error should not unexpectedly reset the draft or revive old hidden choices.
The form is ready when editing is predictable: the customer can correct a decision, retain useful work and review one coherent request before sending. That outcome supports the specific task your ChatGPT ad invited, without promising storage or cross-device recovery the implementation does not provide.
Sources and scope
Define which enquiry answers survive step changes, back navigation and interruption within a ChatGPT ad journey, including how dependent answers change when earlier choices are edited.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.