A quote-request form that asks for “Any relevant files” gives the buyer a second job: deciding what the estimator needs. One person may attach a photograph. Another may upload a complete project folder. A third may stop because they do not have a polished brief.
Make the request specific enough to help the business price the work. Explain which attachment is needed, what decision it supports and whether the buyer can continue without it. The best upload control cannot compensate for an unclear request.
The aim is a usable commercial enquiry. A file should earn its place in the form by helping the recipient understand or price the proposed work.
Decide what the attachment must establish
Start with the person who prepares the quote. Ask what they need to learn from the attachment and what they do when it is absent. That conversation often separates essential input from material that is merely convenient to have.
For an illustrative print job, an estimator might need the intended finished dimensions and a preview of the artwork to judge the requested service. A production-ready source file could be necessary later, after the scope and price are agreed. Requiring it at the enquiry stage may exclude a buyer who needs help preparing that file.
The GOV.UK file-upload guidance recommends asking people to upload something only when it is critical to delivering the service. Applied to quotation forms, that is a useful challenge: explain the decision the file enables before making the field mandatory.
Do not collect the largest possible package simply because storage is available. A focused request is easier for the buyer to fulfill and easier for the recipient to interpret.
Write the request around the job
Replace the generic label with the actual artifact: “Artwork preview,” “Photos of the installation area” or “Existing floor plan,” where those are genuinely relevant to the service. Then explain what the recipient will use it for.
For a fictional print service, an original upload module might read:
Artwork preview, if available
Attach a preview so we can assess the layout and the work needed before printing. A PDF, JPG or PNG is suitable at this stage. You can request a quote without finished artwork; describe what you need help creating in the project details.
The file types in that example are stipulated for the fictional service. A real business should list the types its team and upload system actually accept. Do not copy a broad file list into the interface if the recipient cannot open or evaluate everything on it.
Distinguish an example from a requirement. If a rough sketch is acceptable, say so. If a measured drawing is essential, explain which measurements it must show. A buyer should be able to judge readiness before starting the form.
Put technical limits before the file picker
Show the accepted formats, per-file size limit and any limit on the number of attachments before the buyer chooses a file. If the limits differ by artifact, attach the explanation to the relevant control.
A fictional form might allow one PDF up to 10 MB. The important design decision is that “one,” “PDF” and “10 MB” are visible before selection and agree with the server’s actual rules. A picker that appears to accept a file and rejects it only at final submission makes the buyer repeat work unnecessarily.
Explain whether a link can be used instead of an attachment if the business supports that option. A link to a public preview may suit some enquiries; it is not automatically a substitute for a file the estimator must inspect. Be clear about what access the recipient needs, and avoid promising that every third-party sharing service will work.
W3C’s form-instruction guidance recommends explaining formats and other relevant requirements. Keep these instructions visible after selection so the buyer can compare them with the file they chose.
Let the buyer see what will be submitted
Show the selected filename and a way to remove or replace it. If more than one attachment is allowed, keep the files individually identifiable. A message saying only “Files added” makes it difficult to catch the wrong version.
For the fictional print enquiry, the buyer might select an old artwork preview and then replace it with a revised PDF. The final review should show the revised filename without suggesting that both versions will be sent. If both remain attached, let the buyer identify which one is current.
Selecting a file and submitting the enquiry are separate actions. The interface should make clear whether the request has been sent. A successful upload indicator should not look like the final confirmation of the quote request.
Keep the attachment tied to the relevant project description. If a buyer changes the service type and the file is no longer appropriate, explain that relationship rather than silently deleting the attachment or submitting it under the wrong request.
Keep recovery specific and proportionate
The most useful error tells the buyer what prevented this file from being accepted and what to do next. A format problem, a size limit and an interrupted transfer need different explanations.
GOV.UK’s upload component includes separate guidance for wrong file types, oversized files, empty files and unsuccessful uploads. Use that specificity without claiming more than the system knows. If the transfer failed for an unknown reason, do not say the document is corrupt.
Preserve the written project details while the buyer corrects the attachment. If the file is optional, the form should offer the supported route to continue without it. If it is essential, explain an alternative way to complete the enquiry when one exists.
W3C’s notification guidance emphasizes clear feedback for successful and unsuccessful submissions. In this context, the buyer needs to distinguish a file attached to the form from an enquiry successfully received by the business.
Make the estimator’s response predictable
Tell the buyer what the attachment enables after submission. Does the team use it to prepare a quote, decide whether a site visit is needed or ask a more specific follow-up question? Those are different promises.
For a fictional service, “We’ll review your preview and contact you if we need a production file” sets a different expectation from “Your artwork is approved for printing.” The quote-request stage should not imply a production approval that has not happened.
If the business offers a response target, use the actual supported target and define the relevant conditions. Do not add a fast turnaround claim simply to make the form seem appealing. The recipient should be able to fulfill the expectation the page creates.
Review the request with imperfect inputs
Try the form with a buyer who has a finished file, a rough sketch, several versions and no attachment at all. Ask each person what they believe is required and what will happen after they submit. Then ask the estimator whether the resulting enquiries contain what is needed for the promised response.
This review may reveal that the business needs a clearer project question more than another file field. A photograph can show a space while leaving the intended dimensions or service scope unanswered. The attachment should complement the request, rather than become a substitute for explaining it.
The broader commercial-form guide covers field value and completion. For attachment-heavy enquiries, the decisive question is whether the buyer can supply the right material without guessing what the estimator wants. A well-written request settles that before the file picker opens.