Contact forms: which questions to ask without complicating the request

The contact form is the one place on the website where you ask for something instead of offering it. Every extra field is a question to answer before knowing whether it will be worth it, and it loses someone along the way. The problem isn't length in itself: it's that fields get added for the convenience of whoever receives the request. This guide helps you decide field by field, with a rule that still holds when someone at the company asks for one more.

There's only one rule, and it applies to every line: if I didn't have this information right now, would I handle the request differently? If the answer is no, the field can wait for the first reply.

The test to run on every field

Write next to each field the sentence that justifies it. Not “the sales team needs it,” but what actually changes: who the request goes to, with what priority, with what response. Fields that fail the test fall into three types.

• Data that's needed, but later. VAT number, full address, and tax code are needed when issuing a document, not when asking whether a job is doable. Asking for them right away assumes a commitment the reader hasn't made yet.
• Data that's useless to anyone. The “how did you hear about us” field gets filled in at random or left blank, and the answer doesn't change anything you'll do. If you really want to know, ask on the first call.
• Data you'd like but won't get. A budget entered in a form is almost always a convenient made-up number. It takes a conversation, not a dropdown.

What's left are the fields that genuinely change how the request is handled: contact details to reply with, a free-text description of the need, and the small amount that decides who picks up the request — the area, if you only work in certain provinces, or the type of business, if you have separate departments.

A form before and after

An example of reworking a quote-request form for a services company. The middle column shows why the field was originally added, the last one shows the decision made.

From eleven fields down to six, three of them required. None of the removed data was lost: it moved to after the first reply, once the person already has a reason to give it.

When different paths need different questions

If the same inbox receives requests that have nothing in common — a quote, support on an existing system, a job application — a single form forces everyone through questions meant for someone else. The solution isn't three separate forms, but one first question that opens the right path.

1. The first screen just asks what it's about, with two or three options written in the customer's words, not your department names.
2. Based on the choice, only the relevant fields appear: the system reference or installation date for support, the job description for a quote.
3. The last step collects contact details, which are the same for everyone.

This is only worth doing if the paths are genuinely different. If the specific questions amount to only one or two, a single form with one extra field stays simpler to maintain and faster to fill in.

The form's wording: labels, instructions, errors

A form gets filled in by reading. Labels, instructions, and error messages are content just like the rest of the page, and this is where people are lost most often for trivial reasons.

• The label sits above the field and stays visible while typing. Gray placeholder text inside the box disappears at the first keystroke: someone who gets distracted no longer knows what they were filling in.
• The instruction goes before the field, not after the error. If a reference number has a specific format, say so while they're typing, with an example.
• The error message says what to do, not what went wrong. “Invalid field” doesn't help; “Enter an email address, for example [email protected]” does.
• Mark the required fields, not the optional ones, and don't rely on color alone: someone who can't tell red from gray still needs to be able to read the error.
• Everything has to work from the keyboard, and every label has to be linked to its field: that's what lets a screen reader announce the right question.

One flaw needs fixing without debate: if the page reloads after an error and wipes out a description already written, almost no one rewrites it.

What happens after submission

The last field isn't the last step. Whoever sends a request has just handed over their contact details without knowing what will come back, and the confirmation page is the moment to tell them.

• Who responds and from which address, so the email isn't mistaken for spam.
• What happens before the reply, if an internal check is needed.
• What to do in case of urgency: the phone number, with the hours it's staffed.

Avoid timeframes you can't always meet. “We reply within an hour” becomes a problem the first Friday evening no one replies.

Verifying that requests actually arrive

When a long form is the right choice

The answer isn't always to remove fields. In some cases a more demanding request pays off, and brevity causes damage.

• When every request is costly to handle, such as a site visit, and off-target ones take time away from the others.
• When the request is already a formal process: a job application, a return, a sign-up. Whoever fills it in knows they need to provide that data and has it ready.
• When attachments are needed to respond: a drawing, a photo of a part. A longer form beats three back-and-forth emails.

The difference lies in who benefits from the field. If it helps respond better to that person, it can be asked. If it only fills an archive, it shouldn't.

What this guide doesn't cover

This guide covers what to ask for and how to word it. What happens to the request after it arrives — who it's assigned to, how to avoid losing it among email, phone, and messages, how replies are tracked — is an organizational problem and is covered elsewhere. The analysis of where the path breaks down, even before the visitor reaches the form, also has its own guide.