InboxIQ: Why We Built Submission Intake Around the Email Inbox

Every PEO we have ever worked with has, at some point, built a submission portal. A web form where a broker is supposed to enter the prospect's details, upload the loss runs, attach the census, and hit submit. Every one of those portals has the same adoption curve: a few brokers use it the first month, and then everyone goes back to email.

This is not a failure of the portal. It is a fact about brokers. A broker working an account is sending the same package to three or four markets, and the fastest way to do that is to forward the email. Asking them to re-key into your form is asking them to do extra work for the market that is least likely to win because it was the most annoying to submit to.

So when we designed intake for HALO IQ, we started from the inbox rather than trying to replace it. InboxIQ is the result.

InboxIQ receives submissions by inbound email. Brokers send them the same way they send them anywhere else, and the message and everything attached to it enters the system without anyone opening a browser.

From there, three things happen in sequence. Each attachment is classified. Each classified document is parsed into structured data. The result is matched to a company and routed to the module that needs it.

That sounds simple, and the design goal was for it to look simple from the outside. The work is in the details of each step.

Classification: what is this document?

A submission email rarely labels its attachments helpfully. The file is called "scan_0417.pdf" or "ABC Co.pdf" or "loss runs" when it is actually three loss runs, an ACORD 130, and a dec page merged into one file.

InboxIQ classifies each attachment. The categories it recognizes are the ones that matter for PEO and broker underwriting: loss runs, ACORD 130 applications, employee census files, X-Mod worksheets, and declarations pages from the current policy.

Classification is where AI does its first job in the pipeline. A model reads the document and decides what it is. The principle we hold to is that a confident classification should proceed on its own and an uncertain one should go to a person with the model's best guess in front of them. In our own PEO, the ambiguous cases have usually been either an unusual carrier format or a scanned fax of something that was already hard to read on paper.

Parsing: deterministic first, AI second

This is the design decision we are most often asked about, so it is worth explaining.

Loss runs from a given carrier look the same every time. Travelers formats its loss runs one way, Zenith another, State Fund another, and each has been stable for years. For those, the fastest and most accurate approach is not AI at all. It is text extraction and pattern matching: pull the text layer out of the PDF, identify the carrier template, and apply a parser written for that template. The output is exact, repeatable, and cheap. If the parser fails, it fails loudly, which is what you want.

Only when the document does not match a known template does InboxIQ fall back to a model. The model reads the document and extracts the same fields the deterministic parser would have: claim number, injury date, claimant, status, paid, reserves, total incurred, valuation date, policy period, carrier. A reviewer should know which path produced a number, because the two deserve different levels of scrutiny.

We built it this way for two reasons. First, accuracy: a regex that matches a known layout does not hallucinate a reserve figure. Second, cost and speed: there is no reason to spend inference on a document whose structure is fully known. AI earns its place on the long tail of formats, which is where a purely deterministic system would simply give up.

The same principle applies to the other document types. ACORD 130 forms are standardized, so the layout is known. Census files are spreadsheets with wildly varying column names, which is exactly the kind of long-tail problem a model handles better than a rule. Experience rating worksheets follow the bureau's layout.

Parsing one loss run is not the hard part. The hard part is that a submission usually contains several loss runs covering overlapping periods from more than one carrier, each valued at a different date.

InboxIQ hands parsed loss data to ModIQ with the carrier, policy period, and valuation date preserved on every claim. ModIQ then aggregates by policy year, which is the only unit that makes sense for mod projection or loss picks. Two runs covering the same policy year at different valuation dates have to be reconciled, not summed, and a missing policy year has to be treated as a gap rather than a clean year. We will write more about what to look for in loss runs in a later post; the point here is that the intake layer preserves the metadata that makes that analysis possible.

Matching: which company is this?

A parsed submission has to attach to a company record. InboxIQ matches the documents to a company using the identifying details in them, with enough tolerance to recognize that "ABC Landscaping Inc" and "A.B.C. Landscape, Inc." are probably the same prospect. If a match exists in ConnectIQ, the documents attach to it. If not, the submission is new business.

Ambiguous matches should go to a person. This is one of the places where we deliberately did not want the system to guess, because attaching a loss run to the wrong company is a worse outcome than asking a human a five-second question.

Routing: the deal exists before anyone opens it

Once matched, the submission creates a deal in ConnectIQ. The deal carries the company, the documents, and the parsed data. Loss runs and worksheets route to ModIQ. The ACORD, census, and dec page feed the company basics and workers' comp sections of the proposal wizard.

What this means operationally is that by the time a rep opens the deal, the data entry is done. The rep's first task is review, not transcription. A broker who sent a submission at nine in the morning can get a status update before lunch, because nobody had to spend the morning keying claims.

For the broker, this is also the mechanism behind a shared view of the deal. The broker sent an email; the PEO sees a structured deal. Both are looking at the same underlying record, and the broker can see that the submission landed, was parsed, and is being worked, without sending a follow-up email asking whether anyone received it.

What we got wrong the first time

Our early thinking tried to be clever about everything: match aggressively, open a deal on any email, parse every attachment. That direction produces noise. A deal opened from a broker's out-of-office reply, or a loss run attached to the wrong entity in a parent-subsidiary group, costs more trust than it saves time, and reps stop believing the queue.

The design we landed on is conservative where being wrong is expensive and automatic where being wrong is cheap. Classifying a known carrier's loss run is automatic. Attaching it to one of two companies with near-identical names is not. Opening a deal from a submission with real documents attached is automatic. Opening one from an email with nothing attached is not.

We also came to see the audit trail as part of the automation rather than an afterthought. A parsed number should carry its source document and its extraction method with it. When a carrier questions a figure six months later, the answer should be a click away, not a search through someone's email.

Where it leads

InboxIQ is the front door to everything else in HALO IQ. It is the reason ModIQ has clean, policy-year-aggregated losses to work with, the reason the proposal wizard starts half-filled, and the reason a ConnectIQ deal exists on the day the submission arrives rather than the day someone got around to it.

We built it around the inbox because that is where the work already is. The job was never to change how brokers send submissions. It was to make sure that what they send becomes something a PEO can act on in minutes.