Use this state list to review a slow enquiry form: ready to send, sending, received, rejected and receipt unknown. If the current interface only has “Send” and “Thank you,” the visitor has no useful explanation for everything that happens between them.
That gap matters when a ChatGPT ad has invited someone to describe a project. The person may have spent several minutes writing details that are difficult to reconstruct. A spinning indicator without explanation leaves them deciding whether to wait, click again, refresh or abandon the page. The right recovery depends on what the system actually knows.
Write the waiting state before choosing an animation
A waiting message should identify the action in progress. “Sending your enquiry” is more informative than a generic loading symbol. Keep the message near the submit area and preserve the entered answers visibly or in a recoverable form, according to the implementation.
Avoid a percentage or countdown unless it is driven by meaningful progress information. An invented “95% complete” creates an expectation the system cannot explain when it remains there. A calm statement about the current action is better than simulated precision.
Ask the technical owner when the interface should move from ordinary waiting to an extended-wait explanation. The threshold should reflect observed service behaviour and the chosen system, not a universal number copied from this guide. The wording can acknowledge that the request is taking longer while avoiding an unsupported claim that it has failed.
Separate rejection from an unknown outcome
A validation rejection has a known meaning: the submitted information needs correction and the service has not accepted it in the intended form. Show the relevant form-error recovery, preserve the other answers and let the customer make the correction.
A lost response is more complicated. The receiving system may have saved the enquiry while the browser failed to receive confirmation. “Nothing was sent” would then be false. “Your enquiry was received” would also be unjustified if the page has no evidence of receipt.
Use an honest unknown-state explanation and a supported way to check. That might be an enquiry-status lookup, a repeat request designed to reference the same submission or a contact route through which staff can search the receiving queue. Choose the mechanism with the system owner; do not promise duplicate prevention because the button was temporarily disabled.
Walk through a concrete interruption
Imagine a hypothetical visitor responding to a ChatGPT ad for a workspace survey. They enter a location and a detailed description, then submit while their mobile connection becomes unstable. The server records the request, but the browser does not receive the success response.
If the page simply restores the button and says “Try again,” the customer may create another enquiry. Staff could then contact the person twice or process inconsistent copies. Disabling the button during the first attempt reduces one kind of repeated click but does not resolve this later uncertainty.
A better designed recovery first preserves the text and states that receipt could not be confirmed. If the system supports checking the original request, use that route. If manual support is needed, provide enough non-sensitive reference information for staff to locate it. The customer should not have to send their complete project description through a second channel merely to ask whether it arrived.
The message must follow the known state
- Waiting for response
Show that the page is waiting for a response and preserve the text.
- Receipt confirmed
Show the reference and next step from the confirmed response.
Checkpoint - Status unknown
Offer checking or contact without claiming nothing was sent.
Reconsider
Make the status usable without watching the screen
The waiting and result messages need to work for visitors who do not see a small indicator change. W3C’s status-message explanation describes making relevant dynamic updates available to assistive technology without unnecessary focus changes.
Ask an accessibility reviewer to test the actual sequence. Announcing a message every second can become disruptive; saying nothing when the result changes can leave the person waiting indefinitely. The goal is meaningful state information, not a continuous stream of technical activity.
Keep the language specific enough to distinguish sending the enquiry from uploading an attachment. If the file transfer is still running, the page should not imply the complete request is already received. When uploads are optional, any ability to continue without the file must follow the supported business process.
Decide what the customer can do during the delay
A blocked submit button should not leave the whole page unusable without explanation. Determine whether the customer can inspect their answers, cancel the attempt, copy their description or contact the team. Each action must match the system’s actual capabilities.
Cancellation is especially easy to overstate. Stopping the browser’s wait does not necessarily recall a request that already reached the server. Use a label that accurately describes the supported action and explain any uncertainty that remains.
The form-progress guide covers retaining answers when someone navigates away. Here the immediate requirement is to avoid destroying their work as part of error handling. Do not clear the form until the application has a justified reason to do so.
Close the incident with a verified result
Test a normal response, a rejected request, a delayed response and a dropped confirmation. Coordinate with the receiving team so test enquiries are identifiable. Compare the interface state with the number and contents of records that actually arrived.
Check what happens if the customer refreshes or returns later. A recovery link should not turn a completed submission into another enquiry. Once receipt is established, use the confirmation-page pattern to explain the next business step.
The deliverable from this review is a small set of truthful messages tied to tested states. The customer may still encounter a slow connection, but they should understand what is known, retain the information they wrote and have a practical route to resolve what is not known.
Sources and scope
Design waiting and recovery when an enquiry submission after a ChatGPT ad click is slow or has an unknown receipt status.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.