The unfortunate use case for RPA

My mantra for business processes is this: Standardise -> Optimise -> Automate -> Eliminate (if you can). Sometimes though, we can’t help but ‘just automate’, no matter how much it drives you mad.

So here is the story, and this is a classic.

COVID-19 lockdowns and challenges have led to a surge and backlog of emails in customer service. We were approached to help sort out the backlog of emails for a service provider – to try and find a way to automate some of the tasks coming out of the email queue.

Our investigation turned up a few process design gaps across a variety of contact types, but this story is about just one of them: refund requests.

These refund requests were a result of a ‘system generated’ automated email sent to an ex-customer informing them that they are owed a refund due to a final bill settlement. Great customer service; but the refund requests were 10% of the email volume in backlog. We dug a little deeper.

These automated ‘system generated’ emails required the ex-customer to: download a refund form (pdf attachment) -> print -> (hand) write details -> sign -> scan -> attach -> send to a customer service email address or fax or post the form with a letter requesting a refund.

The customer’s emails, faxes and scanned mails land in a customer service email queue where customer service agents verify the information in the body of the email, verify the information in the signed form, and fill up a web form that’s on the service provider’s website.

The web form submission goes into a queue within the CRM system for a billing specialist to pick up and verify. If the information checks out, the billing specialist clicks a button that triggers an automated process from the CRM into the billing system, the system processes the refund, and the customer gets notified via email. If the verification fails, the billing specialist sends an email asking the customer to send a new form. Do you see where this is going? Yes, another email back into the customer service email queue.

Cutting to the chase, in the interest of clearing some of the email backlog, we had to automate part of the refund process. This is a workaround until the service provider fixes the ‘system generated’ email and brings in design changes.

This is “The Unfortunate Use Case of RPA.”

• We know what’s generating the emails and the repeat emails and some more repeat emails.
• We know this email process of refunds shouldn’t exist while there is a much better, partially automated process in place.
• We know how we can make it easy for the customer.

And yet, we couldn’t help but use RPA to automate this scenario. While it’s against our mantra, it is important that we put a temporary robust solution in place, while our client goes through the long cycle of major process design and system changes.

If we stuck to our mantra, we’d deliver no benefit – and RPA can help with short term pain as well as more meaningful long term transformation. Sometimes, practicality beats mantra.

The next unfortunate use case would be automating direct debit add/change requests and a few more. They have a story of their own but I’ll keep it for another day.

So there you have it – The Unfortunate Use Case for RPA.

Learn how to get started with RPA.