A water heater can tell you a lot about how underwriting technology should work.
Say your guidelines are comfortable with a water heater under 15 years old. At 16 years, maybe you want somebody to take a closer look. At 20 years, you already know you are not taking the risk. An experienced underwriter understands those boundaries, but that does not mean an underwriter needs to manually apply the same rule every time a submission comes through.
That is where technology can help. Build those guardrails into the workflow, let the clear-cut risks keep moving, and bring the underwriter in when the answer requires judgment.
The short version
- Underwriting at scale is not about replacing underwriters. It is about using technology to handle repeatable decisions so underwriters can spend more time on exceptions and judgment calls.
- Your underwriting appetite needs to become rules the system can act on. Those rules can determine what moves forward, what gets referred and what stops.
- The technology is only as good as the data feeding it. Bad or inconsistent risk data can create extra work and lead to very different underwriting outcomes.
- The people behind the platform matter. Insurance experience becomes especially important when you are setting guardrails, entering a new line of business or trying to understand what the data in your book is telling you.
How can carriers scale underwriting without sacrificing human judgment?
The goal is not to take underwriters out of the process. It is to make sure they are spending their time on the risks that need them. If a risk fits comfortably within your appetite, there may be no reason for an underwriter to manually review every detail before the quote can move forward. If it sits near the edge, that is where you may want an experienced person to take a closer look. And if the risk clearly falls outside your guidelines, the system should identify that before an agent spends time completing a quote that was never going to be written.
That is where technology earns its place. If the risk stays inside the guardrails, keep it moving. If it hits one of them, decide whether that means a warning, an underwriting review or a stop. You do not need an underwriter looking at every submission just to confirm that the system followed a rule everyone already agreed on.
How do you turn underwriting appetite into rules the system can act on?
I tend to think of underwriting rules as guardrails because that is essentially what they are. You know the range of risk you are comfortable writing, and the system needs to know what to do when a submission gets close to, or crosses, one of those boundaries.
The water heater example is one. A pool is another. You may be fine with the pool as long as there is a fence around it and certain other safety requirements are met. You may allow dogs but exclude certain breeds or sizes. You may be comfortable with a Coverage A amount as long as it stays within a certain percentage of the replacement-cost estimate.
None of those decisions are especially useful to the workflow if they only live in an underwriting manual. The system needs to know what the rule is and what should happen when an answer falls inside or outside it. Once those guardrails are built into the workflow, you do not need somebody interpreting the same guideline from scratch every time.
Which submissions need an underwriter?
Not every submission needs the same level of review, and underwriting is rarely just a choice between approve and decline. There are plenty of risks that sit somewhere in the middle, which is why we use different levels of edits in the system.
A warning may tell an agent that a certain answer is going to require additional documentation, but it still lets the quote continue. A referral can flag the submission for an underwriter to review before binding. A soft edit can stop the agent and require an underwriter to get involved before the quote can move forward. A hard edit means the risk falls outside the guidelines and cannot move forward through the normal workflow.
The carrier decides where those lines are, and those rules can change. If you are suddenly getting far more referrals than expected, or you are stopping risks that your underwriting team would have been comfortable writing, you can revisit the guardrail rather than accepting that as the permanent process.
The point is not zero human involvement. It is zero unnecessary human involvement. In the personal-lines workflows we support today, somebody is still entering or validating the information. The agent is still involved in binding the policy, and the insured still attests that the application information is correct. The technology helps decide where an underwriter needs to step in along the way.
How do you trust an automated underwriting workflow?
If you are going to let clean risks move through without an underwriter reviewing every one, the obvious question is: how do you know the system is doing what you intended? The answer is that you should be able to test those rules before you rely on them.
Within our platform, clients can preview how their underwriting edits will react before those changes go into production. You can answer questions in different ways and see what happens. If one answer should keep the quote moving, another should create a referral and a third should stop it, you can run through those scenarios before your agents are depending on them.
You can also decide that some things are worth watching without stopping the transaction. Maybe you are comfortable letting a policy bind, but you want your underwriting team to review policies afterward when a certain characteristic shows up. An exception report lets you do that without turning every one of those policies into a roadblock for the agent.
That is the balance you want: make the straightforward decisions faster without losing sight of what is moving through the book.
Why does data quality matter in automated underwriting?
You can build a perfectly logical underwriting rule around bad data and still end up with the wrong answer. We saw that with one of our customers when we were reviewing aerial-imagery data.
Two vendors were looking at the same image of the same roof after a hurricane and came back with very different interpretations. One essentially saw tree coverage around the roof. The other recognized that the tree had uprooted and fallen onto the house. That is a pretty important difference if you are using the vendor’s roof-condition score to help determine whether the risk moves forward.
Our VP of Underwriting caught the discrepancy while our team was reviewing the data. Once we dug further into the customer’s existing vendor, we started seeing other areas where we were not comfortable with what the data was telling us. Because we were also helping support that customer’s underwriting operation, we could dig into the problem, help evaluate whether the data source was giving them what they needed and look at other options.
That kind of discrepancy creates work because somebody has to determine which information is reliable before making a decision. More importantly, it can change the underwriting outcome. One vendor may send a good risk into review when it did not need to go there, while another may make a damaged property look better than it is and let it move further through the process than it should—all of which can increase operating cost, create unnecessary delays and change the carrier’s exposure based on the data used to evaluate the risk. The system can only make a decision based on what you feed it, which is why I don’t think vendor selection should be treated as completely separate from the underwriting technology conversation.
How does faster underwriting improve the agent experience?
Underwriting efficiency is not only an underwriting-team issue. Agents feel it every time they quote a risk.
If I am an agent, I want to know as soon as possible whether a carrier is a realistic option. I do not want to spend several minutes answering questions only to find out at the end that you are not writing any more of that risk because capacity is closed.
Capacity can be based on geography, product type, a particular mobile home park or any number of characteristics the carrier wants to control. If you only want 200 policies in a 500-unit park, for example, once those 200 are written there is no reason to make the next agent complete an entire quote before telling them they cannot write it.
Put that check as early in the workflow as you reasonably can. Saving a few minutes may not sound like much until you multiply it across thousands of quotes. An agent who spends eight minutes on a dead-end quote has lost eight minutes they could have spent helping somebody else.
That is why we think about where questions and eligibility checks belong, not just whether the system is capable of asking them. The order matters too.
Why do the people behind the technology matter?
Sometimes a client knows exactly what it wants the system to do, and sometimes it does not. We have had clients bring us their underwriting manuals and ask us to help work through how those guidelines should operate in the platform. We have also worked with companies launching product lines where they did not have the same depth of experience as we did.
That is when a technology conversation becomes an insurance conversation too. What should the guardrails be? What should trigger a referral? What information should you collect? Which vendor makes sense for the data you need? Are you seeing something in the book that suggests one of your rules deserves another look?
Those questions are harder to answer if the conversation is focused only on the software. We have spent decades working with different carriers and different lines of business, so there are areas where we can bring experience that a client may not have internally. There are large carriers that have leaned on our team to support books of business in product areas where they did not have that same level of operational experience.
That does not mean they do not know insurance. It means no company has to be the expert in every line, every process and every technology decision.
To me, that is where the difference between a software vendor and a partner starts to show up. The platform matters, but so does who you can call when something in the book does not look right.
Why should underwriting rules change over time?
The rules you launch with should not automatically become the rules you live with forever. Your appetite, loss experience and available data can all change, and sometimes the risks moving through the system show you that one of your original assumptions deserves another look.
Our underwriting team may notice, for example, that a group of risks looks pretty good but keeps getting referred or rejected because of the same rule. If the system is doing exactly what you told it to do, the problem is not the software. The better question is whether that rule still reflects what you want to write.
We may go back to the carrier and say, we are seeing good-looking risks here, but A, B and C keep knocking them out. Is that still what you want? That does not mean we make the underwriting decision for them. We bring them what we are seeing so they can decide whether the appetite needs to change.
The same principle applies to maintaining the rules themselves. Clients can already make certain changes to rating and underwriting rules without having us rebuild the system, and our Self-Service capabilities are making more of those routine changes easier for their own teams to manage.
You should not need a development project every time your underwriting appetite changes.
Underwriting at scale is about putting expertise in the right place
When I think about underwriting at scale, I keep coming back to the same idea: technology and underwriters should not be competing for the same job.
The system should do what systems are good at: apply the rules consistently, check the data, stop the clear noes, keep the clear yeses moving and send the gray areas to somebody who knows what to do with them. Underwriters should spend their time interpreting unusual situations, making judgment calls and helping the organization refine its appetite as the book evolves.
That gives agents faster answers, gives your underwriting team more time for the risks that need them and gives the carrier a better way to grow without turning every new submission into another manual task.
Technology provides the structure. People provide the judgment. You need both.
Frequently asked questions
Does underwriting automation replace underwriters?
No. The best use of underwriting automation is to handle repeatable decisions and route exceptions so underwriters can focus on risks that require experience and judgment.
What is an underwriting referral?
An underwriting referral happens when a submission does not clearly fit the normal path and needs an underwriter to review the risk before the quote or policy can move forward.
What is the difference between a soft edit and a hard edit?
A soft edit stops the normal workflow but allows an authorized underwriter to review the issue and determine whether the risk can proceed. A hard edit represents a condition that cannot be overridden within the normal workflow.
Why does data quality matter in automated underwriting?
Because the system is making decisions based on the information it receives. Inaccurate or inconsistent risk data can create unnecessary referrals, inappropriate declines or allow a risk to move forward without the review it deserves.
Can carriers change underwriting rules without a developer?
Yes, depending on the rule. Clients can already make certain rating and underwriting changes themselves, and self-service capabilities are making more of those routine changes easier to manage without waiting on a developer.
