A submission management system is the software that holds a commercial submission from the broker's email to a quote or a decline: the documents, the keyed data, the clearance result, the appetite decision, the requests to the broker, the underwriter's notes and the outcome. At some carriers it is not a separate product but a module of the policy administration system or the underwriting workbench, and the hard part is not the screens but the manual work of getting each email into it. Someone opens the mailbox, retypes the forms, searches the book and checks the appetite guide before the system holds anything useful. Botminds' Commercial Submission Intake & Clearance is an intake layer for exactly that stretch: an agentic solution that reads the mailboxes, keys and clears each submission and tests it against appetite, working alongside the policy and account system the carrier already runs rather than replacing it.
Examples are from a fictional sample carrier, Keelwater Insurance Group, and its Central region; all names and figures describing it are sample data. The state rules and model laws cited are real and linked.
Where an intake layer sits: between the mailbox and the systems you keep
1What arrives
- Broker and wholesaler emails in the region’s submission mailboxes
- Applications, line supplements, schedules of values, loss runs, financials, as PDFs, scans or spreadsheets
- Emails that are not submissions: certificate requests, endorsements, signed forms for existing files
2The intake layer
- Six agents: read, key with page and box, clear, test appetite, request what is missing, rank
- The region’s settings: threshold, scope, holds, windows, authority, clocks, each versioned
- The audit trail: every agent step, every decision, who and when
3What you already run
- Policy and account system: accounts, open submissions and in-force policies in every office, read for clearance
- Appetite guide, approved and versioned; authority letters and workload
- Underwriters’ queue and workbench, where pricing and binding happen
What is a submission management system?
A submission management system is the place a carrier keeps everything about a submission before it becomes a policy, and the workflow that moves it from received to quoted, declined or bound. It answers four questions at any moment: what came in, what state it is in, who has it, and what was decided and why.
The term covers products of very different sizes. Some carriers buy a dedicated submission or underwriting workbench; others use the submission module of their policy administration system; others run submissions out of shared mailboxes, spreadsheets and the policy system's quote screen. Buyers searching "commercial underwriting platform" and "submission management system" may be looking at the same decision from two ends: whether the answer to slow, error-prone intake is a new platform, or better work in front of the one they have.
Do I need to replace my underwriting workbench?
Not to fix intake. If underwriters wait days for files, duplicates slip through and brokers chase answers, look upstream of the workbench first: at the hours between the email and a usable submission. A new workbench with the same manual intake in front of it inherits the same delay.
The cost of replacement is the other half of the case. A policy or workbench replacement moves rating, forms, open quotes, in-force policies and the reports built on them, and every one of those is a risk to the business the carrier already has. An intake layer touches none of them. It reads the mailboxes, reads the book for clearance, applies the appetite guide the carrier already approves, and hands its output to the queue the underwriters already use. If the platform later needs replacing for its own reasons, the intake layer's job does not change.
Replace the platform, or add an intake layer in front of it
Replace the platform: Rating, forms, quotes, in-force policies, reports and the underwriters’ daily tool.
Add an intake layer: The work between the mailbox and the submission: reading, keying, clearing, appetite, requests, ranking.
Replace the platform: Little; open business is migrated or run in parallel.
Add an intake layer: The policy and account system, the workbench, the appetite guide and authority letters.
Replace the platform: In-force business and pricing, during migration.
Add an intake layer: The accuracy of keyed data and clearance matches, which page citations and evidence make checkable.
Replace the platform: Only what the new platform’s own intake does; email still has to be read.
Add an intake layer: The intake stretch itself, while the rest of the stack stays as it is.
Replace the platform: Brokers who still email unstructured submissions.
Add an intake layer: A policy system that cannot be searched or fed at all; a platform at the end of its life.
How does intake software integrate with policy admin? Reads first, then hands off
Intake software integrates with a policy administration system in two directions: it reads the carrier's accounts, open submissions and in-force policies to clear each new submission, and it hands a keyed, cited submission to wherever underwriters price. The first direction is essential on day one; the second can start simple and grow.
The read side is what makes clearance work across offices. In the sample, the clearance checker searched 41,820 accounts, 6,214 open submissions and 18,905 in-force policies across all four offices for each new submission, which is how a Chicago submission found its duplicate in Atlanta. That search needs the named insured, trading names, FEIN, addresses and contact for every account, read where they already live. The intake layer also reads the approved appetite guide and the authority letters, so that a risk above an underwriter's $50 million authority routes to the regional manager without anyone looking it up.
The hand-off side is a design choice to settle up front, not a feature to discover later. The options run from underwriters working the intake layer's ranked queue and opening the policy system only to price, through a file or message the policy system imports, to a direct write into the carrier's submission screen. Whichever is chosen, two rules hold: the keyed values keep their source citations wherever they land, and the policy system remains the system of record for anything quoted or bound.
What data should a submission file hold? The minimum an examiner can rebuild
A submission file should hold enough to rebuild what the carrier received, what it checked, what it decided and who decided, months or years later. That is a higher bar than "the keyed data", because the decisions are as much part of the file as the values.
The NAIC examination standard gives the outline: applications complete, accurate and signed where required, and a file whose documentation supports the decisions made. New York's records rule makes it specific, requiring a policy file to include the application and whatever else is needed to reconstruct how the policy was solicited, rated and underwritten (11 NYCRR 243.2). It also covers what never became a policy: an application on which no policy was issued is kept for six calendar years, or until the examination report that reviewed it is filed, whichever is longer.
What a submission file should hold, and the rule or reason behind each part
| Part of the file | What it contains | Why it must be there |
|---|---|---|
| The submission as received | The email, every attachment and the received timestamp | Proves what the broker sent and when; the timestamp decides who was first |
| Keyed values with sources | Each field with the page and box it came from; missing values marked missing | Accuracy can be checked; the examination standard asks for accurate, complete applications |
| Clearance result | Match score, fields matched, threshold, the account it matched, the rule and the decider | Defends the carrier’s choice between two brokers |
| Producer and sanctions checks | Licence, appointment status, sanctions screen and their dates | Appointment and sanctions are tested by examiners and regulators |
| Appetite and authority | Write, refer or do not write; the rule and the guide version; routing above authority | Shows the risk was selected under guidelines in force that day |
| Requests and replies | What was asked of the broker, when, and what came back | Shows requests for more information were made consistently |
| Decision and outcome | Quote, decline or bind; who decided; notices sent | The decision the rest of the file must support |
Who owns the system of record?
The carrier does, whichever software holds the data. Regulators expect an insurer's records to be available to them on request and readable when produced, and New York's rule leaves the insurer answerable even where someone acting on its behalf keeps them.
New York's rule states the expectation in practical terms: the records must be readily available to the superintendent (11 NYCRR 243; see underwriting workflow management), in readable form, and failure to produce one within a reasonable time is itself a violation unless the insurer can justify the delay. For an intake layer this settles two design questions. The output must be exportable in a form the carrier controls, and the audit trail of agent steps and human decisions must be produced on request as readily as the policy file. A vendor that holds the only copy of why a submission was declined has put the carrier's examination response in someone else's hands.
Can intake work with shared mailboxes?
Yes, and for most carriers it has to, because brokers send submissions to a regional or line mailbox, not to a person. An intake layer that watches the shared mailbox, splits each email and routes what is not a submission does the sorting the desk does each morning, and does it continuously.
In Commercial Submission Intake & Clearance the shared mailbox is sorted as it arrives
The two limits in that caption matter more than the sorting. A shared mailbox is the carrier's evidence of what arrived and when; an intake layer that deleted or answered from it would be altering that evidence. In the sample, the mailbox reader's written limits are that it never replies to a broker and never deletes an email, and the mailbox sweep runs every five minutes as a region setting. Access to the mailbox itself is a security question, taken up next.
What the rules say about a vendor reading your submissions
A vendor whose software reads a carrier's submission mailboxes holds nonpublic information about applicants, and state data security rules require the carrier to vet and oversee it. The obligations are the carrier's, and they apply before the first email is read.
The NAIC's Insurance Data Security Model Law, where a state has adopted it, requires that "A Licensee shall exercise due diligence in selecting its Third-Party Service Provider" and require it to implement appropriate administrative, technical and physical measures to protect the information it can access. New York's cybersecurity regulation is more specific. Each covered entity must have written policies for the security of information "accessible to, or held by, third-party service providers", including, to the extent applicable, guidelines on the provider's "policies and procedures for access controls, including its use of multi-factor authentication", its use of encryption in transit and at rest, and notice of any cybersecurity event affecting the carrier's information.
For a buyer, those rules turn into questions to ask before signing: where emails and attachments are processed and stored, who at the vendor can see them, how access is authenticated, whether data is encrypted in transit and at rest, how the carrier is told of an incident, and what the contract says about all of it. An intake vendor that cannot answer them in writing is not ready for a carrier's mailbox.
How long does a submission system take to implement?
A platform replacement is measured in the time it takes to migrate open and in-force business safely. An intake layer is measured in the time it takes to write down rules the carrier already applies in people's heads, connect the mailboxes and the book, and prove the agents on the carrier's own past submissions. Botminds does not publish a standard number of weeks; what decides the time is mostly what the carrier has ready.
What has to be ready before an intake layer goes live
- The appetite guide, written as rules
Rules by class, state and size, each with an identifier and text, approved by a named manager and versioned.
- The clearance rule, written down
Fields compared, match threshold, offices searched, first-in hold, broker-of-record window, who decides and who approves a release.
- Authority letters and routing
Who may write what, and where above-authority risks go.
- Read access to the book
Accounts, open submissions and in-force policies for every office the search should cover.
- The mailboxes and their owners
Which shared mailboxes are watched, and which team receives each kind of non-submission.
- A sample of past submissions with known outcomes
Duplicates the desk caught, risks it declined, files that needed requests, to prove the agents before going live.
- The hand-off decided
Where keyed submissions go for pricing, and how citations travel with them.
- The vendor security answers, in writing
Data location, access controls, encryption and incident notice, for the carrier’s third-party policy.
In Commercial Submission Intake & Clearance the written rules become versioned settings
How do you migrate open submissions? Mostly, you don't
With an intake layer, open submissions mostly stay where they are. They are read, not moved: the clearance search covers open submissions in the existing system, so a new submission that duplicates one already in progress is caught from the first day, and the open one is finished where it started.
The detail that matters is time. A first-in rule measures its hold from the first complete submission's received timestamp, so the intake layer has to read the original timestamps of open submissions, not the date it first saw them. In the sample, Quillfield Wholesale's Redwater submission was received in Atlanta on Friday 9 October at 14:12, and its 30-day hold ran to 8 November whatever day the Chicago duplicate arrived. A migration that re-dated open submissions to the go-live day would hand every pending account a fresh hold, and every second broker a grievance.
When an intake layer is the wrong answer
An intake layer is the wrong answer when the problem is not intake. If the policy system cannot price the business, if the underwriting rules themselves are unclear, or if brokers already submit complete, structured data through a portal, then the work in front of the system is not where the time goes, and reading emails faster will not help much.
It is also the wrong first step when the system of record cannot be read at all. Clearance depends on searching the book; a carrier whose accounts and open submissions cannot be queried has a data problem to fix first. For a carrier that still takes broker submissions by email, the intake stretch is where the hours and the errors are, and it can be fixed without touching what already works. The agents and their limits are set out in submission intake automation, the buying questions for AI generally in AI for commercial underwriting, and the solution itself at Commercial Submission Intake & Clearance.
Questions people ask
Is a submission management system the same as an underwriting workbench?
They overlap. A workbench is the underwriter's tool for evaluating and pricing; a submission management system tracks the submission from receipt to outcome. Some products do both, and an intake layer feeds either one.
Does an intake layer keep its own copy of our accounts?
It needs to search them, which in the sample means the carrier's accounts, open submissions and in-force policies across four offices. How that search is served, and what is held where, belongs in the vendor security answers the carrier's third-party policy requires.
Where does the appetite guide live?
Wherever the carrier approves it, as long as the intake layer applies the approved version. In the sample, the guide is rules by class, state and size, version 2026.3, approved by the regional underwriting manager on 1 September, and every verdict cites the rule and its text.
Can different regions run different clearance rules?
They can, and the sample's settings are per region. But examiners review guidelines for each regional office, and a broker who loses under a stricter region's rule will notice. Different settings should be a decision with a reason, not drift.
What happens to submissions that arrive by portal instead of email?
They still need clearance and an appetite check, and those steps do not care how the submission arrived. The reading and keying matter less when the data is already structured, which is why portal-heavy carriers gain less from that part.