Claims Intake Automation for a Regional Insurance Provider

Client context

A regional property and casualty insurer whose claims arrived by email in every format imaginable: more than thirty broker form layouts, scanned paper forms (occasionally handwritten), photos, and repair invoices mixed into the same threads. I built the document pipeline, the review workflow, and ran the rollout with the intake team.

The problem

A four-person intake team read each submission and re-typed the details into the claims platform: policy number, claimant, date of loss, description, estimated amount. On a normal week they kept up. During storm season, claim volume tripled and the backlog stretched to five working days — meaning a customer with a leaking roof waited a week just for an acknowledgment. The insurer was also missing its own service commitment of responding within one business day.

Re-typing brought quieter problems too. A transposed policy number sent a claim to the wrong file. Mis-keyed dates of loss raised coverage questions later. Every downstream step inherited the intake errors.

The automation I built

I built the intake pipeline on UiPath, with Document Understanding doing the reading. A robot watches the claims mailboxes and the broker portal export. Every incoming document gets classified first — claim form, invoice, photo, correspondence — because you can't extract data from a document until you know what it is. Claim forms then go through OCR extraction, which returns each field with a confidence score.

Those scores drive everything. Extracted data is validated against the policy database: does the policy exist, was coverage active on the date of loss, does the claimant match the policyholder? A duplicate check runs before any record is created, since claimants often email twice. When every field clears its threshold, the robot creates the claim through the platform's REST API and sends the claimant an acknowledgment with their reference number. When any field falls short, the whole claim routes to a review station in UiPath Action Center, where a person sees the original document and the extracted fields side by side.

We drew a hard scope line at intake. The automation gets a clean, validated claim into the system; humans decide everything after that. Nobody's coverage decision is made by a robot — and being able to say that plainly mattered a great deal to the client's compliance team.

• Monitors shared claims mailboxes and the broker portal export around the clock
• Document classification separating claim forms, invoices, photos, and correspondence
• OCR data extraction across 30+ broker form layouts, with per-field confidence scores
• Validation against the policy database: active coverage, date of loss, claimant match
• Duplicate claim detection before any record is created
• Human review queue in UiPath Action Center for low-confidence extractions
• Automatic acknowledgment email to the claimant with their claim reference
• Structured intake data delivered to the claims platform via REST API

What made it hard

Handwriting was the first fight, and we chose not to fight it. Handwritten forms are a small share of volume and OCR accuracy on them wasn't dependable, so the classifier routes them straight to the human queue. Automating 100% of documents badly is worse than automating 85% of them well.

Threshold tuning took real iteration. Set confidence limits too strict and everything lands in the review queue — you've built an expensive document viewer. Too loose, and bad data slips into the claims system, which is far worse. We tuned per field: a policy number must be near-certain because little downstream catches a wrong one, while a free-text description can tolerate more. We landed at roughly 70% straight-through processing.

The people side needed as much attention as the pipeline. The intake team initially saw the project as their replacement. We brought them in as the reviewers and the source of truth for edge cases, and their catches during testing shaped the validation rules more than any spec did. By go-live, two of the four had moved into adjudication support roles the department had been unable to staff.

One technical footnote: the claims platform's API covered record creation but not attachment upload, so a small UI automation handles that single step. I kept it as isolated as possible — when the vendor ships the endpoint, one workflow gets deleted and nothing else changes.

Results

Intake went from the department's bottleneck to its quietest step:

• Average intake time per claim went from about 25 minutes to under 5; straight-through claims complete in under 2
• Roughly 70% of claims are processed without a human touching them; the rest are verified in the review queue
• Claimants receive acknowledgment within the hour instead of after two or three days
• Sampled audits put intake data accuracy above 99%, and policy-number errors have effectively disappeared
• The next storm season's volume spike was absorbed with no backlog and no overtime

Business impact

The most visible change is speed at the front door: acknowledgment inside an hour changes how a claim feels to the customer, especially after a storm. Internally, adjusters now start from clean, validated records, which shortened their handling time too — an effect nobody had put in the business case. The intake team shrank through redeployment rather than layoffs, and the review-queue pattern became the template for the insurer's next automation projects.

Lessons learned

Confidence thresholds are a business decision wearing a technical costume. Where you set them determines the trade-off between throughput and risk, and that call belongs to whoever owns the risk — I learned to put actual numbers in front of the client and let them choose. The other lesson: the human review station deserves as much design effort as the extraction pipeline. Its usability set the ceiling for the whole system's throughput, because every automation eventually funnels its hardest cases to a person.

Stack