What should a website enquiry form ask?

A first enquiry form should collect enough information to make a useful response possible. For many service businesses, that means a way to reply, the service needed and a short description. Every extra question should have a reason: it helps you check suitability, prepare a quote or route the message to the right person.

This is a starting point, not a universal field list. A local gardener, a software studio and an emergency service need different first conversations.

Begin with the reply

Ask for a name and one reliable contact route, usually email or phone. If you ask for both, explain why. A service choice can help route the enquiry when the business offers distinct work. A free-text box lets someone describe what they need in their own words.

For a visiting service, a town or postcode may help determine coverage. Ask for the level of location detail you need now. A full street address may be unnecessary until a visit is arranged. If a job has timing constraints, a simple when do you need this? field may be more useful than a long set of scheduling questions.

Mark fields as required only when you cannot take the next step without them. If a form asks for a budget, explain what the answer is used for, or consider leaving it optional. Avoid asking for sensitive information in a general enquiry box unless the workflow truly requires it and is designed to handle it safely.

As a worked example, an enquiry for pest control might need a postcode to check coverage, a pest or problem description, urgency and a contact route. A photograph may help assess the situation but should be optional if the customer cannot provide one. Ask for a full address when arranging a visit, rather than automatically collecting it from everyone who is only asking a question. These are proposed field choices; the operating business should decide which are necessary.

Match the form to the follow-up process

The form is only the start. Decide who receives the message, what information appears in the notification and what happens when the usual person is away. Test a submission from a phone and confirm it arrives in the right inbox. Check that the success message tells the customer what to expect without promising a response time you cannot meet.

Compare that with a software project enquiry. It may need the business problem, current process, people involved and a target date, but an exact technical specification would be unreasonable at first contact. In both cases, the form should collect what changes the next response. The operator can ask for detail later when there is a real conversation.

A quick field review

Before launch, go through each question and ask: What will we do differently because we have this answer? If no one can explain the use, remove it or make it optional. Then submit three test enquiries: a normal request, a vague request and one from a phone. Check the confirmation, notification and reply path for each.

If the business needs photographs, job status, assignment and recorded follow-up, the next step may be a structured intake workflow rather than a longer form. Start with the information needed for a good first response and add complexity only where it helps.