Submission intake and triage
Submissions arrive the way brokers want to send them: an email, a spreadsheet of locations, an ACORD form, a loss run as a scan. Someone reads them and types them into a system. The underwriter then spends the first hour deciding whether the risk was ever in appetite.
The symptoms
- Submissions arrive as PDFs, and someone re-keys them.
- Out-of-appetite risks reach an underwriter's desk.
- Nobody knows how many submissions you declined last month.
What a good answer looks like
None of this needs us in the room. Run it this way with the people you already have and the problem gets smaller.
01 · Accept the format the broker already uses
Intake that requires the producer to change how they work is intake that gets bypassed. Take the email, the attachment and the form as they arrive, and do the normalising on your side.
02 · Extract, then validate against something
Extraction on its own moves the typing rather than removing it. Every extracted field needs a rule to be checked against, and a confidence level that decides whether a human sees it. What cannot be validated goes to a person with the document open beside it.
03 · Triage before an underwriter opens it
Appetite and eligibility are already written in the binder. Applied at the door, they answer most submissions without a person, and the underwriter's day starts on the risks that were worth their judgment.
04 · Count what you decline
Submission volume, hit rate and decline reasons are the cheapest signal you have about whether the appetite matches the market. Most teams cannot report them because intake never wrote them down.
What makes it hard once you are at scale
Extraction accuracy is the part everyone demonstrates and the part that matters least on its own. The difficulty is what happens at the edges: a schedule of two thousand locations, a loss run that contradicts the application, a broker who sends the same risk three times with different limits, a submission that is in appetite for one carrier on your panel and not another. An intake that cannot say why it made a decision will not survive its first coverage dispute, which is why every action needs to be logged and reversible.
Where it sits in the blueprint
Intake is an agent standing on the map. The agent reads and normalises. The map tells it what a submission, a risk and an appetite are in your business, which is what lets it decide rather than guess. The gateway is what stops it writing anywhere it should not, and records what it did.
What we bring already built
These are in production. Take them as they are, shape them around how you work, or leave them out and we will integrate what you already run.
- Intelligent Document Processing
- Extraction and validation from unstructured submissions: applications, schedules, loss runs.
- Eligibility and Appetite
- The rules the triage decision is made against, held in one place rather than per program.
- Submission intake agent
- Reads the submission, normalises it against the map, and routes what it cannot resolve to a person.
- Document Management
- Storage, versioning and retrieval, so the original document stays next to the decision made from it.
- CRM and Customer 360
- The broker and client record the submission attaches to, rather than a queue of loose files.
The number this has to move
One business number, agreed before the work starts, with the baseline taken from your own reporting.
- __ %
- Submissions handled without a person
Is this the one costing you the most?