4 “Work In Process” Metrics Every Tech Support Leader Must Know

Q4 is approaching and it will soon be time to evaluate and update your technical support organization’s customer focused metrics for 2012.  To get started, I recommend that you consider customer metrics in two categories, “work in process” and “service delivery”.

Work in process metrics focus on the cases or tickets that are still open and include measurements such as backlog, backlog ratio, average age and internal service level achievement.

Service delivery metrics focus on the end of the support process, at the time or after the service has been delivered. These measurements include SLA (also called average days to close) and customer satisfaction.

Today’s blog post focuses on the “Work In Process” metrics and leading indicators that every Technical Support leader must know. (A future post will cover metrics for service delivery.)

1) Total Backlog: Tracking backlog is as simple as tracking the number of open cases or tickets at any given point of time, regardless of their status (e.g. researching, waiting for customer feedback).  Backlog is important because every open case means you have a customer waiting to be satisfied and each case has a “holding cost”.

• The right backlog goal will vary based on your service delivery targets, complexity of support cases, and resource modeling.
• Before setting a backlog goal, I recommend that you create a baseline trend of actual backlog performance and determine the correlation with achieving service delivery targets. You may find that when backlog stays between one and three weeks worth of new case volume totals, you consistently achieve SLA or customer sat. However, as soon as backlog creeps up to four weeks or more, you do not achieve SLA or customer sat.
• You should also understand the productivity trends and resources necessary to achieve backlog targets. Although holding only one week’s worth of backlog cases may sounds attractive, you need to understand the costs and whether your staffing/resource budget supports it.

2) Backlog Ratio:  The challenge with a backlog total goal is that it does not consider fluctuations in case opening volume, while a backlog ratio does. A backlog ratio is the number of cases in your backlog divided by the average, actual number of new cases received during a designated time period.

For example, If you decide to set a goal based on holding three weeks worth of case volume, you would take your actual backlog and divide it by the rolling three week average of new case volume.

• Actual rolling three weeks of new case volume = 300
• Current backlog total = 300
• Achievement of goal – 100%

Note….Although this method adjusts for fluctuation, it is may be harder to grasp and track than a pure backlog number.

3) Average Case Age is the total days (or hours) your backlog cases have been in the open status divided by the total cases in your backlog. Average age is important because as cases age, your customer satisfaction levels will drop. No-one likes to wait!

For example:

• If the total open days for all cases = 5,000 days and your total backlog = 1,000 cases
• Average age of backlog is calculated as 5,000/1,000 = 5 days
• So, on average, the cases sitting in your backlog have been open for 5 days

Before setting a goal, I recommend that you create a baseline trend of actual, average age performance and determine the correlation with achieving service delivery targets. You may find that when average age is in the 2-5 day range, you consistently achieve SLA or customer sat. However, as soon as average age exceeds 6 days, you do not achieve SLA or customer sat.

FT Works, a consulting firm that specializes in Tech Support, also recommends that you consider a “stale case index”, which provides a deeper dive into case age. A stale case index considers what percentage of open cases are older than X days. (X days will vary based on your overall average age target and service delivery goals).

When managing cases, leveraging a “first in first out” or “last in last out” methodology does not work. But, a stale case index can help keep tabs on the mix of cases in your backlog.

4) Case Lifecycle:  To effectively manage your case or ticket activities, you must understand the lifecycle of your cases from opening to closing, which employees and departments work on your cases and how long each stop takes. Most CRM systems out of the box or with small enhancements can help you measure the case lifecycle.

During the work in process time, it is important to understand:

• How many and what percentage of tickets are “touched” by other departments?
• Of those tickets that are “touched”, what is the average turnaround time, from start to finish, of the case work?
• What trends do you see by product, release, case type, problem type?
• Are certain employees handing off more cases than others? If yes, could that be a training or coaching opportunity?

For example, you may find that for Product A, 50% of your tickets require the support of a development engineer. And, once the handoff from tech support to engineering occurs, the average turnaround time is 5 business days. This contrasts with Product B, where only 20% of tickets require engineering help and those only take an average of 2 days in engineering. This should make you ask why.. what is different?

Most technical support leaders would agree that tickets that require the help of employees outside of the primary technical support organization will take longer to resolve, than tickets handled solely by technical support. As soon as the hand-off occurs, we lose control and we add cost to the support process, so it is critical we get visibility to the case lifecycle steps while the work is in process.

Are there other critical, “work in process” measurements that you use in your technical support organization? What do you think of these recommendations?  Please add your comments!

© 2011 – 2012, Marci Reynolds. All rights reserved.