Contact form checklist: when website inquiries seem too quiet.

Check the whole route: reaching the form, completing it, saving the request and getting it to the person who responds.

By Page Health Check · Published September 8, 2026

A form can look correct while a later handoff fails. It can also work correctly and receive little traffic. Before assuming you need a new website, gather enough evidence to locate the problem.

1. Define what “working” means.

Ask whoever handles inquiries where a successful request should appear: an inbox, a CRM, a booking system or a website dashboard. Identify who responds and the normal internal handoff. If the request is saved in one place and an email alert is sent separately, check both.

2. Reach the form like a new customer.

Start on the page a buyer is likely to visit, not a bookmarked form address. Follow its quote, booking or contact link. Confirm the destination is correct and that the form is usable on a narrow screen with banners open.

For a wholesale inquiry, the page should explain that route clearly. For a logistics quote, it should connect the requested details to the service being discussed. A general contact form can be appropriate if it tells the buyer how the request will be handled.

3. Read the labels and requirements.

Every field should have a visible, meaningful label. Mark required and optional fields, and explain unusual formats next to the field. Placeholder text disappears when a visitor types, so it should not carry the only instruction. These practices follow the W3C guidance on form instructions.

• Can the buyer tell what each field is asking for?
• Does the first conversation actually require every mandatory field?
• Is there a usable route for someone who cannot provide an exact figure yet?
• Does the button describe the request being sent?

4. Agree a controlled test.

Only test a form you own or have permission to test. Confirm the details with the person receiving it first. Use an agreed test identity and an obvious marker such as “Website form test.” Do not use a real customer's details or accidentally create a booking, order or paid commitment.

Record the page, time, browser, viewport and test marker. Submit once. Note the result before trying again so duplicate tests do not confuse the inquiry queue.

5. Check feedback and errors.

A successful submission should make the outcome clear. If something fails, the message should explain what needs attention and how to continue. Check that the message is visible and reachable with a keyboard, and ask the editor to check how it is announced by assistive technology. See the W3C guidance on form notifications.

As part of an agreed test, check a simple recoverable error, such as a required field left empty. Does the person know which field to fix? Do other entries remain available? Is a contact alternative shown if the service cannot save the request?

6. Verify receipt beyond the success screen.

Have the owner locate the exact test in the destination system. Then check any expected notification and confirm that the responsible person can act on it. A browser success message alone does not establish that an inquiry reached its final destination.

• Saved, but no alert: investigate the notification route, recipient and spam handling.
• Not saved: ask the site maintainer to examine the form integration and its error handling.
• Saved and delivered: investigate traffic, the offer and follow-up before deciding the form caused the quiet period.

Ask the owner to remove only the agreed synthetic record after the test, if appropriate. Keep the test notes without retaining unnecessary personal data.

Send the editor a specific issue.

Share the exact URL, test time and marker, reproduction steps, visible result and whether the record reached its destination. State the acceptance check: for example, “One agreed test is saved once, an accurate confirmation appears, and the intended person can find the request.”

For the wider route into your form, use the website inquiry checklist. These checks support diagnosis; they do not measure conversion impact or replace a full accessibility or security audit.