The Help Desk How-To

Objectivity is the name of the game

2006-06-28T12:07:00.000-04:00

As a technician, I'm forced to use many different products from many different vendors every day. Whether I'm deciding to recommend Veritas or BackupAssist to a client, or whether I'm going to be remotely connecting to a computer using DameWare, VNC, or Remote Desktop Connection, for any given problem, there can be quite a few solutions. One of the problems I see with technicians today is the rampant 'fanboyism' that seems to be entirely too common.

What do I mean when I say 'fanboyism'? Well by that I mean that there are people out there who line themselves up behind one company and will support it to its death no matter what happens between now and then. While this seems to be most common in the video card (ATI vs. nVidia) and OS (Windows vs. Linux/BSD vs. Mac) arenas, you can find these zealots in pretty much every facet of our society.

Why is this a problem? As a technician, your primary focus should be on your customer. Not your profit margin, but how satisfied you can leave your client. When you start following a certain company or product without regard to actual quality, you are putting your customers at risk. Risk of what? Risk of not having a superior product. It is a case of the blind leading the blind; they are blind because they don't know better, and you are blind because your judgement is clouded by a logo.

When you are making a decision for yourself, you should feel free to purchase or use whatever product you like; by living in a free country with a free market, it is absolutely your right. When you are purchasing on behalf of your client however, this is no longer your purchase, you are simply and intermediary between a purchaser and their product. Your opinions should stay out of the process unless specifically requested (e.g. if you're asked 'which of our options would pick?' then feel free to weigh in.)

If you have data that can back up your statement (e.g. 'if you goto website W, website X, or website Y and look at their reviews of product Z, you'll see that they unanimously agree that product Z is the superior product') that is great and there isn't a problem. The problem arises when people become so attached to a product line or company that they will recommend it solely on name alone, and not on the performance of the product. Just because a product performed great in the past does not necessarily mean that it will perform well in the future.

While I have no doubt that company N has served you well in the past, whenever you make a recommendation to someone else, they are trusting that you are recommending a superior product. To find out which is the superior product, you should be able to provide the research you've done as to why it's the best option. You should be putting yourself in their shoes, and wondering 'if I was this client, what information would I like to know about this recommended product?'

You won't always be asked to provide references. In fact, the times that you are not asked will probably outweigh the times you are asked about 99 to 1. Regardless of how often though, you should always be prepared to cite netural sources, and by that I mean if you're recommending a search engine to a client, citing a report from searchenginedigest.com is good, citing a report from googlesucks.com is not.

So to wrap things up, you are going to be trusted to make a recommendation to someone sooner or later. You can do the irresponsible thing and recommend something on gut instinct, or you can do the responsible thing and do your homework; find out which of your options is the best not because of loyalty, but because of respect for your clients.

Justin Smith
nexxai@gmail.com

The Zen of Research (Part 1)

2006-06-27T14:37:00.000-04:00

This article will be the first in a multi-part series dealing with how to research issues using the internet, other mediums such as books or manuals, and other technicians. This particular article will focus mainly on using search engines as your first line of defense when faced with an issue that you may not be fully ready to tackle.

Inevitably, as a technician you are going to be asked a question that you don't immediately have the answer to. Whether that day is a week from now, or a year from now, someone will ask you about a technology that you just don't have a clue about and you will be forced to do some research.

The problem with research is that there are so many avenues you can take, yet it seems very few people know how to use the tools they have at their disposal effectively. Not to say that they aren't being used at all, but in my experience they aren't being used properly.

Now what do I mean what I say "they aren't being used properly?" Well for example, every technician I know understands that the internet is your best resource for 80-90% of any technical issue you're faced with; they know to load up Google or Yahoo! and that once they find their way around, they'll be able to find the documentation they're looking for. The problem is how they use these tools.

[NOTE]: For the remainder of this article, I will be using Google when I talk about search engines, simply because it is my personal favorite. These tips however are not limited to Google, and will work on the search engine of your choice.

The biggest problem I see with people using Google is the terms they use when they're trying to find documentation or any kind of information on it, really. For example, they know that a user is having printing problems, but they aren't quite sure what to enter in the magic text box that seems to taunt them on the Google home page.

Before we start searching, we need to get a few pieces of information:

- Have there been any changes since the problem first occurred?
This can be tricky as when you ask, you don't want to imply that they were the cause of the problem. A technician who was by their desk earlier who installed a simple word processing application may have inadvertently caused the issue.

- What hardware is involved in the problem?
If we use the broken printer example from above, this would include not only the model number of the printer, but also of the computer, how much ink is left, and how much paper is in the tray

- Are there any warnings or errors being presented?
This not only includes messages on the screen or display that might give you some insight as to the problem, but also any audible warnings (beeping, scraping, etc). Also, the lack of an error message in some cases, can be as useful as no message at all.

- How many people are affected by this issue?
This isn't as necessary in the research phase as it's more of a general troubleshooting question you should be asking, but it's good to have handy either way.

Once you've got the above information, you should be equipped enough to start doing some research into the problem.

How do you do that you ask? Plain English (or thereabouts). One thing a lot of people don't understand about search engines, is that they aren't incredibly intelligent devices. They give us the power to search the internet, but they don't really have any kind of intelligence. How does this affect you? Well, you have to understand that all a search engine does is go to millions (or billions) of webpages, and makes a list of every word found on that page, and then keeps track of where those words were found. It also keeps track of what words are grouped together more often. Knowing that, we can simply enter in keywords of what we know and it will search its own database for pages it found with the words you entered together.

Sounds simple, right? Well it is, but there is a bit of a catch. Search engines will typically only allow you to enter 10 real words (real words being any words other than common ones such as "it", "and", "to", etc.) so you need to be able to look at your problem and pick out at the very most 10 words than accurately describe the problem you're having.

Using the broken printer example above, let's say that there were no changes made to anything, it's a Dell Optiplex GX280 PC connected to an HP 3380 All-In-One printer via a USB cable, there is an error on the printer that says "Unable to Communicate with HP scanning software", and there is only one affected user.

Looking at that description, it can seem a bit intimidating but it really shouldn't be. My very first search on Google would be: "gx280 hp 3380 usb unable communicate" I'm sure the first thing you're asking is 'Why didn't you put the word "Dell" in front of GX280?' The reason is that 'GX280' is a fairly uncommon string and while adding the word Dell may remove a few non-Dell entries, it's not going to be significant enough to warrant it. 'GX280' is obviously a part/model number so it's pretty specific, however '3380' could apply to anything and as such, we want to make sure we're clearly defining it as an 'HP' product.

After running this search at Google, there are no results. Should this be surprising? Absolutely not; you won't always get the perfect search the first time. Now, you should start looking at your search string and figuring out what may too specific. My first removal would be the 'GX280'. At this point, I would be assuming that there are no known issues with those two devices and should be ready to accept that this is an accepted configuration.

After running a search of "hp 3380 usb unable communicate" on Google, the first reply is a forum post on the HP website with some troubleshooting steps and multiple possible fixes. This is a great starting point as forum posts are often frequented by users themselves, and while they may not be official support, they usually have some pretty helpful advice.

Being able to pick out only the most important words in a bunch of geekspeak may be difficult at first, it only gets easier with time. Just remember to keep as much detail about the problem in the search while not getting so specific that you end up excluding relevant documents from your search. Personally, I find it easier to run a search that's too specific and widen my search parameters from there.

In our next installment, I'll be speaking about how to use hard copy documentation to its maximum potential. I'll be explaining how to obtain documentation from the vendor, and how to use it without wasting anyone's time.

Justin Smith
nexxai@gmail.com

Setting customer expectations, SLAs and saying no

2006-04-13T18:47:00.000-04:00

The topic of setting customer expectations while working within SLAs and having to say no is probably the most business orientated aspect of any technician’s job. While all three topics will most likely be defined by management, it still falls to the technician to adhere to these guidelines to maintain company profits, but you must do so while maintaining good customer relationships.

Setting customer expectations

Most companies have Service Level Agreements (SLAs) that will dictate for you when a resolution is expected given a certain severity of call. As a guideline for those who don’t work in an SLA-driven environment here’s a brief description.

Severity 4 – A single user is unable to use a non-business critical application or has a work around provided for a business critical application but normal operation is not functioning.
Average Resolution Time: 3 – 5 Business days

Severity 3 – A single user is unable to us a business critical application or multiple users can not access a non-business critical application.
Average Resolution Time: 2-3 Business days

Severity 2 – Multiple user are unable to access a business critical application.
Average Resolution Time: 1 day

Severity 1 – Major outage, multiple users are not able to access all applications, internet, e-mail etc.
Average Resolution Time: 1-4 hours.

The above is only meant as a guide as each corporation will set different SLAs based on cost; obviously a company can supply severity one support for severity four issues the moment they find the pot of gold at the end of the rainbow.

In order to set adequate customer expectations, you need to tell the user in clear and simple words “Based on your level of severity, I will have this issue resolved in [insert SLA time]. I will be working as diligently as possible, however if you don’t receive resolution within that time, please contact me.” The user will often push back with “But I really need this fixed now.” It’s important to control the situation with something like “I understand and I will work as quickly as I can to resolve this issue but I do have additional cases in my queue and I am following company guidelines for addressing these cases with the appropriate severity. If you’d like to escalate the severity of this issue, I will need to contact your manager for approval.” The point to make here is that you are working hard, you are on their side but you are also on everyone’s side and it isn’t possible to bump them ahead of the line as that’s not fair to anyone else in your queue.

Almost every corporate environment also has an escalation process that will allow users to move up the severity of the case. You should provide that option to the client only if requested, because more often then not it requires contact with a manager who will require justification for the change in severity. This really prevents a lot of “I was surfing porn and now my computer isn’t working” calls from being escalated. This may seem harsh but it’s very important to have your users understand that when it really comes down to crunch time, not stupid user tricks, that you’ll be there for them.

Now then, back to the heart of setting customer expectations. It’s very important for technicians to realize that no matter what the problem is, it will take you 3 hours or more to fix it. You might be saying “Wow, this dude really sucks at his job if he can’t fix anything in less then three hours”, but that’s not what I’m really saying. Many times, users will have 20 more questions for you once you get to their desk, plus 8 more problems you’ve never seen and a friend down the hall who is having a similar yet (amazingly enough) completely different problem that you should check out while you are there. Any smart tech will ask a user for a 3 hour block of time to work with the user or alone on the users system. This will give you enough time to investigate the issue at hand and any other potential problems and if you are able to resolve everything in significantly less time then you explain that it’s better to be safe then sorry and be on your merry way.

Third party vendors

Eventually, you will have to deal with a third party vendor to supply you with parts, software, or any real type of good and/or service. At times like these, it’s important to be very clear with the client. If a part is on order and will take two weeks to arrive, you obviously can’t resolve the case any sooner then that. Inform the client that you are waiting on a vendor and that you may not receive your product for at least that amount of time, but probably a bit longer. Since a third party vendor is not something you can control, you should never give a firm date unless you have a contractual obligation from the vendor.

But I don’t have SLAs…

Get some. Obviously you can’t force someone to have SLAs if you are working on a job site without them. But that doesn’t mean you can’t maintain your own SLAs. Depending on your current and regular work load you should be able to keep a reasonable SLA with your self. If I’m a single technician who is responsible for 10 cases a day that take an average of 1 hour to close I’m not going to be able to treat all my clients with severity two level, but I can resolve most of them that way. If you maintain your own personal expectations and set them at a realistic and reliable level then your clients will see you as a valuable professional. I can’t stress enough about how important it is to keep appointments with clients and provide updates to them when plans change. You won’t sound unprofessional if your clients are expecting resolution as early as this afternoon but as late as tomorrow and you don’t resolve that day as long as you tell them the moment you know. If it is a severity one issue address it above all other clients so that you can present a consistent ‘When I need a technician, I’ll have one.’

Saying No?

I know, you are saying “That word is not in my vocabulary; I have been instructed by Managers that I can not say no.” They are right, never say things like ‘No’, ‘I can’t do that’, ‘it’s not my job’ or ‘I can’t help you.’ If you have an issue you can’t resolve for one reason or another it’s still very important to not say no.

Problem 1: You don’t know the resolution.

In this case you respond with “This problem is going to be escalated to a high level technician. This problem goes beyond the scope of my capabilities.” This is a good way to say you don’t have any clue as to what’s going on and you need help. You should now make every effort to have a higher level technician show you what is wrong with the users problem, after all you want to be able to resolve this problem should it arise again.

Problem 2: The support request is not covered by your contract.

"I’m sorry sir but we can’t fix stupidity." "Your toaster is not a supported device; please don’t call back, ever." There are days where every tech wishes he/she could say either one or both of those. A correct response is “I’m sorry but that’s not something we are able to support, if you’d like, I can take this call to my manager.” With this response you are giving the person a way out, escalation to your manager, at the same time it frees you from having to explain how absurd the request is; “I really can’t explain why I can’t support this, I will route your call to my manager if you’d like.”

Problem 3: The request is unsupportable, by anyone.

Requests like this often come in the form of “I want to be able to get my e-mail while visiting the moon.” or “How do I setup Linux to run on XP?” Stick to answers that are honest and avoid blame “I’m sorry but that’s not a configuration that is supported by the manufacturer and I don’t have any documentation or resources that would enable me to configure your system like that.” If you are faced with “But Bill in accounting has his Windows running Linux” then offer to follow up, “Well I don’t have it as a supported configuration, if you’d like I’ll contact Bill so that I can understand his setup and see what we can do for you.” Often in cases like this the user doesn’t know what they are asking for, this would take us back to “Speaking to your client (Part 2)”

Finally, you need to be able to stick to your convictions and stick to them consistently. If you tell one user one thing, assume they've told every other person in the company about it, because if someone else calls back with that same issue, you better be ready to offer the same resolution as the first one. Word travels fast in an office, and if you start offering different resolutions or SLAs to different people, eventually it's going to come around and bite you.

To summarize what's been said today, you need to be able to set clear expectations for your clients, but you also need to be able to set realistic boundaries for them as well. Being able to sit down with your management and work out guidelines that will protect both you and your users will do wonders for your rapport as they'll be able to expect the same great service from every technician in your organization.

Robert Reid
rfgreid@hotmail.com

A proper analogy for any technician

2006-04-13T13:12:00.000-04:00

I have found one of the most gut wrenching things to do as a help desk technician is trying to explain a problem or resolution in layman’s terms, the only thing worse than that is hearing another tech mess up by giving a bad analogy, and possibly having to backtrack.

I have found that the best analogy that any technician can use is the office environment it self. After all, explaining to a user that the difference between a Pentium III and Pentium 4 is similar to the difference between six cylinder and eight cylinder engines is asking the user to understand computers as well as cars. Obviously if you are supporting an office user, they work in an office and it should be an easy comparison.

Here’s what I’ve developed so far:

Hard Drive: A hard drive is like a filing cabinet. It holds all the files you have saved, it’s big but not very fast and so it takes some time to find the files you need.

RAM: It’s your workspace, your desk. The more surface space you have on your desk the more files you can have out of your hard drive and the easier it becomes to add tools (programs) and paper work to your work area.

Cache: Functions as a small IN/OUT box. It’s a temporary storage place for files that are being worked on but do not need to be on the desk right now.

Page file: Desk drawers, a small filling cabinet that can temporarily hold some files that you will be working on again in the near future but don’t need now. I often have questions about this since many users don’t understand the difference between RAM and HDD space. Once I explain the difference with what I’ve written above in Hard Drive and RAM, the concept of virtual memory often makes heads explode, so do your best to avoid this topic if at all possible.

CPU: The user. It’s the brain, what makes things go. You can even explain that a GHz is actually a measure of the number of instructions a computer can process per second. I often equate this to ‘how many lines of a document can you read in a second?’ This way you can also explain that a program has hundreds of lines in it that allow it to perform a single task. I also feel it’s important to explain that the human brain is much more complex and that although it sounds like a lot (3 billion instructions per second) the instructions have to be simplified for a computer to process them.

Network: Telephone. A network is after all a physical connection between other computers / sources of information. If you get a questions like “What is the difference between 10/100/1000 Mb networks?” Then keep the answer simple, each is 10 times faster then its predecessor.

That’s about all I have thought of for explaining a computer to a user. I’m sure you see how easy it can be to add an additional item to this analogy. I strongly believe there is no reason to vary your analogies and if something can’t be explained within this analogy then explain it technically. As we’ve explained in previous posts, tell the client ‘The only way I’ll be able to explain this to you is to be very technical, do you still want me to explain it to you?’ If they are interested in hearing it, proceed.

Robert Reid
rfgreid@hotmail.com

How-To: Speak to your client (Part 2)

2006-04-11T14:27:00.000-04:00

As we discussed in part 1, communication is as big a part of your job as a technician as the technical know how. No longer are the days where the IS or IT departments are holed up in a bunker some 20 floors beneath street level, or put in a 3 foot by 5 foot closet and expected to never speak to anyone. As a current technician, you are going to be forced to interact with your users directly. Whether that means being on a SPOC (single point of contact) such as a helpdesk or technical support line and speaking to the users on a regular basis, or being a second/third level technician who needs more information about an issue and must contact that user, you will be speaking to someone outside of the IT department eventually. How easily you can adapt your conversation to the user's knowledge level will determine how much confidence the user will have in you, as well as what kind of leeway they will give you should the resolution take longer than expected.

This article focuses on the soft skill (or people skill) techniques you can use to communicate more effectively with your client which will let you focus on the more technical part of your job. We will go over things like how to determine your user's technical competency, how to explain issues to a non-technical person, and in a forthcoming article, how to politely refuse a client's request.

Before you even begin to think about explaining an issue to a user, you must first determine their technical competency. By jumping the gun and explaining in minute detail how a particular server's file system crashed to a non-technical person could make that person feel inept or stupid which could lead to more problems during the duration of the issue, and conversely, telling a technically-inclined person that 'the smart TV box needed a nap' could invoke the reaction by the listener that you are the dumb one. So, the question you're probably asking is: 'How do I determine what a user's technical competency level is?' Unfortunately, this is something of a soft science and can't be precisely defined. There aren't any hard and fast rules to determine how skilled your user is, but there are some things you can listen for that might give point you in the right direction:

- Does the user seem to be forcing you to do all the work?
Example: You're asking them to do something simple like a few mouse clicks and they still want you to come to their desk and do it for them?

This could be because the user just doesn't feel comfortable doing something that they haven't done before. I know personally, if I'm learning a new procedure, I like having someone watch over my shoulder the first time I walk through it, just to make sure that I'm doing it right. If I can get through it with nothing breaking, I'm a happy camper and won't have any problems doing it again by myself. The user may find themselves in the same boat: they want to have someone watching over their shoulder to ensure that they aren't causing any more problems. Now this doesn't necessarily mean that this person is completely green, but if you have this request multiple times from the same user, a little light should go off in your head that this user may not have the skillset you do.

On the other hand having a user that really loves to work the KB and mouse does not indicate that they are either competent or willing to learn. I've often experience this as a power user wanna be. A very dangerous position to be in, this user often has lots of questions and seems to know the lingo. It will take some time to determine if the user really is on the ball, a statement like "Should I reinstall the TCP/IP stack?" clearly shows that someone has learned to do something but doesn't really know what it does. In case you aren't sure the answer is always "NO" if the TCP/IP stack needs to be reinstalled, you do it and NOT in front of the user.

- Does the user say the word 'thing' a lot?
Example: 'That computer-thing is making a lot of noise?' or 'The thing I just clicked on went away.'

99% of all people have an innate desire to show off/brag/etc. as often as possible. Why does that matter? Because if they knew the term, they would use it to try and impress you (or perhaps simply themselves). Instead, the user is trying to let you know that they are manipulating a certain object but don't know how to explain or describe it any better. Hearing the word 'thing' a lot usually gives me the impression that the person does honestly want to help you help them, but don't have the know-how to do so.

As well as I touched on above, a use of correct technical terms is not a clear indication of capability either. What you are really looking for here is more the ability of the user to articulate and be comfortable in their environment. You may have a user that says "I'm using program and trying to process when I get error." This isn't proof that the user knows what's going on, it simply indicates that the person can explain things to you accurately.

These are just two of millions of subtle nuances you should be listening for when speaking to a client explain an issue; little hints that should give you a fairly good idea of what kind of person you're speaking with. You have to remember that you shouldn't only be listening to what a user says, but also how they say it. Like you probably know, something like 70% of face-to-face communication is through body language. Why does that matter? Because even if you're not face-to-face with your user, you can still hear different movements. I know that you're probably thinking that I'm crazy, but the next time you're on the phone, I bet that without a doubt you could at the very least be able to tell if the person you're speaking with is smiling. That's a physical action, but it's incredibly easy to pick up on if you actually listen for it.

The next question I can hear you asking is: 'Alright, well now that I know my user has a [terrible/alright/excellent] technical background; what do I do with this information?' You want to take this information and tailor the rest of your conversations to their skill level. The reason you want to do this is that, as we discussed earlier, you don't want to go over your user's head because they'll just end up zoning out and not listening to anything you say and you also don't want to patronize someone who does have the knowledge. If there is ever a case of doubt, you are better off assuming that the user does not know or is not interested in knowing and you should reveal virtually nothing about the situation.

You want to be able to keep your listener interested throughout as much of the conversation as possible, so when you're describing things to a non-technical person don't go overboard on the details. Instead of saying something like 'the software's internal development team didn't use the strongly() function and so there was a stack overflow and the core dumped', say something like 'there is a problem with the program and there is nothing you could have done, the best thing you can do if you come across another problem like this is contact us'. Most people aren't going to care why the program broke, they're just going to want to know that someone knows it's broken; how it gets fixed generally won't concern them. As the saying goes, 'Ignorance is bliss.' Like most people who don't care what goes on under the hood of their car, they just want it to get them from A to B, most people don't care that the page file needed to be moved to a different drive and that the RAM was upgraded from DDR to DDR2, so long as they can still save their Word documents.

You want to use the vaguest terms possible, I would advise that you not provide any at all while still maintaining the essentials of the resolution. You don't want to lie about any details, but by going overboard on the specifics that are more than likely going to fly over your user's head anyways, you're just wasting both your and their time. It is best to say 'The issue is fixed now, if you or anyone else in the office has this problem again have them contact us right away.' You can also use analogies, but be sure to use a pre-planned analogy, and not something on the fly. Why pre-planned? It's because if you realize you need to change something halfway through your explanation, chances are high that your user will already have assimilated the first part, and will have an incredibly difficult time remembering something different. The whole reason for using an analogy is to link a familiar mental picture to something new, in the hopes that they'll remember it. An upcoming post will contain an excellent example of an analogy that should be used whenever possible, watch out for it.

To end off this article, I'd like to leave you with one more helpful tip. You are eventually going to have people who, after you've fixed a problem and explained the solution in layman's terms, ask for more details. The big conundrum here is how much detail do you go into? My answer is to let them know that any more explanation is going to be highly technical and might not make any sense. At this point they can make up their mind with whatever they feel comfortable with, and with either decision, you win. If they decide not to have you go further into detail, this will allow you to get back to your other awaiting work, and if they ask you to explain it to them, chances are that you might have underestimated their technical skills, and/or they really are eager to learn. I personally really like it when someone asks me to explain the technical details, it gives me an opportunity to speak in my native tongue (Geek) and not apologize.

Always remember the most important tip of all: enjoy yourself if you can; the moments where the crisis is averted and you are the hero are the moments in which you get to enjoy your professional pride. Take pleasure in the fact that at the end of the call a client who started off angry is now happy with your work.

Justin Smith
nexxai@gmail.com

How-To: Speak to your client (Part 1)

2006-04-10T14:41:00.000-04:00

As the first real article on this site, I'd like to start off by writing about something that every technician is going to have to do at some point in their career, but will probably end up doing wrong, and that is speaking to your client.

Inevitably, being a technical support contact, you are going to have to speak to a client, whether it's being the first point of contact and they have called you to report a problem, to get more information about a particular problem, or to let them know an issue has been resolved. Unfortunately, in my experience, most technicians do this the absolute wrong way.

What's the wrong way, you ask? Well let me explain. For the purposes of this article, I will define a "user" as someone who has between 0 and 10 hours of total training of a particular product. Whether this means that they went to a night course on how to use Microsoft Word more effectively, or they looked at the sticker on their phone that tells them how to get their voicemail is irrelevant; they are not power users by any stretch of the imagination, just someone who knows enough to get by. Also, for our purposes the words "client" and "user" can be used interchangeably.

Problem Description: User calls the helpdesk and says "I can't save my document to my network folder."

What I almost always hear the technician ask is something along the lines of "Ok, and what server and share is giving the error?" There are so many things wrong with that sentence, I don't even know where to begin.

1. As much as it may pain you to do so, empathize with your client, but don't sympathize. Start out replying by saying something like 'I understand how that can be frustrating, now let's see what we can do to fix it.' Letting the user know that you relate to the problem will let them know that you have formed some sort of personal attachment to their issue. Also, most users will realize that the problem isn't your specific fault, so emphasizing that you're willing to help them fix it actually lets them know that you are taking personal responsibility for the problem and will invest all of your resources into fixing it. The reason I use 'we' is to set the customer expectation that they will be involved and that you need their help. This is something I think is critical in setting customer expectations and allowing them to feel involved in the process. (Setting customer expectations is something we will discuss more in depth in a later article.)

2. 'What server and share...' assumes that the user first of all knows what a "share" is, and secondly what server this 'share'-thing is on. Never assume that your user has any technical knowledge beyond what they've just explained to you in whatever technical or non- terms. Ask more user-friendly questions like 'Where are you trying to save to?' This will allow the user to respond in whatever level language they feel comfortable in. Also by listening to their response, you should be able to make a good guess as to their technical competency and tailor your next questions accordingly. The initial call is an excellent time to learn client lingo and educate the client on proper terms. While educating a client on proper terminology is something that we will focus more on at a later date, it is very important at this stage to note that the use of the exact words used by the client should be noted to determine where the issue lies. This is often how the user and technician get confused.

3. She didn't say anything about an error, so don't assume one is showing up. Feel free to ask 'Is there an error message on your screen?' but don't assume that there is one just because something isn't working. Maybe she had a mapped network drive that is no longer showing up under My Computer in a Save As dialog box. That would satisfy the criteria of not being able to save to her network folder, but not having an error, would it not? You must play detective for the users and realize that more often then not they have left out information inadvertantly, as they're really not sure what to be looking for in the first place. Ask more probing questions like 'What is the title of the window that you're currently looking at?' or 'Can you describe what buttons you have available to you?' More often than not, even something as simple as knowing that there is a certain button available on the window she's looking at will help you immensely in narrowing down what the user is looking at.

Now, that's three major problems in a 10 word response; that's pretty bad, if you ask me. Never mind that 2 out of the 3 issues could be resolved by not assuming anything. Being a proficient help desk technician requires more than just being able to solve a technical problem, but also to be able to tailor your responses to the client so that they feel comfortable doing what you're asking (e.g. converting 'geekspeak' to 'normalspeak').

I can tell you that 99 times out of 100, if you are able to communicate on the same level as your client (whether that means dumbing things down to the point of using Winnie the Pooh characters or whether you're communicating back in forth in binary), you will be able to get them to listen to you, as well as get them to do what you're asking, with little resistance. You have to remember that computers, while not necessarily a new thing in the workplace, are still mysterious machines that at the click of a button can make incredibly huge calculations and at the same time play the latest song from Britney Spears. The more comfortable they feel around them, the less worried they'll be about potentially breaking something.

Next week, I'll continue this article by going more in depth about how to explain technical issues and terms to users who might not "get it".

Justin Smith
nexxai@gmail.com

Introduction

2006-04-10T14:19:00.000-04:00

Welcome to The Help Desk How-To, a blog dedicated to teaching you how to become a better help desk analyst and/or on site technical support. We will be writing approximately an article each a week on a different topic relating to supporting users via the phone or in person, in some sort of technical role. Articles will range from "How to translate geek-speak and back" and "How to get the information you require in the shortest amount of time". This won't be an incredibly technical blog, but more about how to take the technical side of a help desk and make it understandable, for both the helpdesk itself, as well as the users that are requiring its assistance.

My name is Justin Smith, and I've been in some sort of technical support role for the past 8 years. I've done my share of phone work either conducting surveys, and in various technical support positions both first, second and third level. Currently, I'm a senior help desk analyst/help desk supervisor for a small company in Calgary, Alberta, Canada, where we support approximately 50 or 60 different small businesses with an average user base of 15-20 per client.

My counterpart, Robert Reid, has essentially the same role as myself (we work for the same company), and he is incredibly gifted in this area as well. He is my first resource when I find myself stuck with an issue. He is very experienced in the helpdesk and one of the very few people I know that I can say without a doubt is better at this than I am.

We'd like to thank you for reading; we hope that you'll get something informative out of our writing and we also hope to get your feedback, both on articles that we write, as well as topics you'd like us to cover. Feel free to e-mail myself (nexxai@gmail.com) or Robert (rfgreid@hotmail.com) with any comments, suggestions or questions, and we'll do everything in our power to respond to those requests as fast as humanly possible.

Hope to see you soon.