Contact forms: the fields that cost you leads

The fields that cost a contact form the most enquiries are the ones a visitor has to stop and think about: budget, timeline, company size, "how did you hear about us", a required phone number, and anything that rejects input for its format. For most service businesses, a name, one way to reply and a free-text box for the message is enough to start the conversation; everything else can be asked in your reply. How the remaining fields are built matters almost as much as how many there are, and it is where many forms lose people without anyone noticing.

Our contact page guide covers the page around the form: direct channels, what happens after submit, spam. This post is about the fields themselves.

Which fields cost the most enquiries?

Every field is a small decision. Some are easy (your name). Some make the visitor stop, guess or worry. Those are the ones that lose people.

Each row is a trade. A budget field does screen out buyers who cannot afford you, and for some businesses that is worth it; that case is covered below. What we see more often is a long form copied from a template, where nobody decided what each field was for. On the websites we build, every field has to name the person who will use the answer and what they will do with it. Fields that fail that test go.

How should each field be built?

A short form can still fail if each field is awkward to fill in. The details that matter most:

• Labels above the field, always visible. Placeholder text inside the box disappears on the first tap, and the visitor forgets what the field was. It also fails accessibility checks.
• The right input type. type="email" gives phones the keyboard with the @ sign; type="tel" gives the number pad. A phone field set to plain text makes every visitor switch keyboards.
• Autocomplete attributes. They let the browser fill name, email, phone and company in one tap. MDN's autocomplete reference lists the tokens; name, email, tel and organization cover a contact form.
• One column. Two fields side by side on desktop become a confusing zigzag for the eye, and they stack anyway on a phone.
• One name field. "Your name" is faster than first and last, and works for names that do not split that way.
• Phone numbers in any format. Accept "+971 50 123 4567", "050-1234567" and "9876543210". Clean them on the server. Rejecting spaces or dashes is one of the commonest reasons a form fails without the visitor knowing why.
• Optional fields marked as optional. Mark the exception, not the rule. If most fields are required, write "(optional)" on the others.

A form built this way looks like this. It is plain HTML; whatever your platform generates should produce the same attributes:

<form action="/api/enquiry" method="post">
  <label for="name">Your name</label>
  <input id="name" name="name" type="text" autocomplete="name" required>

  <label for="email">Email</label>
  <input id="email" name="email" type="email" autocomplete="email" required>

  <label for="phone">Phone or WhatsApp (optional)</label>
  <input id="phone" name="phone" type="tel" autocomplete="tel">

  <label for="message">What do you need?</label>
  <textarea id="message" name="message" rows="5" required></textarea>

  <button type="submit">Send my enquiry</button>
</form>

Four fields, three required. Autofill completes the first three on most phones, so the visitor types only the message.

How should the form handle mistakes?

Many lost submissions are not people who chose to leave. They are people who pressed the button, saw something go wrong, and gave up.

• Validate when the visitor leaves a field, not on every keystroke. Flagging an email as invalid after the first letter is typed reads as an accusation.
• Say what is wrong, in words, next to the field. "Enter an email address, like name@company.com" rather than a red border alone, which colour-blind visitors may not see.
• Keep everything they typed. A form that clears itself after an error is a form nobody fills in twice.
• Handle server failures. If the submission fails, show a message with a phone number or email, and log the failure so someone knows. A form that spins forever is worse than one with no submit button.
• Do not block real people with spam checks. Invisible measures first; see the spam section of the contact page guide.

The W3C's forms tutorial covers labels, instructions, validation and error messages in detail, and following it fixes most of the problems above at once.

Should you use a multi-step form?

For a three-to-five-field contact form, no. Splitting four fields across two screens adds a step and a "Next" button for no gain.

Multi-step forms earn their place when the form genuinely needs more information: a quote request with a project type, a size, a location and a deadline, or a booking that depends on earlier answers. Then the steps help, as long as the first step is the easiest (what do you need?), a progress indicator shows how many steps remain, and the contact details come last, when the visitor has already invested in the answers. The W3C tutorial above has a section on multi-page forms.

When are extra fields worth the lost enquiries?

When the enquiries you lose are ones you did not want. If half your enquiries are for jobs below your minimum, a budget field with honest ranges ("Under ₹2 lakh", "₹2 to 5 lakh", "Over ₹5 lakh", "Not sure yet") will cut the volume and save hours of calls. The trade only makes sense if you were turning those leads away anyway.

The same logic applies to a required phone number for a business that only sells by phone, or a location field for one that only serves three cities. Add the field, explain it in the label ("We only work in Pune, Mumbai and Bengaluru"), and measure the result.

If you are getting few enquiries rather than too many, remove fields. Screening a trickle makes it smaller.

How do you find the field that is losing people?

Measure the form as a funnel: views of the page, form starts, form submits.

• Form starts and submits. GA4's enhanced measurement can record form_start and form_submit events. It misses some forms built with JavaScript, so submit a test and check the events arrive. If many visitors start and few submit, the form is the problem; if few start, the page is.
• Session recordings. A free session-recording tool shows where visitors stop, which field they tap twice, and which error they see. Watch twenty sessions on a phone and the problem field is usually obvious.
• Server logs of failed submissions. Validation errors logged on the server show what real visitors typed that the form rejected.
• The conversion rate. Divide submissions by visitors to the contact page, before and after each change. The conversion rate calculator shows what a given uplift is worth over a year.

When the form works, connect it to where the leads are handled; connecting your website forms to your CRM covers that step. For where the form fits in the wider plan, it is decided in step 3 of our guide to planning a website: the page's next action, written down before anyone designs a field.