The Broker Submission That Sat Unread for Four Days

Four emails from Priya

The first one arrives on a Monday at 09:12, in the shared new business mailbox of a managing general agent in Leeds. Priya is an account handler at a small commercial broker in Birmingham.

Monday 09:12. Please find attached our presentation for the bakery group we discussed: five sites in the West Midlands, property and liability, loss runs from both current insurers. Grateful for your indication by Thursday.

Wednesday 14:30. Just checking this reached you? Happy to take a call.

Thursday 16:48. Any appetite on this one? We present to the client tomorrow at two.

Friday 11:05. No need to come back on this now, we have placed it. Thanks anyway.

Callum, one of the MGA's five underwriters, opens the first email on Friday afternoon, after the fourth. The presentation takes him twenty minutes, and it is exactly what the MGA exists to write: sprinklers at the two largest sites, a few small claims and one open escape of water, values well inside its authority. He would have sent his questions on Monday and quoted by Wednesday.

The MGA is invented: 30 people, property and liability for food and drink producers, written under delegated authority from two insurers. The four emails are not. Every commercial underwriting team has a Priya, and most of them have had this Friday.

312 unread, most of them a no

On Monday morning the mailbox held 312 unread emails. Around ninety new submissions arrive in a week, each with six to fifteen attachments: a presentation, a proposal form, a schedule of values in Excel with the client's own column names, loss runs from every previous insurer, a survey report.

Most of them are outside appetite. A scaffolding contractor, a nightclub, a recycling yard with a fire last year. The only way to find out is to open them. Amira, the underwriting assistant, logs each one into the policy administration system by hand, in order of arrival, and that is most of her day. The underwriters work the queue by broker relationship and by what looks quick. Priya's broker is small and new to the MGA, and her email looked like work.

So the submission the MGA wanted sat behind forty it did not. The out-of-appetite brokers waited a week for a no, which they mind more than the no itself. And when an underwriter finally reads a file, the question he sends back, what is the sprinkler position at site 3, is usually answered in a document nobody had time to open.

A month of submissions, and what became of them

Helen, who runs underwriting, books a call after the bakery group. Her first question is whether AI could read the mailbox for them. Her second, a minute later, is whether it would start declining things on its own. It would not, and that answer shapes everything else.

What I ask for is unglamorous: a month of submissions, exported from the mailbox with their attachments, a note of what became of each one, quoted, declined, not taken up or never answered, and the underwriting guide with the limits and referral rules of the MGA's authority.

The export arrives by Wednesday, and the second list takes Amira two days to rebuild, because nothing records a submission that was never answered. It shows what Helen suspected: the quotes went mostly to brokers the underwriters already knew, and several files that fit the appetite got no reply at all.

The underwriting guide is a 14-page PDF. It says which trades the MGA writes, the value ranges and the territories. It does not say what the underwriters actually do: that bakeries with fryers need a suppression system, that anything with an open loss above a certain figure goes to Helen, that one of the two insurers will not take cold stores. Those rules live in five heads. Before any model reads a single submission, they have to live somewhere the team can read and change.

Appetite in a table, then the reading

So the first piece of the build contains no AI at all. It is a table: trades mapped to the MGA's own trade codes, value ranges, territories, loss history limits, excluded trades and the authority's referral triggers, each rule with the name of the underwriter who owns it. Helen's team edits it themselves. When an insurer changes its appetite, the change is a row.

Then the reading. A Microsoft Graph subscription on the new business mailbox picks up each submission. A model sorts every attachment, presentation, proposal form, schedule of values, loss run, survey, and extracts it into one schema, with a page or cell reference behind every value. A schedule's headers, "Bldg Sum" or "Stock & Contents", are mapped to the site schema once per client, confirmed by a person and reused next year.

The checking is code, because arithmetic and dates should give the same answer every time. Paid plus outstanding must equal incurred on every loss run line, and each report's valuation date must be inside the MGA's freshness rule. Sites are matched across the proposal form and the schedule after addresses are normalized and geocoded. Values unchanged since last year are flagged, because a sum insured nobody has touched for years is the classic underinsurance trap. Then the appetite table runs, and every exclusion names the rule that caused it.

Here is what Priya's Monday email would have become a few minutes after 09:12:

