Customer Service RPA: Human-Robot Collaboration Best Practices (Part 2)

Merritt: The key drivers for Customer Service RPA focus on reducing average handling time (AHT), improving in-call and after-call quality and as always, on making a positive impact on the customer and the agent. RPA plays a key role here given the fact that a typical contact center agent works through 15-20 applications and uses ALT-TAB up to 1,500 times per day to help customers. These robot-like activities are often the root cause of poor quality and high AHT metrics that our clients are trying to solve for.

A fitting e.g. here would be that of a large US insurance company, whose knowledge base houses over 14,000 articles, which agents need to search through to access relevant content throughout their calls to ensure proper procedures are followed. Given this highly regulated insurance environment, any input error during the customer interview process can result in downstream problems during the policy binding process. Hence it is imperative to get it right and document the work to get a successful customer outcome. To help reduce errors and improve AHT for certain call types, there were two initial RPA use cases for this client. First, we deployed an “Autonote” bot, which is trained to monitor user navigation on the desktop and automatically documents completed processes to include any changes in key data (policy info in this case). Autonote is typically a part of every customer service RPA implementation as they have an immediate impact on agent experience by reducing the time spent on after-call work.

For the second use case, we used the powerful combination of agent guidance plus RPA to “push knowledge” to the agent at critical times through the call when certain exception paths need to be followed. Say, for example, a hurricane is bearing down on the East Coast and a call comes in about flood insurance for a customer in that storm path. Here is an instance where the business can quickly update business rules for the bots who are monitoring these 3000+ desktops and if a new policy request comes in for a customer in this area, the bot can recognize this and take the agent down a new exception path. The bot will now guide the agent through the appropriate script, prevent the process from competing and document the call with autonotes. This is one of many examples where business users can update an RPA bot automation to change rules in the process flows to trigger robots in real-time to assist and automate certain exceptions paths for the agents. The first two instances of automation helped the client reduce input errors for targeted call types by 82% while reducing after call work by 51%.

Another very hot space right now for customer service RPA is in the BPO space. Organizations often need to train thousands of agents on customer processes with desktop applications that are not their own. This can limit their ability to improve the process, quality, and customer experience during a given call. To add to the complexity, these agents typically have to answer calls on behalf of several different clients. So, instead of curating separate scripts or training modules for each process and customer, our BPO customers often implement Smart Agent Assistant solutions which bring together a common UX experience that is shared across all agents. It is further powered by intelligent guidance and automation thereby eliminating the challenge of navigation complexity across different clients for the agents. A recent BPO implementation of a Smart Agent Assistant reduced onboarding time for their agents by 67% and saw a reduction in AHT of 24%. More importantly, because this Smart Agent Assistant can deliver a consistent UX experience for agents across multiple client types, BPO customers can achieve their outcome of providing a more universally skilled agent as opposed to segmenting their teams by clients due to specialization needs

If you look at our customer base and the thousands of use cases in this customer service RPA space, there’s a pattern that emerges across verticals and brings together the three important capabilities mentioned above: Automation, Intelligent Guidance, and UX Design. Unlike back-office unattended automation, when humans are involved in customer service implementations, all three critical capabilities are required to ensure that mundane steps are automated while intelligently guiding the agent with a UX design that is natural and native to their given call flow and existing desktop. I’ve seen amazing bots in my time that could take a mid-call process down from 4 minutes to 20 seconds, but if that automation is not compatible with the agent’s UX in a way that is “built for people”, it will just be a great bot that never gets used; and that is a big difference between automating for people vs automating for robots.

Merritt: There is a big difference in attended and unattended RPA when it comes to Security & Governance. Unattended automation involves bots that do not have users attached to them. Meaning, when a company is onboarding unattended bots, they must consider them as if they are a new virtual employee and assign them an employee ID, set up applications access rights based on the tasks they will be asked to perform, etc. Often, these bots may need access to many or all applications, which instills fear in the information security teams regarding a person with the wrong intent taking over these bots from the inside or outside to change their programming and do bad things. To prevent this type of wrongdoing or reduce the risk at least, these stand-alone unattended bots have their own sets of regulations, security/governance requirements, and management/alert enabled dashboards associated with them.

