Communicating with the IT Help Desk

If you took an informal poll and asked some your work colleagues how many of them enjoyed calling the IT help desk .... how many would say they did? I suspect the numbers would be low.

In many of situations, reaching out for help only happens after you’ve tried to resolve things on your own. After you've exhausted all possible workarounds you can think of to complete the task. Prior to calling, you may even allow a bit of time to pass hoping that the issue with automagically correct itself....

Why don't we like calling the help desk?

The issue isn't isolated to healthcare. The thought of calling the help desk for the bank, cellphone company, or internet provider can bring forth a feeling of dread for a lot of people. ... Now, I do recognize that this does not apply to everyone. Some individuals are completely comfortable with making these types of calls. If you are one of these people - I applaud you for that.)

What is wrong with the process that makes it less than ideal?

To start with, it seems to take forever and time is a valuable resource.  Especially in a clinical setting. If you are lucky, you have the number memorized and don’t need to hunt for it. (Or better yet, your workplace has the number posted on, or close to, workstations and phones.) When you finally make the call, chances are there’s some sort of phone tree on the other end to listen to.  You'll need to take more time to ensure you select the correct option for a real live person who may be able to assist. Now, once you’ve made it through the tree and a live voice answers, explaining the issue so it’s understood is a whole different ballgame. It may even seem like  healthcare providers/staff and IT staff don’t speak the same language ….. Sure it’s all English, but you’ve got a clinical perspective and they’ve got a technology perspective. Rarely do the two align during brief conversations.

Is there anything we can do to make it better for ourselves?

Do we need to resign to the fact that it will never be a great experience and continue on our path of avoidance? I’m not sure it will ever be enjoyable. (Asking for help puts one in a vulnerable state which is not typically one of comfort.)  But, it may be possible to make it a bit easier, and if all goes well - a bit more effective.

5 high-level concepts for end users to make communicating with the IT help desk a bit easier.

1)  Maintain a positive and professional demeanor.

Having a professional demeanor can go a long way towards achieving a pleasant outcome.  You may be having a terrible day. And before reaching out for help there may have been some pretty stressful moments. ... But, the individual on the other end of the call is not personally responsible for the issue/situation. Keeping this in mind can assist you in maintaining a friendly tone.

If the conversation seems negative, a natural instinct for both parties will be to finish the call as soon as possible. (Often without and acceptable resolution.) If the situation is unpleasant the parties may be less likely to ask clarifying questions and the risk of assumptions can increase. (Assumptions should be avoided whenever possible in both the technology and clinical worlds.) The likelihood of receiving effective and efficient help increases with a positive conversation.

2)  Provide context.

According to the oxford dictionary the definition of context is as follows:

“The circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood.”

Providing context for an IT-related issue is huge - be it technical in nature or workflow related. It holds true for both the caller and the help desk staff member/IT analyst receiving the call. Nothing sends troubleshooting down a rogue alleyway faster than assumptions.... And, failure to provide context can lead individuals to “fill in the gaps” with guesswork.

It’s unfortunate, but in many situations overcoming the first assumptions can be difficult. For the end-users this assumption is often that the issue is technical. For the help desk staff/IT analyst, it's that the issue is user error or workflow related. I know - I don’t like this either, but it happens, a lot. The only way to work through this one is for both sides to provide context and to explain the situation and their thought process in more detail.

Key components for context include detail on the following:

• What were you trying to do when the issue occurred?
• Were there any steps taken prior to the call to remedy the issue? (e.g. attempting to work around a previous error which resulted in the current error message)
• Is the IT analyst aware of anything technical that may be causing end user issues? (e.g. a recent change or steps to correct prior technical issue which may have affected end users?)
• Is this issue/system behavior happening to others or has this happened before?
• What are the technical components to consider? (e.g. mobile device vs desktop, connection method - wired/wireless/cellular, etc.)

3)  Avoid acronyms and abbreviations.

In my many years of experience in this industry, I’m not sure who likes to use acronyms more - IT staff or clinical staff …. It should come as no surprise, that with two very prolific acronym loving groups, there are some crossovers.

My absolute favorite has to be "MI".  On the clinical side MI stands for myocardial infarction. (Another term for heart attack). On the IT side, MI often stands for a major incident.  (Usually defined as significant technical event that requires an 'all hands on deck' response ... I like to think of it as a “code blue” for the IT department.) Yet, to some in the IT world, MI can mean message indicator or management interface …. On a couple of rare occasions in a clinical setting I've seen MI used as an abbreviation for mental illness. You see how this could get confusing?

It's not hard to misinterpret acronyms. So it’s a good idea to avoid them wherever possible. Unless of course, they are a critical component of the issue. In those situations make sure to articulate the acronym definition.

4)  Set expectations.

It’s important to make sure both parties are on the same page about expectations for the call. Far too often, the end-user is looking for an immediate resolution or a workaround they can use.  They want to get on with their day as soon as possible. Unfortunately, with some technical issues, an immediate resolution is not going to be possible. Instead of a quick resolution, the help desk staff/IT analyst needs to gather detailed information to investigate the issue. I’m sure you can imagine how frustrating it can be when all you want them to do is fix the problem. ... and all they seem to want to do is ask tons and tons of seemingly irrelevant questions. Verbalizing expectations is key to ensuring that both parties are on the same page. It also allows both parties to clarify their needs.

5)  Be aware of and respect roles.

This principle is one that often gets forgotten. On the end-user side ... we like to think that the individual answering our call for help is an all-knowing technical wizard. One who understands our issue perfectly and has a quick simple solution every time we reach out. On the receiving end .... we like to think that the end-user has all the time in the world to interact with us and they have a perfect understanding of how to use the applications.  Not to mention they would never even consider straying from the defined and documented workflow. (I’ve been on both sides of these calls and I’ve had to face the reality that this is not the case on many occasions.  Much to my dismay.)

It is important to recognize that there are a wide variety of proficiencies and areas of expertise in IT. It is not possible to be an expert in them all. There are also several clinical and administrative roles, where job scope will come into play. Most applications have role-based security. The result is that only those with the required credentials/security clearance can complete certain tasks. (For example, a pharmacist cannot authorize an inpatient order to discharge a patient. With role based security the application will restrict this from occurring.) This is no different on the IT side. Except for some ‘one-stop shops,’ it’s not atypical for a system analyst to be restricted from interacting with network and server settings. It is important for both call participants to communicate if there is a need to involve others. This helps to align expectations.

For example, let’s consider a situation where a clinician/provider calls because they can no longer enter orders on a patient’s record. (The icon is grey or an error message is appearing which prevents the action from completing.) After some investigation, it is discovered that the patient has been accidentally discharged in the system. To remedy this, you may need a clerical/administrative end user to reverse the discharge. By nature of their roles, neither the clinician/provider nor the help desk staff / IT analyst can perform the action. Both participants in the conversation need to respect the roles of each party to reduce the potential for frustration. (Note: It is important to communicate who will be responsible for contacting and other individuals needed. This is so the resolution is not delayed.)

While, the concepts above cannot guarantee that every call to the IT help desk is effective, efficient, and overall pleasant experience - they will help. Who knows, they may even lead to some improved numbers in the informal poll that was mentioned at the start of this post :)

"To effectively communicate, we must realize that we are all different in the way we perceive the world and use this understanding as a guide to our communication with others. "   Tony Robbins