Test a website enquiry form before launch

Test the complete enquiry journey

Before you announce a new website, send an enquiry through it. Follow the message all the way to the person who should respond. A confirmation on the page and a usable record in the business's system are separate things to check.

Use the sequence below on a site you own or are authorized to test. Mark test submissions clearly, use your own contact details and tell the recipient what to expect.

Write down what success means

Name the destination: an inbox, a customer record or another agreed system. Then name the person responsible for the response. If the form stores a record and sends an email alert, check both.

Choose a recognizable test phrase, such as “Launch check, 27 September”. Record the fields you will enter and the result you expect. This makes it easier to find the right submission and notice a missing message, service selection or contact detail.

Complete the form as a visitor

Open the public page on a phone and submit the test enquiry. Check that every label is readable, the keyboard does not hide the action you need, and there is enough space to correct a mistake.

Repeat on a desktop using the keyboard. Move through the fields with Tab and activate the submit button. Ask your developer to check that labels, errors and status messages are also available to screen-reader users. A successful mouse click does not cover every way someone may use the form.

Make ordinary mistakes

Leave a required field empty, enter an incomplete email address and try a longer message. The form should explain which field needs attention and how to fix it. Required fields should be identified before submission. W3C's validation guide explains these checks.

Keep errors readable and specific; a red outline alone is not enough explanation. Correct the mistake and confirm the rest of the visitor's work is still there. W3C's notification guidance covers clear feedback for both failure and success.

Verify receipt, then test the reply

Find the test in its intended destination. Compare it with what you entered. If an email notification is part of the flow, confirm the intended recipient received it and check the reply address before responding.

Reply to your test using the normal business process. Does the reply reach you? Can the person responding see enough context without searching through a second system? Record who will check new enquiries when the usual owner is away.

Check a failed submission safely

Ask the developer to simulate a failed request in a controlled test environment. Do not disable a live business service to create the test. The visitor should receive a useful message and keep their input so they can retry.

Test slow responses and repeated clicks too. Agree how the system avoids creating several copies of the same enquiry. If a fallback email link is offered, make clear that opening an email draft does not send it; the visitor still needs to complete that step.

Keep a small launch record

Record the page tested, date, device, expected result, actual result and any issue still open. Retest the complete journey after a fix and once more on the published site. A preview passing its checks does not prove the live destination is configured correctly.

Give the business owner the enquiry destination, response responsibility and a contact for reporting problems. Repeat the check after changes to the form, domain, hosting or receiving system.

Keep the useful part

The short checklist.

A clearly labelled test reaches the intended destination.
The stored details match what the visitor entered.
The business can reply using its usual workflow.
Required fields, errors and confirmation are understandable.
A failed request leaves the visitor a usable next step.
Someone owns ongoing enquiry checks.

Have a brief in mind?

Bring the context. We’ll help work out a useful next step.

Start the conversation