Websites · Note 10
Does your enquiry reach the right person?
A safe end-to-end check for small businesses with a website enquiry form.
A contact form has two ends
A customer fills in your form and sees a thank-you message. That is one part of the journey. The other part happens inside your business: the right person receives the request, can find the details and knows what to do next.
Testing only the page misses that second end. You do not need a new platform to start checking it. You need one clearly labelled test enquiry and a record of where it goes.
Start with a safe test
Use your own business website and an email address you control. Tell the person who receives enquiries that you are testing. Put TEST in the message so it cannot be mistaken for a real customer. Do not submit a payment, occupy a booking slot or include a real customer’s information. If the form triggers those actions, agree a separate test method first.
Make the test realistic: use a phone, enter the sort of request customers actually make and include the details staff need. Record the time you submitted it.
Check what the customer sees
Before submitting, can you tell which details are required and which are optional? Are there instructions for anything with a specific format? W3C’s form guidance recommends making these instructions clear and warns that placeholder text is not a replacement for labels.
After submitting, does the page say whether the enquiry succeeded? A message such as ‘We received your enquiry’ is different from ‘Your booking is confirmed’. Use words that describe the state your system has actually reached. If something failed, explain what needs fixing rather than leaving the person guessing.
W3C’s guidance calls for clear success and error feedback. If the page adds a status message without moving focus or loading a new page, ask your developer to check that assistive technology can announce it. A visible green message alone is not a full accessibility test.
Follow it into the business
Now check the destination. Did the test arrive in the expected inbox or work list? Can staff read the original request and contact details? Is the person responsible for the next step clear?
Record the result rather than assuming that a thank-you screen means an email was delivered. If the website stores the enquiry but its email alert fails, staff need a way to find the stored request. If it does not store enquiries, ask how an alert failure would be detected.
Do not add a response-time promise just to make the confirmation sound reassuring. Use the hours and response process the business can actually support.
Test the failure path too
On your own form, leave a required field empty and try an invalid email format. Check whether the problem is explained near the relevant field and whether you can correct it without retyping the whole request. Then navigate the form with the keyboard.
Do not deliberately break the live service or repeatedly submit requests. A deeper failure test belongs in a controlled environment, with the developer and staff aware of it.
Keep a small check log
A simple log is enough: test date, form URL, device, submission result, destination result, next-step owner and any issue found. Recheck after changing the form, email settings or an integration, and choose an ongoing interval that fits how the business uses the form.
This test does not prove that every enquiry will arrive. It gives you evidence about one path at one time, and a repeatable way to catch a broken handoff.
If enquiries already reach the right place reliably, you may not need more automation. If staff repeatedly copy them between tools or cannot tell who owns the next step, map that gap before choosing software.