During 2023, we had an opportunity to remove a large portion of manual processing and keying from our universal credit (UC) application process. In order to streamline our claim response process, we built a solution using Microsoft Power Automate RPA to imitate the behaviours of our users. The resulting benefits included improved application response rates, greater accuracy and cost savings by significantly reducing the time needed to process our massive flow of UC claims.
RPA (robotic process automation) has proven to be a valuable solution for streamlining repetitive manual tasks. One particularly compelling use-case is managing the influx of UC applications that housing providers receive each year.
These applications demand multiple rounds of manual review, logging and response via the DWP’s web form, making it a tedious and time-consuming process. A single application might only take a few minutes but when you’re dealing with approximately 4,500 applications at the end of the financial year, it translates to weeks of work.
Imitating human actions
To address this challenge, we embarked on a large RPA project with two primary goals: to alleviate the workloads of our rent and income teams; and to avoid creating additional tasks for them. Since an API wasn’t available, our only option was to create a process that could imitate human actions, including logging in, managing a to-do list of claims, associating them with our customers, and completing each claim.
This endeavour presented an exciting challenge due to the variability of customers’ data. Without a unique identifier such as a ‘tenancy reference’ on the UC portal, we relied on matching customer names, which often differed significantly. By refining our matching criteria, including postcode and date of birth, we achieved an 80 per cent match-rate for claims, an impressive result considering the inconsistent data provided by UC applicants.
Variable customer-provided data
For example, a customer named John Smith in OpenHousing might have provided their name as J. Smith, John M. Smith, Jon Smith or even spelled their name wrong with a slip of the keyboard (the latter case being very difficult to write an algorithm to account for).
We were immensely lucky to speak to another housing provider who had successfully tackled a similar challenge; our heartfelt thanks to Phil Nichols and Hassan Bahrani from Thirteen Group who gave us their time to look at their solution, giving us inspiration for our own.
Data extraction, pairing & matching
Our approach involved using web-scraping tools in Microsoft Power Automate Desktop to login and extract the data from the to-do list which we articulated into claim records in SQL. Using the details from the claim such as the customer-provided name and postcode, we paired the claim with the customer data from OpenHousing and calculated the fields we would need for any given UC claim (such as rent, service charges, number of bedrooms, number of tenants and so on).
We now had a complete ‘claim detail’ record for each claim we were able to match on. At this point, we relied heavily on our income and rent team (thanks to Ayshea Wall, Siama Aslam and Natasha Morris) to check that this data was correct and matched the calculations that they themselves would output; this was crucial to our aims because we wanted to replicate the day-to-day user process.
To navigate the UC portal, we developed a solution in Power Automate Desktop using the URLs from the matched claims and the field data we stored in SQL to populate the pages of forms using Microsoft’s tools to identify form fields relying on attributes such as ID and label.
40-second claim processing…
After two weeks of adjustments and data validation we conducted micro-testing, where our developers worked closely with our income team to process claims one-by-one. Once we had accommodated for elements such as web pages timing out, cases that had been closed by another team member or situations where the customer wasn’t fully set up in our housing system, we escalated our testing. Rapid testing began, where the ‘robot’ autonomously processed claims every 40 seconds and we would only confirm the final numbers before submission.
This was a huge confidence boost not only for our development team but also for our income team whom we were building it for, because we experienced an error rate of around only one per cent among the initial cases we tested, all of which were easily resolved, usually due to a missed service-charge mapping.
Removing human frailty
The benefits of this RPA solution include the ability to operate outside normal business hours and it doesn’t get tired or bored! It eliminates the risk of human error over extended periods and it articulates its session results via email. Additionally, it’s also capable of updating OpenHousing via APIs to log the session in customers’ diary notes. Decoupling the data from the ‘robot’ enables us to analyse data and generate reports, and make changes without affecting multiple steps in Microsoft Power Automate, giving us a high level of agility.
At the moment, our solution runs three times a week to manage backlogs while we refine it further in preparation for the expected surge in claims at the end of Q1 2024. So far, we’ve successfully processed nearly 4,500 claims entirely through RPA, saving our internal teams over 400 hours and counting.
Steven Waite is a cloud developer at Platform Housing Group. This article was written in conjunction with Rob Fletcher (director of data and applications) and Peter Thomas (cloud developer) from Platform Housing Group.
