Health / Insurance · Automation & RPA
Automating three back-office processes and turning down two others
Five automation candidates, timed on site. Three cleared the ROI threshold, two did not. We documented why and built only the three.
- Sector
- Health / Insurance
- Size
- 600 employees
- Service
- Automation & RPA
- Model
- Assessment then fixed prices
- Duration
- 2-week assessment, 3 robots in 11 weeks
Context
The back office manually re-keyed data between the member management tool, a partner extranet and a control spreadsheet. Management had an automation budget and a list of five processes supplied by the business teams.
The problem
- Manual re-keying between three systems with no interface
- Effort estimates supplied by the teams, never measured
- No API available on the partner extranet
- Previous automation attempt abandoned after six months
What we did
- Two weeks observing and timing the five processes as actually run
- Gap between reported and real time ranging from -40% to +25% depending on the process
- Three-year ROI calculation including maintenance, process by process
- Two processes ruled out: too infrequent for one, business rules changing quarterly for the other
- Three UiPath robots built with exception queues and named alerting
- Four weeks running in parallel before cutover on each robot
- Written and tested manual fallback procedure for each process
Results
- 3 / 5
- processes retained
- 1 840 h
- returned per year
- 9 mois
- payback period
- 99,2 %
- success rate at 6 months
What remains
The recovered hours were reallocated to handling complex files, not to headcount reduction — a condition set by management from the outset. The two rejected processes were covered by a note explaining why, which the client reused to arbitrate other internal requests.
« The most useful part of the assessment is the section explaining why two processes should not be automated. We still use it. »
Stack
- UiPath
- Power Automate
- SQL Server
- REST API