Insurance brokerage case study

Summary

A specialised insurance brokerage sells cover to medical aesthetic practices. It received 700 to 800 qualified leads a month and converted fewer than 20% of them. Agents spent 70% of their time on data entry. The project replaced paper applications with a question routing system, removed a middleware layer, and pre-filled insurance applications for electronic signature. Conversion rose above 50%. Application time fell from hours to 20 minutes. The client stopped spending more than $200,000 a year on infrastructure and maintenance.

Results

Metric	Before	After	Change
Conversion rate	<20%	50%+	150% increase
Application time	Hours	20 minutes	95% less
Infrastructure and maintenance cost	$200,000+ a year	$0	$200,000+ saved
Agent time on admin	70%	15%	55 percentage points less

The problem

Business context

The client insures medical aesthetic practices. Underwriting depends on the services a practice offers, the licences its providers hold, and the rules of the state it operates in. The client and its competitors worked from paper applications and phone interviews.

Business problems

graph TD A[700-800 Monthly Leads] --> B{Manual Process Bottleneck} B --> C[<20% Conversion Rate] B --> D[60%+ Abandonment Rate] B --> E[70% Agent Time on Admin] C --> F[Revenue Loss] D --> F E --> G[Cannot Scale] style A fill:#e3f2fd style B fill:#fff3e0 style C fill:#fce7f3 style D fill:#fce7f3 style E fill:#fce7f3 style F fill:#ffebee style G fill:#ffebee

Conversion

The client received 700 to 800 qualified leads a month and converted fewer than 20%. More than 60% of applicants abandoned the paper application. Manual qualification delayed the first response to each prospect.

Agent workload

Agents spent 70% of their time on data entry and administration. Incomplete applications needed several follow-up contacts. The client could not take on more volume without hiring more agents.

Systems

Lead capture, customer management, and order processing ran on separate systems. A person handled each step between them. A middleware layer sat between the front end and the back end. An audit showed that 85% of its operations were plain field mappings.

Constraints

Constraint	Requirement	Approach
Regulation	State insurance rules differ and must be applied	State rules coded into the question routing
Data security	Medical and financial data need protection	Fewer components, fewer credentials to manage
Continuity	Customer service must continue during the change	Old and new systems run side by side, gradual rollout
Budget	Existing budget and staff	Removing middleware cut cost
Time	Online competitors threatened market share	Three phases, each shipped on its own

What was built

Three phases

graph LR A[Phase 1
Intelligent Automation] --> B[Phase 2
Architecture Simplification] --> C[Phase 3
Document Automation] A --> A1[Dynamic Question Routing] A --> A2[Smart Qualification Engine] B --> B1[Middleware Elimination] B --> B2[Direct Integration] C --> C1[Auto-Fill System] C --> C2[E-Signature Integration] style A fill:#e3f2fd style B fill:#f3e5f5 style C fill:#e8f5e8

Phase 1: question routing

The team built a question routing engine that follows the same path a human agent takes in an interview. Each answer decides the next question. The engine qualifies the prospect for each insurance product as it goes and skips questions that do not apply.

Features:

Questions depend on earlier answers
Qualification for several products in one pass
State rules applied by location
Risk assessed from the services offered

Phase 2: middleware removal

An audit of the middleware showed that 85% of its operations were field mappings with no business logic. The team connected the user interface to the back end and kept the parts of the middleware that held real logic.

Outcomes:

66% faster response times
4x fewer failure points
85% less maintenance work
Fewer credentials and data copies to protect

Phase 3: pre-filled applications

The system writes an insurance application that is 90% complete from the answers collected. The customer reviews it and signs it online.

Outcomes:

20 minutes to complete, down from hours
90% less work for the customer
Electronic signature
Automatic submission

Technical detail

Routing engine

The engine is a decision tree. Service type and state select the path:

graph TD A[Customer Starts Application] --> B{Service Type?} B -->|Botox| C[Cosmetic Path] B -->|Surgery| D[Medical Path] B -->|Laser| E[Equipment Path] C --> F{State Location?} D --> F E --> F F -->|CA| G[CA Compliance Rules] F -->|TX| H[TX Compliance Rules] F -->|FL| I[FL Compliance Rules] G --> J[Auto-Qualify Products] H --> J I --> J style A fill:#e3f2fd style B fill:#fff3e0 style F fill:#fff3e0 style J fill:#e8f5e8

