Before you run ads: test your website’s enquiry journey

Start where the customer will arrive

Open the exact destination planned for your advert. Check whether the page explains the same service, audience, and next step. A campaign about a specific service should not require visitors to search a broad catalogue before finding it.

Ask someone unfamiliar with your company to describe what the page offers and what will happen after they enquire. If their interpretation differs from your intention, revise the page before adding traffic. Use real service limits, geographic coverage, and examples of suitable projects instead of vague promises.

Choose a next step your team can support

A quote request, a callback, and a confirmed appointment are different commitments. Label the action accurately and explain the information the customer will need. If the team reviews requests during working hours, say so in language your operations can consistently support.

For an illustrative home-renovation business, “Request a project call” might ask for project type, location, and a contact method. It need not demand detailed dimensions before the first conversation. Later, a staff member can request plans through the agreed process.

Make the form understandable while it is being used

W3C’s form guidance recommends labels that identify controls and are associated with them. Check that each field remains understandable after someone starts typing; disappearing placeholder text should not be the only explanation. State which information is required and why unfamiliar details are needed.

Review the questions with the person who answers enquiries. Remove fields they do not use for the initial response, and allow a sensible contact choice where your workflow supports it. Test realistic names and phone numbers instead of repeatedly using the same short sample.

• Use the form on a real phone with the on-screen keyboard open.
• Move through links, fields, and buttons using a keyboard; check that the current position is visible.
• Increase text size and confirm that labels, instructions, and the submit button remain usable.
• For Arabic pages, check reading order, mixed-language contact details, and whether confirmation messages are also translated.

References: W3C Web Accessibility Initiative: labeling form controls

Follow a test request beyond the button

Tell the receiving team that you are running a test, then use a clearly marked fictional enquiry and a contact address you control. Keep private customer information out of the exercise. Compare the details entered with the record the team actually receives.

Check mistakes, retries, and interruptions

W3C recommends clear success and error feedback, including instructions that help people correct mistakes. It also distinguishes browser-side validation from server-side validation: checking a form in the browser alone is not a security boundary. Ask your developer to verify both layers.

Test failure handling in a safe test environment rather than disabling your live enquiry system. The customer should be able to understand whether a request was received, needs correction, or could not be sent. A generic “Something went wrong” message leaves that decision unresolved.

1. Leave a required field empty and enter an invalid email address. Check that each error identifies the relevant field and explains the correction.
2. Correct the error. Check that information already entered remains available where practical.
3. Try a slow connection and repeated taps on submit. Verify the waiting state and how duplicate requests are handled.
4. Simulate a delivery failure. Confirm that the page avoids a false success message and offers a working alternative contact method.

References: W3C Web Accessibility Initiative: form success and error notifications · W3C Web Accessibility Initiative: validating input

Use a short readiness decision

Record each issue, its owner, and what a passing retest looks like. Fix failures that prevent submission, lose requests, or mislead customers before directing paid traffic into that journey. Repeat the relevant check after changes to forms, hosting, notifications, or the receiving team.

If you measure enquiries, define the event carefully: pressing submit is different from successful receipt. Compare recorded submissions with actual requests and label test traffic so it does not distort your review. This exercise cannot promise campaign results, but it gives you a verified path for handling the interest your campaign may create.