In previous No Jitter posts, I’ve discussed the selection of processes for robotic process automation, or RPA (see “
Contact Centers About to Get Smaller” and “
RPA: Becoming the Linchpin of Enterprise AI”). These decisions focus on the amount of time saved, the opportunity cost of eliminating errors, and the frequency of the target processes. But once you have consensus on the processes that are candidates for automation, what’s next?
Creating a process design document (PDD) is the first step. This document should include a narrative and graphical (screenshots and flow charts) description of the targeted process, such as screen navigation, research during customer interactions, or customer journey analytics, as
I’ve discussed previously. Additionally, the PDD should provide programmatic guidance that includes code samples; variable parameters; host system interface architecture and methods; and description of any other programmatic elements relevant to the target process.
The PDD must have enough plain English for business managers to understand how the robot will execute its functions. This will allow contact center managers to understand how the robot will work before they approve the build. This is critical, as business managers will understand the process in a way that developers will never understand. Without management approval and/or sponsorship, robots will never reach their potentials.
The PDD’s reliance on screenshots is vital to the success of a robot that uses computer vision, which is an artificial intelligence (AI)-based solution that allows the software robot (resident on the agent’s PC) to see and manipulate the computer interface the same way that a human can. This includes anything you can do with a mouse, touchscreen or keyboard. Computer vision was developed for situations where APIs aren’t available or when the APIs don’t offer the capability necessary to complete a function or process. Many RPA solutions use computer vision to programmatically access and manipulate data within the agent’s computer interface.
This use of computer vision offers two key benefits:
- The functions get executed on the agent’s PC with the agent’s access credentials. As such, agents can manage the progress, remain in the loop when necessary, start or stop the robot as needed, perform quality checks, and provide status to the customer when the robot completes it work.
- The robot doesn’t need to use an API to perform a transaction. This is a major factor for legacy, custom-written compute platforms that don’t expose APIs.
For these reasons, accurate screenshots with detailed annotation are the best way to document a process within a PDD.
What’s not readily apparent to contact center managers is that training documentation for large contact centers often includes the narrative and screenshots discussed above. Further, many large contact centers produce video and/or computer-based training for the same purpose. All of these training materials are perfect for PDD. Putting the robot developer in a training class is also an option.
Better yet, many RPA platforms offer low-code development environments that make it possible for non-developers, like trainers, to build 90% of the code for software robots. These low-code development interfaces are augmented with computer vision so the developer is able to invoke a recording function that allows the computer to write code as the computer “observes” the performance of a particular process. In less technical terms, the developer can turn on the recording function and then execute a copy/paste process and the computer will write a substantial portion of the code to support the software robot’s execution of the process. What’s left for a skilled developer is management of variables and exception handling.
Once the business signs off on the PDD, the development process can be very rapid. Using rapid prototyping, development for a contact center solution may only take two to three weeks, with several prototypes delivered inside of this timeframe. In these cases, iterative Agile methods may slow the development process.
For example, I know of one contact center that delivered a production robot in 14 weeks that saves the cost of 47 full-time equivalent employees. This included downloading a trial version of software, training their people, creating a PDD, delivering seven prototypes, negotiating licensing terms, and accomplishing production distribution to 600 seats. By the way, the first-call resolution KPI went up immediately, because the agents had more time to focus on speaking with customers rather than having to put them on hold to perform the complex research necessary to support the interactions.
We’re in a new world where non-coders can use AI to create software robots. Some are calling this the era of the citizen developer. Nothing has moved the contact center productivity needle like this since the introduction of interactive voice response and computer-telephony integration 30 years ago.