In the case of attended bots, the bots do not get their own “credentials” or IDs but instead sit alongside the users and act on their behalf. This means they are bound by the user’s credentials and can do no more than what the user can do. In other words, if the user cannot access a particular application or a screen when helping a customer on a call, neither can the bot. Typically, organizations already have strong monitoring and application logging process in place within their existing applications, so any and all changes can be easily tied back to that user; additionally, audit needs for bots here are secondary considerations. Why is this important? It’s all about time to market and speed of deployment. Having these discussions upfront with your security teams is critical and is not something you should wait for unless you want to delay your project by another six months regardless of the approach (attended or unattended). As we often advise our customers – don’t let security-related discussions stop you from pursuing an unattended path as you should onboard both – attended and unattended RPA – in parallel, but taking a collaboration-first approach with your bots has fewer hurdles and takes advantage of the IT infrastructure that is already in place within an organization.

Merritt: Going back to my earlier point around back-office blinders, having hybrid RPA capabilities is a must for those who want to remain in this space and live beyond the hype. As we invest in our automation and AI strategy to support end-to-end customer service automation use cases, hybrid RPA eliminates the need for an organization to acquire and assemble multiple technology products to deliver and manage one omnichannel customer interaction. Fewer technologies, means fewer vendors, fewer integration points, and fewer points of failures in the process, which ultimately reduces total cost of ownership (TCO), change management, and internal maintenance that is required to support customer outcomes.

For instance, when a customer interaction begins in self-service with a Jacada virtual assistant, we want to make sure that our platform offers them an end-to-end seamless experience as the customer moves through their journey, regardless of channel. The unattended RPA capabilities for that virtual assistant will also open additional self-service use cases for automation as needed. In addition, when that self-service experience requires a human touch and moves into the contact center, we have attended bots in place waiting for the interaction handoff to help navigate the agent and customer through a frictionless experience inside of a very disparate technology stack.

To further that use case and extend into an additional hybrid mode scenario, imagine that same customer call wherein the attended bots might need 2-3 minutes of processing time to research and resolve a complex process for a customer. Here is an opportunity where an attended bot can be used to push that processing work to an unattended bot sitting in the cloud. This approach can free up the agent and the attended bot, so they can continue to work on other customer requests and/or open up a chance to upsell customers if needed. In such scenarios, hybrid automation can provide better end-to-end continuity of customer interactions across self-service and assisted service use cases, while optimizing the live agent/customer interaction. The key is not having to stitch together multiple RPA and self-service products to achieve this optimized interaction but instead, deliver it all through one low code design environment. This is where we feel we have a unique value proposition in the marketplace today.

Merritt: That’s a great question and the list is extensive, but here are a few that are on the top of my mind based on a recent conversation.

1. When it comes to customer service RPA, don’t become a victim of the “process discovery” hype. You already have the data you need to automate. Start with your top 10 call types (remember, RPA bots were meant for processes with high volume / high interaction / high people involvement) and look for those opportunities where you can automate small microtasks that are common across disparate call types and teams. Automations like password vault, autonotes, and processes where agents typically place the customer on hold are great initial targets for quick wins.

2. All RPA vendors are niche vendors right now regardless of billion-dollar valuations, so begin your RPA vendor search based on the outcome, benefit, or the area that you are trying to address. Once you have identified that, find vendors with strong experience in that space who fit your type of technology debt, assess whether you want a pure DIY effort or like a more consultative approach, and then conduct your evaluation accordingly. Too many companies in these early years purchased the bots first and then tried to put the bots to work in scenarios that didn’t fit the type of bot and/or vendor expertise, and are now, unfortunately, paying the price.

3. RPA is a business and IT endeavor no matter what a vendor tells you. We always recommend supporting an agile team structure for RPA deployment. When we start working with our customers, we suggest that they form a 5-member team consisting of two business analysts from the targeted focus areas, two automation designers who are familiar with your applications and are experienced in RPA bot development, and one scrum/program lead. This 5-member team can do amazing things in a short span of 4-6 months. The collaborative team approach connects both IT and business teams helping them break down legacy silos between these two groups and support joint design and development. We suggest aligning this team as close to the contact center (or department of focus) as possible, so you can get direct and frequent feedback from the agents/users. While it’s easy in unattended RPA deployments to give bots the work and expect that the work will be performed as designed, the same process and principle doesn’t apply when working in an RPA attended environment. An environment where the UX design can define the success or failure of the process. In such cases, even the best bots in the world might not be useful if they are not built for that user population.