Fix a quote form whose Submit button appears to do nothing

Find the point where the journey stops

Start with the customer's description: did the button ignore the tap, display an error, spin indefinitely, or show a thank-you message? Those are different failures. Record the page address, device, browser and exact visible behavior. Reproduce the issue without an editor session. A preview that works does not establish that the published page, its scripts and its connected form are working.

Distinguish a control problem from a delivery problem

Wix identifies overlapping page elements as a possible cause of unusable fields. W3C guidance also separates input validation from submission feedback. Apply that distinction to your investigation: a customer must be able to reach the control, correct rejected answers and understand the submission result. You do not need to redesign the entire contact page to discover which of those steps is failing.

Use the receiving evidence your system actually provides. If it stores submissions, inspect the marked record there. Otherwise ask the maintainer to verify server acceptance and the intended receiving destination through supported logs or delivery evidence. A thank-you screen alone is not proof. Wix-specific submission-table names belong to the Wix example.

Source checks: Wix Forms: Troubleshooting · W3C WAI: Validating Input

Run one controlled test on the published form

Use fictional details clearly marked as a test. Give the message a unique identifier, such as TEST-FORM-101, so the owner can locate one submission without confusing it with a real enquiry. If technical inspection is needed, ask the person maintaining the site to check the browser's request and error logs without exposing customer information.

• Open the published form on a phone and a computer; complete every required field with valid sample answers.
• Tap Submit once, wait for a result, and record the visible message rather than immediately tapping again.
• Check whether an error appears above or below the visible screen; inspect fields covered by banners or floating widgets.
• Find the marked test in storage if available, or verify supported acceptance and destination evidence; check staff notification separately.
• Change only the suspected failing component, publish the repair, and repeat the original device test.

Avoid repairs that hide the original fault

Do not remove all required-field checks just to make a button respond. That can pass incomplete requests to staff. Do not replace a working backend with an unverified email-only shortcut. If a script failed, preserve its error and the page version before changing it. If a request was never accepted, a new thank-you message is cosmetic and does not recover the enquiry.

Measure completed requests, not repeated clicks

After the repair, keep a short pass/fail record for valid submission, invalid submission and mobile submission. Each valid test should produce one accepted request with verifiable receiving evidence and a truthful confirmation. Monitor genuine reports of stuck buttons separately from marketing traffic. A change in total enquiries cannot, by itself, prove that this repair caused an increase.

Leave a reproducible repair note

The repair note should identify the failing control, the smallest change made, the published date and the test identifiers. Name who checks submissions when notifications are unavailable. If the form remains unreliable, place a verified phone number or alternate contact path beside it and explain the temporary route plainly. Remove that temporary message only after the complete path works.

Worked example: an illustrative customer journey

For example, a fence contractor receives a report that its quote button will not submit on an Android phone. The owner enters TEST-FORM-101 with a service selection and email address. Nothing reaches the submission table. Scrolling reveals a required date field hidden behind a floating chat bar; the date was never completed.

The maintainer moves the bar away from the field and makes the error visible. Repeating the same inputs produces one stored request and a confirmation. That establishes that this particular blocked path was repaired. It does not establish how many previous customers encountered the issue or whether every other browser is unaffected.

Questions about this task