Why Insurance Applications Get Keyed Three Times Over
Mid-market carriers re-key the same application into lead, workbench, policy admin, and archive. The fix is connecting two systems you already own.
TL;DR. We have watched the same application data get typed into three or four systems at four different mid-market insurance carriers in the last 18 months. The pattern is consistent: lead capture, agent workbench, policy admin, compliance archive. McKinsey puts underwriter administrative time at 30 to 40 percent, and most of that is re-keying. The fix is rarely a new platform. It is connecting two systems you already own, in the right order.
Insurance application re-keying persists because nobody owns the seams between systems. Sales bought the lead system. Distribution bought the agent workbench. Actuarial and claims own policy admin. Compliance owns the archive. Each tool was bought by a different team to solve a different problem, on a different budget cycle, and the data crossing between them is somebody's manual job. That somebody is usually a back-office processor or, worse, the underwriter herself. McKinsey has been saying for years that 30 to 40 percent of underwriter time is administrative, most of it re-keying. We see this every week in mid-market carriers between $30M and $200M in premium.
What this actually looks like at a final expense carrier
Walk a single application through and you can see where the headcount goes.
A 68-year-old in Tampa fills out a final expense quote form on a lead vendor site. Hometown Quotes, NextGen Leads, Senior Market Sales, pick your vendor. The lead lands in the carrier's CRM, often Salesforce with a Sales Cloud or Financial Services Cloud configuration, sometimes an older Velocify install that nobody has wanted to migrate. A licensed agent in the call center calls within four minutes, because lead aging crushes conversion. The agent re-keys the prospect's name, date of birth, beneficiary, and health questions into the agent workbench, which is usually a quoting and e-app product like iPipeline iGO, Ensight, FireLight, or an in-house React app that wraps the carrier's rate tables. That is keying number two.
The agent submits the application. Now it has to land in policy admin. For a mid-market carrier, policy admin is one of three things: a Duck Creek install (newer carriers, expensive), an Applied Epic environment that the carrier extended beyond its agency-management roots, or a green-screen system the company has been running since 1994 that everyone is afraid to touch. The submission rarely flows through clean. A processor opens the e-app PDF and types the same fields into a 3270 emulator or a Duck Creek policy entry screen. That is keying number three.
The policy issues. A copy of the application, the policy document, and any underwriting evidence get archived to a compliance system. NetDocuments, iManage, Laserfiche, or a SharePoint folder that compliance treats like a record system. Sometimes there is a fourth re-key into the BI warehouse, usually a Snowflake or SQL Server install where the actuaries pull persistency and lapse reports. That makes four touches of the same data, and we have not even gotten to claims yet.
Why this is structural, not lazy
The reflexive answer is that the people involved should just be more careful, or that the carrier should buy a unified platform. Both miss the point.
Final expense is a high-volume, low-face-amount product distributed almost entirely through independent agents. The LIMRA-Life Insurers Council Final Expense Survey reported 1.06 million policies sold in 2024 across 28 carriers, with 86 percent of those policies sold through independent distribution. Independent distribution means the agent does not work for the carrier. The agent works for an FMO or IMO, who has contracts with eight to twelve carriers, and each carrier expects the agent to use a different e-app product. The agent picks one, the lead system speaks a different one, the carrier's policy admin schema is older than both, and the data hand-offs were never designed.
When carriers try to fix this with a unified platform, the project runs three years, the executive sponsor leaves, and the carrier ends up with the same problem plus a new line item. We have written before about why ripping out the core system is almost never the right move, and the same logic applies upstream. The policy admin system is calcified for a reason. It has 18 state filings worth of rate and form logic baked into it. You do not get to start over.
The other reflexive answer is offshore data entry. We have watched carriers stand up a 12-person team in Manila to clear submissions. Throughput goes up for six months, then error rates climb, then a state regulator finds a misfiled beneficiary in a claims audit, and the carrier ends up paying penalties and rebuilding the process anyway. Hiring against the symptom is expensive and slow.
The fix: two systems, the right order
The work we do here is almost never a new platform. It is connecting two systems the carrier already owns, in a specific order, and instrumenting the seam so the ops VP can see what flows and what fails. Here is the order that has worked at every mid-market carrier we have helped.
Step 1: stop re-keying between the lead system and the agent workbench
This is the highest-volume seam and the lowest-risk one. The data is structured (name, DOB, contact info, basic health), the agents touch it every day, and a broken integration is recoverable in seconds because the agent is on the phone with the prospect. Build a bidirectional connection between Salesforce (or whatever lead system the carrier runs) and the e-app product. When the agent opens the application, it pre-fills. When the agent submits, the lead status updates automatically.
Two things happen after this lands. Agent productivity rises 15 to 25 percent because they stop typing the same nine fields. And the carrier gets clean source data for everything downstream. Lumenalta's research on insurance data modernization is consistent with what we see: phased data work cuts errors and processing time materially before any AI gets involved. The big number people quote in this space, 75 percent error reduction or thereabouts, is what you get when humans stop being the integration layer.
This is also the step where the ops VP learns what AI actually does and does not do for an insurance workflow. We have written separately on what AI works for in mid-market insurance ops, and the short version is: AI is good at pulling structured data out of unstructured documents (loss runs, medical records, application PDFs) and bad at deciding edge cases. Use it where it adds value and stay out of the rest.
Step 2: push structured data forward from the workbench to policy admin
Now you have clean data at the workbench. The next seam is the hard one. Policy admin schemas are old. Some Duck Creek installs accept modern API calls and you can pipe the application through cleanly. Some carriers are running a policy admin system that only accepts batch files or, worse, only accepts data through a screen-scraped session. We have built RPA bridges for that case. They are not glamorous, but they work, they remove the keying job from a human, and they are fast to ship.
Decerto's underwriting workbench guide is a reasonable reference for what a modern workbench-to-policy-admin integration looks like when both sides cooperate. Newer entrants like Cognisure are reframing the intake problem by extracting structured data straight out of ACORD forms and loss runs. The point is not which vendor you buy. The point is that the seam between workbench and policy admin is where the carrier learns whether the upstream data is actually clean. You will find edge cases here. Run them with a single underwriter for two weeks before you scale.
Step 3: archive automatically from policy admin to compliance
This is the cheapest seam, and most carriers do it last because the savings are smaller. Once policy admin has clean structured data and a generated policy PDF, archive the document to NetDocuments, iManage, or whatever compliance is on, with the right metadata for retention. This is almost always a one-week project. We do it last because it is the easiest to do correctly once the upstream is clean. Doing it first means you are just archiving messy data faster.
Why this order matters
Agent ROI is fastest at step 1. The carrier sees lift in the first month and the call center floor gets behind the project. You also de-risk step 2, because by the time you are touching policy admin, the data going into it is clean, structured, and source-of-truth. The data quality issues that would normally surface in policy admin show up two months earlier, at the workbench, where they are cheaper to fix. Step 3 is straightforward because you are not retrofitting metadata onto noisy records.
Carriers who try to do this in reverse order get stuck. Policy admin integrations that ingest dirty upstream data become permanent. Compliance archives that index off bad metadata are worse than no archive. We have seen one mid-market carrier sink $1.4M into a policy-admin-first integration project that they had to rebuild a year later, because the input data quality never got addressed.
What you stop doing
When you connect the seams in the right order, four jobs go away. Not four people, four jobs. The processor who re-keyed e-apps into policy admin stops doing that and starts working exceptions. The underwriter who re-keyed medical evidence stops, which gets you a chunk of the 30 to 40 percent McKinsey number back. The compliance clerk who manually filed PDFs stops. And the BI analyst who reconciled data between policy admin and the warehouse stops chasing mismatches and starts building reports the actuaries actually asked for.
The headcount math is rarely a layoff. It is reallocating people from typing to thinking. That is how you actually move the needle at a mid-market carrier without a three-year migration.
FAQ
Do we need to rip out our policy admin? No. The whole point is that you do not. Most mid-market carriers we work with keep their existing policy admin (Duck Creek, Applied, or a legacy mainframe) and connect modern systems around it. The integration layer can speak whatever the policy admin speaks, including 3270 screens if that is what we get.
How long does this take to implement? Step 1, the lead-to-workbench connection, ships in six to ten weeks. Step 2, the workbench-to-policy-admin seam, takes three to six months depending on what the policy admin will accept. Step 3 is typically two to four weeks. Total elapsed time is six to nine months, but you are getting value from week eight onward, not at the end.
What if our agents work outside our agent workbench? Most do, at least some of the time. A serious final expense agent has four or five quoting tools open. The fix is to make your workbench the easiest one to use for your products, with the lead data already pre-filled, so the agent picks yours by default for the business that matters to you. We do not solve the agent's whole workflow, we solve the part that gets your applications in clean.
Where does final expense fit specifically? Final expense is the worst version of this problem because of the volume and the independent distribution. With 1.06 million policies a year flowing through 86 percent independent channels, the carrier touches the data after three other parties have already touched it. That is also why the ROI is the largest here. The same approach works for term life, simplified-issue UL, and supplemental health, but the unit economics of final expense make it the place to start.
Will compliance accept this? Compliance generally loves it, once they see the audit trail. The reason is that connected systems with logged hand-offs produce a cleaner audit record than humans re-keying PDFs. We bring compliance in during step 1, not at the end, so they help design the metadata schema and the retention rules. That avoids the rebuild at step 3.
If this sounds like your Tuesday
We have spent the last 18 months in mid-market insurance ops shops, watching the same application data get typed four times. At Granular we build the connective tissue between the systems carriers already own, in the order described above, with the ops VP as the customer rather than the CIO. That means measurable lift in the first eight weeks, no platform migration, no offshore team. If you are running a $30M to $200M carrier and your underwriters are spending 30 to 40 percent of their time keying data they already have, we should talk. Book a 30-minute discovery call and bring an application. We will trace it through your stack with you and show you which seam is worth fixing first.
Keep Reading
- AI for Mid-Market Insurance: What Actually Works. A clear-eyed look at where AI delivers real lift in carrier operations and where it stalls, with examples from final expense, term life, and supplemental health.
- How to Cut Claims Processing Time Without Replacing Your Core System. The downstream version of this problem: how to shorten cycle times in claims by connecting what you have, not migrating off it.