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, timeliness, and resolving all of the problem’s details.
New issues can be a learning experience for all help-desk representatives. When the help-desk representative creates knowledgebase articles containing his attempted steps and their outcomes, his peers can review the articles the next time a similar issue arises. Learning from past issues and creating knowledgebase articles allows for easier resolutions of similar issues in the future and could improve escalation rates and customer interaction time, simply because the collective education of the group has contributed to the improvement of the service delivery.
If the problem cannot be solved over the phone, the help-desk representative must escalate the issue to the development team by creating a ticket, selecting a specific issue type, such as authentication issues, performance issues—or whatever else pertains to your business—as well as the assignment of a priority (ie. critical, high, medium, low—of which the timeframes and definitions match to your business processes) directly to the issue. Then, the development team can get to the root of the problem and fix it so that the issue will not arise for other customers. Future help-desk representatives who work on a similar issue should add their notes to the knowledgebase article and the development ticket for the outstanding item with their own thoughts and findings. Building a single knowledgebase allows for information to be easily accessible in a one place, no information will be left out and the development team that is solving the issue will have everything it needs.
Like everything regarding the help desk, these tickets need to be prioritized by which ones need to be solved right away and which ones can be put further down the queue. The development team sorts tickets by which ticket receives the most activity and it works through the screen shots and knowledgebase articles to re-create the user experience and fix the issue’s root cause. A good development team will resolve the most-often-occurring tickets in order to prevent more complaining customer issues in the future. Since the knowledgebase is conveniently in a single place, it is easy for the development team to work through all of the issue’s information it can re-create and solve the issue in a timely manner.
Help desks that consistently communicate key information across silos will be more successful because of their deeper understanding of an issue. The development team representative contacts the help desk representative noted in the tickets and knowledgebase articles to further understand the issue and brainstorm solutions. If a solution is hard to come by, a discussion with the help desk representatives may spur more ideas on how to solve the ticket. Usually, all tickets are resolved at this point in the process.
Once the ticket is resolved, the development and help-desk teams can test the fix. Testing the fix is important to ensure that the problem was definitively solved and that the fix does not generate additional issues. When multiple teams test the fix, it is more likely that everything will be working smoothly due to the diverse nature of the team skillsets and perspectives. Once the fix is tested, the fix can be released (to the user’s delight). After that, the team can then roll out the fix to all customers, which will ensure that the customers who were experiencing the issue will no longer be affected. This also prevents all other customers from experiencing the issue in the future.
It is not enough just to stop the continuous feedback process once the fix is released. Customers need to know that you have listened to them and resolved their issues. Customer communication is just as important as internal communication, so customers who complained about the issue need to be notified that they were heard. This gives the customers a great deal of satisfaction while building their confidence in your process and brand.
