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”