When every quote request needs another round of questions
A potential customer submits your website form, but you still cannot tell what service they need or whether they are in your area. You reply with questions, wait for answers and repeat. Adding more required fields seems sensible, until the form starts looking like a job application.
The goal is not the shortest possible form or the most detailed one. It is enough information to make your next decision without asking customers to complete work that belongs later. Here is how to choose what stays, what becomes optional and what can wait.
Define what you need to do after submission
Finish this sentence: “With these answers, we should be able to ___.” Perhaps you need to confirm service coverage, arrange a consultation or decide whether a site visit is necessary. Use that next action to judge every question.
An initial enquiry is not a complete project brief. A quote request is also not an instant estimate: if pricing requires measurements or an inspection, explain that before the form. A button labelled “Request a quote” should not suggest that a finished price will appear immediately.
For a hypothetical fence contractor, the first decision might be whether the project fits their service area and type of work. Town, repair versus replacement, a short description and contact details could support that decision. Exact measurements and material selections might wait until a conversation.
Make a simple field-review worksheet
GOV.UK recommends a question protocol: a record of why each question is asked and how the answer will be used. Adapt that principle to your business rather than copying the structure of a government form.
Create five columns on paper or in a spreadsheet: question; decision it supports; needed before the first reply; can the customer reasonably answer it; final choice. Mark each question “required now”, “optional”, “ask later” or “remove”.
For example: “Full street address; plan a site visit; no, because we confirm suitability first; yes; ask later.” If nobody can name a decision an answer supports, that is a reason to remove the question, not simply make it optional.
Structuring forms - Service Manual - GOV.UK
Review contact, service and location fields
Contact details: ask for the method you need for the next step. If you reply by email, requiring a phone number too needs a reason. If a call is essential, say so. A name can help personalise your reply; a mailing address usually serves a different purpose.
Service required: use descriptions customers recognise rather than internal department names. Offer “Not sure” when uncertainty is a legitimate starting point. Do not make someone diagnose a technical problem before they can ask for help.
Location: decide whether a town or postal code is enough to check coverage. Request the full address immediately only if it changes your first response. Explain any service-area restrictions beside the field or before the form, rather than leaving customers to discover them after submitting.
Designing good questions - Service Manual - GOV.UK
Review description, timing, budget and attachments
Job description: replace an unexplained “Message” box with a helpful prompt. For the hypothetical fence contractor: “Tell us what needs repairing or replacing and roughly how much fencing is involved, if you know.” Do not require precise measurements customers cannot safely obtain.
Timing: distinguish a preference from a firm deadline. “When would you ideally like the work completed?” invites a different answer from “Is there a date the work must be finished by?” Include flexibility if your scheduling decision depends on it.
Budget: ask when the answer changes the options you can offer or whether the project is a fit. Explain that purpose. Ranges and a “Not sure yet” option may be more realistic than requiring an exact dollar figure. If you have a genuine minimum project charge, disclose it before asking customers to enquire.
Photos and documents: make attachments optional unless they are necessary for the first assessment. Explain what would help and ask customers to avoid including people, private documents or unrelated personal information. Do not require an upload merely because the website supports it.
Designing good questions - Service Manual - GOV.UK
Forms Tutorial | Web Accessibility Initiative (WAI) | W3C
Test the form from the customer's side
W3C guidance calls for clear labels, instructions and feedback. Identify required and optional fields explicitly. Keep labels visible while someone types, and make error messages explain the correction needed, such as entering an email address in the expected format.
Complete the form on a phone and using only a keyboard. Deliberately miss a required answer. Can you find and fix the error without losing other answers? After submitting, check that the confirmation clearly says the request was received and explains the next step. State a response timeframe only if you can meet it.
Separately, verify that the enquiry reaches the right inbox or business system. A reassuring screen does not prove your team received the message.
Forms Tutorial | Web Accessibility Initiative (WAI) | W3C
User Notification | Web Accessibility Initiative (WAI) | W3C
Choose a proportionate change, then review it
Start with wording, clearer prompts and removing unnecessary requirements. Questions that appear only when relevant can help with distinct service types, but add implementation and testing work. Custom website development may make sense for that complexity or difficult accessibility problems; a form review alone does not justify rebuilding your website.
After making changes, review subsequent enquiries for missing information, suitability and clarification exchanges—not submission totals alone. Note other changes, such as advertising or availability. A small sample cannot prove a conversion improvement, but repeated misunderstandings can show which question needs attention next.