A few days ago I had a very interesting conversation with an executive in the enterprise technology industry. We spoke about identifying the root cause for case delays in particular and ways to analyze case traffic in general. I was very surprised to learn that the concept of case lifecycle and the ability to track that for time as well as failed attempts was completely new to him. In this light, here’s a case lifecycle primer and a some metric guidelines associated with it.
If we think about a typical case, in most companies it would transition between multiple entities handling it for multiple reasons. Those may be the customer, the support team, an escalation team and possibly the engineering team. The case will spend some time waiting for a person or a technology resource to become available, be worked on and then transition to the next phase. As we well know, the case may spend varying amount of time in each phase and can transition between those phases repeatedly. For example, a case is opened, assigned to a support engineer, who analyzes it, proposes a resolution to the customer. The resolution does not work, the customer returns the case to the support engineer, who researches some more, requests additional information, etc.
The discussion we had concerned support managers’ ability to analyze information from case life cycle and associate the phases with improvement opportunities on one hand and impact on customer satisfaction on the other. To give us the level of detail needed, we must know, for every case, what state it is in. This state needs to include the entity that owns the next action (customer, support, engineering, etc) and details of that action. For example, a case status may be “Customer – Installing Fix”, “Customer – Collecting Information” or “Engineering – Fixing Bug”. Now, in order for this information to have any value beyond the immediate case status, we need to be able to map the entire case journey along a timeline, and do it for our entire caseload.
So, how do we do that? Enter the audit trail.
Most case management systems keep an audit trail, some will log all changes to the case, others only specific ones. In any case, recording status changes and their timestamp is the first step we need to take if we want to analyze our case load. Once we do that, we can begin to understand where our cases spend their time which will enable us to investigate the reasons for the delays. More adventurous managers will want to attempt regression analysis of various case parameters to determine the operational drivers of customer satisfaction, from case life to repeated requests for additional documentation.
Have you ever attempted to analyze your caseload this way? Have you been able to come to any meaningful insights and drive improvements?
