Reading what the broker actually sent
You already know what a submission is and you have opened more of them than we have. The problem was never the definition.
The problem is that one risk arrives as a covering email, a slip, three versions of a schedule and a photograph, and exactly one of those is machine-readable.
How SnapLine takes a submission in
Extraction runs over the whole bundle, in whatever shape it turned up.
- Email bodies, including the ones carrying material terms that never made it into an attachment
- MRC slips, native and scanned
- ACORD forms, in whichever version the agent's system produces
- Schedules of values in Excel, across tabs and across versions
- Loss runs, including the ones that stop short of the period that was asked for
- Survey and engineering reports
- Scans and photographs, with or without an address attached
Extraction runs over the bundle rather than document by document, which matters because the same field often appears in four places with three different values. SnapLine keeps the disagreement visible instead of picking a winner off-screen. Where a required field is genuinely absent, it goes to the outreach view and becomes a request back to the broker, not a guess.
The add-in runs inside Outlook
The add-in runs inside the underwriter's own Outlook. Nothing is forwarded to a portal, and no one is asked to adopt a second inbox, which is the step most intake tools lose people at.
By the time the email is open, clearance has run, the bundle has been read, and the panel on the right is already saying which fields came out of it and what is standing between the risk and a quote. Opening it in full gives you the queue and the detail view.
Why submission documents are hard
Document AI trained on invoices and contracts does acceptably on documents that announce what they are. A submission does not announce anything. It assumes a reader who already knows the conventions, and the two standard forms break that assumption from opposite directions.
The MRC slip is the clearest case. It is a sectioned instrument, not prose. Information is distributed across sections by convention rather than by label, fields are positional, and much of what matters is a cross-reference to something attached elsewhere in the bundle. A general-purpose model reading it linearly produces text that is technically accurate and underwriting-useless. It has read the words and missed the document.
The ACORD fails it the other way round. The form is standardised, so a model reads the boxes confidently and reports a clean result — while the version differs from the one it was tuned on, the page is a scan of a print of a scan, and the thing that actually changes the risk has been written in the margin by hand. Confident and wrong is a worse outcome than obviously stuck.
The rest of the bundle is no kinder. Schedules of values come in whatever format the broker's client gave them. Scans are scans. The covering email frequently contains a term that contradicts the slip, usually the most recent and therefore the correct one.
Every field, not just every document
A citation at document level tells an underwriter almost nothing. Every field links to the region of the document it was read from, with the confidence, the reason it was flagged, and anywhere else in the bundle the same figure appears.
The panel is where an underwriter settles a value without opening the attachment, and where a vendor audit finds out whether we can show our working.
What separates this from generic extraction
Three more things, and none of them is model size.
An underwriter validates the record. The output is a draft that a person confirms or corrects, not an answer handed down. This matters less as a philosophical position than as an operational one: you are accountable for what you bind, and a system that cannot show its working cannot be used by someone who is.
The judgements are insurance judgements. A total insured value on the slip that disagrees with the column sum in the schedule is not a text extraction problem. Which figure governs, and whether the difference matters at all, is an underwriting question. SnapLine carries both values with their sources rather than picking one and moving on, because the choice belongs to the person who is accountable for the bind.
Absence is treated as information. A missing year built, a schedule that stops short, a loss run that stops short of the period that was asked for. Generic extraction returns null and moves on. SnapLine routes it to outreach, because the gap is the thing you need to act on.
Bring your own awkward submission
Our sample submissions are chosen to work. Yours are not. Bring three of your own into the demo and open a few fields on the awkward one.
If the result is a record you would be prepared to underwrite from, there is a fixed-scope Proof of Value across twenty of your live submissions, with a written report at the end. If it isn't, that's a short conversation and we'll have taken half an hour of your time.