• Risk. Bakery group, five sites in the West Midlands, property and liability, renewal 1 October, broker deadline Thursday.
• Appetite. Trade written, values inside the authority, territory covered. Fryers at two sites: suppression confirmed at one (survey, page 7), not stated at the other.
• Loss runs. Two insurers, four claims, arithmetic correct on every line. Three small and closed, one open escape-of-water claim at site 3, below Helen's referral figure. Insurer B's report is older than the freshness rule.
• Reconciliation. The schedule lists a cold store at site 4 that the proposal form never mentions, which matters, since one of the two insurers behind the MGA does not take cold stores. Building values at three sites are unchanged since last year.
• Not stated. Composite panels at site 2. The survey is silent, so this is an open question, not a no.
• Drafted. An information request to Priya about the second fryer, the cold store, a fresh loss run and the panels, waiting for Callum to edit and send.
• Queue. Top: in appetite, deadline in three days.

None of that is underwriting. It is the reading Callum did on Friday afternoon, done on Monday morning, with every line traceable to its page. The full design is in the blueprint for insurance submission intake. It is written from the broker's side of the same exchange, and the reading and the checks are the ones a receiving desk needs.

The replay that turned away a sandwich maker

Before the triage touches a live submission, the month Amira rebuilt is replayed through it, and every card is laid next to what the underwriters actually decided. Two mistakes in that replay change the design.

The first is a sandwich maker marked out of appetite. The broker had written that food waste is collected by a recycling contractor, and the model mapped the trade to waste and recycling, which the MGA excludes. A wrong yes gets caught by an underwriter. A wrong no is never seen by anyone, which makes it the most expensive error the system can make. So an exclusion is now a sort order, never a decision. The model proposes a trade code with the sentence it relied on, out-of-appetite files drop to the bottom of the queue with their reason, and an underwriter confirms every declinature.

The second is quieter. One card says "no composite panels". Nothing in the file says that. The survey simply never mentions them, and in a food factory that silence is exactly what an underwriter needs to see. Since then every answer carries its source, an answer without one is shown as not stated, and the card counts the open answers so none slips through by accident.

The replay also finds the same bakery sent twice by one broker, once to the shared mailbox and once to Callum directly. Submissions are now fingerprinted on the insured, the sites and the renewal date, and merged into one card.

What only an underwriter does

The line is simple to state. The system reads, checks and sorts. The underwriter underwrites. Whether to quote, at what price and on what terms, whether to refer a risk to one of the insurers behind the MGA, and whether to decline, are all Callum's or Helen's decisions, and the card is written to inform them, not to make them.

Nothing reaches a broker without a person either. Information requests and declinatures are drafts until an underwriter edits and sends them, and each one is logged against their name. The client owes the insurer a fair presentation under the Insurance Act 2015, and deciding what still needs asking to get one is underwriting judgment. When Priya answers, the card updates and marks what changed, so Callum reads the difference, not the whole file again.

Submissions carry personal data, from directors' names to the injured people in liability claims, so the files stay in the MGA's own Microsoft 365 tenant, the model runs in a UK or EU region under a data processing agreement, and cards are visible only to the underwriting team.

The next Monday at 09:12

Priya sends another one, a cheese maker in Staffordshire. By half past nine it is at the top of Callum's queue, with a question about a smoking room already drafted. He sends it before his first meeting. The recycling yard that arrived the same morning gets a clear no with a reason by the afternoon, which its broker will like better than a week of silence.

Amira no longer types submissions into the policy system. She checks the cards that stopped for a person, the handwritten proposal forms and the schedules nobody could map, and she chases the brokers whose deadlines are closest. And Helen can see what nobody could see in the old mailbox: which in-appetite submissions are still waiting, for how long, and with whom.

Before you build a triage for your desk

Look at the products first. FurtherAI and Sixfold sell submission intake and underwriting support to carriers and MGAs, and if one of them fits your classes and your systems, use it. A build earns its place when your appetite, your authority and your systems are specific enough that a product would have to be bent to fit, or when you want the rules in a table your own underwriters control.

It usually lands as a multi-step workflow with a human in the loop, one of the tiers on the AI workflow automation page. What moves the effort is how many classes of business you start with, how much of the appetite still lives in people's heads, and what access your policy system allows. The full blueprint covers the extraction schema and the traps, and the reasoning behind who decides what is in the post on human-in-the-loop design.

Frequently asked questions