A submission starts to slip the moment it moves faster than the context around it.
A broker emails over a new commercial property risk. There is an application, a couple of loss runs, a statement of values, and a note that the client needs terms before their current policy renews in eleven days. Someone on the account team acknowledges it. Underwriting opens it two days later and asks for the missing supplemental. Service chases the broker. Meanwhile the broker has already called twice, and each time a different person gave a slightly different answer about where the quote stands. The submission is technically moving. What nobody has is a single, current view of what came in, what is missing, who owns the next step, and what the broker has already been told.
This guide is for the person who runs intake and quoting inside a brokerage or MGA and is tired of holding the whole picture together in their head and their inbox. It walks the submission from the first broker email to a bound policy, shows where it usually breaks, and describes what a more reliable version looks like, including where AI genuinely helps and where it should stay out of the way.
Make each submission complete, owned, and answerable
The point of fixing intake is not to industrialize broker relationships or take judgment away from your underwriters. It is narrower and more useful than that. You want three things to be true for every submission the moment someone asks about it: it is complete enough to work, someone clearly owns the next step, and anyone broker-facing can answer where it stands without pinging three internal teams.
Before building anything, it helps to run a plain test against your current setup. Can a service user see the submission, the client, the line of business, the target date, the documents received, and the documents still missing, all in one place? Can they tell whether the file is waiting on the broker, on underwriting, on rating, or on a carrier referral? Can they give the broker a consistent answer without reconstructing the history from email? And can whoever runs the team see which brokers, lines, or carriers generate the most back-and-forth? If the honest answer to any of those is no, the problem is not the volume of submissions. It is that the submission has no shared record, so every status question becomes a small investigation.
Follow one submission from broker email to bound policy
It is worth tracing a single submission end to end, because the breakpoints hide in the handoffs, not in any one person's work. In most brokerages and MGAs the path looks something like this.
The submission arrives, usually by email, sometimes through a portal, sometimes as a forwarded thread with the real detail buried three replies down. Someone logs it, or means to. An account or service user reads the application, identifies the client, the line, the coverages requested, and the effective date, and starts a mental list of what is missing. Underwriting picks it up and judges appetite first: is this a risk the carrier or the MGA even writes? If yes, they check whether the submission is complete enough to rate, which it often is not, so a request goes back to the broker for loss runs, a signed application, updated values, or a supplemental questionnaire. Rating and pricing happen once the file is complete. Anything outside authority goes to a carrier or a senior underwriter as a referral. A quote comes back, often with subjectivities attached, or the risk is declined, or it stalls waiting on one more document. Then the quote has to be handed back to the broker cleanly, and if the broker binds, the file moves to issuance and the policy is set up.
Each arrow in that path is a handoff between people who may be looking at different versions of the file. The work usually crosses the account owner, one or more service users, an underwriter, a rater or pricing reviewer, and sometimes a carrier contact. The submission has to show where it truly is, not merely that an email went out. "I forwarded it to underwriting" is not a status. "Waiting on broker for 2023 loss runs, target date in nine days, owned by underwriting" is a status.
Where a submission actually stalls
Intake breaks in a small number of predictable places. Naming them makes them fixable.
The submission is never fully logged
If intake lives in an inbox, the submission exists only as a thread. There is no record that says what was requested, what arrived, and what is outstanding. When the broker calls, whoever answers has to open the email chain and infer the state of play. Two people can read the same thread and reach different conclusions about whether it is complete.
Completeness is judged too late
Underwriters frequently discover missing information after they have started reviewing, not before. That wastes a review pass and adds a round trip to the broker. The missing-document check should happen at intake, against a known requirement list for the line, so the broker gets one clean request early rather than a trickle of asks over a week.
Every team keeps its own status vocabulary
Service calls it "in progress," underwriting calls it "pending info," the account owner tells the broker it is "with the underwriter." All three describe the same file, and none of them tells the broker when to expect an answer. Without a shared set of states, status becomes a matter of who you ask.
The broker hears different answers from different people
Because the record is thin, broker communication drifts. One person promises terms by Friday, another mentions a missing document the broker thought they had sent, a third says it is still being reviewed. The broker loses confidence in the file long before any coverage decision is made.
The quote handoff loses context
A quote gets approved, and then the actual handoff to the broker is rushed. The subjectivities are buried in a PDF, the assumptions behind the price are not restated, and the follow-up to confirm binding is left to memory. Plenty of quotes die here, not because the terms were wrong, but because the last step was never owned.
A worked example: five carriers, eighty submissions
This example is illustrative, not a real client. Picture a commercial-lines brokerage that passes roughly 80 submissions a month across five carriers, split between property, general liability, and a smaller book of professional lines. Three service users handle intake, two underwriters at the brokerage triage and package before anything goes to a carrier, and the founder still personally touches the larger accounts.
On paper the volume is manageable. In practice, the founder spends the first hour of most mornings answering "where is my quote" calls from brokers, because nobody else can reliably say. About a fifth of submissions bounce back to the broker at least twice for missing information, usually loss runs or a signed application, because completeness is checked when an underwriter opens the file rather than when it arrives. A handful of submissions each month sit untouched for three or four days simply because no one was clearly assigned. And roughly once a week, two different service users work the same broker's submission without realizing it, because a resend looked like a new request.
Now picture the same brokerage with one shared queue. Every submission has a record the moment it lands: broker, client, line, effective date, coverages requested, documents received, documents missing, owner, and a status anyone can read. A morning view might look like this.
| Submission | Completeness | Waiting on | Target date | Broker update |
|---|---|---|---|---|
| New property, mid-size warehouse | Missing 2023 loss runs | Broker | 9 days | Reminder drafted, needs send |
| GL renewal, contractor | Complete | Underwriting | 6 days | Status due to broker today |
| Professional lines, new venture | Complete, referral needed | Carrier | 14 days | Hold update until carrier replies |
| Property endorsement | Complete | Rating | 3 days | Quote expected tomorrow |
None of the underwriting judgment changed. What changed is that the founder can answer any broker call in ten seconds, the missing loss runs were flagged on day one instead of day three, and the duplicate submission would have been caught because both service users would have seen the same record. The improvement the broker feels is speed and consistency. The improvement the team feels is that mornings stop starting with an investigation.
Build the submission record before you speed up the messaging
The tempting first move is to automate broker communication: faster acknowledgments, cleaner status emails, templated missing-information requests. That helps only if the record underneath is reliable. Otherwise you are sending tidier messages about work whose real state nobody is sure of, which erodes trust faster than silence.
So the first build is the submission record, not the messaging. At minimum it holds the broker and client, the line and coverages requested, the effective or target date, the priority, and the account owner. It holds the document checklist for that line with what has arrived and what is outstanding. It holds the underwriting questions, the pricing assumptions, any referral or approval notes, and the current status. And it holds the communication history: what the broker has been told, what was promised, and the next follow-up date. Once that record exists and is trusted, every downstream improvement, including AI drafting, has something solid to work from.
Who owns each step
Ambiguous ownership is what lets a submission sit for three days. A simple map of steps, owners, and sources removes the "I thought someone else had it" gap. The specifics vary by shop, but the shape is consistent.
| Step | Owner | Where it lives | What "done" means |
|---|---|---|---|
| Intake and logging | Service user | Broker email or portal, agency management system | Record created with client, line, coverages, effective date, and owner assigned |
| Completeness check | Service user | Document checklist for the line | Every required document is received or explicitly requested from the broker |
| Appetite and triage | Underwriter | Underwriting workbench, carrier appetite guides | Risk is accepted for review, redirected, or declined with a reason |
| Rating and pricing | Underwriter or rater | Rating tools, carrier systems | Indication or firm price produced, assumptions recorded |
| Referral or approval | Senior underwriter or carrier | Carrier submission, referral notes | Referral resolved, terms or decline returned |
| Quote handoff | Account owner | Submission record, broker communication log | Quote, subjectivities, and expiry sent to broker, follow-up date set |
The value here is not the table itself. It is that when a submission stalls, you can point at exactly one step and one owner instead of holding a meeting about it.
The fields that must travel with a handoff
Most context is lost at the handoff, not during the work. A quote moves from underwriting to the account owner and the assumptions stay behind. A submission moves from service to underwriting and the target date is not attached. The fix is to agree, once, on the fields that must travel with a submission at each handoff so the receiving person never has to reconstruct them.
| Handoff | Fields that must travel | What breaks if they do not |
|---|---|---|
| Service to underwriting | Client, line, coverages, effective date, documents received and missing, broker priority notes | Underwriter re-reads the whole thread and re-asks for documents the broker already sent |
| Underwriting to rating | Accepted appetite, risk details confirmed, open questions, carrier or program selected | Price is built on unconfirmed assumptions that unravel at referral |
| Rating to quote handoff | Price, coverage terms, subjectivities, assumptions, quote expiry | Broker receives a number with no conditions, then is surprised at binding |
| Quote to binding and issuance | Accepted terms, satisfied subjectivities, effective date, billing and policy setup details | Bound coverage is set up from memory, and a subjectivity is missed |
Writing these down is unglamorous and it is where most of the reliability comes from. A handoff with a known field set is a handoff that does not lose the plot.
Give every submission a status people can trust
A shared status model is what lets anyone answer a broker without asking around. The states do not need to be elaborate. What matters is that all teams use the same ones and that each state says who the submission is waiting on. A workable set is: received, awaiting broker information, in underwriting review, in rating or pricing, out for referral, quoted, awaiting broker decision, bound, or declined. Each state answers the question the broker actually cares about, which is not "what stage is this" but "who is holding it and roughly when do I hear back." When a service user can look at a file and read "awaiting broker information, requested 2023 loss runs on Monday," the whole intake process gets quieter, because the answer is already there.
Clearance and duplicate submissions
Duplicates deserve their own section because they are specific to how brokers work and they quietly waste real underwriting time. The same risk often arrives more than once: a broker resends with an updated attachment, two service users pick up the same thread, or a competing broker submits the same account to the same carrier. In an MGA with delegated authority, clearing a submission against what is already in the system is not optional housekeeping, it protects the carrier relationship and avoids two people quoting the same risk on different terms.
A reliable intake process checks each new submission against existing records at the point it lands: same client, same line, same effective date, overlapping broker. When there is a match, the record links them rather than opening a parallel file. This is one of the clearest places where a shared record beats an inbox, because an inbox has no idea it has seen this risk before, and a record does.
Subjectivities and the gap between quote and bind
A quote is rarely the end of the work. Most carry subjectivities: a signed application, a satisfactory inspection, updated values, proof of prior coverage, a completed supplemental. The submission is not truly ready to bind until those are cleared, and this is exactly the stretch where files go quiet. The quote was the visible milestone, so attention moves on, and the subjectivities sit unowned until the effective date is uncomfortably close.
Treating subjectivities as tracked items on the submission record, each with an owner and a due date, closes that gap. The broker knows precisely what is still needed to bind, the account owner can see which quotes are one document away from placement, and nobody discovers on the effective date that an inspection was never scheduled. The quote handoff should hand off the conditions as clearly as it hands off the price.
Where AI helps inside intake and quote handoff
AI is genuinely useful in this workflow, and it is useful in a specific, bounded way: it reads and sorts and drafts, so people spend their time on judgment instead of retyping. The insurance sector page draws the line plainly, and it holds here. AI reads, sorts, and flags. Coverage, appetite, underwriting, and quoting decisions are made by accountable people.
Inside those limits, the practical uses are real. AI can read an inbound submission and its attachments and pull the structured facts into a draft record: client, line, coverages requested, effective date, and the key risk details from the application. It can compare what arrived against the document checklist for that line and flag what is missing before an underwriter opens the file. It can classify submissions by line, urgency, and likely completeness so triage is faster. It can draft the broker follow-up, the missing-information request, and the quote status update for a person to review and send. And it can watch the queue for aging files, probable duplicates, and status that disagrees across systems, surfacing them rather than deciding what to do about them. In every one of these, the output is a draft or a flag that a person confirms, never an action taken on its own.
Where accountable people still decide
The boundary is worth stating directly, because it is what keeps this safe and credible in an insurance context. Whether a risk fits appetite is an underwriting decision. What coverage to offer, on what terms, at what price, is an underwriting decision. Whether a subjectivity is satisfied is a person's call. What the broker is told about declinature or difficult terms is a relationship decision that belongs to the account owner. AI can make all of these faster by removing the reading and drafting load around them, and it can make sure the person deciding is looking at a complete file. It should not be the thing that decides. A brokerage that keeps that line clear gets the speed without handing its judgment, or its carrier relationships, to a model.
Traps that keep intake manual
Teams that set out to fix intake tend to stumble on the same few mistakes.
Treating intake as an email problem
Better email templates and faster acknowledgments feel like progress, but they do not create a record. If the underlying file still lives in a thread, you have decorated the symptom.
Automating messages before the record is trusted
Sending polished status updates from an unreliable record just spreads wrong answers more efficiently. Get the record right first, then let it drive the messaging.
Letting completeness stay an underwriting discovery
If missing documents are found during review rather than at intake, every incomplete submission costs an extra round trip. Move the check to the front.
Skipping the quote handoff
Approving a quote is not placing it. Quotes that are never cleanly handed back, with subjectivities and an expiry and a follow-up, are quotes you lose after doing all the hard work.
Ignoring the broker-level pattern
When the same broker keeps sending incomplete submissions, or the same line keeps stalling at referral, that is information. Left unread, it repeats every month.
The first month: one line, one set of carriers
A first build should be deliberately narrow. Pick one line of business and the carriers you place it with most, and follow that slice from broker email to bound policy. Trying to fix every line and every carrier at once is how these efforts stall.
Within that slice, the first month has a clear shape. Map the actual path a submission takes today, including who touches it and where it waits. Define the submission record, the document checklist for that line, the status states, and the owner for each step. Connect the minimum sources that make a shared queue useful each morning: the broker email or portal intake, the agency management system, underwriting status, documents, and rating or quote data where it is practical to reach. Then stand up one shared queue for submissions, missing information, review, quote handoff, and broker updates. Only after that queue is trusted do you add AI summaries and drafted responses, and only where a person reviews anything that leaves the building.
What to measure
You will know it is working from a handful of numbers, and these are worth watching from week one so you can see the change rather than assume it. Track the share of submissions that have a clear owner, target date, and status within one business day of arriving. Track the time from a broker's submission to the first meaningful response. Track how submissions are distributed across who they are waiting on, because a pile stuck on "awaiting broker" points somewhere different from a pile stuck at referral. Track the repeated reasons submissions bounce back for missing information, by broker and by line. And track how many quotes are handed off cleanly without someone reconstructing the status by hand. These numbers also tell you when to stop tuning and when a particular broker or line needs a real conversation.
A realistic rollout sequence
Sequence matters more than speed. The order below front-loads the things that make everything else reliable and defers the things that only pay off once the record is solid.
| Stage | Do first | Defer until stable |
|---|---|---|
| Foundation | Submission record, document checklist, status states, owner per step, for one line | Extending to every line and carrier at once |
| Visibility | One shared queue anyone can read; clearance check against existing records | Custom dashboards and cross-team reporting views |
| Assistance | AI extraction into a draft record, missing-document flags, drafted broker updates for review | Any AI action that sends or decides without a person confirming |
| Placement | Subjectivity tracking and a clean quote handoff with follow-up | Full binding and issuance automation before the handoff is trusted |
Done in this order, each stage makes the next one safer. Skip ahead, and you end up automating on top of a record you cannot trust, which is the one outcome worth avoiding.
How Ubisar would approach this
If broker intake and quote handoff are where your week gets eaten, the first move is not a new system. It is picking one line, following real submissions from the broker's first email to a bound policy, and building the shared record and queue that slice needs. In an early month, that means the submission record, the document checklist, the status states, and clear owners, connected to just enough of your email, agency management, underwriting, and rating data to make the queue useful every morning. AI comes in to read submissions, flag what is missing, and draft the broker updates, while your people keep every appetite, coverage, and quoting decision. You would judge it by whether brokers get faster, more consistent answers and whether quotes stop losing context on the way to binding, and you would narrow or stop if the completeness and ownership rules are not yet settled. If that is the workflow you want to fix first, this is the shape of the AI, Data & Tech Implementation service, and you can tell us about your intake process on the contact page. Related reading: the insurance sector page, the proposal and SOW workflow, and the relationship and client service workflow.