Home opinion-and-analysis The-Wired-CIO CIO Trends What your IT dept wish you knew about requesting support

What your IT dept wish you knew about requesting support

"Why won't the help desk just help us?" says many an office worker about their internal IT support. Yet, IT is similarly lamenting, "Why can't the user just log a ticket properly?". Never before has "help us help you" seemed so strained. Let me break away the tension and reveal just what your IT department wish you knew about logging a support request.

If your company is like mine then the way to access the help desk is dead simple. At least, theoretically. Just e-mail helpdesk and log your request. Yet, in practice, this instruction escapes the comprehension of some users and even those who do send their request to the correct mailbox still need to be given lists of "do" and "do not's" with respect to what makes a "good" ticket.

Dear user, you might think it does not matter. Why is the help desk being so anal? Can't they just call for more information if there's anything they don't understand? Can't they just forward the e-mail on between themselves?

The truth is it does matter, and with just a teensy-tiny bit more information and crafting in the e-mails you send to the help desk the chances are your issues will be resolved much more swiftly.

Let me take this opportunity to tell you how your company's help desk system most likely works because if its machinations are transparent then this helps you understand why you are asked to contact the help desk in a specific way. This becomes more and more important as the company continues to grow, with more staff in general and more IT team members too.

First, chances are high your emails aren't being received in the first place by a human being. Most likely it is software in place which monitors the helpdesk mailbox. Whenever you write to it a ticket number is assigned to your request. An e-mail is sent back to you with this ticket # as well as a link to use to view the status and progress of your request.

By using this system, multiple IT staff can view the help-desk queue and see what has not yet been allocated, as well as their own work queue.

There are important ramifications here.

For one, IT Managers, systems administrators, even individual help desk support staff are not across everything which is sent to the help-desk, and similarly IT staff may not necessarily be familiar with any specific request. If you send a request to the help-desk but then directly ask someone else the same thing without indicating it has already been logged you are making additional work because the history of your request - or even that it is already a request in progress - may not be known.


This means extra effort is expended on one thing which prevents working on other things. You may get responses asking for more information that you believe you have already supplied; you may incur additional company expenses; you may cause the work of one person to overwrite the work of another person

Second, and this is a major one, you will have a greater chance of response and resolution by using the help-desk than e-mailing or calling any specific individual. The reason is simple: there are more eyeballs looking at the queue.

People try and latch on to someone who they know has helped them in the past but if the same request was sent to the help-desk the probability is higher that it will be acted on and resolved than if an individual is e-mailed directly. In fact, that person may be on leave or unwell or in meetings. By sending requests to specific individuals you only hinder your own chances of resolution.

Thirdly, the IT team can view the help-desk queue at the end of the day and see what has not yet been allocated. This is much easier to see than looking at collective inboxes. If your job is not yet actioned this is easier to see when it is sitting in the help desk queue.

Lastly, if you want to follow up on an issue, don't send another e-mail and raise a new ticket. Instead, reply to the e-mail response you received with the ticket #. This way your e-mail will be tacked onto the end of the existing ticket.

Now you know to write to the helpdesk address you are told to use. However, what should you actually write? Taking a few moments to reflect before pressing 'Send' will also help bolster your chances of getting assistance.

When you send an e-mail to the help-desk, please do these things:

Think 'am I sending this to the right department?'. The help desk is not payroll. It is not finance. It is not sales. It is not procurement. Are you seeking assistance on a technology-related matter, for existing technology? Or are you asking for a report from your applications software? Are you asking for new equipment? Depending on your company's internal policies, these requests may be handled via a different process.


Include a brief description on the subject line. Not only is it bad practice in general to send an e-mail with a blank subject line, it means your request is going to show as just 'blank' in the help desk queues. When the help desk is particularly busy staff are not going to continually open a ticket to see what it contains. Tickets are prioritised based on impact and severity and tickets with a blank subject line are going to be marked as low priority.

Don't send your e-mail to specific IT team members as well as the help-desk; just send it to the help-desk.

Include basic information on what you are trying to achieve, what you are seeing (including error messages) and what you expected to happen. Don't say something that is further down the track of where you are. For instance, don't say "I can't get onto the Intranet" when your problem is that you are unable to install USB modem software on your laptop. While the lack of the USB modem working may be preventing you from, indeed, getting onto the Intranet your problem is not with the Intranet but with the modem software and your rights on the laptop.

Sometimes, you will want to phone instead of e-mail. That's catered for but most help desks would prefer you reserved the telephone for urgent matters. If you call, it is vitally important you remember to give useful information just like that stated above. Do not say "Call me". That's horrendously unhelpful.

In fact, in my view, any message that just says "call me" with zero indication of severity ought to be considered low priority. It's good practice in general to give a brief explanation of what your call is about, no matter whether to the help desk or to others.

When leaving your phone number be sure to state the area code if there is any possibility the people you are calling are in a different state. This is also just plain good practice.

So that's your help desk. It's not rocket science even if the problem you are facing apparently is. Help your help desk to help you.

Remember:

  • e-mail the support address your company issues
  • don't e-mail other addresses, even on the CC: line
  • don't address your e-mail to specific individuals
  • include a description in the subject line
  • explain what you are trying to achieve and what is happening and what you expected to happen
  • retain the automated reply you receive and reference the ticket number in it if you need to follow up.

 

LEARN NBN TRICKS AND TRAPS WITH FREE NBN SURVIVAL GUIDE

Did you know: Key business communication services may not work on the NBN?

Would your office survive without a phone, fax or email?

Avoid disruption and despair for your business.

Learn the NBN tricks and traps with your FREE 10-page NBN Business Survival Guide

The NBN Business Survival Guide answers your key questions:

· When can I get NBN?
· Will my business phones work?
· Will fax & EFTPOS be affected?
· How much will NBN cost?
· When should I start preparing?

DOWNLOAD NOW!

David M Williams

joomla site stats

David has been computing since 1984 where he instantly gravitated to the family Commodore 64. He completed a Bachelor of Computer Science degree from 1990 to 1992, commencing full-time employment as a systems analyst at the end of that year. Within two years, he returned to his alma mater, the University of Newcastle, as a UNIX systems manager. This was a crucial time for UNIX at the University with the advent of the World-Wide-Web and the decline of VMS. David moved on to a brief stint in consulting, before returning to the University as IT Manager in 1998. In 2001, he joined an international software company as Asia-Pacific troubleshooter, specialising in AIX, HP/UX, Solaris and database systems. Settling down in Newcastle, David then found niche roles delivering hard-core tech to the recruitment industry and presently is the Chief Information Officer for a national resources company where he particularly specialises in mergers and acquisitions and enterprise applications.