All bots completed running successfully. 17000 calls made by the bots in a span of 2 hours. Server performance measured to be normal. Server withstood the load. All metrics are within acceptable limits. This is precisely the outcome one would hope to see after a performance test for a contact center product. In order for this to happen, one would have to plan the strategy way ahead of the actual test.
The first part to planning this would be to fix the date for the performance test so that you can work backwards on planning the entire episode. The next part is to decide on the metrics that need to be monitored and the benchmark for the metrics that will confirm the test a success. Some of the typical call center product metrics can be
- Time taken to retrieve a call
- Time taken for the call to be connected to an agent
- Time taken to write the data to a DB
- Time taken to contact integrated applications
- Call drops during peak
- Call quality during peak
- Misdirected calls
- Performance of recording features
The server side metrics like CPU and memory usage are also vital when the test runs at its peak.
Once you’re done with the metrics, you will have to select a tool for automating the tests. For a call center, you will have to imitate the agent action of answering calls and closing the call and completing post call activities. This article’s focus is on using RPA technology (UIPath to be precise) to imitate the actions of the agent. There are a number of tools in the market which can be used for this purpose. You can read about Forrester’s research on RPA on this report to make an informed decision on your automation technology. Though you will have to pay for this report, I’m sure you can google for creative ways to access this report for free. I do not have any personal inclination toward any of the RPA software and have chosen UIPath just as a case study. I am sure that other RPA software will have such capabilities as well.
UI Path is one of the market leaders in the field of Robotic Process Automation software. They have a community edition as well as an enterprise edition. The enterprise edition of UI Path contains three components: the UIPath Studio, the Orchestrator and the UIPath Robot.
UI Path studio provides a set of tools to the developer to create the automation code. It is highly intuitive and has a lot of features that can be used to imitate the call center agent actions. The workflow recorder of the UIPath studio will come in very handy when trying to replicate the agent’s action. Once the automation code is ready, it is published to the orchestrator. Quoting UIPath.com, the orchestrator is a highly scalable server platform, that deploys and manages your entire workforce, handling like a virtuoso all the critical enterprise duties: release management, centralized logging, reporting, auditing and monitoring, remote control, scheduling, workload management and asset management. It pushes the published code to the all the UIPath robots that have been configured and connected to the orchestrator (explained in a later section).
Once the automation code is ready, you will have to select the infrastructure to run the UIPath robots. These robots can be commissioned on a desktop or on any virtual machine from where they can run unattended. Amazon Web Services (AWS) provides virtual desktop infrastructure which can be used to solve this need. AWS have their own Workspaces which can be procured for the duration of the testing. Refer to this article to learn more about working with AWS workspaces.
Once you setup one workspace with the necessary software – your contact center application or browser (if it is a cloud application) and UIPath Robot, you can create an image of this workspace and clone the remaining required workspaces using this image. After commissioning the workspaces, all the robots that are installed in the workspaces have to be connected to the Orchestrator, so that the orchestrator can push the automation code and control the robots. You can refer to this documentation to connect your bots to the orchestrator.
Now that the environment is ready, you will need to do several test runs to see that all bots are connected and running properly. In order to imitate the agent action, you will need to have login credentials associated with each robot. This can be managed using the Assets feature in the orchestrator where you can create a new Asset with asset type as credential and select value as Value per Robot. This ensures that each robot has a unique set of login credentials to work with.
After setting up the environment, it is vital that you have a testing strategy in place. For a load test, you will gradually have to increase the load till the peak performance is achieved and maintain peak run for a specific amount of time that will help you collect enough data for analysis and make decisions. In a call center scenario, you gradually increase the number of agents taking calls. If you are planning to run 300 concurrent call center agents, then one of the ways of achieving this is by creating ten batches of thirty robots each in the UIPath Orchestrator. This can be done from the Environments section in the Robots page in the Orchestrator. Create ten new environments and call them Batch1, Batch2 and so on till Batch10. In each batch, you can add thirty bots and make sure you don’t select the same bots in two different environments. One robot can be part of one environment only. You will have to clone the automation code ten times and have different names for each batch. Once you publish these batches, it will be available in the Processes page in the Orchestrator. You will be able to match the process name with the corresponding environment name in the processes page. For example, process name with Process_Batch1 can be associated with Environment Batch1. This is done so that when you trigger Process_Batch1 from the orchestrator, only the bots in Environment Batch1 are fired and not the remaining bots.
AWS Workspace Precautions
It is important to make sure that all the Amazon workspaces are clean and no other applications are running before the test and you can reboot all workspaces to ensure this. In case you have procured workspaces in the Auto-stop running mode, it is better to increase the Auto stop timeout duration for the workspace. The duration should be at least an hour more than the duration of the test. This is imperative because the workspaces do not consider the actions of a bot to be a valid action to stay in an active state. Even though the bot will be executing the automation code and imitating an agent, the workspace will auto-shutdown if no one is logged into the workspace for the defined autostop timeout duration.
Login to the UIPath Orchestrator and fire the first batch of bots. Monitor the call center dashboard to ensure that all the bots have started answering and making calls. You will also be able to monitor the bot logs from the Orchestrator. After an agreed duration, fire the next set of bots. Keep going till you reach the maximum number of bots desired and run at peak for the agreed peak duration and then steadily ramp down the number of bots.
It is now time for analysis and retrospection.