When it comes to release management, it is essential to start with an in-depth analysis of the service delivery and development work flows in order to further continuous process improvement between your help desk and your development team.
It is essential to start with an in-depth analysis of the service delivery and development work flows in order to further continuous process improvement (CPI) between your help desk and your development team. This is especially true when it comes to release management. Breaking down barriers to the on-going understanding of customer needs through actionable data not only will help your organization improve the user experience of your product but also will increase the quality of your help-desk customer experience.
Similar to all business processes, repeatability is key. When it comes to help-desk-driven release management in which you are essentially creating an ever-evolving loop and connecting your product iterations to satisfy any issues and perceptions of your end-users, you must use a highly repeatable process in order to gain actionable, quantitative data.
CPI’s exist everywhere and while this is by no means a new concept, it is one that I want to expand upon. Here’s a classic example based on my own organization’s legacy operational take on the CPI:
- A customer has an issue and contacts the help desk.
- The help desk troubleshoots the problems that arise using decision trees, fixes some of the issues (typically 70 percent), records bugs, and escalates a summary of the issue, and suggested action items to the development team in a general developer ticket queue.
- The development team tries to resolve the highest recurring issues in the next product release.
Now that we have this outline, let’s dive into the workflow a bit deeper and develop some specific processes to be followed at each step.
The customer is the first point of contact because he has a complaint or an issue and contacts the help desk. It is important that this initial contact with the help desk is a positive experience for the customer, even if his issue does not get resolved at this particular time. At this initial touch point, it is important that the help-desk representative empathizes with the customer and gathers pertinent issue details. In order to solve the issue, the help desk must determine what the issue is. Customers may believe that the issue is one thing, but what they describe may be something different. It may be necessary for the help-desk representative to access the device remotely to walk through the issue with the user. If the device is unavailable remotely, screen captures tell a thousand words. Additionally, even the diarizing of the issue and knowing the steps that caused the issue is a good way to gather data points prime for analysis. Recreating the issue is the best way to get the help desk and the customer on the same page, as it reassures the customer that the help-desk representative knows exactly what he is talking about and the customer is more likely to feel that there will be a resolution.
After assessing the issue, the help-desk representative updates the notes with screen shots and the context within which the issue occurred. This documentation is important for further research after the call or in the event that the call must be escalated to a more specialized engineer who is well versed in the issue at hand. For best practices, the help-desk representative records the system information through user-defined fields (drop downs), so that the information gathering process is repeatable and consistent. A help-desk process is the key for improved quality,