Is it safe to submit an enquiry again when the form stops responding?
A visitor enters dimensions for a custom order, attaches a drawing and submits an enquiry. The connection drops while the screen is still loading. Did the business receive the request, or should the visitor start again? In this illustrative scenario, a reassuring success message is only one part of the answer. The application needs to distinguish another attempt at the same request from a genuinely new enquiry.
Name three separate states
Prepare different messages for processing, received and not yet confirmed. Pressing a button starts an operation; it does not establish that the sales team has read it. Show a reference when the server confirms the record. If no response arrives, avoid declaring certain failure or success. Explain the uncertainty and offer one useful next step without unnecessarily clearing the visitor’s work.
Learn from a documented implementation
MDN explains that repeated POST requests can cause additional effects. Stripe’s API demonstrates retries associated with an idempotency key. This behaviour is not automatically present in every enquiry form. A comparable design needs an explicit application and storage contract; the example is not a requirement to use Stripe.
Distinguish another attempt from another enquiry
In the example, the first submission creates request A. A retry after a connection problem retains that identity so the server can return its existing result. If the visitor changes the quantity, decide whether that means a revision or a new request. Do not silently accept changed content under an unchanged key. Ask the developer to define retention, conflicting requests and retry limits. Keep email addresses and phone numbers out of the key itself.
A disabled button is only one layer
Temporarily disabling the submit button can discourage repeated clicks, but it does not control requests from a refreshed page, another tab or a retry elsewhere. Pair the loading indicator with meaningful status text and avoid leaving the control disabled indefinitely. The designer should define visible states, the developer should define uniqueness, and the business should identify when the team actually receives the enquiry.
Make the acknowledgement precise
Once the record exists, show its reference, a short summary and the next step. Queueing a notification email, sending it and delivering it are separate events. A delayed email should not create another enquiry. Avoid promising a response time the team cannot sustain. Give the visitor a reference to quote when asking for help, while ensuring that the reference alone does not expose private enquiry details.
Test beyond one successful submission
In a test environment, submit the same request twice, delay the response after storage, and refresh the confirmation page. Count business records and notifications in each case. Then submit a genuinely different enquiry from the same person and verify that it remains possible. Keep these tests from messaging real customers. Include the acceptance conditions in the website design scope so ownership of duplicate handling is settled before launch.
Frequently asked questions
Are two enquiries from one email address always duplicates?
No. The same person may request different products or projects. An email-only uniqueness rule can block legitimate enquiries.