Claim Submission Apps with Interactive 3D Vehicle Models

Summary

We build guided claim submission applications in which a person reports vehicle damage by marking it on an interactive 3D model of the car. This kind of engagement covers the browser-based 3D interaction layer, the step-by-step submission wizard, photo capture bound to specific parts, integration with the claims automation back end, and repair facility selection. The output is a structured claim record rather than free text and unlabelled images.

The Challenge

First notice of loss is where claims data quality is won or lost. A free-text description of damage forces an adjuster to interpret, call back and re-key, and unnamed photographs say nothing about which component each one shows. Structured capture means every tap has to resolve to data the claims system already understands - a modelling problem before it is a rendering problem.

The runtime environment is hostile: a phone at the roadside, on a mobile connection, held by someone who has just had an accident. Untuned 3D assets exported straight from an authoring tool are far too heavy for mid-range devices, meshes left unnamed make part mapping guesswork, and a damage vocabulary invented by the build team rather than agreed with the claims side produces records adjusters cannot use. Connectivity drops mid-submission, and without a resume path the person starts again or gives up. A single body style rarely suffices either, so covering sedans, hatchbacks, pickups and SUVs demands an early decision about shared taxonomy against separate models.

The Solution

The 3D interaction layer

The model is rendered in the browser with WebGL through three.js, from source geometry authored in a modelling tool and exported for the web.

• Asset budget - reduced polygon counts and compressed textures so first paint happens on a mobile connection, using mesh compression and a compact glTF payload.
• Part-level picking - each selectable component is a named mesh mapped to a canonical part identifier, so a tap resolves to a part code rather than a screen coordinate.
• Damage taxonomy - selecting a part opens only the options valid for it: gouged or flat for a tyre, cracked or shattered for glass, scratch or dent with size bands for a panel.
• Photo binding - camera capture attaches to the selected part, so evidence and the damage assertion stay linked.
• Fallback - a diagram-based path for devices that cannot run WebGL.

Wizard, integrations and downstream data

Submission moves through defined steps: contact details, vehicle information, photographs, then damage marking. The completed claim is pushed into the claims automation back end and queued for loss adjustment, so the payload matches that system's schema exactly - policy reference, loss date, part codes, damage severity, image references and geolocation. Notification of the estimate returns by email or SMS, after which the person requests payment or selects a repair facility, ranked by distance from the loss or home location and routable on an embedded map. A satisfaction survey posts back with the claim.

Constraints that shape the build

This is a mobile-first responsive web application rather than a native app, because nobody should have to install software under stress. Language switches by locale, with layout that tolerates longer strings. Photographs are personal data and frequently contain plates, faces and location metadata, so upload runs over signed URLs into storage with retention rules, and EXIF handling is an explicit decision. Submission is resumable, with partial claims persisted so an interrupted session continues.

How the work runs

We pair React front-end engineers with 3D artists so the model and the interaction contract are designed together, agree the part taxonomy with the claims side before geometry work begins, and build the wizard as a state machine with each step independently testable and the 3D runtime loaded only when the damage step is reached.

What This Delivers

Claims arrive as typed part identifiers, damage categories and images attached to specific components, so adjusters assess rather than reconstruct what was reported, and machine-readable first notice of loss data feeds into automated loss adjustment. The person filing gets a guided path they can complete on a phone, in their own language, without installing anything and without losing progress to a dropped connection.

Technologies and Tools

React.js with JavaScript, HTML and CSS, three.js and WebGL for browser-based 3D, glTF with mesh compression for asset delivery, 3ds Max and Blender for geometry authoring, device camera capture, a mapping API for facility routing, signed-URL object storage, and integration with the claims automation back end.