The insurance industry standardised the submission decades ago. ACORD, the body that maintains the data standards commercial insurance runs on, has published the forms and formats that were meant to let a broker’s submission flow cleanly into a carrier’s systems. The standard has existed for a generation, and a large share of commercial submissions still arrive the way they always have, as an email with a PDF attached, a spreadsheet of loss runs, and a set of financials in whatever shape the account happened to produce them. That gap between a standard that exists and a submission that arrives as unstructured documents is where underwriting automation either pays or quietly fails to.
The operation grows, and the underwriting bench grows with it
An underwriting operation scales in a way that looks like success from the outside. More submissions in, more business bound, more revenue, and more underwriters and underwriting assistants hired to work the flow. The lines rise together, which reads as a book winning in its market. Underneath, the cost of getting a submission from the inbox to a quote is not falling the way it should as volume grows, because most of the work between those two points is still being done by people moving information between systems that were never connected. At Digital Forms we call the point where that catches up with an operation the Manual Wall, the growth ceiling a business hits when it keeps adding headcount to absorb volume that software should be carrying.
The underwriting version of the wall is specific. A submission arrives as unstructured documents, and someone reads them, keys the data into the policy-admin or rating system, pulls third-party data from separate portals, checks the account against appetite, and routes anything outside guidelines to a senior underwriter. Every one of those steps is a handoff, and the Human API problem is the name for what fills the space between them, the underwriters and assistants who spend their days as the connective tissue between the submission inbox, the data sources, the rating engine, and the policy system. The expensive part is not the judgement at the end but the hours of preparation the judgement has to wait behind.
Why this bites harder now
Two pressures have made the manual layer more costly than it was a decade ago. The first is talent. Underwriting expertise is scarce and getting scarcer as an experienced generation retires faster than a new one is trained, so every hour a skilled underwriter spends re-keying a loss run instead of assessing risk is an hour bought at the wrong price. When the constraint on growth is underwriter capacity, spending that capacity on data entry is the most expensive possible use of it.
The second is speed. In competitive lines the carrier that quotes first often wins, because a broker works the submissions that come back fastest, and an operation whose turnaround is gated by manual intake is losing business it never sees decline. Submission volume and quote speed pull in opposite directions when the work in between is manual, and the operations that feel this most are the ones growing fastest, because volume is exactly what overwhelms a process held together by people. The result is a book that could be growing faster held back by a bottleneck that does not appear on any underwriting report.
What is underwriting automation, really?
The phrase usually gets heard as a software category, a question of which insurtech platform or rating engine to buy. That framing is where a lot of the disappointment comes from, because the platform is rarely the thing that was missing. Most operations of any scale already run a capable policy-admin system and a rating engine. Underwriting automation, in the sense that actually moves the cost and speed lines, is the automation of the manual work that persists around those systems, above all the intake of the submission and the extraction of its data into a form the rating engine can use.
It helps to separate two things that get blurred together. The rating engine prices the risk once the data is in it. The policy-admin system holds the record and issues the documents. Neither of them reads an emailed PDF, reconciles a loss run against the account, or pulls the third-party reports an underwriter needs before they can even begin. That work sits in the gap between the inbox and the platform, and it is done by a person because nothing was ever built to do it. The platform is doing its job in every one of these cases, and the hours are accumulating in the space it was never designed to cover.
What to automate first: document automation for underwriting
The mistake operations make when they decide to attack the manual layer is to try to automate the whole underwriting workflow at once, which is slow and expensive, and it tends not to finish. The cost is not spread evenly across the submission. It concentrates at the front, in the intake and preparation steps that every submission passes through regardless of whether it ever becomes a quote, which is why document automation for underwriting is almost always the first place a return shows up.
Automating submission intake means turning the emailed PDF, the loss-run spreadsheet, and the financials into structured data the moment they arrive, so an underwriter opens a prepared file rather than a stack of attachments. It is high-volume, rules-heavy work that happens on every submission in the pipeline, including the majority that will never bind, which is precisely why it is expensive to do by hand and rewarding to automate. The same structural pattern shows up across every regulated back-office DF works in, which is why the diagnosis here mirrors what we describe for claims automation, where the highest-value first step is almost always the intake of the claim rather than the adjudication at the end.
The natural second step, once intake is handled, is the data gathering that sits between the prepared submission and the rating engine. Underwriters routinely pull reports from separate portals, a motor vehicle record from one and a loss or catastrophe report from another, then paste the results back into the file by hand. Automating that enrichment, so the required reports are retrieved and attached to the submission automatically, removes a second concentrated block of preparation time, and it is usually the step that follows intake in the sequence. The principle holds one layer in, because the underwriter should arrive at a file that is ready to assess rather than one that still needs assembling.
The reason sequencing matters is that the first automated step has to earn the next one. An operation that starts with intake sees underwriter time freed and quote turnaround shorten before the appetite for the project runs out, and that early result is what funds the rest of the roadmap rather than a large programme that competes with every other demand on the business. It is the same logic we apply in claims, where we have written about why hiring more analysts does not fix a processing bottleneck that is structural rather than a question of capacity.
What your rating engine was never going to do
It is worth being direct about the limit of the software, because the gap is predictable. A rating engine is built to price a risk from clean inputs, and a policy-admin system is built to hold the record and produce the paper. Neither is built to know that a particular broker always sends loss runs in a format that needs manual cleaning, or that a guideline exception three years ago was handled a specific way that only a senior underwriter remembers. That knowledge lives in experienced people because the workarounds were never built into a system, which is exactly why an operation cannot simply hire cheaper staff to carry the same volume.
That is the real constraint behind the Manual Wall in underwriting. The operation is not short of a platform, and it is not short of capable underwriters. It is short of the automation that would let those underwriters stop spending their scarce expertise on preparation and spend it on risk selection and pricing, which is the work only they can do. Adding assistants buys more manual capacity at a rising cost per submission, which is the opposite of what an operation trying to grow its book profitably actually needs.
What this looks like inside a mid-market carrier
Picture the shape without a name attached. A specialty carrier or program administrator is growing submissions at a healthy clip and hiring underwriting assistants to keep the flow moving, and its combined ratio looks stable on the quarterly pack. What does not show on the pack is that a large share of underwriter and assistant time goes to intake and preparation, reading submissions, re-keying data, pulling reports, and cleaning loss runs, before any risk assessment begins. During a growth push that work multiplies, quote turnaround stretches, and the operation covers it by hiring, because hiring is the visible lever and the cost of the manual work is buried inside a growing headline that reads as expansion.
The upside becomes real the moment someone counts the hours going into the repetitive front end of the file and prices what recovering them is worth. In operations of this scale the recoverable figure is routinely large enough to matter to the expense ratio within the first year, not because of a heroic transformation but because the intake work was never automated in the first place. That is the operational lever in concrete terms, and it is available in most underwriting operations precisely because it has been treated as the unavoidable cost of doing business.
How to find the manual work worth automating
The starting point is measurement, not a software decision. Before committing to any build, an operation needs to know where its handling cost and its turnaround delay actually concentrate, which submission steps consume the most underwriter and assistant time and which points in the flow put speed-to-quote at risk when volume rises. Surfacing that is what we built our Profit Leak Diagnostic to do, because operators consistently underestimate how much scarce underwriting capacity is trapped in preparation work they have stopped noticing.
From there the discipline is to build narrow and prove it fast, so the first result funds the next rather than a budget request that competes with everything else. The initial move we make is usually an Operations Sprint that automates a single high-value step, most often submission intake, and puts a working result live in weeks. The point of both is the same, to replace the assumption that manual preparation is simply what underwriting costs with a number the operation can act on.
The question worth asking at the next underwriting hire
The next time an underwriting operation reaches for another assistant to keep up with submission flow, the useful thing to examine is not whether the person is needed to clear the current backlog, because they almost certainly are. It is whether the backlog exists because the book is genuinely growing or because the same submission preparation is being done by hand on every account that comes through the door. One of those is a reason to hire, and the other is a reason to automate, and an operation that has never separated the two is paying underwriter wages for work that was never underwriting.
