A new patient fills out the appointment form on a practice’s website. She types her name, taps her phone number in from autofill, picks a time, and presses Send. The page says thank you. She waits for a call that never comes, and a week later she books somewhere else. Nobody at the practice ever knew she existed.

We found exactly this on a site we look after. The form had been quietly discarding real appointment requests, and every test the team ran had passed. That is what makes this kind of problem so expensive: from the outside, the form looks like it works. Here is how it happens and what to do about it.

The hidden field meant to catch bots

Most contact forms carry a “honeypot.” It is an extra field hidden from people but visible to the automated scripts that fill in every box they find. If that hidden field comes back filled in, the form assumes a bot sent it and throws the submission away.

It is a reasonable idea with one dangerous detail: the name of the field. Developers often give it an ordinary name like “company,” “website,” “address” or “phone,” so a bot will be tempted to fill it. Browser autofill and password managers are tempted too. They see a field called “company” and helpfully drop in your saved company name, even when the field is hidden and even when the code asks autofill to stay out of it. That request is a suggestion, and some password managers ignore it.

The result is a real customer, using a perfectly normal tool, who looks exactly like a bot.

Why nobody noticed

In the case we found, the form did three things when it decided a submission was a bot:

Showed the visitor the normal thank-you page
Stored nothing
Sent no email to anyone

That is the worst possible combination. The customer believes the message went through. The business never sees it. And nothing in any report says a submission was rejected, because the whole point of the design was to reject bots quietly.

It only happened to people who used a password manager or saved autofill details. Anyone on the team testing the form by typing into it got through every time, so it passed every check. The clue, when we finally looked, was in the data itself: the saved submissions were almost entirely the team’s own tests.

The fixes

Give the hidden field a name nothing recognizes. Something meaningless that no autofill tool will match to a name, email, address, phone or company. Better still, leave it unlabeled entirely.

Never silently discard a lead because a filter fired. On a form that brings in customers, a suspected bot should be saved and flagged, with the email notification held back, so a person can take a quick look and decide. A bot costs you one row in a table. A wrongly rejected customer costs you the customer, and you never find out.

There is a difference between forms here. A newsletter signup can safely drop a suspected bot, because the worst outcome is one missing subscriber. A request for a quote, a consultation or an appointment cannot.

The same rule applies to every check

Honeypots are only one filter. Forms also use spam filters and bot checks such as Cloudflare Turnstile, the small “verify you are human” step. All of them can be wrong about a real person, so all of them should follow the same principle:

Keep the evidence. If a check fails, save what the person sent and mark why it was held.
Tell the person clearly. “Something went wrong, please try again” with no detail leaves them stuck. Say what happened in plain words.
Give them another way in. Put an email address or a phone number right in the error message, so a customer who cannot get past the form can still reach you.

Save first, then send

One more design choice matters more than most owners realize. When a form is submitted, it should save the submission to a database first and only then send the notification email. If the email service has a bad afternoon, the lead is still sitting there safely.

The form should also record whether the email actually went out. That one detail turns “I think the form is working” into something you can check. If notifications stop sending, you see it in the records instead of hearing about it from an unhappy customer.

And make sure those notification emails go to someone who reads them. An inbox nobody opens is a quieter version of the same problem. Speed matters too, which we covered in speed to lead.

A five-minute test you can run today

You do not need a developer to find out whether your form has this problem:

Use your phone, the way a customer would. Open your contact form on your phone and fill it in using autofill or your password manager. Do not type the details by hand.
Check that it arrived. Confirm the notification email reached the right inbox, and if your form saves submissions somewhere, confirm it is there too.
Try every form you have. Contact, quote, booking, careers. They are often built differently.
Count your leads by month. Look back over the past year. A sudden drop that lines up with a website change, a new plugin or a new spam filter is worth a closer look.

If your phone submission never shows up, you have found the leak, and it has probably been costing you for a while.

What we do

Building forms that never lose a real customer is part of how we approach websites and solutions: every submission saved, every filter flagging instead of discarding, and every notification recorded so you can see it worked.