The Help Desk How-To

Techniques for technicians

Wednesday, June 28, 2006

Objectivity is the name of the game

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

Tuesday, June 27, 2006

The Zen of Research (Part 1)

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

Thursday, April 13, 2006

Setting customer expectations, SLAs and saying no

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