Fight the backlog monster!

Posted on Posted in Technical Support Tagged with ,

Thank you to Bruce Mittendorf and several anonymous other readers for suggesting this topic.

Bruce points out that backlog (volume of open cases) and incoming volume tend to move together. In other words, a higher incoming volume means higher backlog. But interestingly the percentage of backlog cases (backlog/incoming) does not fluctuate as much as we would expect. Support engineers work harder when volume is higher, leading to lower than expected backlogs, but relax a bit when volume wanes (and, to be fair, when volumes are high the easier cases are resolved first, so that the average complexity of cases in the backlog builds up, leading to slower closure down the line). You can verify this for yourself by comparing teams who work with different product lines and who experience high volumes at different times.

With that, how do you work on reducing case volume regardless of backlog?

Watch a scalable target

The right number to watch is the ratio of backlog to incoming cases. So if your rolling average for incoming is 500 cases a week and your current backlog is 2500 cases, you have 5 weeks’ worth of backlog, which would be a lot. Well-managed organizations with highly complex cases can shoot for 2 weeks. With low-complexity support the target should be as little as 2 days. Using a ratio is best since it will scale well regardless of the growth of the user base, acquisitions, and the like.

Define the right metrics and objectives

Are there any incentives for support engineers to resolve issues quickly? If the emphasis is on grabbing lots of cases (but not resolving them) not so much. Ditto if the focus is on meeting rigidly scheduled customer updates. Instead, focus on outcome metrics that make a difference for the customer.  A good start would be to use customer satisfaction (measured by post-case surveys), productivity (cases closed per month), and resolution time (e.g. 80% of cases closed in 2 weeks). Align customer goals and internal goals.

And don’t reward laggards! In many support organizations someone with a high backlog is exempt from taking new cases. It could be ok if used sparingly but otherwise the message you are sending is to build up backlog to get some peace…

Organize cases by ownership

Who owns the next step: support? the customer? engineering? some other internal organization? It is the case owner’s responsibility to drive all cases to resolution, regardless of who owns the next step, but using broad categories will help divide and conquer the backlog problem.

Influence other internal organizations

if you have a large cache of cases waiting for another internal organization, perhaps Engineering, relying on individual case owners to push cases to resolution may not be enough. Instead:

  • Consider closing cases rather than waiting forever. For instance, it may be better for all involved, customer and support, to close cases with minor bugs, which you know will not get addressed, or not for a long time. Why create expectations that will not be met? Log the bug, ensure that the customer has a way to get around the problem, and move to the next issue in the backlog.
  • Define an SLA that includes appropriate incentives to resolve issues quickly, just as there are for support
  • Define a process for identifying and tackling issues that are not making progress. Why send 253 individual notifications about 253 stalled issues when you can instead review the entire list in a setting that rewards cooperation and prioritization?

Whittle away at the really stale cases

If you are starting with a large cache of old cases, focus on the 10% of oldest issues, whatever they may be. (Who knows, you may find some with birthdays!) With ancient cases, check with the customers first, as they may have lost interest.

From week to week, work your way towards less antique cases.

Conduct regular case reviews

There’s no miracle for backlog management. Every week, sit down with each support engineer and review each and every case in their queue: what’s the status? what’s the next step? are there any blockers? With some support engineers you will find they can do it pretty much by themselves, but for others you will have to do it each and every week…

Review the backlog at the management level

Ask each manager to report on older cases each week. This will force everyone to keep on top of case reviews.

How do you manage backlog? And have you found that your team closes more cases when it’s super-busy?

3 Comments on “Fight the backlog monster!”

  1. Thanks for posting my question. I would be interested in seeing any feedback that is provided.

  2. Dealing with old and stale cases is not particularly rewarding, as closing a 6-month-old case that nobody cared about hardly gets noticed.

    Perhaps the best way to handle it periodically is to trigger one fixed-size “round” of it at a specific time during the week when the associates might already find themselves slightly detached from the daily grind, such as “look at the three oldest cases after lunch on Friday”.

    Maybe you take a few minutes to reevaluate it, try to reproduce the problem on newer versions, try to understand why is it that the case fell through the cracks in the first place. In any case, the goal of this exercise should be to generate an update trying to get attention back in the case. If you revisit this case at a later time and find out that the last comment was your attempt to bring it back to life, maybe now you can just close it.

    In terms of turning it into a mildly rewarding activity, perhaps a small informal team celebration every month to highlight those “archaeologists” that closed the most ancient cases. It is still a boring activity, but the results can be turned into a nice social thing among team peers.

    For the very old backlog, perhaps one can even try a more extreme approach. If a case has had no interaction at all for 6 months or a year, just close it with a message stating it is believed to not be relevant anymore, asking the customer to reopen it if necessary. Closing a case does not lose any information, so there should be no harm in doing this.

    There is a slight probability that some customers will get annoyed if their stale case gets closed, but even this can be directed to a good outcome: you now have their attention and energy, so jump immediately into the chance to interact with them and drive that reopened case towards resolution. 🙂