Six processes, one system: how an insurer went from a first bot to an automation programme

1.5 million broker emails. A backlog of 4,000 claims files. Thousands of cases a day. How one insurer automated six core processes, and why the technology turned out to be the smallest obstacle.

1.5 million emails a year from the broker network. A backlog of 4,000 unprocessed claims files that was putting the company’s rating with the regulator at risk. On top of that, thousands of cases moving through claims handling every single day. That was everyday life at an insurer belonging to one of the largest insurance groups in the world. The pain points sat in four different departments, from support and finance through to new business applications.

Today the company’s most important central processes run automatically, from contract creation to premium refunds and broker communication. The interesting question is why a single automation project grew into a programme that reshaped the entire organisation. How any one of those bots works matters much less. The answer has less to do with technology than most people assume. It comes down to three steps that happen before the first bot is ever built.

Why most companies stall after their first bot

Plenty of automation initiatives start with a pilot and finish there. The first bot goes live, the team celebrates, and then not much happens. Nobody has answered the questions that come after the pilot. Which process is next? Who decides priorities when three departments are all shouting at once? Who runs the bots once there are more of them? Without those answers the loudest stakeholder usually wins, and the company automates whatever happens to be politically convenient at the time. The business case becomes a matter of luck. There is a second pattern on top of that. The pilot is carried by a handful of enthusiasts, but nobody has settled who maintains the bots, who fixes errors and who responds when a process changes. Six months later the bot is orphaned even though the technology works perfectly well. Operations were simply never planned.

Our insurance client went a different way, because they got the order right. First a strategy with an operating model that assigns responsibilities. Then the systematic selection of processes. Every process that made the cut was analysed properly before anyone wrote a line of code. All six automations were later built on that foundation.

Step one: getting the order right

The starting question was where automation would achieve the most. Answering it meant a strategic process identification and an assessment of the process landscape by volume, rule-based structure and economic impact.

Claims processing came out on top. 1,500 cases a week, eight minutes each on average, plus the backlog of 4,000 claims files that was weighing on the rating with the local regulator. The topic had attention all the way up to the board. Four weeks after the project started, the first UiPath robots were in production. They run 22 hours a day, create the files from structured input data, reconcile internal databases and report status back to the case handlers. A month later the backlog was at zero.

That first success served a purpose well beyond itself. A visible quick win with numbers everyone understands buys an automation programme the one thing it needs most, which is trust.

Step two: rethink the process instead of copying it

Process identification also delivered more than just the first candidate. What came out of it was a scored pipeline, with estimated effort, expected benefit and technical feasibility for every process. A vague intention to do something with automation became a roadmap with an order of play and a business case per process. That pipeline drove the five automations that followed.

The most common mistake in automation is speeding up a bad process without changing it. The bot then takes exactly the same detour a person would, only without complaining about it. That is why business analysis and solution design come before every implementation. What should the process do in future? Which steps can go? Which technology fits which step?

Contract creation shows how much difference this makes. The insurer writes new contracts through its field sales force and an online portal in the contract management system SCOUT; all of that data then has to be transferred manually into the LF4 policy administration system. The obvious route would have been to read the PDF contracts with text recognition. The analysis found something better. The contract data is already structured, so the robot receives every contract as an XML file over a file share, and the error-prone business of reading PDFs disappears entirely. Processing is 80 per cent faster, accuracy sits at 95 per cent, and 0.85 FTE were freed up.

Broker communication makes the same point about matching technology to the problem. 1.5 million emails a year, unstructured, with attachments, under the pressure of service level agreements and regulatory requirements. RPA on its own would not have got far here, because bots can click but they cannot read. The solution combines machine learning, natural language processing and intelligent OCR on the UiPath platform. The robot understands the content of each email in context, extracts the documents it needs and only asks a human when it needs an instruction. 98 per cent of cases now run without any intervention. 2,000 hours a month were freed up, and the cost per transaction fell by 91 per cent.

Step three: scale once the foundation holds

With an operating model and a priority list behind them, every further process became faster and cheaper. Governance worked, the infrastructure ran, and the business units knew how working with the automation team actually goes.

Three more processes followed. In claims handling, the insurer automated tasks across twelve of its most critical applications, including support calls after an accident, preliminary analysis of certain claim types, data entry for direct costs and changes of policyholder. Each employee now handles 15 per cent more claims, and calls in the contact centre take half as long as they used to. For premium refunds, a bot triggers the postings in SAP and then settles the credit balance in the customer management system; the investment had paid for itself after 6 months. In payment processing, where too many emails and too little time were dragging morale down, processing time fell by 80 per cent, time spent in the inbox by 56 per cent and call volume by 38 per cent. Between the first process and the sixth, the road from idea to go-live also got noticeably shorter; what took months of coordination the first time round had become routine.

The most telling figure from this phase barely shows up in any business case: 75 per cent fewer overtime hours in the support team. Automation is often described as a threat to jobs. Here it was the reason people got home on time again and satisfaction in the team went up.

The results

Six processes at one company, all built the same way. Here is the overview:

Process	Results
Claims processing	Backlog from 4,000 to 0 in one month · 75 % of the workload automated · live in 4 weeks
Contract creation (new business)	80 % faster processing · 95 % accuracy · 0.85 FTE saved
Broker communication	98 % fully automated · 2,000 hours saved per month · 91 % lower cost per transaction
Claims handling	15 % more cases per employee · 50 % shorter call times · 100 % data accuracy
Premium refunds	0.8 FTE freed up · 3 % error rate · payback after 6 months
Payment processing	80 % less processing time · 75 % fewer overtime hours · 70 % shorter turnaround times

The time savings listed here alone add up to several thousand hours a month. That time now goes into customer contact and into the exceptional cases that really need human judgement.

What happens after go-live is part of the picture too. The bots from these six processes are monitored, maintained and developed further in live operation, for instance when a core system gets an update or a business unit raises a new requirement. Automation has no end date. It is an operational discipline, and that is exactly why it needs an operating model.

What other companies can take from this

None of this story is specific to insurance. High volumes and broken handovers between a specialist application and a legacy system exist in every industry. An audit firm setting up client engagements, a retailer posting 40,000 invoices, and in this case an insurer creating claims files: the patterns look alike, only the systems have different names. What transfers is above all the approach. An operating model that clarifies priorities and responsibilities (strategy consulting and automation operating model). Systematic selection of the processes with the greatest impact (strategic process identification). And for every process, a target design with the technology to match, drawn up before anything gets built (business analysis and solution design).Strategieberatung & Automation Operating ModelStrategische Prozess-IdentifikationBusiness Analyse & Solution Design

Companies that take this route stop running individual automation projects. They build a capability that gets more valuable with every use case.

Wondering how much automation potential sits in your own company? Talk to us. A first conversation costs nothing but an hour of your time. No sales pitch, just a straight assessment.