A service business contact form needs a way to reply, a description of the request and any detail required to route it. Start there. Add another required field only when the first response genuinely depends on it. A short form that leaves the business guessing is not useful; neither is a form that demands a complete project specification.
Work backwards from the first reply
Imagine three enquiries that arrived this week. What would you need to send each person a useful response? For a general website project, that might be a name, email address, current website and a short description of the problem. For a vehicle service enquiry, the shop may need the vehicle details before discussing options.
Separate information needed to start the conversation from information needed to finish the job. A complete address, long budget breakdown or file upload might belong later in the process.
A field-by-field starting point
- Name: enough to address the person naturally. Decide whether separate first and last names serve a real purpose.
- Reply method: request an email address or telephone number according to how the business follows up. Explain when both are necessary.
- Type of request: useful when different services need different handling. Include a plain “Something else” option.
- Relevant context: a website URL, vehicle description or other detail tied to the request.
- Message: leave room for the customer to explain the situation in their own words.
For example, the N3 Sales contact page distinguishes remote start quotes, radios, repairs and fitment questions. It also offers a vehicle field. Those are visible examples from a site I built, not evidence that the same fields suit every business.
Make the instructions visible
Keep a label beside each field. Placeholder text disappears when someone types, so it should not carry the only explanation. Mark required fields consistently and show a useful error next to a field that needs correction. “Enter an email address” helps more than a general “Invalid submission.”
The W3C forms tutorial covers labels, instructions, validation and feedback. These are good checks for the experience of completing the form, beyond its visual styling.
Explain what sending the form actually does
For an enquiry form, say that the business will review the request. Do not imply that pressing Send books an appointment or confirms a price unless the system actually does that. If you publish a response time, make sure the business can support it.
Provide another contact route for someone who cannot use the form. Also decide who is responsible for watching the receiving inbox and what happens when that person is away.
Test delivery, not just the button
During an agreed test, submit a clearly labelled message, check the confirmation screen and verify that the message reached the intended recipient. Check the reply address, required-field errors and the narrow-screen layout. A successful-looking screen alone does not prove that an enquiry was delivered.
For a more detailed project request, read how to write a useful project brief. If the current enquiry process needs work, describe it to NSDT.