Your site said thank you.
That is not proof.
Somebody types out their job, taps the button, and the page tells them thanks, we will be in touch shortly. That sentence was written by the page. It was not written by the person who was meant to receive the enquiry, and the two can disagree for months without anybody noticing. The symptom is not an error. The symptom is a quiet phone and a website that everyone agrees looks fine.
Two of the five failures below are defects we found and fixed on this website, and both are described in full further on. We do not publish statistics we cannot show you, so you will not find a percentage here.
The short answer.
A success message is a screen state. It is not a receipt. Between a customer's thumb and your reply there are five separate places an enquiry can die, and four of them leave the page looking perfectly healthy while they do it. The only way to know which state your site is in is to send one real enquiry through the live form and confirm it landed somewhere a human is actually watching. Reading the code is not the same test.
Five places an enquiry dies.
In order, from the device in your customer's hand through to somebody typing a reply. A site can fail at any one of them and still pass every test that only looks at the page.
The button nobody can tap
The enquiry never starts, because the way to start it is not reachable on the device the customer is holding. A control can be present in the page source, correct in the markup, visible on the desktop the site was built on, and still render at zero height on a phone. Nothing is logged when this happens. There is no failed submission to count, because there was no submission.
The form that reports success without capturing
The customer completes everything correctly and the page confirms it. Behind that confirmation, the submission went to an endpoint that answers politely and stores nothing. The browser sees a 200 response, the script shows the thank-you state, and the data is gone. This is the failure that does the most damage, because it manufactures evidence that the form works.
The address nobody reads
The submission is captured properly and the notification is sent to an address that was set up during the build and never opened since. An old webmaster account. A staff member who left. A mailbox whose password nobody has. The enquiry exists, it is delivered, and it is delivered to nobody. Notification addresses need to be configured deliberately and named out loud, not inherited.
Spam, or a shared inbox with no owner
Automated mail from a website is exactly the shape of mail that filters treat with suspicion, and one enquiry in the junk folder teaches nobody, because nobody looks there. The shared inbox is the same failure wearing a different hat. Four people can see an enquiry and each can reasonably assume one of the other three has it.
Nobody owns the reply
The enquiry arrives, the right person reads it, and it still dies. It arrives at four in the afternoon while they are on a job. It gets read on a phone, marked as read, and loses its place in the list by the next morning. A lead with no owner and no deadline ages out quietly, and the customer has already booked the business that answered.
We shipped the second one ourselves.
An earlier version of this website posted its own enquiry form to "/". Our host answered that POST with a 200 response, because it treated the POST as a request for a page that exists. Some hosts reject it outright; ours did not. The browser read that 200 as success, the page showed the thank-you message, and nothing whatsoever was captured. Every visible signal said the form worked. We found it in our own code during a review and fixed it by moving to a host-level form handler with the notification address configured explicitly rather than assumed.
We publish that because it is the most useful thing we can tell you about your own form. It was not a broken site. It was a working site with a defect that had no symptom.
The rule we adopted afterwards is the one worth copying. A form is not considered working until somebody has submitted the real form once and confirmed the email landed. Not a local test. Not a look at the code. A submission on the production site, and a human opening the inbox.
There is a subtlety in that worth knowing about. A draft deploy shares the production inbox, so an enquiry sent from a draft URL arrives looking exactly like a real one. That proves the draft path works. It proves nothing at all about the path a customer on your live domain will take, and those two paths can differ in the one setting that matters.
The first one, on our own audit.
On an audit of this website, the mobile menu's only call to action computed to display:none on every phone. The cause was ordinary and invisible: a base CSS rule sat after the media query at equal specificity, so it won, and the button that had been written to appear on small screens never appeared on any of them. The element was in the page source the whole time. It had been shipping that way.
Exposing the button surfaced the next defect underneath it. The primary button's text measured 1.83:1 against its background, where WCAG 2.2 AA requires at least 4.5:1 for normal text. Legible on the designer's screen, close to unreadable in daylight on a phone. It now measures 5.49:1 in the light theme and 7.94:1 in the dark one. Two defects, one hiding the other, neither producing a single error anywhere.
How to test yours this afternoon.
Use a phone, not the desktop
Pick up the device your customers actually use and find the way to contact you from the home page. If you have to think about where it is, or pinch to hit it, that is the finding. Check it in daylight as well as indoors.
Send one real enquiry from the live domain
Not a staging link, not a preview URL, not the version you have open in a build tool. The address a customer would type. Write something you will recognise later, and note the exact time you sent it.
Open the inbox and look for it
The inbox that is meant to receive it, opened by the person meant to receive it. Check junk and the promotions tab before deciding it arrived cleanly, because arriving in junk is a different result from arriving.
Name who replies, and by when
One person, not a mailbox. A shared inbox with four people watching it has nobody watching it. Decide what the reply deadline is and whether anything tells you when it has been missed, because the last failure point is a management one rather than a technical one.
If you would rather have the mechanical half done for you, the free audit runs thirty weighted checks live in your browser with no card, and it will tell you plainly what it cannot see from the outside. A form's destination is one of the things it cannot see, which is why the submission test above still needs a human doing it.
Where this stops being a form.
Everything above assumes the finish line is an email in the right inbox. For a lot of businesses it is not. The enquiry has to become a quote, then a booking, then an invoice, and each of those lives in a different tool. When the handover between them is a person remembering to do it, the failure points do not stop at five. They multiply, and they move out of the website entirely into the gap between your tools.
That gap is the real bottleneck when the quote goes quiet after you send it, or the booking is made and nobody confirms it, or the invoice sits there because nobody wants to be the one who rings. Rebuilding the website does not touch it.
That work is priced differently on purpose. An AI agent takes one job in that gap and does it every time: the first reply, the quote that needs chasing, the booking reminder, the invoice nobody wants to ring about. Each one is from $350 to set up, then from $89 a month, per agent, and each one drafts before anything goes out in your name.
If the gap is wider than an agent can cover, we will say so rather than sell you a website for it. Either way the form test above comes first, because none of it matters while the enquiry is still dying at the button.
Send us one that went missing.
Tell us what your form does now and where it is meant to land, and we will trace the path end to end and tell you what we find, including when the answer is that your form is fine and the problem is further down the line.