What Should a Tradie Website Quote-Request Form Ask?

A tradie website quote-request form should collect enough information to decide whether the job fits your business and how to follow it up. A practical starting point is a name, a usable reply method, the general job location, the type of work and a short description. Add timing or photographs when they help assess the request.

The right fields depend on the work you accept and the way your team responds. A repair enquiry and a planned renovation do not need identical questions. Start with the decision your staff must make, then justify each field against it.

This guide focuses on website enquiries, rather than the document you send when quoting for a job. It supports our Tradie Websites in New Zealand pillar guide. Omniva Digital publishes this resource and provides website services; the examples below are illustrative, not measured conversion results.

Before choosing fields, decide what happens after someone presses the button. Will you review the job, call for details, arrange an assessment or offer a booking? These are different commitments. Use a button such as “Request a quote” or “Send an enquiry” when a staff member still needs to assess the work.

Explain the next step beside the form. State the response arrangements your business can actually maintain, including relevant operating hours. Do not promise an instant quote, a confirmed appointment or a same-day visit if submitting the form does not deliver that result.

If the form is unsuitable for urgent work, say so clearly and provide an appropriate contact route that your business genuinely monitors. A phone number alone should not imply round-the-clock availability. Keep the enquiry journey consistent with the services and operating area described on the rest of the website.

For each proposed question, ask: “Which decision will our team make using this answer?” If nobody can explain that, consider removing it or asking later.

• Name: lets your team address the person and distinguish enquiries.
• Reply method: collect the contact details needed to respond. Decide whether one channel is sufficient instead of automatically making both email and phone mandatory.
• General job location: a suburb or town may be enough to check service-area fit initially. Ask for a full site address when the workflow needs it.
• Type of work: use a short list of services you actually provide, with a suitable alternative when a customer is unsure.
• Job description: ask for the main problem or desired work in everyday language. Give a short example of useful detail.
• Timing: distinguish a requested timeframe from a confirmed appointment. Include an “unsure” option where appropriate.
• Photographs: make these optional unless you have a clear operational reason otherwise, and explain what they can help you assess.

A budget question can help with some larger projects, but it should serve a real screening or planning decision. Do not add it simply because another website does. Customers may not know a reasonable allowance before discussing the scope.

Keep required fields identifiable. A longer form is not automatically better qualified, and a shorter form is not automatically more useful. The practical test is whether suitable customers can complete it and your staff can act on the information.

The following examples are fictional design briefs. Adapt them to the services, staffing and response process of your own business.

Example one: a repair enquiry. A small trade business wants to check whether a reported issue falls within its services and operating area before contacting the customer. Its initial form asks for a name, preferred reply details, suburb or town, a short description and the requested timeframe. An optional photograph may help explain the visible issue, but the form does not ask customers to investigate it or carry out a technical diagnosis.

The page provides the business's actual contact arrangements and explains whether staff review website requests only during stated hours. The enquiry does not reserve a visit. If the business needs a precise address or further information, staff obtain it during follow-up through their agreed process.

Example two: a planned renovation project. A different business needs to understand the type of project, general location, stage of planning, intended timing and a brief description before deciding who should respond. It may offer an optional photograph or relevant drawing upload if someone is responsible for reviewing those files. A budget range belongs in this form only if it informs a useful next decision.

Neither example needs to collect every detail required for a final quote at the first contact. Separate initial suitability checks from the later site assessment and quoting process.

An illustrative confirmation is: “Your enquiry has been received. We will review the details and contact you using the information provided. This request does not confirm a booking or price.” Use this only when receipt has actually been established, and add response timing only if it reflects your real process.

The New Zealand Privacy Commissioner's collection guidance explains that personal information should be necessary for a lawful business purpose and that people should be told about its collection and intended use. Put a clear explanation and an accessible privacy-statement link where people submit their details.

For this form, document why each personal detail is needed, who will receive enquiries and what happens to the information afterwards. Make sure the published explanation matches the real process, including any systems used to receive or manage submissions.

For photographs, explain what is useful: for example, a view of the relevant work area where it can be taken safely. Ask people to avoid unnecessary faces, unrelated personal documents or other private details. Do not encourage them to take risks to obtain an image.

Agree supported file types and size limits with the developer, show these before upload and provide a way to enquire without photographs. Decide which staff can access attachments and how files will be handled and removed under your business's retention process. Do not collect files merely because an upload control is available.

Use visible, understandable labels such as “Job suburb or town” and “Tell us about the work”. Placeholder text inside an empty box can disappear as someone types, so it should not carry the only explanation. The W3C guidance on form labels describes associating labels with their controls so people can identify and use them, including with assistive technology.

Explain unfamiliar choices, identify optional questions and keep examples short. Check that fields are usable on a phone and that the customer can move through them with a keyboard. A technical field name in a database should not become a confusing customer-facing label.

If an entry needs correction, say which field has the problem and how to fix it. For example, explain that a reply address is missing instead of showing an unexplained “Invalid submission”. Preserve useful information where possible so the person does not have to restart. The W3C guidance on form notifications covers understandable error and success feedback.

Make the confirmation accurately describe the result. A request being accepted by the website is different from staff reviewing it, booking a visit or agreeing a price. If submission fails, explain the available next step and provide a genuine alternative contact method.

Before launch, agree who receives submissions and who checks that they arrive. Use clearly labelled test information and verify the agreed destination, whether that is an inbox, a customer-management system or another workflow. Seeing a success message in the browser is not enough to confirm that the team can find the enquiry.

• Submit a valid request and check the received details, including any supported attachments.
• Leave a required field empty and check that the error is understandable and the useful entries remain.
• Try the form on a phone and with a keyboard, including choices and upload controls.
• Check what happens when a file is unsupported or too large, if uploads are included.
• Confirm that the person responsible can locate the submission and use the supplied reply details.
• Check the wording of the confirmation and the available contact alternative.

Ask the developer how spam protection and submission failures will be handled without unnecessarily obstructing legitimate customers. Record who maintains that protection and who investigates missing submissions. These are checks to carry out on your own implementation; this article does not certify a particular form.

Assign a staff role to review new requests, clarify missing details and record the next action. If the website describes response hours, make the staff process match them. A well-labelled form cannot compensate for an unowned inbox.

Review form activity alongside actual follow-up. Separate attempted submissions, accepted submissions, enquiries delivered to the team and enquiries that fit the work you accept. Decide how you will identify test requests and spam so they do not distort the review.

For a simple fictional example, five suitable requests out of eight genuine delivered enquiries would be 62.5% suitable. That is arithmetic, not a benchmark or forecast. Record why the other three were unsuitable before changing the form. The underlying issue could be unclear service-area copy rather than a missing mandatory field.

A tap on a phone link does not establish that a call connected, and a form submission does not establish that a job was won. Use the evidence your systems actually provide. Improve the questions, page copy or response process around the specific gap you find.

Write down the accepted services and operating area, the next decision after submission and the person responsible for follow-up. List each field with its purpose and required or optional status. Include upload rules, privacy wording, confirmation and error messages, the delivery destination and the tests needed before launch.

Agree how the team will check delivery after website or email changes. Keep account access and maintenance responsibilities clear, and review the form when your services or response arrangements change.

For the wider website plan, return to our tradie website guide covering planning, costs and better enquiries. If you want Omniva to help scope the build, explore our New Zealand tradie website service and describe the enquiry workflow your business needs.