by: Ben Stephens, Service Strategies 
In a service organization there is always more service demand than can be met in a single day, week, or month. Incomplete service requests, “work in process,” backlog or case load are some of the common names for the work yet to be completed in the support center.
Occasionally, operational reports may include a metric or two about case backlog. These usually take the form of what you might see in an inventory report… backlogged cases plus new, minus closed, equals the new balance of case backlog. Often these are displayed as a line graph to show trends over time. You may also see backlog expressed in terms of “days backlog.” Here the number of open cases is divided by the average number of cases closed in a day to come up with the “level of effort” required to eliminate the backlog.
I guess case backlog is like the national debt, it will never get reduced to zero, only grow and shrink over time. And just like the national debt, when it grows passed some “certain level” everyone begins to talk about it, which eventually leads to some type of organized “backlog busting” initiative involving pizza or other some fun food. So does your organization measure case backlog and if so how?
{ 9 comments… read them below or add one }
The operations I have been associated with measure backlog is by the cycle time which is the committed response time to the customer. This committed response time is labeled a “cycle” which is measured sperately from cycles to solution. E.G. One of our clients has a response time of 8 hours while another client has 24 hours as the response time thus each of those queues is managed differently based on the cycle time. The question that determines the actions taken is “how late are your lates?” and what is the volume? Having 3 cases 2 cycles late is managed much differently than having 50, 4 cyles late.
This is an interesting question, I’ve seen many ideas and “principles” on this matter, but nthey do seem to change. I beleive the current view is the best one too :
Our main objective is Customer Satisfaction, which is a lagging indicator.
Backlog is something we actively look out, as it constitutes a leading indicator, however we don’t put objectives on it, more or less for the reasons mentioned above : not all of the backlog is in our control.
In the past, we used to have objectives only on the part of the backlog that we control (i.e. active cases, not in development). Cases that were at the customers (proposed solutions etc.) have sometimes been considered as within our control, i.e. we can in fact chase up the customer to make sure that we the case is not fogotten. The objective ran out as a comparison to past quarter, i.e. need to reduce backlog by say 5, 10, or 15%.
The problem with doing objective on the backlog is that you can never control the incoming volume. The “lean Factor” suggestion on the thread above is interesting, but I beleive has a caveat : if the colume explodes (for instance a new version of a siftware), then the backlog will augment and perhaps in such a way that people los productiviy – basically because they’re swamped. And it’s very difficult to say when someone gets swamped.
As to what type of backlogs we measure,, I guess they’re pretty standard :
In process at Support
in process at Development
Waiting for a customer action
With solution proposed.
We also try to measure backlog age, with buckets of 1-14 days, 14-30, 1 to 3 months, 3months +.
Lastly, a good thing to look at is the rate of cases being solved within an acceptable timeframe, as a percentage to overall incoming cases. This is quite a similar method as the lean factor mentioned above, basically amking sure that you manage quickly enough a deent percent of your invoming volume.
Hope this helps !
We segment our “problem” backlog with our “request” backlog. We further segment our “request” backlog as contracted requests (paid integrations, for example) vs un-contracted requests (enhancement ideas, mainly).
We do this for a few reasons:
“Problem backlog” implies our maintenance burden, which directly relates to SLA’s (customer perspective) and our maintenance financials (internal perspective).
“Contracted requests” directly relates to billable services, which is financially a different team, but still must be tracked as backlog from a customer perspective.
“Uncontracted requests” are customer ideas to make the product better. We want to encourage this feedback, so we don’t treat it as support backlog. We do track it tightly with Product Management, however, as these are golden nuggets to present at customer forums to justify maintenance renewals (“You asked for this …, and it’s in the next version”).
This is a fun discussion,
I agree not all backlog cases are equal and support backlog consists of only those cases that can be resolved or advanced by support. Cases that are linked to defects(or in R&D hands), pending customer confirmations should not be included with the “work” backlog, even though they may not be closed. Understanding what the “actionable” backlog is the key to managing it.
Does anyone use case effort or number of customer contacts to aid in managing the backlog?
Do you encourage team members to collaborate based on case age?
email me.
Excessive backlog is dangerous to the productivity of support engineers. If a threshold is exceeded, then engineers start to feel overloaded and service quality degrades for less tests and research. In my organization, we usually use 20 cases as a magic number. Effective and frequent followups are necessary for backlog control. We encourage frontline engineers to escalate all cases over 10 days to escalation engineers if no solid solution is worked out by then.
Am trying to get the below practice installed in my company … not successful yet. Am trying this with directs for now.
1) Define the term “Lean Factor” as: LF = “Support” bucket backlog today / Inflow in the last 30 days. This tell us what is the “cushion” on which we deliver the current level of service. Our objective is to take down as much as possible. Right now we hover around 25%.
2) We focus primarily on “Support” bucket backlog as the “Customer” bucket response level is at customer discretion/prioritization. And, the “Development” bucket (these folks own the code base – my team can read and suggest changes, but we can’t make the changes ourselves) is again not really under my control, but we monitor it to make sure the response level does not reach an alarming state.
Case backlog is always an interesting metric.
Pure backlog statistics can sometimes be misleading because the unclosed case universe is frequently littered with cases that cannot be resolved within the realm of a typical Services staff. These include:
Product Defects/Enhancements
Issues that cannot be duplicated (but client refuses to close the case)
Cases awaiting client response
I have found it useful to park the backlog into different buckets (including the above). It can have a powerful impact on internal resource allocation. Important to segregate the backlog to understand those backlog cases which can be directly influenced by the Service organization and those dependent upon others.
We look at backlog in our technical support operation in three levels. Over 60 days, 30 to 60 days and within 30 days. That gives us a clear view of the long-standing issues that are likely to cause customer dissatisfaction as well as the “normal” workload that is keeping our support team busy every day.
As long as we are keeping the total backlog within 2 weeks of normal weekly totals, we consider that to be a reasonable level. As that total starts to move up to 3 weeks or even a monthly total, we have a workload that could potentially exceed the capacity of the support team to maintain customer satisfaction. If that backlog moves down below 2 weeks, we can consider reallocating resources to knowledge creation, new version preparation or other less customer critical tasks.
Backlog is normal and expected, it’s just a question of how much. That will vary by company, product and customer expectations.