A submission queue rarely looks broken from the outside. It looks busy.
Broker emails land through the morning. Each one carries an application, a loss run or two, a schedule of values, maybe a supplemental form, and a line about how the client needs terms by Thursday. An underwriter opens the attachments one at a time, reads what is there, notices what is missing, and tries to hold the whole risk in their head while three more submissions arrive behind it. Appetite lives partly in a guideline document and partly in experience. Pricing inputs get checked somewhere else. The decision the underwriter has to reach, whether to quote, decline, refer, or go back to the broker for more information, sits on one screen with no shared view of how it was reached.
The cost of that is quiet but real. Submissions that could have been quoted age past the broker's deadline and get placed elsewhere. Submissions that should have been declined on the first read absorb an hour of work before anyone says no. Good risks and marginal ones sit in the same undifferentiated pile, sorted mostly by who chased hardest. And when a broker later asks why an account was declined, or a manager asks who approved an exception, the answer is somewhere in an inbox.
This guide is for the underwriting operations lead, or the underwriter who has quietly become one, who wants incoming submissions to move through review in a way the whole team can see and trust, before piling on more volume. It is about the carrier side of the work: taking what brokers send, deciding what is worth quoting, and doing it in an order that makes sense. How a submission gets assembled and handed off in the first place is the broker's own workflow, and a separate problem.
The job is to make every submission something an underwriter can decide on
It is tempting to frame this as a speed problem and go looking for a faster way to read. Reading speed is not really the constraint. The constraint is that most submissions arrive as partial stories, and a lot of underwriting time goes into assembling the story before any judgment can happen.
A submission review workflow worth building does four things. It pulls the broker's request, the risk facts, the loss history, the attachments, and the missing items into one place an underwriter can actually look at. It surfaces the appetite question early, before someone has spent an hour on a risk the carrier was never going to write. It gives every underwriter the same place to work, so review does not depend on who happens to pick up the file. And it keeps the reasoning behind each quote, decline, referral, or request for more information, so the team can answer for its decisions later.
A test before you build anything
Before adding tools, check whether your current setup can answer four questions on any live submission. Can an underwriter see the request, the risk facts, the loss runs, the attachments, and the missing items together, without reopening five systems? Can the workflow show whether a risk looks in appetite, out of appetite, or worth a referral before detailed review starts? Can you see quote, referral, decline, and broker-waiting status across a book, by product, segment, and owner? And can a manager see why submissions were declined, referred, or returned, without asking the underwriter to remember? If the honest answer to any of these is no, the workflow is not visible enough yet, and no automation layered on top will fix that.
Follow one submission from broker email to a quote or decline
The clearest way to find where review breaks is to follow a single submission from the moment it arrives to the moment it is quoted, declined, referred, or returned. The delays almost never sit inside the reading itself. They sit in the handoffs between the documents, the appetite question, the pricing inputs, and the person who has to decide.
A common version runs like this:
- A broker email or portal submission arrives with attachments and a note about timing, and someone opens a file for it.
- The application, schedule, loss runs, and supplemental forms get checked to see whether there is enough there to underwrite.
- The risk is compared against appetite, authority limits, product fit, geography, and the carrier's referral triggers.
- An underwriter builds notes, sends questions back to the broker, pulls in pricing or a referral owner, and moves the account toward a quote or a decline.
- Broker replies, quote assumptions, declines, and open questions get tracked in whatever space the underwriter keeps, usually an inbox and a spreadsheet.
The shape is sensible. The problem is that each handoff is a place where a submission can stop moving without anyone noticing. The account is not lost. It is just waiting, and nobody owns the wait.
Where submission review actually stalls
The stalls are predictable. They look slightly different across property, casualty, specialty, and different distribution channels, but the underlying patterns repeat.
Completeness is read as a formality
Someone glances at the submission, sees an application and a loss run, and marks it ready. Then the underwriter starts and finds the schedule of values missing, the loss run three years short, or the supplemental for that class never attached. The submission goes back to the broker, the clock restarts, and the underwriter has already spent the setup time. A completeness check is only useful when it names what this specific risk needs, not whether some documents happen to be present.
The appetite question is asked too late
Appetite often lives in a guideline document, a rate filing, and the memory of senior underwriters. Because it is scattered, the fastest way to find out whether a risk fits is often to start underwriting it. So declines that should take five minutes take an hour, and the same borderline classes get re-argued from scratch every time they appear.
Nothing decides what gets worked first
When submissions are worked in the order they were opened, or the order the broker chases hardest, the queue has no relationship to value or urgency. A renewal with a real bind date waits behind a speculative new-business submission from a broker the carrier rarely wins with. Sorting by volume of email is not prioritization.
The same risk arrives more than once
In wholesale and open-market business, the same account often comes in through several brokers. Without a way to see that, two underwriters can work the same risk, the carrier can quote against itself, and clearance disputes surface after terms have gone out. This is a carrier-specific tax that the broker side never sees.
Follow-up lives in personal inboxes
Once a submission is waiting on the broker for a missing schedule or a clarifying answer, it usually drops into one individual's inbox. If that underwriter is out, buried in another account, or simply busy, it stalls silently. Nobody can see the aging because the aging is invisible.
The reason behind a decision disappears
A submission is declined, referred, or quoted on a specific assumption, and the reasoning lives in the underwriter's head or a one-line email. Three months later, when the broker asks why, when a similar risk appears, or when a manager reviews the book, that reasoning has to be reconstructed. Over a year, the carrier loses the pattern of its own decisions.
A worked example: a commercial property team and 250 submissions a month
To make this concrete, say a commercial property underwriting team receives around 250 submissions a month across a handful of brokers, and quotes roughly a third of them. These numbers are illustrative, meant to show the shape of the problem rather than describe a real carrier. Even so, the pattern will be familiar to anyone who runs a book.
Of those 250, a meaningful share are out of appetite on arrival: wrong occupancy, a location the carrier does not want, or a size band outside authority. Another share are in appetite but incomplete, missing a current loss run or a full statement of values. The rest are workable now. In a queue with no triage, all three groups look the same on Monday morning, so the underwriter reads them in roughly the order they landed. The out-of-appetite risks still get read in full. The incomplete ones get started, then parked. The clean, quotable ones wait their turn behind both.
A triage step changes the first hour of the week. Instead of one undifferentiated pile, the team sees something closer to this:
| Submission | Early appetite read | Completeness | What happens next |
|---|---|---|---|
| New warehouse risk, standard occupancy | Looks in appetite | Application and current loss run present, statement of values missing | Underwriter requests the statement of values before starting detailed work |
| Renewal, operations changed since last year | In appetite but changed materially | Prior policy, updated application, and claims summary attached | Senior underwriter reviews because the risk profile moved |
| New submission, occupancy outside guidelines | Reads as out of appetite | Complete | Quick decline with the reason recorded, broker told the same day |
| Renewal near the bind date | In appetite | Complete, pricing assumptions not yet reviewed | Prioritized for a pricing referral before terms are released |
Nothing here removes underwriting judgment. The out-of-appetite risk is still declined by a person, and the reason is written down once so the next similar submission is faster. The value is in the first hour: the team stops spending equal effort on every submission and starts spending it where a quote is both possible and worth winning.
Build the submission packet before you speed anything up
AI and automation are only as good as the material they work from. Before adding either, it is worth defining the packet that should travel with every submission, so a human can review it even on a day when no automated step runs. The packet is not a new system. It is an agreement about what a complete, reviewable submission looks like for your book.
For most commercial lines, the useful packet holds a few things: the identifying facts about the risk, the systems the information came from, the documents themselves, the rules the risk is measured against, and the current status. Laid out plainly, it looks like this:
| Part of the packet | What it holds | Why it has to be there |
|---|---|---|
| Risk identity | Insured, broker, product, line, segment, geography, requested effective date, requested coverage and limits | Lets you sort, clear, and route a submission without opening every attachment |
| Source documents | Application, loss runs, schedules, supplemental forms, exposure data, prior account notes, broker correspondence | Keeps the underwriter from hunting across email, portals, and drives for the same file |
| Measurement rules | Appetite criteria, authority limits, referral triggers, common decline reasons, pricing inputs | Turns appetite from private memory into something the whole team applies the same way |
| Status and history | Completeness state, quote or decline status, referral owner, broker follow-up, aging, final disposition | Makes the wait visible so submissions stop stalling in silence |
Most carriers already have every one of these somewhere. The work is rarely buying a new place to keep them. It is deciding what a complete packet means and making that definition the same for everyone, so the next underwriter to touch a file starts from the same picture as the last one.
Triage is really an appetite question asked early
The single highest-value change in most submission workflows is moving the appetite question to the front. Every submission deserves a quick read against a short set of questions before anyone commits real time. Is this a class, size, and geography the carrier wants? Is it inside the underwriter's authority, or does it need a referral? Is there an obvious reason to decline it now, before reading further?
Done well, this is not a rigid filter that rejects anything unusual. Underwriting lives in the borderline cases, and a triage step that kills every exception will quietly train brokers to send their good business elsewhere. The point is to separate three groups fast: risks clearly worth full review, risks clearly outside appetite that can be declined with a recorded reason, and risks that need a human referral because they sit on an edge. The first group gets the underwriter's attention. The second stops absorbing it. The third reaches the right person while the broker's deadline is still live.
Give the queue an order people trust
Once a submission is in appetite and workable, something has to decide what gets underwritten first. Left alone, that decision defaults to email order or broker persistence, neither of which reflects what the carrier actually wants to write.
A queue people trust usually weighs a few real things: how close the requested effective or bind date is, how likely the carrier is to win and keep the account, the strength of the broker relationship behind it, and whether the risk is a renewal the book cannot afford to lose. None of this needs a scoring engine to start. It needs the queue to show the handful of facts that let an underwriting manager, or the underwriters themselves, agree on what comes first and why. The goal is simple: on any given morning, the next submission worked is a defensible choice, not an accident of who chased hardest.
Clearance and duplicate submissions
Clearance is one of the parts of carrier work with no equivalent on the broker side, and it quietly causes real damage when it is weak. In open-market and wholesale business, the same risk often arrives through more than one broker, sometimes within days. If the workflow cannot recognize that two submissions describe the same insured and risk, two underwriters can work it in parallel, the carrier can issue conflicting terms, and a clearance dispute lands after quotes are already out.
The fix is not complicated in principle. Every incoming submission should be checked against open and recent submissions on the identifying facts, the insured, the risk address, the effective date, before it is assigned. When a probable match appears, a person decides which submission and which broker the carrier is working with, and that decision is recorded. This is exactly the kind of matching software is good at proposing and a person should still confirm, because the cost of clearing the wrong broker is a broker relationship.
Handle missing information as part of the workflow, not around it
Almost every submission needs something more from the broker at some point: a current loss run, a full statement of values, an answer about the operations, a signed supplemental. How the team handles that gap determines a surprising amount of the total cycle time.
The weak version treats the request as a personal errand. The underwriter emails the broker, the account leaves the shared view and enters an inbox, and it comes back, or does not, on the broker's schedule with no visible aging. A stronger version keeps the waiting submission in the same queue as everything else, with the specific missing item named, an owner attached, and a clock running. A manager can then see at a glance which accounts are waiting on brokers, for how long, and for what, and can chase the ones aging toward a lost opportunity. The difference is not effort. It is whether the wait is visible.
Where AI helps inside submission review
AI earns its place in this workflow when it takes the reading and sorting load off the underwriter and leaves the judgment where it belongs. The useful roles are narrow and specific.
It can read a submission packet and produce a source-linked summary of the loss runs, exposures, and broker notes, so the underwriter starts from a structured brief instead of a stack of attachments. It can extract the fields that would otherwise be re-keyed, insured names, locations, exposures, effective dates, prior losses, requested limits and deductibles, and flag which of those are missing. It can compare the visible risk facts against written appetite and referral criteria and show where they seem to line up or conflict, with its confidence and its sources visible, so a person can check it. It can draft the broker follow-up email, the decline note, or the referral summary for an underwriter to edit and send. And it can watch the queue for the things people miss when they are busy: probable duplicate submissions, referrals that have aged, missing documents, and accounts drifting past their response targets.
In every one of these, the AI reads, extracts, sorts, and flags. It does not decide. A summary that reads cleanly is not a reviewed submission, and an extracted field is not a checked fact, so each output has to show its sources and stay editable by the underwriter who is accountable for the account.
Where the underwriter still decides
The boundary here is not a matter of caution. It is what keeps the workflow trustworthy. A system can tell you that a risk sits outside the written appetite. It cannot decide whether this particular account, with this broker, at this point in the year, is the exception worth making. It can surface that a loss run shows a pattern. It cannot decide what that pattern means for price, terms, or whether to quote at all.
So appetite calls, pricing, terms, the quote itself, and the decision to decline stay with underwriters, and the workflow's job is to make each of those decisions easy to record: who decided, on what basis, and when. That record is what lets a manager review the book later, what answers the broker who asks why, and what turns a year of individual decisions into something the team can actually learn from. A good workflow does not take judgment away from underwriters. It stops burying that judgment under document-chasing and re-keying.
What to measure
If you want to know whether the workflow is working, a small set of numbers tells you more than a dashboard full of them. Watch how many submissions are complete enough for a first review without going back to the broker. Watch the time from arrival to the first real underwriting action, because that is where opportunities are won or lost. Watch how many submissions come back for missing information, sorted by what was missing, because that points straight at the broker or product to fix first. And watch the aging of everything sitting in quote, referral, decline, and broker-waiting status, along with where submissions end up by product, broker, and reason. The reason detail matters most: a book that can explain why it declines and refers what it does is a book a manager can actually steer.
Traps that keep submission review slow
A few mistakes show up again and again when teams try to fix this, and most of them come from automating before the underlying workflow is sound.
Automating the decision before the packet is reliable
The temptation is to jump straight to automated quoting or declining. If the submission packet is still incomplete or inconsistent, automation just makes confident decisions on bad inputs faster. Get the packet and the appetite view stable first. Automate the reading and the routing long before the deciding.
Trusting summaries without sources
An AI summary an underwriter cannot trace back to the loss run or the application is worse than no summary, because it looks authoritative. Every extracted fact and every generated note needs a visible source and an easy way for the underwriter to correct it.
Making appetite so rigid it kills referrals
If triage hard-declines everything unusual, the team loses exactly the borderline business underwriting exists to price. Appetite rules should route edge cases to a person, not reject them automatically.
Leaving broker follow-up outside the workflow
If waiting-on-broker submissions disappear into inboxes, the queue understates the real work and the aging is invisible. Follow-up is part of the workflow, not a side conversation.
Measuring only quote volume
Counting quotes issued says nothing about whether the right risks were quoted, how fast, or why others were declined. Completeness, aging, referral quality, and recorded reasons are the numbers that show whether review is improving.
A realistic first month
You do not need to redesign underwriting to make submission review better. The first build should take one line, one segment, or one broker channel, and make real submissions easier to review without asking the team to abandon the tools they already use.
A sensible first month looks roughly like this:
| Week | Focus | What should exist by the end |
|---|---|---|
| Week 1 | Map one segment's path from broker email to quote or decline | A clear picture of how submissions move today and where they stall |
| Week 2 | Define the packet, the completeness checklist, the appetite signals, and the status model | An agreed definition of a complete, reviewable submission for that segment |
| Week 3 | Connect broker intake, document storage, underwriting notes, and quote or referral status where practical | A live queue showing complete, incomplete, in-review, referral, quote, decline, and broker-waiting states |
| Week 4 | Add AI extraction and summaries inside the underwriter's controls, then tune with the team | One segment reviewable from a shared queue, with underwriters still owning every decision |
At the end of the month, the test is simple. If underwriters are moving faster without losing control of their decisions, and a manager can finally see the queue, keep going and widen it to the next segment. If the status of submissions is still unclear, narrow the scope and fix that before adding anything. The boring first version, one segment, one clear packet, one visible queue, is almost always the right place to start.
How Ubisar would implement this workflow
In week 1, Ubisar would pick one underwriting segment and follow its submissions from broker intake to quote, decline, referral, or request for more information, looking specifically for where accounts stall and where reasoning gets lost. The first thing we would build is a submission review queue that shows packet completeness, source-linked documents, the appetite question, referral triggers, the underwriter who owns each account, and the current decision status.
In weeks 2 and 3, we would connect the broker email or portal, the document store, policy and claims history, the pricing sheet, and the underwriter notes this queue needs, no more than that. AI would help extract facts, summarize loss runs, draft follow-ups, and flag missing documents and probable duplicates, while underwriters kept appetite, pricing, referral, and quote decisions, each one recorded. By week 4, one active segment should be reviewable from the queue, with a person accountable for every call.
At the end of month one, we would keep going if underwriters are moving faster without losing decision control, and narrow it if the packet is still unclear. This is a practical use of the month-to-month AI, Data & Tech Implementation service, and it connects to the wider insurance sector work on intake, claims, and reporting. The broker side of the same pipe is covered in the broker intake and quote handoff workflow. If submission review is where your team is losing time, tell us about the workflow and we will map the first month with you.