Measuring your actual use of support analysts is a topic that generates a great many suggested approaches. After ploughing through a number of the theories, I still hadn’t found any solutions that I could apply to the support analysts at CODA. The nature of our business means that our caseload generally consists of complex accounting and technical issues; and resolution times vary from minutes to weeks (always aiming for more in the former category, of course). A simple calculation (involving the average resolution time, the number of cases closed and the hours worked) didn’t provide the information I needed to measure performance in a meaningful way, so I came up with an alternative.

Although the initial setup was quite complicated, maintaining it has been fairly straightforward and each quarter it has – without fail – given me useful insight into what our support analysts were actually achieving.

In this article, I describe my method for measuring utilization, as well as the reasoning behind it. It’s important to note that the results are by no means black and white but if you’re diligent in recording hours and case tracking, it could very well work for you. At CODA, we’ve tested the approach across two different support teams, over eight consecutive quarters, and have proven results of its effectiveness.

Getting started

To get started, you have to collect this key data:
• The maximum hours in the quarter (number of days in the quarter, minus any days closed for holidays etc., multiplied by the number of hours in each working day).
• The total hours in the quarter that each analyst was available to receive and work on cases (subtract vacation, sick, training etc.).
• The number of cases received.
• The number of cases closed.
• The cases each analyst received.
• The cases each analyst closed.

Input these numbers into a simple data sheet (see fig. 1, the names and numbers have been changed to protect the innocent but they do represent a typical percentage case split).

Figure 1: A sample data sheet showing key data points for analyzing support analysts’ actual productivity.

You can then use these key figures to calculate various performance indicators as shown in fig. 2.

Figure 2: Calculated performance metrics. The names and numbers have been changed, but the principles and calculations remain the same.

The columns explained

Cases closed per day – This column indicates the number of cases that we believe an analyst could potentially close without burning out. We have set this at: 1.5 cases for a technical question, 4.0 cases for an application-type question, which we feel is appropriate for our complexity of support. The number you place in these columns should be set according to your environment and circumstances.

Closed case capability (based on hours worked) – These values will be used when generating the “Utilization based on capability” measures later on.

Available cases – This is an in-house calculation that provides a fair split of cases available for each analyst to answer during the quarter and was probably the most complex and time-consuming for us to pin down. It’s calculated by removing the cases that are logged or closed by a number of people who are not measured in this exercise (i.e. we have some team leaders and other support staff that close certain cases). It’s important to remove those individuals not primarily focused on closing cases. The remaining cases are broken out by the products supported and spread evenly between the analysts. You should base this number on your experience (before we deployed the table in fig. 3, we had some strange and wonderful calculations). Now we simply determine a fair split of the cases for each product and calculate the available cases from that.

Figure 3: Our in-house table for calculating a fair split of cases between analysts.

If you have a more complex center and dividing the total cases for a product into three isn’t feasible, you can try this alternative table (fig. 4). We use this method with our larger center. The table shown is a subset of that table but you should find that the focus is on how we expect the analysts to use their time rather than how we expect the cases to be split.

Figure 4: Sample table for a larger, more complex support center.

Hours worked – These figures are taken straight from a column on the first data sheet.

Hours to close a case – This is a good indicator of how much of an analyst’s time it takes to close a case. This is not how long it actually takes to close, because there will be down time and customer time (where the case is out of the analyst’s control) and it is an average, but it does serve as an indicator to highlight the more productive analysts in the team. This is calculated by dividing hours worked by the actual cases closed.

Available cases factored by hours worked – This is an important measure to calculate. In the “Available Cases” column, we identified how many cases would have been available if an even/fair split of incoming cases had been made. What we’re considering here is that your analysts don’t work every hour of every quarter so you can’t expect them to take a case when they aren’t working. So, this measure gives a more accurate average for what each individual analyst could have been expected to achieve that particular quarter. It’s calculated using: “Hours worked”, divided by “Max. hours”, multiplied by “Available cases”.

Actual cases closed – These are also taken from the first data sheet.

Straight utilization for the quarter (% hrs worked) – This is a simple percentage calculation of the hours worked vs. those that could have been worked. This can serve as an indicator of employee issues if an analyst shows a particularly low percentage and the reason is not easily apparent or known. In our example, Analyst 6 is low at 68% but this can be explained by time-off for personal reasons.

Utilization based on capability – This measure highlights whether analysts are appropriately staffed and capable of handling an increase in caseload at both an individual and at a team level. It’s calculated by expressing “Actual cases closed” as a percentage of “Closed case capability”.

When I started to explore the best ways to measure utilization, I soon realized that this measure has limitations. It seems reasonable and logical – measure what someone is capable of, compare that to what they did in a given period and then express the result as “utilization” -- but the number you produce only has any real meaning if your analysts are working flat out.

Taking another look, it became apparent that – in the real world – analysts can only work on as many cases as the customer base actually logs. That’s why the “Available case” metric becomes such a critical factor in these calculations. Since an analyst can only work on and close the cases your customers give them, they may appear to be underutilized from a basic utilization calculation but that may not be the true picture. In addition, analysts can only receive and work on those available cases when they are actually working.

Utilization factored by “Available cases” and “Hours worked” – This measure was calculated by: “Actual cases closed” divided by “Available cases factored by hours worked”. This number should exceed 100% because the comparison is between cases closed vs. those available to an analyst while working on support.

Factored by available cases – This measure was calculated by: “Actual cases closed” divided by “Available cases”. It recognizes that, regardless of whether the analyst was present and working on support cases, someone had to take and close the case. What we’re considering here is that if the team still met its target, despite the lower availability or utilization of some team members, then others must have come in higher and picked up the slack. This comparison is necessary, as utilization is a relative measure, so that we can view the results from as many perspectives as possible and build up a more complete picture of what’s actually happening.

Average – Taking the mean of “Factored by available cases & hours worked” and “Factored by available cases” results in the overall utilization percentage. This can then be used to award bonuses, accordingly.

Part 2 of this article explains how to put this method into practice and how to calculate bonuses for support analysts.

About the author

Matt Hinchliffe is Director of Support, Americas for CODA Financials, Inc. - the US-based division of global Financial Intelligence solutions provider, the CODA Group (www.coda.com). His background covers a full range of experience in software and support roles: from support analyst to trainer and manager, including a “ground-up” reorganization of CODA’s Support Centre in Golden, Colorado that has produced significant gains in efficiency and effective customer service delivery.

When implementing any new measurement you should ensure you are aware of the impact on your organization, customers and employees. The SSPA, author, or CODA may not be held liable should the application of this, or any other measurement negatively impact your business.