Make the form confirmation reflect a request that was actually saved

Identify what triggers the thank-you message

Observe the form while submitting valid and invalid sample answers. Does the same confirmation appear in both cases? If so, ask the maintainer which event triggers it. A click handler can change page text even when validation rejects the request or the receiving service is unavailable. The customer's visible receipt should not be based on an interaction that is earlier than acceptance.

Use a state the system can honestly confirm

W3C recommends feedback that distinguishes submission success from errors. For your business, define the exact success boundary: a saved submission, accepted booking request or another durable record staff can review. The wording should match that boundary. Receiving a request is not the same as confirming an appointment, issuing an estimate or promising that a member of staff has already read it.

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: W3C WAI: User Notification · Wix Forms: Creating Automated Email Responses for Form Submissions

Test success and deliberate failure separately

Use a staging copy or an agreed supervised test if simulating failures could disrupt real customers. The owner need not modify code personally, but should insist on evidence that each tested state produces the correct message. Ask the maintainer to document what happens when the server accepts a request but the browser fails to receive the response.

• Submit a valid marked request and match its receipt to supported acceptance and receiving-destination evidence.
• Attempt submission with an invalid required field and confirm that a useful correction appears instead of success.
• Ask the maintainer to test a rejected or unavailable delivery response in a safe environment.
• Check whether entered information remains available after an error so customers can correct or retry it.
• Repeat on mobile and record the success message, record identifier and follow-up expectation.

Keep an interruption from becoming a false receipt

Do not trigger a generic thank-you overlay before the request result is known. Do not tell customers to resubmit repeatedly when acceptance is uncertain; staff may need to check for duplicates first. An email acknowledgement can supplement a page receipt, but its failure does not necessarily mean storage failed. Explain uncertainty without claiming a request was definitely lost or definitely received.

Reconcile displayed receipts with saved requests

Compare marked test confirmations with their supported receiving evidence. There should be no success receipt for a deliberately rejected test. Watch real reports of missing requests and repeated submissions after the repair. Keep this operational verification separate from analytics: a confirmation page view or click event is not an independent record that an enquiry reached the team.

Give the customer a clear next step

Approve the exact success and failure wording with the business owner. Include who will respond, how customers can add missing information and which contact route works if the form fails. Keep the acceptance boundary in the maintenance note so a future redesign does not accidentally restore click-based success behavior. Avoid unsupported promises about response speed or appointment availability.

Worked example: an illustrative customer journey

For example, a flooring company's custom form displays 'Your quote request is received' as soon as the button is clicked. TEST-RECEIPT-501 with an invalid email shows that receipt but never appears in storage. The maintainer changes the confirmation to wait for an accepted request.

A valid TEST-RECEIPT-502 now creates a stored record and then displays the receipt. Invalid input receives a correction message; a simulated unavailable service receives an honest failure message. These tests establish the relationship between tested states and feedback, not a measured change in the company's lead volume.

Questions about this task