A customer fills in your website form. The page says “sent”. You see a form submission in an analytics report. Yet nobody in the business answers the enquiry because it never reached the right inbox. This is a different problem from getting more traffic, and a more urgent one. A working contact route is part of the service you are offering.
You can test it without being a developer. You need a phone, access to the inbox that should receive the enquiry, and someone who knows what should happen next. Fifteen careful minutes can reveal a broken button, a rejected message, a hidden spam folder, or a handoff that works technically but fails in the office.
This guide is a practical test for an owner or manager. It does not require you to send real customer details through a test form. It also gives you a clear record to hand to the person who maintains the site if something fails.
First, find every route a customer can use
Start with the home page, the main service page and the contact page. Write down each way someone can reach you: a form, a phone link, an email link, a booking tool, a chat window or a third-party quote system. Follow every route rather than assuming the main contact form is the only one. An old form in a footer may still take real enquiries.
On a phone, tap the call button and check the number that the dialler opens. Do the same with the email link. On a desktop, copy the link address if clicking it would launch a program you do not use. Compare the result with the number or inbox the team currently monitors. A correct number in visible text is not enough if the underlying link points somewhere else.
For a form, note the URL you started from and where the form sends you after submission. If the site uses a separate booking or payment service, write down its domain. That makes it easier to tell whether a failure lives on your site or at the next service in the chain.
Make one clean test enquiry
Use a test name and an email address you control. Put a short, unmistakable marker in the message, such as “Website form check 25 September”. Do not use a real patient’s, client’s or employee’s private details. If the form has a service selector or location choice, record what you chose. If there are several forms, give each test a different marker so you can tell them apart in the inbox.
Before you press Send, take a quick screenshot of the completed form without exposing a password or private data. Then submit once. Write down the time, the page, and what you saw. Did the button change? Did you get a clear success message? Did the form stay filled, reset, or move to a new page? A spinner that never ends is not a successful submission.
Try an incomplete submission too. Leave a required field empty or enter an email without a valid address. The page should tell you what to correct without losing the rest of the message. The browser may catch some errors before the form reaches the server, but that is not the whole safeguard. MDN’s form guidance notes that client-side validation can be bypassed and that server-side checks still matter. Your maintainer should test both.
Check the real destination, not just the thank-you screen
Open the inbox that should receive the message. Search for the exact marker, then check spam, junk, quarantine and any shared mailbox or ticket queue. Ask the person who normally handles enquiries whether they can see it too. Some systems deliver to one account but not the shared view the team uses every day.
Read the message. Does it include the customer’s reply address, chosen service, location and question? Is the reply address usable, or does the Reply button point back to the website’s own mailbox? Does the message say which page sent it? These details determine whether a team member can answer without guessing.
If the site is built on WordPress, do not let a developer close the issue by saying the mail function returned true. The WordPress documentation for wp_mail() says that a true return value does not by itself mean the recipient received the email. It means the sending method processed the request without an error. The inbox is a separate check.
If nothing arrives, keep the exact test time and marker. The person maintaining the site can inspect the form submission record, mail service logs, sender settings and any spam filtering. Do not keep hammering the Send button with the same entry. Repeated tests can create duplicates while leaving the root problem unclear.
Check what the customer sees next
The visitor needs a result they can understand. “Sent” is better than a silent reset, but it may still be vague. The confirmation should make clear that the request was received by the site, what happens next, and what the person should do if the matter is urgent. It should not promise a response time the team cannot meet.
Try the form on a narrow phone screen. Read the field labels, type a long message, and open any dropdown. Check that the keyboard does not cover the Send button and that the confirmation remains visible after the page moves. A form can pass a desktop test and still be hard to complete on the device most buyers use.
Next, use the reply address from the received test to send a short answer. Verify that it reaches the test inbox. This closes the loop. A form that delivers to you but cannot be answered easily is still a poor enquiry route.
Separate a recorded event from a delivered enquiry
Analytics can help you see how often people use a form, but it cannot replace the inbox check. Google Analytics recommends a generate_lead event when someone submits a form or request for information. That event has to be configured with the right trigger. A click on Send, an attempted submission, a success message and a delivered email are different steps. Your report should say which one it counts.
Ask the person managing analytics to run the same marked test while watching the site’s event record. There should be one meaningful event for one successful submission, not an event every time a visitor clicks a button with empty fields. Then compare it with the message in the destination inbox. If the event fires but the message does not arrive, your tracking is working and your delivery route is not. If the message arrives but no event appears, customers may still be reaching you while the report undercounts them.
Google also describes later lead stages such as qualification and contact. Those are useful only when the business can supply the underlying decision. A form entry is not automatically a qualified prospect, and a qualified prospect is not automatically a sale. Keep the labels honest so the team knows what to fix.
Test the handoff inside the business
The website can be perfect and the enquiry can still stall. Ask who opens the inbox when the usual person is away. Is there an owner for each service or location? What happens when a message needs a quote, a callback or a specialist answer? If the process depends on one person remembering to forward an email, write that down as a risk.
For the test, follow the actual route the team would use. If enquiries enter a shared inbox, ticket system or customer database, check that the record appears there with the right owner. If the site sends an email notification and also saves a database entry, compare the two. The database can provide a recovery path when mail delivery fails, but only if somebody checks it and its access is controlled.
Make the next action visible. A simple record can hold the received time, service requested, person responsible, first response time and outcome. You do not need a complex system to discover that enquiries are arriving but sitting unanswered. You do need a way to see the difference between a new message and one already handled.
Retest after changes that can break the route
Run the test after a redesign, a form-plugin change, a new email provider, a domain move, a spam-filter change, or a new booking integration. Retest when a phone number or receiving address changes. A contact route is a chain of systems; any change in that chain can leave the page looking fine while the final message goes astray.
Keep a small record of each check: date, page URL, device, test marker, screen result, inbox result and person who verified it. The record does not need to be public. Its value is that the next person can see exactly what worked and when. If a later report shows a sudden fall in enquiries, you can distinguish a quiet market from a broken route before changing the marketing plan.
Where a form collects sensitive information, ask the appropriate person to review what it requests, where the entry is stored and who can see it. A test does not make the privacy design safe. The form should ask only for information needed to start the conversation and should explain the use of that information clearly.
A result you can hand to your website team
At the end of the test, write one plain sentence: “The form on this page accepted the test at this time, displayed this result, and the message did or did not arrive in this inbox.” Add the marker and screenshots. If the reply path failed, say so. If analytics recorded a different outcome, include that too. This is enough evidence for a maintainer to start in the right place.
The order matters. Make sure a buyer can submit. Make sure the message reaches a monitored place. Make sure someone can answer. Then measure it. More search visibility is useful only when the business can receive the people it attracts.
If you would like me to inspect your site’s contact route as part of a wider review, send me the site. I will start with what a visitor can actually use. For the larger measurement setup, see call and form tracking for small businesses.