A homeowner in Tacoma wants to discuss a remodel. They know which room feels wrong and what they would like to change. They may not know the materials, measurements, budget, or construction schedule yet.
Your quote-request form needs to work with that level of knowledge. Ask enough to understand the request and reply usefully. Save questions that depend on a site visit or a longer conversation for that stage.
For a contractor serving Pierce County, the first decision may be straightforward: is this work you handle, in an area you serve, and can you reach the person who asked? Build the form around those decisions.
Decide what the request actually starts
A quote request might begin a conversation, allow the team to assess service fit, or lead to arranging a visit. Explain which one applies before asking the visitor to fill anything in.
For example, a remodeler could describe the form as an initial project request, with scope and next steps discussed afterward. That wording should match how the business operates. Sending a form does not establish a price or reserve an appointment unless the actual system and process do that.
The GOV.UK guidance on structuring forms recommends knowing why each question is needed and how its answer will be used. Apply that test to your own workflow: who reads this answer, and what decision does it help them make?
Start with a seven-field example
Here is an email-first starting point. These seven fields are a design recommendation, not a required standard or a proven ideal count.
- Your name. Required in this example. One name field gives the team someone to address without separating first, middle, and last names.
- Email address. Required here because the first reply is by email. Choose a contact route the business actually uses.
- Phone number, optional. Explain whether the team may call about the project. If telephone contact is essential to your process, make that clear and reconsider whether email also needs to be required.
- Project town or ZIP code. Use this to check service-area fit. A University Place project can be identified without asking for the full property address immediately.
- What work are you considering? Offer services the business really handles, such as a kitchen remodel or an addition. Include a way to say “Not sure” when the visitor cannot choose a category.
- Tell us briefly about the project. Ask what they want to change and what is there now. A short explanation should be enough to begin.
- When are you hoping to start? Optional. Broad answers such as “Still exploring” or “Flexible” let someone describe their plans without inventing an exact date.
Use the answers to prepare the first response. If a field has no effect on that response, discuss removing it or asking later.
Give optional questions a reason
A budget question can help when it changes which work the business can consider. Explain its purpose, use appropriate ranges, and offer “Not sure” if you can discuss early ideas. The ranges must come from the business, not a designer’s guess.
Photos may help explain a space, but an upload should be optional unless it is necessary for the next step. Only offer it when the website supports uploads and the team has a place to review them. Explain the limits and ask visitors to leave unrelated personal information out of the image.
Detailed measurements, drawings, and a full address can wait when the team does not need them to assess the first request. Property access codes and payment details do not belong in this introductory example.
Write questions people can answer
“Tell us what you would like to change” is easier to answer than “Provide complete project specifications.” A helpful hint might be: “Which room or area is involved, and what would you like it to do differently?” This is example wording, not a request for a detailed scope or a binding specification.
Keep the label visible while someone types. W3C’s guidance on labels explains how labels identify controls and connect them to assistive technology. Its form instructions guidance also explains why placeholder text cannot replace labels or persistent instructions.
Mark optional questions beside their labels. If you show several work-type choices, give the group a clear question. Developers can use a fieldset and legend to associate related controls, as described in W3C’s grouping tutorial. Pictures can support a choice, but the words still need to explain it.
Make errors and completion useful
Test an incomplete request. The form should identify the field that needs attention and explain the correction in text. An email error should help the visitor fix the address, and their project description should still be there afterward.
Then test a permitted submission through to the destination the business checks. The confirmation needs to reflect what the system has verified. “Request received” is appropriate only after receipt is confirmed. A failed send needs an honest failure message and another usable contact route.
W3C’s notification guidance covers clear errors and success feedback. Add your real next step to that feedback. Publish a response window only if the business has agreed to it and can support it.
Connect the form to the marketing question
The service page before the form should explain the work, show relevant examples, and describe the actual service area. The form can then continue that conversation. Umanifest’s construction website approach and marketing strategy service look at those decisions together.
Review what happens after launch. Which requests fit the business? Which missing details require another email? Are customers choosing “Not sure” because the categories are unclear? A completed form and a suitable project are different measures. Use the team’s real observations to decide what to change.
Pick one question on your current form. Write down who uses the answer and what they do with it. If nobody can explain that, you have a useful place to start.
The cover illustration comes from Umanifest’s fictional Stonehaven demonstration. It is not a photograph of a completed client construction project.
Sources & further reading
- GOV.UK: structuring forms
- W3C: labeling form controls
- W3C: form instructions
- W3C: grouping form controls
- W3C: form feedback and notifications
Published by Umanifest with AI-assisted research and writing. External standards and tools can change; sources are provided so you can check the current guidance.