Quality vs Quantity in Customer Service Analytics
Business intelligence and analytics are used across a wide variety of industries to improve operational efficiency and business processes. However, when analyzing any type of data, it’s important to know what you’re looking for. Let’s look at a recent example from the customer service industry to understand this concept.
The Business Requirements
In a customer service center environment, ticket times are the primary factor in measuring the effectiveness of the customer service team. Longer ticket times lead to unhappy customers, which can hurt both customer retention and new sales.
However, the factors behind longer ticket times are often not as simple as they appear. Headcount may not be balanced to meet customer demand, meaning there could be too few or too many customer service representatives (CSR’s) on the job. Additionally, CSR’s may have performance goals that are not in line with ticket priorities, as CSR’s may be measured purely by the number of tickets they solve, rather than the importance of each ticket.
By applying statistical analysis and data visualization (for which we naturally used our own dashboard reporting software, we can create a headcount forecast to best meet customer demand, and create a performance matrix that incentivizes solving higher-priority tickets first.
Breaking Down the Terminology
Tickets Received vs. Tickets Solved
In a customer service organization, it is important to be aware of both how many tickets are received, as well as how many tickets are solved. However, when the customer service team is not receiving enough demands, the results aren’t as visible.
To better balance customer demand, with the customer service team’s ability to solve tickets, it is better to look at two measures: Takt Time and Cycle Time. These terms are often used interchangeably; however, these terms actually measure two different types of activities.
Takt Time is the average time between customer demand during the working day. When compared to a restaurant, Takt Time is average time between customers walking in the door and asking to be served.
In a customer service environment, Takt Time would be measured the time in each working day, divided by the number of tickets received. If 500 tickets are received in an 8 hour working day, the Takt Time would be one ticket per 58 seconds (28,800 seconds / 500 tickets = 57.6 seconds per ticket).
Cycle Time is the average time to complete one unit of work. When compared to a restaurant, Cycle Time is the average time between customers being seated and leaving satisfied.
In a customer service environment, Cycle Time would be the time in each working day, divided by the number of tickets solved. If 450 tickets in an 8 hour working day, the Cycle Time would be one ticket per 64 seconds (28,880 seconds / 450 tickets = 64 seconds per ticket).
The Goals and Objectives
While the ultimate goal of customer service analytics might be defined as “providing better service” or “reducing customer support overhead”, these can be further broken down into specific objecetives that will help us achieve these goals:
Identify Unbalanced Takt Time and Cycle Time
Now that we have defined Takt Time and Cycle Time, it is apparent the ideal state is to balance the two measures. Returning to the restaurant analogy, when Takt Time and Cycle Time are in balance, the customer demand is able to be met by the customer service team. The restaurant is full of customers, and additionally, nobody is waiting for a table.
If Takt Time is less than Cycle Time, as in our example above, problems arise. Tickets continue to come in, but the pace of incoming tickets exceeds the customer service team’s ability to keep up. Often times, these excess tickets begin piling up in a backlog. CSR’s may be asked to work overtime to clear out the backlog after normal working hours, which sharply increases labor costs. Worse yet, customers who have called in their tickets are placed on hold, and after a certain time, customers begin to abandon waiting on hold. The ticket is never even received, and the customer never has their need addressed.
If Takt Time is greater than Cycle Time, the problems aren’t as apparent. There is no backlog, and all calls are answered in a timely manner. However, there is a hidden problem in excess labor costs. There may be too many CSR’s working. Like a restaurant with no customers and too many servers, the management’s failure to appropriately staff the restaurant leads to bored employees, unproductive busy work, and wasted labor costs.
Automate Repetitive Responses
If certain customer requests seem to have a repetitive nature and have similar responses each time, a customer service team can work together to automate these requests. Online resources, such as knowledge base articles, FAQ’s, and customer forums can be used to direct customers to solutions. Directing customers to online resources will significantly reduce Cycle Time, and give the customer an excellent pool of resources to check before submitting future service tickets. These resources will also appear in search engines over time, reducing the number of incoming tickets.
Create Standard Work
The concept of Standard Work is a key pillar in replicating processes. Standard Work lays out each step of the process, and instructs the employee on exactly what to do in every scenario they might face. Additionally, while Standard Work is established, the team can eliminate any non-value-added or unnecessary steps. Standard Work reduces variation in the process, and proactively answers any questions a CSR might have. Eliminating unnecessary processes, variations, and questions will all reduce Cycle Time.
Standard Work also creates a fair measuring stick to evaluate all employee performances equally. Inefficient CSR’s can have their performance assessed more accurately if every employee is held to Standard Work. If a CSR’s performance is suffering, review the Standard Work processes with them to ensure their understanding and competency at the task.
Create a Headcount Forecast to Balance Takt and Cycle Times
After improvements are implemented to reduce Cycle Times, we can forecast headcount to balance Takt Time and Cycle Time. In the example above, assume 9 CSR’s are currently solving 50 tickets each a day, for a total of 450 tickets per day. If a 10th CSR is added, the additional representative can solve 50 additional tickets, and make up for the gap in Takt Time and Cycle Time. In reverse, if we assume customer demand is 450 tickets and the team is capable of solving 500 tickets, the headcount can be reduced by one CSR to balance Takt Time and Cycle Time.
These concepts also apply to peak times within the same working day. In our example of customer demand at 500 tickets per 8-hour work day, assume customer demand is 60 tickets per hour for most of the day, but peaks to 70 tickets during two hours of the day. Assuming each customer representative can solve 6 tickets per hour to meet their 50 per day, 10 representatives would be needed most of the day, and an additional 2 representatives would be needed at peak hours to keep up with customer demand.
On a long-term basis, customer service managers can plan when they will need to hire new CSR’s based on their company’s new sales. If each customer adds an additional 10 tickets per day to the ticket demand, management can plan to add a CSR with each 5 new customers sold.
Measuring Ticket Quality with Takt Time and Cycle Time
Measuring ticket output is a Key Performance Indicator (KPI) in every customer service team. However, the way those tickets are measured could have a drastic outcome on ticket performance.
Some customer service teams measure ticket output purely in numbers. In our earlier example, CSR’s may be measured by their ability to solve 50 tickets a day, or the team may be measured by its ability to solve 500 tickets a day. In both cases, there is no attention drawn to the quality of tickets solved.
Are You Sweeping the Dirt Under the Rug?
To delineate between ticket quality, many organizations assign each ticket with a priority code. For illustration purposes, we will use three basic priorities: High, Medium, and Low.
High Priority tickets are used for critical business failures which much be resolved immediately in order to deliver the business’s core offering. For instance, a power outage or server crash would be assigned a high priority ticket. High Priority tickets typically receive lots of attention due to their urgency. If customers are experiencing an outage or critical failure, it is imperative that CSR’s work quickly to restore service as quickly as possible.
Low Priority tickets are used for customer requests for training, or enhancement requests. Low Priority tickets have no immediate or short-term impact on the business’s ability to deliver its core offering. In most organizations, Low Priority tickets typically receive lots of attention due to their low difficulty level.
This leaves a middle ground of Medium Priority tickets that aren’t quickly or easily solved. Medium Priority tickets are typically requests by advanced customers, who noticed a need to change a process or fix a bug in the system. Medium Priority tickets usually require several hours of testing and research to solve. These tickets may go ignored as the customer service team focuses their attention elsewhere, or get dumped on a smaller group of Level II CSR’s. This behavior is akin to “sweeping the dirt under the rug.”
To illustrate this, let’s look at an example. One of our customers in the telecomm industry was looking to understand and optimize the performance of its customer service, which they felt was a soft spot in their business. However, failing to differentiate between ticket types created an overly optimistic view:
As we can see, while there is a small backlog being created, it seemed that overall most tickets were being resolved. However, looking at data for the same time period but taking ticket quality into account revealed a somewhat grimmer picture:
When Takt Time and Cycle Time were compared, High Priority tickets had a deficit of 15 minutes, Medium Priority tickets had a deficit of 52 minutes, and Low Priority tickets had a surplus by 94 minutes.
Takt Time was obviously out of balance for Medium and Low Priority tickets. There were too many CSR’s working on Low Priority Tickets, and not enough CSR’s working on Medium Priority tickets.
Balancing Ticket Priority Using a Performance Matrix
In order to solve the imbalance between Medium and Low priority tickets, we created a ticket scoring matrix. This matrix assigned weight to the ticket based on its priority score. High Priority Tickets were scored as 1, Medium priority tickets were given a score of 0.85, and Low Priority tickets were given a score of 0.25.
Previously, CSR’s were evaluated purely by the number of tickets they solved. This incentivized CSR’s to solve Low Priority tickets, because of their low effort and high number. It was easy for a CSR to look like a high performer, when in fact, they had only solved relatively unimportant tickets.
After assigning the matrix, CSR’s were incentivized to solve High Priority and Medium Priority tickets first, rather than solving Low Priority tickets. Cycle Time for Medium Priority tickets saw a 47% improvement. This was still not enough to meet Takt Time however, so more CSR’s were trained to be Level II CSR’s to add more headcount to Medium Priority Tickets.
The customer service team also had justification to add four new CSR positions, helping to resolve the existing ticket backlog, as well as keep up with future customer demand.
By measuring Takt Time and Cycle Time, we were able to accurately forecast headcount, and balance gaps in ticket quality, to create a balanced customer service experience. Ticket times improved, and new CSR’s were trained up and added to further relieve customer demand.
The lesson here? If you are looking to improve customer service ticket times, forecast headcount for your customer service team, or really perform any type of measurement or operational improvement to your business – a solid understanding of the relevant metrics and the data points they are derived from is always essential.