Multi-condition routing: the next question depends on combinations of earlier answers
State rules: compliance rules and product availability by state
Service-based qualification: risk assessed from the medical services offered
Product matrix: qualification for several insurance tiers in one pass

Architecture change

The team replaced a three-layer architecture with a two-layer design:

Before: three layers	After: two layers	Change
Frontend ↔ Middleware ↔ Backend	Frontend ↔ Backend	66% faster response
Multiple failure points	Direct connection	4x fewer failure points
Three sets of credentials and data copies	One connection to secure	Smaller attack surface
Middleware to maintain	No middleware	85% less maintenance

Rollout and testing

Parallel operation: old and new systems ran side by side while the team compared results
Feature flags: each change could be rolled out in stages and rolled back at once
Monitoring: response times and conversion tracked through the rollout
Parity tests: the new path had to produce the same underwriting output as the old one

Deliverables

Deliverable	Contents
Question routing system	Production application with decision trees, multi-product qualification, and state rules
Direct integration	Front end connected to back end, with the retained business logic in standalone modules
Document generation	Application pre-fill, electronic signature, automatic submission, and validation
Documentation	Architecture guides, API specifications, decision tree logic, migration steps with rollback, and agent training material

Findings

Most of the middleware did nothing

85% of the middleware operations were field mappings. They added maintenance work, credentials, and latency without business logic. Removing them was the largest single source of the cost and speed gains.

Customers finished the interview-style form

The question flow follows the order a human agent uses. Customers completed it where they had abandoned the static paper form. For this client, conversion rose from under 20% to over 50%.

Logic that was kept

Some middleware held real business logic. The team kept it:

Kept logic	Why	Location
Underwriting calculations	Pricing depends on them	Encapsulated algorithms
Service analysis	Risk assessment accuracy	Standalone modules
Multi-source data matching	Needed for decisions	Direct integration

Security

Going from three layers to two removed a set of credentials, a data copy, and a synchronisation path. The security gain came from having fewer components to protect.

4x fewer failure points
Fewer credentials to manage
No data synchronisation between layers

Business impact

Operations

Conversion

Conversion rose from under 20% to over 50% on the same lead volume of 700 to 800 a month. At 700 leads, that is about 140 new customers a month before and 350 after.

Agent time

Administrative work fell from 70% of agent time to 15%.

Agent activity	Before	After	Change
Administration	70%	15%	-55 percentage points
Relationship work	20%	60%	+40 percentage points
Sales	10%	25%	+15 percentage points

Application time

A customer completes an application in one 20-minute session. Before, it took several hours across several contacts.

Incomplete applications

The structured questions removed 90% of incomplete applications and the follow-up calls they caused.

Financial impact

Cost

The client stopped paying the $200,000 or more a year that the old infrastructure and its maintenance cost.

Revenue

Conversion rose 150% on the same lead volume, so revenue rose without extra spend on lead acquisition.

Payback

The savings and the extra conversions covered the project cost within 4 to 6 months.

Months 1 to 3: build and training
Months 4 to 6: break-even

Technical architecture

Components

graph TB subgraph "User Layer" A[Customer Interface
Conversational Forms] B[Agent Dashboard
Productivity Tools] end subgraph "Intelligence Layer" C[Dynamic Question Router
Context-Aware Logic] D[Auto-Qualification Engine
Multi-Product Assessment] E[Document Generator
90% Pre-Fill] end subgraph "Data Layer" F[Direct Backend Integration
No Middleware] G[Compliance Engine
State-Specific Rules] H[Signature System
Electronic Processing] end A --> C B --> C C --> D D --> E C --> F F --> G E --> H style C fill:#e3f2fd style D fill:#f3e5f5 style E fill:#e8f5e8 style F fill:#fff3e0

Two layers: the user interface calls the back end through native APIs. There is no middleware.

Routing engine: decision trees with multi-condition routing and question generation.

Data: one record per customer, with no copies to keep in sync.

Security and compliance

Area	Implementation	Purpose
Transport and input	HTTPS only, credential management, input validation	Blocks common attack paths
Regulation	State-specific routing, audit trails, data protection	Insurance and healthcare privacy rules
Access control	Role-based permissions, session management, authentication	Limits who sees customer data and logs activity

Extending the system

New products and states are added as new branches in the decision tree. Carrier platforms and reporting systems connect through standard APIs.