From a Mulkiya Photo to a Motor Quote

The commercial appeal is obvious: a motor quote that begins with typing a chassis number loses people, and one that begins with a photograph does not. But the quote journey has five stages, and the abandonment happens at the stages either side of extraction rather than at extraction itself.

The five stages, and where each one loses people

Stage 1 and stage 5 are where the customers go. Stage 2 is where the errors go, which is a different problem — errors do not abandon, they propagate.

Capture: guide, do not validate afterwards

A user who submits a photo, waits, and is told it was unreadable has been given work with no explanation of how to succeed. The second attempt is usually the same photo taken the same way, and there is rarely a third.

Guidance at capture time changes this entirely: an on-screen frame, live edge detection, and specific feedback — "move out of the direct light", "hold the card flatter" — before the shutter rather than after the upload. Detecting a specular highlight over a field and asking for a small angle change costs the user two seconds and saves the whole journey. This is the highest-return work in the flow and it is consistently under-invested because it is interface work rather than model work.

Confirm: show the fields, but not as homework

Presenting every extracted field in an editable form and asking the customer to check it defeats the point. They will not proofread a chassis number, and asking them to implies you do not trust your own output — which invites them not to either.

The better pattern uses confidence to decide what is worth a human's attention. High-confidence fields are displayed as settled facts, in a readable summary rather than as inputs. Low-confidence fields — usually the plate, sometimes the owner name, for reasons inherent to those fields — are surfaced individually and prominently, with the relevant crop of the card shown beside them so the customer verifies against the image rather than from memory. Two focused questions beat twelve unread ones.

Enrich: the card is an identifier, not a risk profile

This is where projects discover a mismatch nobody scoped. A registration card identifies a vehicle: chassis, plate, make, model, year, owner. A motor rating engine wants variant and trim, engine capacity, sum insured, driver history, claims record, no-claims status and intended use. The card supplies the first group and none of the second.

So extraction is a lookup key rather than an answer. The chassis or plate resolves against a vehicle reference database to get the specification, and the rest has to come from the customer, from your own policy history, or from an industry source. A capture-to-quote project without a vehicle reference source is a capture-to-form project, and that distinction is worth settling before the OCR is commissioned rather than after.

Rate: the questions you still have to ask

Every question after the photograph costs conversion, so the honest design question is which ones genuinely change the price. Sum insured usually does and the customer often does not know it — offering a defensible default from the vehicle specification, editable, beats an empty required field. Driver details matter, but asking for them before showing any indication of price inverts the value exchange.

The pattern that converts is an indicative price from what you already have, then the questions that refine it, clearly framed as refinement. A customer who has seen a number will answer four more questions. One who has seen a form will not.