What makes a good technical support engineer?

Having been in a customer facing technical support role for quite a few years now, and having migrated to cover an entirely different suite of products, I feel I have learnt at least some of what is required to make a good technical support engineer. So I have put together what I feel are five essential tips - many of these are common sense, but often when you are bogged down in the nitty gritty of a complex issue, you just need to take a step back and remember the basics that will help you and your client get the best resolution.

Knowledge is King:

It really should go without saying but you need expertise on the product you are supporting, but not only from a user's point of view. You need to learn how your product interacts with its back-end components and any 3rd party systems. If you don't know the internals of your product from top to bottom, then you won't be able to make that link between the problem the customer is reporting and the probable causes. You might start delving off in the wrong direction entirely when a simple solution would be staring you in the face if you knew about all those however uncommon nuances and potential mis-configurations in the first place. When you do learn something new during the course of an investigation, make sure you will be able to remember it six months down the line - filing it in your organisation's internal debugging documentation will not only help you, but help drive quicker resolutions going forwards.

Be your own Bot:

You may not have encountered a particular issue before, but the chances are someone else in your team has, or at least they have had a very similar investigation. The vast majority of organisations now utilise sophisticated in-house or 3rd party ticket management solutions that make finding past resolutions a doddle. Use those categories to filter the issues down and think up the likely keywords that a customer/support engineer would have reported their issue with. You will then have a list of tickets to refer to and see how best to advance your own resolution. As the point of contact for the customer, it is you who has the most control over the resolution time for a ticket from the outset - if there is no need to engage another team to determine an answer, then make sure you don't do it. Check all the product documentation, both customer facing and internal only, read the past tickets, look at any defects raised with DevOps and consider everything that could be causing the problem. If all else fails, don't be afraid to ask the product expert if there is one internally.

Trust no-one:

Our goal is a quick resolution but never ever take for granted what the client has said - replicating the reported issue is a must, but don't just stop there; dig deeper and consider what else could be affected that the client hasn't reported (yet). Don't assume the problem is isolated to the reported issue or even that what the client has reported is actually accurate as there could be user-error. If a client reports an issue that you have to resort to other internal teams to resolve and you close the ticket out asap, that's great, but what if then the client comes back with the same issue affecting something slightly different? It is frustrating for them, for you, and for the internal teams and such scenarios negatively affect relationships between all involved. Get your facts right at the start to ensure a professional engagement with the client. Dealings with Support create a significant perception about an organisation and it is critical to deliver competent investigations. Important too in terms of trust, is to always double-check any information you get back from those internal teams - don't rush to send a resolution solely based on what they have said - nobody is perfect, so do a quick check before confirming anything with the client.

Tact and Diplomacy

Often there will be those high pressure situations where you are on the front line, dealing with an angry frustrated client, criticising (maybe correctly) the product you support. It is at this point you need to listen well and acknowledge the customer's point of view but at the same time move the focus of the conversation on to what can be done to improve the situation, rather than dig further into what is wrong. Ultimately this is what everyone wants so don't take anything personally and be patient. Be professional, follow procedures and ensure communication on high severity issues is flowing as is required - make that your responsibility. If the routine procedures aren't getting you where you need, use your contacts throughout the organisation to get things done. Remember in all communications to put yourself in the client's shoes and think what would be important to you, if you were them. Given that, try to pre-empt what follow-up questions they might have based on your responses to them. Give them the information they need without being too succinct but at the same time not overly verbose. Furthermore, use your position as the customer's sounding board to really listen to them as in a technical support role, you have an unique opportunity to both drive improvement through product management but also to enable account managers to have the right conversations with their clients by being a temperature gauge of customer mood.

Skill Up:

The products we support are always changing, so it is important to keep up to date with all developments and understand why features are being introduced/retired. Make sure you are aware of all sister products in your organisation's portfolio and take the time to gain an understanding of them and how they integrate with the products you support. Having a good working knowledge of competitors' software and how it stacks up against the products you support will help you see where any gaps lie that you can then feed to product management. Knowing why customers are using your product over and above a competitor's will help you make suggestions to keep your product at its best. As well as product knowledge, make sure your industry skills remain current - renew those certifications and gain new ones where you can. Bear in mind that the irony with many service-based jobs is that the ultimate goal could be to make your role obsolete - improvements in code development processes, QA testing, product documentation, knowledge-base applications and the introduction of automated customer service bots are all charting a course for the erosion of the traditional technical support engineer role, so set yourself apart with the skills you possess and continually develop.