A customer takes a photo of a damaged cupboard, adds it to your quote form and presses send. Your team receives their message, but the picture is missing. Or the upload fails and the customer has to start again.
For repair firms, installers and other businesses that assess work before quoting, those pictures can provide useful context. The upload needs to work from the customer’s phone through to the person preparing the reply.
Start by finding where the file disappears. Check selection, transfer, storage and staff access separately. Then fix the failed stage and repeat the whole enquiry. Increasing a file-size setting alone will not repair a format rejection or a missing CRM attachment.
Decide what the photograph needs to show
Before changing the form, agree what your team actually needs. A furniture repairer might ask for one wider view and one close-up of the damage. An installer might need a picture of the existing fitting and the surrounding space. These are examples, not a requirement to collect more images from every customer.
Explain that purpose beside the upload control. Tell people which formats you accept, how many files they can add and the size limit before they open their photo library.
Make photographs optional where your team can start a useful conversation without them. If an image is essential to assess the request, offer another workable route when uploading fails. Do not leave a prospective customer trapped between a required attachment and a broken upload.
Find the first point of failure
Reproduce the problem using a harmless test photograph and a clearly marked test enquiry. Record the device, browser, file format, file size and time of the attempt. Then follow these four checkpoints:
- Selection: can the customer find and select the picture? Does the form show the selected file?
- Transfer: does the upload finish, fail immediately or stop partway through?
- Storage: does the website record the enquiry and associate it with the correct uploaded file?
- Handover: can the staff member handling that enquiry open the right photograph from their normal inbox or CRM account?
If a preview appears but the file never reaches storage, investigate the upload itself. If the file is stored correctly but missing from the CRM, investigate that connection. A customer-facing success message is only one checkpoint.
Check phone-photo formats, not just a desktop JPEG
Testing with one small JPEG from your computer leaves an important gap. Apple’s current guidance explains that supported devices can capture photographs in HEIF format. A phone photograph is therefore not necessarily a JPEG. Apple also describes conversion through supported apps; renaming a file extension is not the conversion process.
Test both a picture chosen from the customer’s photo library and a newly taken picture. Check the actual file arriving at your website rather than assuming every device or selection route sends the same format.
Make the chooser and the server agree
The browser’s file picker and the website’s upload checks have different jobs. MDN explains that the HTML accept attribute guides file selection but does not validate the uploaded file. Server-side checks are still needed. Adding a format to the picker is not proof that your website can process it.
Ask your developer to reconcile the formats advertised on the form, those offered by the picker and those supported by the receiving system. If you accept HEIF or HEIC files, verify that any conversion, preview and staff viewing steps work too. If you do not, explain the supported alternative clearly and preserve the enquiry while the customer replaces the picture.
Keep an ordinary file-selection route
A camera shortcut can be useful, but customers may already have the right photograph. Give them a clear way to choose an existing file. Test the control on the phones your customers use, including cancelling the picker and replacing a mistaken selection.
Dragging a file onto a desktop panel should be an additional convenience. Keep a labelled file-selection control that also works with a keyboard.
Check per-file and total upload limits
A form may accept each photograph individually but reject the group when the customer submits. Ask your developer to document the per-file limit, permitted file count and total submission allowance, including any restrictions imposed before the form handler receives the request.
For a PHP-based website, PHP’s current configuration reference distinguishes upload_max_filesize from post_max_size. The latter limits the submitted POST data, including uploads, and must be larger than the individual upload limit. PHP also documents that an oversized POST can leave its normal form-data and file collections empty.
This is a reason to check the receiving system, rather than simply raising the number displayed beside the form. Ask the developer to identify the setting or service that rejected the attempt and align the advertised allowance with the complete route.
Use a sensible allowance for the assessment you need. Unlimited uploads are not necessary for a repair quotation. If images are resized or compressed, inspect the result: damage, fitting details and dimensions visible in the original must remain useful to your team.
Give customers a clear recovery route
An upload error should identify the affected picture and tell the customer what to do next. A message saying that a file exceeds the stated limit is more useful than an unexplained failure. A format error needs a supported alternative.
W3C’s form-notification guidance recommends clear success and error feedback, with instructions for resolving errors. Put the message near the relevant control and make it easy to find after submission.
Where progress or completion is shown dynamically without moving focus, W3C’s guidance on status messages explains how those updates should be available to assistive technology. A changing visual indicator alone is not a complete solution.
As an acceptance requirement, ask for the customer’s typed contact details and message to survive a failed upload wherever feasible. If they must reselect a file, say so explicitly. Distinguish a selected picture, an uploaded picture and a submitted enquiry. Only confirm the state the system has actually reached.
Keep uploaded photographs controlled
Fixing legitimate uploads should preserve the checks around incoming files. OWASP’s File Upload Cheat Sheet recommends layered protection: limit permitted types and sizes, validate files rather than trusting their supplied Content-Type, generate safe stored filenames and use controlled storage. It also recommends antivirus or sandbox checks where available.
Ask your developer how uploaded enquiry photographs are kept separate from publicly accessible website assets, who can retrieve them and how processing tools are maintained. A difficult-to-guess file address is not a substitute for access checks.
Agree a practical deletion process for temporary uploads and completed enquiries. Give customers a short instruction to photograph only the relevant area, avoiding people or unrelated documents. Collect the information your team needs to assess the work.
Verify the inbox or CRM handover
Decide how staff should receive the images. That might be an attachment, an authenticated link or a file stored against the enquiry record. Treat this as a requirement to test, rather than assuming that adding an upload field automatically makes the file available everywhere.
Submit two different test enquiries with visibly different photographs. Check that each file belongs to the correct enquiry and that a colleague can open it using their ordinary permissions. Testing only from an administrator’s account can miss a staff-access problem.
If your process uses a link, test it from the actual notification and again after the normal delay before someone handles a quote. If processing happens later, decide what staff see while it is pending and how a failure reaches the responsible person.
The useful outcome is an enquiry your team can act on, with the intended photograph available. Our web development and integration service covers the connections and failure handling behind these customer journeys.
Test the difficult cases before accepting the fix
Agree the supported formats and limits first, then use this short acceptance checklist. Use test images without customer information.
- A small supported image completes the whole journey.
- Each advertised format works from a relevant phone or computer, including any required conversion.
- A file close to the permitted size succeeds; one above it produces a useful error.
- The maximum permitted group of files succeeds together, while an excessive selection is handled clearly.
- An unsupported file is rejected with a recovery instruction.
- Cancelling, replacing and removing a selection leaves the form usable.
- A failed or interrupted upload gives a clear next step and preserves typed details where feasible.
- Keyboard and screen-reader checks cover selection, errors and completion feedback.
- The correct staff member can open the correct files from the inbox or CRM, while an unauthorised visitor cannot retrieve them.
- An optional upload can be omitted without blocking the enquiry.
Ask for evidence covering the customer-facing result and the staff-facing record, plus a written account of the final formats, limits and storage route. That gives you something concrete to check after future website or integration changes.
Make useful photos part of a dependable enquiry
If customers rely on photographs to explain the work, start with one genuine submission route and follow it all the way through. Repair the first failure, then verify the remaining stages. The form should make it straightforward to send useful context and clear what happens when a file cannot be accepted.
If your quote form accepts photographs but your team cannot reliably use them, talk to BuzzBoost about checking the upload and enquiry handover. Bring the page URL and a harmless example file that reproduces the problem.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
