There are two ways a contact form goes wrong, and they look nothing alike.
The first is the long form. Name, company, job title, phone, country, industry, company size, budget range, how you heard about us, and a message box at the bottom. It was assembled by adding one field at a time, each requested by someone with a reasonable case, and nobody has ever removed one. It collects excellent data about the small number of people who still fill it in.
The second is the short form. An email box and a message box. It gets plenty of submissions, and every one of them starts a chain of clarifying emails before any work can begin, because the form never asked the one question that would have told anyone what to do with it.
Both are field selection problems. The useful way to decide is not "what would be nice to know" but a narrower test, applied to every field on the page.
The test a field has to pass
A contact form has exactly two jobs. Get the message to the person who should handle it, and collect enough that the first reply can be a real answer rather than a request for more information.
So each field has to pass one of two checks. Either it changes who receives this, or it changes what the first reply says. A field that does neither is not collecting information, it is collecting friction, and it is being paid for in submissions that never happen.
Run that test across a typical long form and most of it fails. Company size does not change who replies or what the reply says on a first contact. Nor does industry. Nor does how you heard about us, which is a marketing attribution question being asked of someone who came to ask for help, and which is answered more reliably by analytics than by a dropdown.
The test also rescues fields that get cut for being unfriendly. A single question asking what the enquiry is about often changes both the recipient and the answer, which makes it one of the most valuable fields on the form even though it adds a step.
The four that usually earn their place
Name. One field, not two. Splitting first and last name is a convention inherited from database design, and it mishandles a large share of the world's naming conventions. A single name field accepts every one of them and still gives you something to open a reply with.
Email address. The one genuinely mandatory field, because without it there is no reply. It is also the field worth validating properly rather than strictly. A format check catches typing mistakes. A rule that rejects unusual but valid addresses, such as long top level domains or plus addressing, quietly turns away real people who will not tell you it happened.
Message. A free text box, with a placeholder that suggests what to include rather than a rigid template. This is where the actual information is, and the most common mistake around it is making it small. A three line box signals that a short message is expected, and short messages are the ones that need a follow-up before they can be answered.
One routing question. A short list of enquiry types, written in the language of the person asking rather than the shape of the org chart. Sales, support, billing, press, and something else is usually enough. Keep the list under about six options, because a longer list forces people to read every one and guess, and a wrong guess is worse than no answer at all.
That is the standard set. Everything after it needs to argue for itself.
Fields that cost more than they return
| Field | What it buys | What it costs |
|---|---|---|
| Phone number | Faster contact when it is genuinely needed | Many people abandon rather than give a number to a first enquiry |
| Company name | Context for business enquiries | Excludes individuals, and is usually guessable from the email domain |
| Budget range | Filters early on price | Reads as qualification before any relationship exists |
| Postal address | Needed for physical delivery only | High effort, and almost never relevant at first contact |
| How did you hear about us | Attribution | Self-reported and unreliable, with better sources available |
| File upload | Lets people attach evidence up front | Adds a real barrier, and on some platforms forces the sender to sign in |
The file upload row deserves a note, because the barrier is often larger than it looks. Google's own documentation for the file upload question type states that to answer it, responders need to sign in to a Google Account, that uploaded files land in a folder on the form owner's Drive, and that the question cannot be used if the form is stored in a shared drive. A field intended to save one round trip can therefore end the conversation before it starts. If attachments matter for some enquiries and not others, asking for them in the reply, once a thread exists, costs the sender far less.
Phone number is the field most often argued for and least often justified. If the team calls back on fewer than half of enquiries, the field is collecting numbers nobody dials, in exchange for the submissions of everyone who did not want to be called.
Required, optional, and the middle ground people forget
Marking everything required is the reflex, and it is the main reason long forms fail. Every required field is a point where someone who cannot or will not answer has to abandon the form entirely.
The rule that holds up: a field is required only if the enquiry genuinely cannot be handled without it. By that standard, on most contact forms, the list is email and message. Everything else is optional, including name.
Between the two settings sits the option people skip. Conditional fields appear only when an earlier answer makes them relevant. If someone selects billing, ask for the account reference. If they select support, ask which product. Nobody else ever sees those questions. The form stays four fields long for every visitor while collecting what each specific case needs, which is the outcome the long form was trying to reach by asking everyone everything.
The same applies to anything legally required. A consent checkbox for marketing contact is not the same question as the enquiry itself, and bundling them so that the enquiry cannot be sent without accepting marketing is both a poor experience and a shaky basis for consent. Keep them separate and leave the marketing box unticked.
Most of the data you want belongs after the submission
Here is the observation that shortens contact forms faster than any argument about conversion. A large share of the fields on a long form are not questions for the sender at all. They are notes the team wants to record.
Priority. Assigned owner. Whether it has been answered. Which stage it is at. Estimated value. Whether this person has contacted you before. None of that is known to the person filling in the form, and several of those fields exist only because the form is the only structured place the team has to put anything.
That is a tooling gap dressed up as a form design decision. When the tool holding the responses can carry its own columns, the team records status, owner and internal notes against each submission after it arrives, and the form goes back to asking only what the sender knows. Response tools that support internal fields alongside the submitted answers also tend to key contacts on the email address, so a person who submits three enquiries over a year appears as one history rather than three unrelated rows. That single behaviour removes the urge to ask returning customers for details you already hold.
It is worth looking at how different intake situations are structured before adding another field. An enquiry form, a job application and an event signup want genuinely different things, and the mistake is usually running all three through one form that has been extended until it half serves each.
The parts of the form that are not fields
Two things sit outside the field list and do more for the outcome than any of the questions.
The first is what happens the moment the form is submitted. A confirmation that appears and then vanishes leaves the sender with no evidence they made contact, which is why so many teams receive the same enquiry twice, and why the third message is often annoyed. An acknowledgement that quotes back what was submitted solves both. It proves the message left, it gives the sender a copy of their own wording, and it creates a thread that a reply can land in. It also works as a continuous test of the mail path, because if people stop mentioning that they received one, something has broken.
The second is how validation fails. Error messages that appear only after the whole form is submitted, and that clear what was typed, are the most reliable way to lose a completed enquiry. Validate each field as the person leaves it, say what is wrong in plain words next to the field rather than at the top of the page, and never discard entered text. A form that asks four questions and then throws away the answers is worse than a form that asks eight and keeps them.
Both of these are properties of the tool rather than decisions about fields, which is why they are so often left at whatever the default was.
Making it survive a phone
Most contact forms are now completed on a phone, and a long form is much worse there than on a desktop. The whole form is never visible at once, the keyboard covers half the screen, and progress is invisible.
Two changes do most of the work. Set the correct input type on each field so the phone shows the right keyboard, with the numeric pad for a phone number and the email layout with the at sign for an address. And if the form is genuinely long because the process needs it, present one question per screen with a progress indicator, which suits a small screen better than a single long page and makes the remaining effort visible rather than a guess.
What to change first
Take the current form and mark each field with which of the two tests it passes: does it change who receives this, or what the first reply says. Delete or make conditional everything that passes neither, and move the fields that are really team notes into the response record instead. If the tool behind the form cannot hold those notes, that is the thing to replace, and it costs nothing to try the same intake on one that can, such as Halict.
Q1. How many fields should a contact form have?
Four is a workable default: name, email, message, and one question that routes the enquiry. Add a fifth only if it changes who handles the message or what the first reply says. Length itself is not the problem, but every field that fails that test is being paid for in submissions that never arrive.
Q2. Should the phone number field be required?
Rarely. Requiring a phone number on a first enquiry loses the submissions of everyone who does not want a call, in exchange for numbers the team mostly will not dial. If calls genuinely are the primary channel for some enquiry types, make it conditional on those types rather than mandatory for all.
Q3. Is it better to split first name and last name?
A single name field handles more of the world's naming conventions and asks for one action instead of two. Splitting is worth it only when a downstream system genuinely needs the parts separately, such as printing personalised documents, and even then the split can often be done after the submission rather than demanded on the form.
Q4. What is the right way to handle a consent checkbox?
Keep consent for marketing separate from the enquiry itself, leave the box unticked by default, and never make the enquiry impossible to send without accepting marketing. Bundling them gives you a list of contacts whose consent is difficult to defend, which is worse than a shorter list.
Q5. Where should internal notes like priority and owner live?
Not on the form. The sender does not know them, so asking is meaningless, and a field the team fills in afterwards belongs with the response record. Tools that support internal fields let you define those columns once and record them against each submission, where they can also be filtered and exported alongside the answers.