The damage photos come back too dark, too close, or missing the one angle the adjuster needs

The observable is always the same. The adjuster opens a file that has 6 photographs attached and cannot work it: 2 are too dark to read, 3 are so close that nothing around the damage is visible, and the one angle that would settle the question was never taken. A re-request goes out, the claimant has left the scene or the vehicle has been moved, and the file is 3 days older before anyone has looked at anything.

The instinct is to treat this as a claimant problem and write better instructions. It is a capture problem, and the evidence for that is available today in your own data — provided you stop looking at the overall rejection rate, which is an average across at least 2 populations that fail for unrelated reasons.

Split the rejects by capture path before touching a screen

One table settles which of the causes below you actually have. It takes an afternoon and it does not require any change to the product.

1. Pull every claim from the last 30 days where a photograph was re-requested, and tag each request with a single reason: too dark, blurred, too close, wrong subject, missing angle, or unrenderable.
2. Join each rejected image to its capture path — in-app camera, device gallery or file picker, email attachment, or supplied by a third party — and to a device class: iOS, high-end Android, low-end Android, desktop browser.
3. Compute the rejection rate per capture path per device class rather than overall. The overall number is meaningless; a rate of 8 percent on the in-app camera and 41 percent on gallery uploads is a finding you can act on.
4. Compare the photo count per claim against what the loss type actually requires. If claims of the same peril arrive with anywhere between 2 and 14 images, no shot list is being enforced, whatever the guidance says.
5. Inspect the stored files rather than the thumbnails: pixel dimensions, byte size, format, orientation flag, and whether capture metadata survived. A pipeline that resizes everything to 1024 pixels wide is throwing away the detail the adjuster needed, and no amount of claimant coaching will fix it.
6. Read the exact wording the claimant saw at the moment of the first request. Not the training material — the string in the interface, which is frequently something like "add photos of the damage".

This is the same discipline as building a drop-off table before redesigning a form, and for the same reason: the screen everyone wants to change is rarely the screen that is failing. The abandonment version of the argument is in claimants who start the online loss report and phone in anyway, and a weak-connection photo upload is one of the steps that shows up in both analyses.

Five reasons a photograph arrives unusable

The last row is worth pausing on because it is entirely your own doing. Modern iPhones capture in a high-efficiency format by default, and plenty of claims systems and document stores still cannot render it, so a technically excellent photograph arrives as an unreadable attachment. The same pipeline frequently downscales for bandwidth, which is defensible for a thumbnail and indefensible as the only copy you keep. Convert on the server, keep the original bytes, and derive everything else.

The gallery upload is a different problem entirely

A live camera capture is an event you witnessed. A gallery upload is a file, and a file has no inherent connection to this loss, this vehicle, or this week. That difference is not about honesty — most gallery uploads are innocent, from claimants who photographed the damage before opening the app — but it changes what the image can be relied on for.

• Capture metadata is unreliable on this path. Timestamps and location may have been stripped by the platform on share, may belong to a different photograph, or may simply be absent. Treat their presence as a bonus and their absence as normal, and never build a rule that depends on them.
• Your own capture context is reliable. When the photograph is taken inside your app you can record the device time, the coarse location, the claim and slot it was captured against, and the app build, and store all of that as your own metadata rather than the file's.
• Live capture is where validation is possible at all. You cannot re-shoot a gallery image, so a quality check on that path can only reject, which is the least useful thing to do to somebody who has already left the scene.
• Both paths need to exist. Refusing gallery uploads outright loses the genuinely useful case of a photograph taken at the moment of the loss, in better light, before the vehicle was moved. Make the required slots live-capture and let everything else in as supplementary evidence.

Which fix your table points at

Each rejection reason resolves to one of 4 interventions, and they are not interchangeable. Work down until one matches the reason that dominates your split.

1. Quality reasons — blur, exposure, motion — go to capture-time validation. Check in the viewfinder, warn before the shutter, and re-prompt in place while the claimant is still standing in front of the damage. Rejecting after upload converts a 5-second fix into a 3-day one.
2. Completeness reasons — a missing angle, no establishing shot — go to a named shot list. Not a paragraph of instructions: discrete slots, each with a one-line label, an example image, and a visible completion state, so the claimant can see that 3 of 6 slots are filled.
3. Subject and provenance reasons — wrong vehicle, old image, screenshot — go to path restriction plus your own capture metadata. Guidance does not fix this, because the claimant believes they have complied.
4. Renderability reasons — format, orientation, resolution — are yours alone. Normalise on the server, keep the original, and stop asking claimants to solve a problem they cannot see.
5. Only when the claimant has genuinely left the scene does a structured re-request make sense: name the specific slot, show the example, and deep-link straight back into that slot rather than to the top of the claim. A re-request that reads "please send clearer photos" is a coin toss.

Order the shot list so the wide establishing frame comes first. It is the most frequently missing image and the one that does the most work, because it is what proves where every close-up was taken — the whole vehicle before the corner, the whole room before the ceiling stain. Claimants skip it because the damage is the point, and a slot that will not tick until it is filled is the only reliable remedy.

What better photographs will not fix

Some limits are physical. Damage that is internal, mechanical or hidden behind a wall is not photographable at first notice by anyone, and no capture flow will change that. A vehicle already towed, water already extracted, or a fire scene made safe has lost its evidence before the app was opened. Building a flow that behaves as though those cases are failures teaches claimants that the app is unreasonable.

The other limit is about what images are allowed to decide. Photographs are evidence for a human judgement, and a set of clean images does not turn a complex loss into a simple one — the routing question that low-severity files landing in the complex queue works through in detail. Photo completeness is a legitimate routing input; photo-derived damage assessment deciding a file on its own is not.

Two operational side effects are worth designing for while you are in here. Photographs re-sent by email to a general inbox routinely open a second file for the same event, so route inbound images by claim reference rather than by sender — the duplication mechanism examined in one loss opening two claim numbers. And a re-request pauses nothing: your acknowledgement and contact obligations keep running while you wait for photographs, which is one of the ways several clocks end up running on one claim file at different speeds.

Every unusable photograph is a decision that was available on the device and got deferred to an adjuster 3 days later, by which time the thing that needed photographing has been towed away.

None of this is a model problem, which is the part teams find surprising. It is viewfinder work, a slot-based capture flow, an upload that survives a bad connection, and a normalisation step on the server — the sort of scope that lands as an MVP and product build with a native capture surface, because a browser file input cannot do the checks that matter. Where it sits in the wider intake sequence, alongside notice capture, triage and the clocks, is covered across claims intake, FNOL and triage, and the broader view is in our insurance and claims work.

• FNOL
• claims intake
• mobile capture
• debugging