Discussions of Robotic Process Automation (RPA) tend to center on unattended bots. However, attended automation is becoming more and more important as it makes it possible for your employees – for example, call center agents – to focus on your customer’s experience rather than the applications they need to use while helping them.
In this blog post, I am going to lean on the experience gained in Pega’s 15 years of delivering enterprise-grade attended RPA and share with you a list of what is required from your RPA vendor to make a great, enterprise-grade, attended RPA bot.
What is attended automation?
Here at Pega, we grew up developing and delivering attended automations. Our first RPA clients were focused on large-scale attended bot implementations and Pega RPA has been built from the beginning to handle those needs.
But when you research the differences between attended and unattended automations, you will get simple, high-level lists that highlight the need for human intervention, front-office vs back-office use cases, and rote work vs a personal assistant. I am guilty of creating these simple lists. Here’s a slide from my PegaWorld iNspire presentation in spring 2020:
What you don’t find – in this slide or in any of the lists RPA vendors or analysts provide online – is what a bot must do (or must not do) to be considered a valuable co-worker.
What you should expect from attended automations
Here’s a list of the six things an attended implementation must include to be considered a truly enterprise-grade attended RPA implementation.
1. No roller-coaster automation allowed
Roller-coaster automation refers to moments when a bot requires you to keep your “hands in the air” when the automations run, just like you would while riding a roller-coaster. In other words, roller-coaster automation means that you can’t touch the mouse or keyboard while you’re automating. Have you seen the attended automation ad in which a user casually walks around the office as their unlocked computer runs the automations? What a waste of time. And how would a CISO react if they strolled down the hall while they waited for the automations to finish? Walking around might be good for someone's daily step count, but sorry guys, this is not attended automation.
No matter the technology of the applications being automated, true attended automation should not be affected by a user sharing the desktop with the bot. It is not okay for the bot to fail because a user did something. Automations must work on all screen resolutions, font sizes, screen colors, and languages. The user should be able to work in one application while the robot is automating another.
A bot should never take control of the desktop by locking the user out or stealing the mouse or keyboard.
Never. Not if you are automating a Windows app, a web app, or a green screen.
And automations should never hi-jack the clipboard. When automations copy data to/from the clipboard when moving it in/out of text fields it is very annoying for attended users who expect the data they put in the clipboard to be retained.
Never. No matter what your use case is.
And attempting to work around the need for roller-coaster automation by adding a second VM for each user that is dedicated to running automations just leads to higher costs and IT headaches.
2. Parallel processing of automations is required
With parallel processing, multiple automations that run against separate applications (or application instances) can run at the same time. This is a must-have for attended automations in the front and back office because it speeds call and processing time.
Here’s an example:
Imagine a new call comes into a call center and the employee needs to do a customer lookup in three separate applications. An attended automation should be able to lookup the account in all three applications at the same time, thus enabling the user to assist their customer as quickly as possible. With parallel processing, the bot should be able to run all three – or even 10 applications – in parallel, no matter what kind of application they are.
3. Automations need to be faster than the person they are helping
I have seen people compete against robots and win. That’s crazy!
Bots that lose to humans run automation scripts filled with pauses and sleeps because their automations can’t move faster than the applications on their slowest day (ex., if it sometimes takes 15 seconds to lookup a customer’s account, then that automation will always have a 15-second pause in it).
Attended RPA needs to be event driven, which lets the automation move as fast as the application can. Building on my previous example, the very instant the customer’s account is found, the automation should move forward – with no need for pauses or sleeps. When the application is slow, automations handle that seamlessly. And when the application is fast, automations fly with it.
Automation techniques can also impact speed. OCR screen scraping and the use of Microsoft UI Automation can be 40x to 100x slower than Pega RPA powered by Deep Robotics.
Attended users won’t use (or be happy with) slow automations. They’ll be impatient, interrupting the automation, which can result in a broken process. Slow automations also have lower adoption rates, increased errors, and frustrated users.
4. Must seamlessly handle multiple customer interactions at once
If we think back to the call center example, an unattended bot works on one customer at a time and is written to support the information required for that one customer (variables are needed for one account number, one customer name, etc.). However, we have all seen the busy call center rep tidying up their notes from the previous call when another call automatically comes in. We’ve also seen reps handling multiple customer chats at once.
These users are great at multi-tasking and need an attended RPA solution that keeps up with them. The tool they need includes a dashboard that holds data for each active customer interaction that is collected from multiple applications. And there can be no risk of automations causing PII confusion or violations.
Pega’s Interaction Framework enables exactly this kind of multi-tasking by users. It essentially keeps a separate 360-degree view for each customer interaction. When the attended user switches between two customers, the active interaction switches, too. All of this is designed to make it easier for the Pega RPA developer to implement the real-world attended use cases they encounter.
5. Can’t steal an application instance from the attended user
Oftentimes, attended RPA users will open multiple instances of an application, the intention being that one instance is for the automations and the other is for them to use. Seems logical. But many RPA vendors make it difficult for the bot developer to figure out which application instance they should automate. This leads to automations that ‘steal’ the application from the end user or, even worse, that update the wrong customer information. PII crosstalk is unacceptable, and your RPA solution should make it easy to ensure it doesn’t happen.
A good attended RPA implementation needs to track application instances and always automate against the correct one without the bot developer having to program complex workarounds to help a bot to find the right one, most of the time. This secure behavior comes ‘out of the box’ with Pega Attended RPA.
6. Common use cases should be easy to implement
If you have seen the average front-office or back office desktop, you know it is littered with numerous open applications that are essential to handle the most basic customer interactions. A common use case for attended RPA is to create automations that help users start all of their needed applications, log into them and bring the app they are looking for into focus (for example, with 17 open applications, it can be hard to find the needed browser tab while engaging with the customer).
The StartMyDay and AssistedSignOn components from Pega RPA require a couple of small things to be configured and then they just work. These components make common, everyday automation use cases like starting applications, finding applications, and signing into applications easy for the bot developer to handle without creating a single automation or UI form.
Much of the above is powered by Deep Robotics, the technology that drives Pega RPA. Unlike screen scraping techniques that focus on scraping data from the surface of applications or UI automation techniques that utilize accessibility layers, Deep Robotics operates in the memory space of the application being automated and gives Pega RPA the same power to control the application as the original application developer. Deep Robotics makes it possible to automate applications of all types with incredible speed and without impacting attended users on the desktop.
And it should also be noted that speed, parallel processing, application management and event-driven automations create significantly more powerful UNATTENDED bots too.
The ROI for attended automation is phenomenal! A 5 percent time savings for 2,500 call center agents can easily translate to over five million dollars in annual savings. When done right, attended automation can decrease onboarding time, reduce errors, improve first-call resolution, and drastically reduce average handling time. Of course, all of this adds up to much improved customer and employee experiences. Whether you’re just starting your journey with RPA or considering adding attended bots into your automation mix, it’s essential you know what will set your users up for success. These six things are critical for your attended RPA implementation to scale to an enterprise-grade, attended RPA.
Related links
- To learn more about Pega Attended RPA and the benefits it can bring your business, check out our recent Forrester TEI study here: https://www.pega.com/forrester-tei-robotic-process-automation.
Don't Forget
- JOIN THE CONVERSATION on Collaboration Center
- FOLLOW @PegaDeveloper on Twitter
- SUBSCRIBE to the Pega Developer Podcast on Spotify or via RSS