Website enquiry form not working? How to build one that never loses a lead

When a website enquiry form is not working, the cause is usually invisible: the email is sent but never arrives, a spam check throws away a real customer, or the Send button does nothing because a script failed to load. The fix is a form built so that no single failure can lose an enquiry: it works without JavaScript, checks everything on the server, catches spam without blocking people, sends each enquiry to two places, and tells the sender plainly whether it went.

This guide is for anyone whose website takes enquiries through a form, whoever built it. It covers how to find out whether yours is losing leads, what good contact form practice looks like in the UK, including what the privacy notice must say, and how we built our own.

Why enquiry forms lose leads without anyone noticing

The enquiry you never see is the one that costs the most, because nobody knows it was sent. A form that breaks loudly gets fixed the same week. A form that fails quietly can lose work for months, and the usual reasons are these:

• The email never arrives. The form sends its notification through a service your domain has not authorised, so the receiving mail server files it as spam or refuses it.
• The spam check eats real enquiries. A form that discards anything that trips a trap will, now and then, discard a person. Browser autofill can fill a hidden field whose name looks like a real one, such as “company”, for a genuine customer.
• It only works with JavaScript. On a slow connection or an older phone, the page’s script may not load, and a button that depends on it does nothing at all.
• There is one destination, and it fails. If the only copy of an enquiry is one email, a failed send loses it. Some forms still show “Thank you” when the send failed.
• A required field blocks the customer. A compulsory question the business does not need stops someone who does not have the answer to hand.
• Nobody hears back. With no acknowledgement, the sender cannot tell whether it arrived, so they try again, ring someone else or give up.

How to test your own form in ten minutes

You do not need to be technical to find most of these. Do this from your phone and from a computer:

1. Send a real test enquiry, from an email address at a different provider from your own (a Gmail address if your business email is Microsoft 365, or the other way round). Check that it reaches the inbox, not the spam folder.
2. Check the acknowledgement. If the form promises a confirmation, it should arrive within a few minutes and say what happens next.
3. Leave a required field empty and press Send. The form should say, in words under the field, what is missing. A form that silently refuses, or loses everything you typed, is losing people.
4. Turn JavaScript off and try again. Most browsers can do this in their settings. The form should still send, or at least tell you plainly how else to get in touch.
5. Use autofill. Let your browser fill the form from your saved details and send it. If that enquiry never arrives, a spam trap is probably catching autofill.
6. Find the privacy notice. There should be a link to it beside the form, before the Send button.

If any of these fail, the rest of this guide is the fix.

What good contact form practice looks like

What goes wrong	What a form that keeps every lead does
The script fails and the button does nothing	Works as a plain form post without JavaScript, and lands on a page that says whether it went
Checks run only in the browser	Runs the same checks again on the server, which turns away broken or malicious input
A CAPTCHA or a strict filter turns people away	Hidden trap fields and a timing check, with anything flagged kept for a person to judge
One email, and it fails	Sends each enquiry to two places, and keeps it if either one takes it
The sender hears nothing	Sends an acknowledgement, only once the enquiry is safely held
No privacy information	Links a privacy notice that covers what UK GDPR Article 13 asks for
Mail lands in spam	Sends from a domain with SPF, DKIM and DMARC for the sending service

Make it work without JavaScript

A form is, at heart, a plain HTML element that a browser can send on its own. Build it that way first, then add the script for the nicer touches: checks as you type, a review step, a message without a page reload. If the script never loads, the form still posts, and the server answers with a page that says either “it has reached us” or “it did not send, here is another way”. It should never answer a person with raw data or a blank page.

Check it on the server, not only in the browser

Checks in the page are for the customer’s convenience: they catch a mistyped email address before the enquiry goes. They are not protection, because anything can post to a form without using the page at all. The server has to check every field again: lengths, a valid email address, a phone number when the customer has asked to be rung, and that every choice is one the form actually offers. The neatest way is one set of rules shared by the page and the server, so the server only ever turns away what the page would not have sent.

Errors should be easy to fix. WCAG 2.2, the accessibility standard, asks that when an input error is detected automatically, the field in error is identified and the error is described to the user in text (success criterion 3.3.1). In practice: a plain sentence under the field, the field marked for screen readers, and the cursor put back in it.

Stop spam without stopping customers

A spam check that throws away anything suspicious will, sooner or later, throw away a customer. The better pattern has three parts:

• Hidden trap fields that a person never sees and a bot fills in. Name them for nothing a browser’s autofill recognises, so a customer’s saved details cannot fill them by accident.
• A check on how the form was sent, such as whether it was submitted faster than any person could fill it in, which catches scripts posting directly.
• Flag, do not bin. An enquiry that trips a trap should still reach you, marked as possible spam, for a person to judge. Give it the same answer as any other enquiry, so a bot learns nothing.

Leave out the CAPTCHA. The W3C’s note on the subject says that a CAPTCHA “not only separates computers from humans, but also often prevents people with disabilities from performing the requested procedure”, and the same note lists honeypots, the hidden trap fields above, among the alternatives. A puzzle stops some bots and some customers, and it is the customers you cannot afford to lose.

