Backlog and “Why Can’t I Close This Case?”

How to define and measure backlog, together with its sister question, when to close a case, seem to always trigger high passions in team meetings.  I thought I’d share my experiences here and ask for sharing of readers’ experiences.

I always viewed backlog as all cases that have not been closed.  And the size of the backlog represents the total impact to customer value as a result of support cases.

With that said, we need to think of backlog from several perspectives:

Operationally, backlog can be broken into several groups:

  • What we are working on or is waiting for us
  • Cases for which we are waiting for someone else internally to respond (specialist knowledge, R&D, marketing)
  • We are waiting for the customer to respond either with information or confirmation that a fix we have given worked

When measuring backlog, we must be able to distinguish between the three groups and analyze it separately for improved performance.

For example: support managers do not usually concern themselves with cases waiting for the customer to produce information.  Not until the customer complains, at least.  However, examining these cases more closely may reveal the need to develop guidelines or tools that will help customers produce diagnostic information quickly and with minimal effort.  I am sure you can think of additional examples.

So, back to the original question “I have given a fix, why can’t I close the case?”  “Because a case is not a vehicle for support workload, it is a representation of diminished customer value and the experience associated with solving the problem.  Therefore we do not close the case until customer value has been restored”

4 responses to “Backlog and “Why Can’t I Close This Case?”

  1. Haim –

    I agree with keeping the case open until we have confirmation that customer value has been restored (with appropriate exception handling for customers who won’t tell us after some number of contacts and some period of time.)

    To your point of there being different classes of cases in backlog, I encourage people to measure Time to Relief (likely resolution delivered) as well as Time to Resolve (cases actually closed.) Time to Relief lets you get a sense of when customers are getting value restored, without prematurely closing cases.

    Of course, *averaging* Time to Relief or Time to Resolve is a bad idea, but that’s a topic for another post1

  2. Thanks David,

    Averaging anything is a bad idea, except, maybe, the same variable over time. I will definitely write a post about why average is a bad descriptor.

  3. Pingback: How Old Is Your Case Load? | Enterprise Software Support

  4. Pingback: Automatic Case Closing, Good Idea Or Not? | Enterprise Software Customer Support