A useful quotation form gives the estimator enough information to choose the next step. That could be a call, a site visit, a request for measurements or a written quotation. Collecting more fields is not automatically better: every question should support a real decision.
Photographs introduce upload, storage and access requirements. Plan the customer experience and staff handover together.
1. Decide what the form promises
Choose whether the visitor is requesting a callback, an estimate, a survey or a confirmed appointment. Make the confirmation describe that exact action. A submitted request should not look like an accepted booking if someone still needs to check availability.
Similarly, photographs may help preparation but cannot establish every condition at the property. State when an inspection or additional information is needed before the business can quote. Use wording that matches your actual process rather than promising an instant price you cannot reliably produce.
The existing trades website guide covers presenting the work itself. This brief concerns what happens when a visitor requests it.
2. Give every field a purpose
Review the proposed form with the person who prepares quotations. For each field, ask what decision changes when the answer is known.
| Proposed field | Decision it supports | Requirement to settle |
|---|---|---|
| Job type | Route the request to the right person | Use categories the business actually handles |
| Area or postcode | Check whether the location is served | Decide whether an approximate area is enough initially |
| Contact details | Arrange the next conversation | Ask for the contact method you will use |
| Short job description | Understand the customer's request | Give a specific prompt rather than an empty box |
| Photographs | Assess visible context | Decide whether they are optional and explain useful views |
| Preferred timing | Check urgency and availability | Distinguish a preference from an agreed date |
Do not require a full address, detailed measurements or a budget merely because a template includes them. They may be appropriate for your process, but the reason should be clear.
W3C's validation guidance recommends identifying required inputs and also validating data on the server; browser checks alone do not establish security.
3. Specify the photograph experience
Explain supported formats, file count and size limits before the customer chooses files. Agree those limits with the developer and estimator rather than copying arbitrary numbers from another business.
A good acceptance brief asks for:
- A visible selected-file list with a remove or replace option.
- A useful error explaining which file failed and how to proceed.
- Preservation of the written description when an upload fails.
- A clear way to send the enquiry without optional photographs.
- An alternative contact route when the customer's device cannot complete the upload.
Ask customers to photograph the relevant work area, without unnecessary people, documents or personal details. Decide who can access those files and how the business will manage them. Customer submissions should not automatically become public portfolio images.
4. Include upload handling in the quotation
The developer's scope should cover more than appearance. OWASP's upload guidance recommends multiple controls, including permitted file types, size limits, generated filenames, content checks and controlled storage. A filename extension or supplied content type alone is insufficient.
As a buyer, request an explanation of where files live, who can retrieve them and what happens when a file is rejected. Ask who maintains that component after launch. Ask for an understandable operating process.
5. Design the handover to the estimator
For a hypothetical kitchen-fitting enquiry, staff might need the area, job description and photographs before arranging a measurement visit. The form should produce one request record with an identifier, received time, status and assigned person. This is an illustrative workflow, not a reported Nolixia customer project.
Separate saving the enquiry from sending an email notification. If the email fails, staff should know where to check the request register. Define which record is the working source of truth and how a request becomes reviewed, awaiting information, quoted or closed.
W3C's notification guidance supports clear success and error messages. The success screen should tell the customer what was received and what happens next, without inventing a response promise.
6. Agree acceptance tests before building
Copy this matrix into the brief and agree the expected behaviour before development. These are proposed acceptance conditions, not tests already passed by a Nolixia customer system. Use files and contact details you control.
| Test case | Customer outcome to agree | Record and staff check |
|---|---|---|
| Permitted phone photograph and complete details | A clear acknowledgement of the request, not an unagreed booking | One request contains the agreed details and staff can open its permitted image |
| Unsupported or oversized file | Identify the rejected file, preserve the written details and explain an alternative | An invalid file is not accepted; any request sent without an optional photo is clearly identified |
| Missing required answer | Identify the field and how to correct it | Do not represent an incomplete request as successfully received |
| Interrupted connection | Explain uncertainty or failure without an invented success | Check the request register before repeating the test |
| Double-tap or repeated delivery | A usable confirmation without encouraging another submission | No unintended duplicate request or quotation task |
| Notification fails after the request is saved | Do not imply that staff have read or confirmed the job | Staff can locate the saved request and the agreed exception owner can handle the failed notification |
| Unauthorised person follows an image link | No access to a private customer file | Verify access controls using an approved test account |
Add the observed result, evidence, owner and Pass, Fail or Investigate status for every row. A successful-form screenshot does not verify the customer message, saved request and staff handover together. For downstream assignment and repeated delivery, use the website-to-CRM test checklist.
Scope your quotation workflow with Nolixia
Contact Nolixia with the types of jobs you quote, the information your estimator needs and where requests should arrive. We can assess a suitable form and handover scope within our website and integration services. Describe the upload requirement in your initial message. Review the smart-form options as a starting point for that discussion; file handling and integrations still need an agreed scope.
