I am going to be honest, I despise working with tier 1, help desk or support staff. It's not the staff; the people for the most part are trying to do their best to help solve problems. My contempt is for their leadership and/or managers who in my opinion, don't seem to care about the user experience or people who use their product or service. This might seem a bit harsh or even hypocritical considering I've managed support teams, and I often work with support teams who manage intake for the platforms or teams I've managed. Actually my first role was as a junior web developer at a small technology firm where I was the main support engineer for about 100 websites. I handled client communication and executed on the work (i.e. sending HTML emails, building HTML pages, updated CSS, etc.)
Let me share a personal story of why the user journey matters and how empathy for your users is critical for improving the support process, having happy (or at least happier) users, and ultimately reducing the volume of work. So this story begins with a refrigerator that suddenly stopped cooling. Obviously seeing a pool of water at the base of your refrigerator and opening the refrigerator door and feeling warmth is discombobulating.
So we called the manufacturer to report the issue since the parts were still under warranty. This is where the misery begins. First it starts with a half an hour wait. We get to the point where we need to enter our model number; the problem is that the support application doesn't recognize the model number so we have to go thru another series of menus and voice options only to finally reach a support engineer. We explain the issue to that person who then transfers us to another person where we have to explain everything over again. We finally get confirmation from the manufacturer that yes there is a problem, and the soonest a tech can come out is in a week. So a week without a refrigerator ok great... for that appointment we have to prepay 200 dollars and we get told there is no promise that the technician can solve the problem during his visit. Tech asked the same questions, however, luckily they were able to fix the refrigerator. It could have played out that during the visit they couldn't fix the issue and would have asked to reschedule another appointment to finish. Regardless, the whole ordeal meant that we had 2 weeks without a refrigerator.
I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.
- Maya Angelou
So let's summarize:
- Call and wait 30+ minutes
- Asked to note model number, which couldn't be found by the support application, had to wait again
- Re-explain the process to another person
- Pre-pay $200 for an appointment that's one in half weeks in the future with no guarantee it will be fixed
Maybe you can relate (hopefully you can't) to the story above: working with help desk or other support engineers. Most of us can, which is part of the problem and it's the number 1 reason in my opinion people aren't a fan of dealing with support teams. Usually people will blame it on outsourcing, however, that isn't the problem here (outsourcing to an offshore team can work). It's the lack of thought put into how to make this process work for users who participate or more accurately are forced to use these lackluster support systems.
Choosing and training support agents
If I had an hour to solve a problem and my life depended on the solution, I would spend the first 55 minutes determining the proper question to ask, for once I know the proper question, I could solve the problem in less than five minutes.
- Albert Einstein
There is a general trend or tendency to hire new staff or junior level employees into support roles. I would advise against that approach. Your help desk or support engineers are your first line of support. They are the face or more accurately the voice of your product or service. Support staff should be well versed in the application, knowledgable in customer service and patient.
You need a dedicated support group, which should be composed of multiple team members. They should serve to handle client communication first and foremost, along with interfacing with internal teams (i.e. engineering, product, project management, etc.). Depending on your product, service and team, communication can include weekly status meetings, responding to tickets, service or maintenance updates, asking about other or upcoming work, telephone calls, automatic emails (personalized when possible), screen-sharing and ad-hoc meetings or even pulling in others to help. Communication is an important, if not the most important aspect of dealing with support requests. 3 key skills for success are: understanding your users, interpreting their requests and confidence in yourself and your system.
Another important skill that requires training is triaging. According to Wikipedia Triage is the process of determining the priority of patients' treatments based on the severity of their condition or likelihood of recovery with and without treatment..; influencing the order and priority of emergency treatment, emergency transport, or transport destination for the patient. So while this is obviously mainly used in a medical context it's an essential skill to being an effective support agent.
In order to triage effectively, a support engineer must be taught to properly gather information and determine the problem by analyzing the symptoms and figuring out the underlying problem. When analyzing, it is important to identify what the user is trying to accomplish so that time is not wasted on attempting to remedy the symptom instead of the actual problem.
Defining workarounds and vetting requests before they are routed to other groups is also essential. If this is done properly, you can reduce the issue queue and resolve requests faster. Done improperly, tickets can pile up, bounce around between different groups or come back to your group because of lack of details or understanding, not to mention dealing with upset users since their issue still hasn't been addressed. Triage is critical because if everything is urgent nothing is urgent. So it's a disservice to yourself and your team if you aren't assessing and prioritizing requests.
Finding patterns and collaborating with other groups
The best way to not feel hopeless is to get up and do something. Don’t wait for good things to happen to you. If you go out and make some good things happen, you will fill the world with hope, you will fill yourself with hope.
- Barack Obama
Once your team has a solid understanding and experience with communication, vetting and triage you are ready for the next level. At this point, patterns will emerge. You'll see the same questions over and over again about your application. You'll see the same requests in the issue queue day after day. Naturally, your first instinct will be to create a guide on how to handle these requests or a frequently asked questions page (FAQ). A FAQ is a page or document that lists out common questions and answers about a specific item in regards to your system.
While this may seem like a great approach, and in some instances it might be a decent direction to take, I would suggest a different course of action. FAQs put the burden on the user to read and find out how your applications works. More importantly, FAQs force the user to have to fix their own problem. Instead of creating more friction between your application or service and your user, consider making user experience or user interface changes to improve and simplify. FAQs do make sense in regards to certain types of questions, which I'll discuss later in the article.
So how can you incorporate user experience or user interface changes into your system: collaboration. You'll need to reach out to the Product Owners, Project Managers, Development Managers, Developers, DevOps, etc. Basically you need to get in touch with someone who can listen to your feedback, understand the problems facing the support team and help queue up changes to the application. This will likely be through several back and forth discussions, which will result in sharing different points of view and necessary conflict. However, through a collaborative model, teams can work together to define and assign priorities and put work into queues taking into account the severity of the problem, difficulty in implementing the development solution, and the importance of a particular user group. This escalation process is essential to the success of your system.
Making changes to create a healthy ticket queue and support process
Things don’t have to change the world to be important
- Steve Jobs
Properly using the escalation process can diffuse an onslaught of support requests and result in happier users. So it's critical you have a fluid process for getting bugs or system issues fixed in a timely fashion. You and your teams should work with other groups to prioritize impact. I've previously discussed the importance of setting priorities as a manager of a development team. If you are successful, you'll prevent issues from even making it into the support queue, which is critical for the success of your team.
Another critical aspect to the success of your support team is documentation. Using team experience and knowledge, support agents should document how things are done to better educate each other and make it clear how things should be handled or routed. This is a great scenario for FAQs. For example, if an API key needs to be generated and that relies on a development team, an internal or potentially external FAQ could be created to describe this process because it sits outside of the support team. So instead of deflecting work and requests that support agents can't answer or don't handle to other groups, the support team stays involved through the life cycle of that ticket so they can gain insight and take away learnings, noting the process for future tickets. This empowers teams with information so they are better placed to help people and avoid frustrations. Wikis, how-to guides, videos, FAQs or issue tracking systems can be used to record this information so it's easily accessible by the team.
Concluding on how to create amazing support teams
It's through vulnerability that human beings create connections. The more vulnerable we can be with one another, the more that we'll trust one another and the more we'll be able to collaborate effectively.
- Neil Blumenthal
Help desk staff should have superior knowledge of your system and ancillary systems. Support engineers should know the ins and outs of the system in order to quickly triage/resolve/route tickets and filter out the noise to escalate "real" business problems. Support engineers should be looking to solve problems permanently and feed system improvements back to the internal teams. Naturally, people in these roles want to help and solve user problems, so they need to be empowered to do so to improve user satisfaction.
In order to do that effectively, solutions need to be provided for them for long standing issues and common problems. There should be an escalation path from help desk staff to development/product teams. By using documentation, training and collaborating on priority issues, problems can be queued up or flagged to the appropriate group for resolution depending on the severity of the issue, difficulty to resolve and the importance of the user. Good luck and happy triaging.