Send every enquiry to two places

The single biggest change you can make is to stop relying on one email. Send each enquiry to your inbox and record it in a second place, usually your CRM, and treat it as kept if either one takes it. Then:

• If the email has not gone, record it in the second place first, because that is now the only copy.
• Tell the visitor it has reached you only once one of the two holds it.
• If neither can take it, say so plainly and offer the enquiry as an email the visitor can send themselves, with their words already written in, so nothing they typed is lost.
• Give each destination a time limit, so a slow provider cannot leave the visitor staring at a spinner and pressing Send twice.

Connecting the form to a CRM properly is its own job. Our guide to connecting your website to Odoo, your CRM, bookings and payments covers what to map and how to keep the lead if the CRM is down, and our guide to whether you need a CRM yet helps if you do not have one.

Acknowledge the sender, and keep it a service message

An acknowledgement stops the double sends and the “did that go through?” phone calls. Keep it short: it reached you, what happens next, and when you read messages. Two cautions:

• Do not repeat what they typed. An acknowledgement that echoes the sender’s own words lets anyone use your form to send their text, links included, from your domain to any address. Restate their choices from the form’s own lists instead.
• Do not sell in it. The ICO treats a message sent for administrative or customer service purposes as a service message, not marketing, but warns: “If your service message has elements that are direct marketing, even if that is not the main purpose of your message, then it will count as direct marketing.” A special offer in the acknowledgement turns it into marketing, with the consent rules that brings.

What the privacy notice must say

A form collects personal data, so UK GDPR Article 13 applies: the information has to be given “at the time when personal data are obtained”. For a form, that means a short line beside the Send button and a link to the full privacy notice, not a policy buried in the footer.

The ICO’s guidance lists what to provide when you collect data directly from people. The items an enquiry form almost always needs are:

• who you are and how to contact you;
• why you use their details (to reply and to quote, say) and the lawful basis you rely on;
• who you share them with, such as the email service and the CRM, and whether any of them is outside the UK;
• how long you keep them;
• their rights, and that they can complain to the Information Commissioner.

You do not need a consent tick box to reply to an enquiry someone has just sent. If you also want to add them to a newsletter, make that a separate choice they tick themselves: the ICO’s consent guidance says you cannot rely on “pre-ticked boxes, opt-out boxes, default settings”, and asks you to keep a record of who consented, when, and what they were told. Ask only for what you need to reply well, too. Every field you add is data you have to look after, as well as friction for the customer; our guide to landing pages that convert covers the friction side.

Make sure the emails arrive: SPF, DKIM and DMARC

The notification to you and the acknowledgement to the customer are both email, sent by a service on your behalf. Receiving mail servers check whether your domain has authorised that service, using three records in your domain’s DNS:

• SPF lists the services allowed to send for your domain (RFC 7208).
• DKIM signs each message, so the receiving server can check it came from you and was not changed (RFC 6376).
• DMARC tells receiving servers what to do with mail that fails those checks, and is what lets them turn away mail that only pretends to come from you. It is now RFC 9989, published in 2026, which replaced RFC 7489.

Gmail’s sender guidelines ask every sender to set up SPF or DKIM, and anyone sending 5,000 or more messages a day to Gmail accounts to set up SPF, DKIM and DMARC, with the From domain aligned. A small business’s form will not reach that volume, but the same records are what keep its mail out of the spam folder. These records sit beside the ones for your business email, so set them up with whoever runs your mailboxes; for our clients that is our sibling practice Dacros. The email your website itself sends is our transactional email service.

How we built our own enquiry form

The brief form on our own contact page is built on every rule in this guide, so it is a live example:

• It works without JavaScript. Without the script, the form posts itself and the visitor lands on a page that says whether it went.
• One set of rules runs in the page and on the server, so the server turns away only what the page would not have sent, and each problem is described under its own field.
• Spam is caught without a puzzle. Hidden trap fields are named for nothing a browser’s autofill knows, and there is a check on how the form was sent. An enquiry that trips a trap is flagged for us to judge, never quietly thrown away.
• Two places. Each enquiry is emailed to our inbox and recorded in our business system, Odoo, and it is kept if either one takes it. If the email has not gone, the business system is tried first, and the acknowledgement goes out only once one of them holds the enquiry.
• The acknowledgement repeats nothing the visitor typed. It restates their choices from the form’s own lists, links our privacy policy and says how long an enquiry is kept.
• The privacy note sits beside the Send button, and the details it collects are listed in our privacy policy.

The case study of our own site sets out how the rest of the site is built and run.

The short version

A form that never loses a lead is not a clever form. It is a plain one with the failure cases thought through: it sends without a script, checks on the server, flags spam rather than binning it, keeps a second copy, acknowledges the sender only when the enquiry is safe, tells people what happens to their details, and sends from a domain that receiving servers trust. Test yours with the six checks above; most of the fixes are small.

If you would like it done for you, on your current site or a new one, our enquiry forms service builds and connects the whole thing: tell us where your enquiries go now and we will send a written quote.