Enline plc

A support query usually begins like this:

*phone rings / email pops up*

“hi, I’ve got a problem with X”

Listen

The most important thing first of all when someone calls is to carefully LISTEN to the user! (or READ the email)

Listening gets you an overview of the issue, however more often than not, by the time the person is reporting the issue to you, it usually means that they have finally given up or have no idea on how to resolve it themselves. This means the support engineer will not only have to deal with technical support issue but sometimes dabble in a little bit of emotional support too.

Being sympathetic to a person and listening makes them feel that they are not alone and you’re willing to assist. This clears their mind of perhaps an initial blind panic or frustration and they can then begin to discuss more openly about what is happening.

The key to solving an issue is to have as much information as possible. Just as important as listening, to get the right information is to ask the right questions. With the answers to these questions, a structured problem solving process can be started in order to resolve the issue.

What is the issue?

Normally this is often volunteered during the initial contact. Often it’s a non-specific “worldview” and therefore can consist of many variables and nothing specific about the causes of “how the world changed” is given. It’s a starting point for a support engineer and they will use this to aim questions based on experience of similar issues they have had to deal with before.

What / who is affected and how much?

This question is all about getting to grips with the severity / priority of the issue, this will also help identify the key players within the system that are behind the unexpected behaviour.

When did it happen?

Once you know when it happened, you can check for changes and scour logs around that time or shortly before and after – knowing when you need to look, saves a big chunk of time.

Has anything changed?

A change can be considered as anything from updating a document to a big hardware upgrade. A support engineer always has to be careful on the wording of this question! If it starts sounding anything like “What did YOU change!?”, this could be construed as asking the user to incriminate themselves! Therefore, it probably would be expected that some ambiguous information or a completely flat out “non truth” could be told.

Going forwards

From here based on the information gathered by asking the key questions (including issue-specific questions) above allows the engineer to carefully formulate a plan, using vast experience and raw knowledge of products to resolve the issue.  If all else fails “Have you tried switching it off and on again?!”