From broker submission to a decision-ready case: how underwriting automation works
Between the broker’s email and the underwriting decision, even the most experienced underwriters can lose valuable time. Not because of expert assessment, but because they repeatedly have to determine whether the case is complete, current, and ready to move forward. In this article, we show how the Underwriter Portal turns the first message into a structured case prepared for analysis and recommendation — so that real underwriting can begin where it should: with risk assessment.
What you need to know
- Underwriting automation does not have to mean automating the final underwriting decision. In the model described by Altkom Software, it structures and automates the work that precedes it: submission intake, triage, completeness checks, document analysis, prioritisation and broker communication.
- A broker submission becomes a case with an owner, status and history, and reaches the underwriter together with a recommended next step, its rationale and the sources behind it. The underwriter reviews that recommendation and can accept, modify or reject it.
- In underwriting process assessments conducted in 2025–2026, the identified potential included a 20–30% reduction in Time to Quote, broker response times of as little as 24 hours and an increase in input data quality from 62% to 92%. Actual results depend on the organisation’s workflow, data quality, eligibility rules and operating model.
First the process, then automation
Underwriting automation often makes teams cautious, especially when it is associated with systems taking over decisions. That is why, in the previous article, we explained our approach: we do not automate the underwriter’s decision. We organize everything that has to happen before that decision.
What is the Underwriter Portal?
The Underwriter Portal is a solution concept developed by Altkom Software to support the work that happens before an underwriting decision. Its purpose is to turn a broker submission into a case that can be moved forward with control: assigned, verified, completed, and prepared for analysis.
The concept was created based on an analysis of underwriting processes, including commercial and corporate underwriting. It assumes that the workflow, rules, and configuration are adapted to the way a specific organization operates.
In the following sections, we show what this process can look like step by step.
From submission to underwriting case
A broker submission does not have to enter the organization as just another email to decipher. It can immediately become a case: assigned, visible in the process, and ready to be moved forward.
An email alone does not show whether we have a complete set of data, whether this is a new case, a supplement, a reply to an earlier question, or another version of a document. In the Underwriter Portal, this type of request receives structure from the start: it is clear what it concerns, who owns it, what status it has, and what should happen next.
This matters not only for the underwriter’s day-to-day convenience. The quality of intake data affects quote quality, response time, and the throughput of the entire process, especially as submission volumes grow. The sooner the broker and insurer work from the same structured context, the easier it is to prepare a quote that addresses the end customer’s needs.
One view of current work
When several or a dozen cases are moving in parallel, it is easy to lose sight of what truly requires attention. One case is waiting on the broker, another is approaching a deadline, a third has high priority, and a fourth looks quiet only until someone checks its status.
In the Underwriter Portal, the main panel acts as an operational view of the team’s work. On screen, it may look like a simple task list, but underneath, each case carries the information needed for the next step.
Instead of starting the day by refreshing the inbox, reviewing files, and trying to remember prior arrangements, the team sees cases with their context and history. This makes it easier to decide what requires escalation, where additional information is needed, and which matters can move calmly into further analysis.
Triage organizes the entry point into the process
Not every case should go straight to an underwriter. Some submissions need to be routed to a specific person or team from the start. Some should receive higher priority. Others do not meet the basic conditions required to proceed.
In the Underwriter Portal, triage works as the first gate in the process. The system recognizes whether a case can move forward, whether it requires additional information, whether it contains process or eligibility issues, and what priority it should receive.
Triage is not a fixed set of labels imposed on every organization. It should reflect the rules adopted by a specific company: formal requirements, policies, work structure, and the way brokers are served. As a result, the system does not “guess” what to do with the case. It consistently applies the rules agreed within the process. Example labels may include:
- Hard stop — the case does not meet a mandatory condition required for further processing.
- Soft stop — the case requires underwriter attention because there is an obstacle, exception, or risk to assess.
- Pre-scoring — the system prepares a starting point for analysis: it shows what appears standard, what requires review, and where risks may arise.
- Priority — the case receives its place in the queue based on the organization’s rules, not on who called most recently or applied the most pressure.
Well-configured triage gives the team faster orientation: what to handle immediately, what to send back for completion, and what can wait without losing control of the case.
Data completeness as a condition for moving forward
In a traditional process, missing information often appears too late — only after the underwriter has opened the case and started working with the materials. That is frustrating because the analysis is interrupted not by a difficult risk, but by something that should have been visible earlier.
In the Underwriter Portal, data completeness becomes a condition for moving to the next stage. The system checks the case against the checklist adopted by the organization: whether the required documents, fields, attachments, and information needed for further work are present. If something is missing, the gap is linked to the case, status, and next step.
OCR and AI prepare the materials for decision
In processes based on broker submissions, forms, reports, schedules, and correspondence, a lot of time can be spent simply determining what the documents actually say. This is not risk assessment yet. It is an earlier stage: reading the data, organizing the information, and checking whether the materials are even suitable for further analysis.
In the Underwriter Portal, OCR and AI perform this work at intake. The system reads data from documents, compares it with information from available sources, and identifies missing items, discrepancies, outdated documents, and areas that require additional verification. It also shows what the analysis was based on — meaning which documents, data, or databases were taken into account.
As a result, the underwriter does not start by manually digging through materials. They receive a case summary, a list of items to review, and a clear signal showing which information is consistent and which requires clarification.
Decision recommendation with rationale and supporting sources
The Underwriter Portal does more than identify missing information and organize documents. Using the data collected, applicable process rules, and available sources, it provides a well-supported starting point for the underwriting decision.
The underwriter receives:
- a recommended decision or next course of action,
- a clear rationale explaining the basis for the recommendation,
- references to the documents, data, and sources used in the analysis,
- a list of areas that require further analysis or expert review,
- a proposed approval path if the submission requires input from a manager, another underwriter, or an additional team.
Where the product parameters allow, the recommendation may also include proposed coverage, coverage amounts, key conditions, or limits. The system presents not only the recommended course of action, but also the supporting factors, any inconsistencies, and the points where human judgment is required.
This means the underwriter does not have to start from scratch or piece together information from multiple sources. Instead, they receive a prepared analysis for review, which they can accept, revise, or reject if their expertise and understanding of the submission lead them to a different conclusion.
Broker communication without breaking the context
Additional information from the broker should go directly into the right case, not live as another email that someone has to match manually. In the Underwriter Portal, questions, answers, and attachments are linked to a specific missing item, status, and next step.
When the broker responds, the team can see whether the issue has been resolved or still requires clarification. There is no need to go back through several earlier messages to understand what was requested and what is blocking further work.
This keeps broker communication direct without taking it outside the workflow. Both sides work from the same context, and the case can return to analysis faster.
Iterations and negotiations without losing history
The first submission rarely ends with the final quote. Along the way, there are questions, additional data, changes in scope, adjustments to terms, and new versions of documents. If those arrangements live mainly in correspondence, it is easy to lose confidence in what is current and why the quote took its final shape.
In the Underwriter Portal, every iteration is assigned to the case: a scope change, comment, rationale, broker response, or another version of the quote. This means the team sees not only the latest document, but also the path that led to it — what changed, why, and on what basis.
This makes the current case easier to manage and also preserves knowledge inside the organization for the future. A full history helps maintain process consistency, reconstruct the sequence of arrangements, and handle similar cases more effectively.
SLA and priorities visible in real time
SLA performance is difficult to maintain when case status has to be reconstructed after the fact from emails, notes, and conversations. In that situation, the team often sees where a case got stuck and who should have taken the next step only after a delay has already occurred.
In the Underwriter Portal, deadlines and priorities are part of the process, not a separate report prepared manually. The case immediately shows whether it is within SLA, whether it is waiting on the broker, whether it requires a team response, and how urgent it is compared with other matters.
This makes the order of work easier to justify. It is not based on the latest email, a phone call, or pressure from a specific person. It is based on the rules adopted by the organization: deadline, case value, risk type, customer segment, data completeness, and other parameters agreed within the process.
What does the Underwriter Portal actually change?
The portal does not change just one step in the process. It changes the way a broker submission moves through the organization: scattered correspondence and loose attachments become a case that can be assigned, verified, completed, and brought to decision.
How much time can you save before the underwriting decision?
Based on underwriting process assessments conducted in 2025 and 2026, we have seen that streamlining the work leading up to a decision can materially reduce time to quote, enable faster responses to brokers, and improve the quality of the data available to underwriters.
In the operating models reviewed, the identified potential included:
- 20–30% reduction in time to quote,
- broker response times of as little as 24 hours,
- increase in input data quality from 62% to 92%.
These figures are not universal and do not represent guaranteed implementation outcomes. Actual results will depend on the current workflow, data quality, the number of back-and-forth exchanges with brokers, submission eligibility rules, and the team’s operating practices.
