In part 1 I showed you how to “tease the help-desk into wanting to help you” by setting an interesting subject, providing some details about what the problem is, and telling them what you want them to do. In this part I will go in detail on what information you should include, how to include screenshots and more. In the end I will provide a tool for you to use the next time you have to call in the cavalry (a.k.a. the help-desk).
Include environment information
For the technician to be able to help you fix a problem, he/she must be able to recreate the problem. To achieve this it may be necessary to test the problem description on multiple platforms, but at the very least on the same platform you’re experiencing the problem on.
It’s not a secret that different browsers behave differently. Especially Internet Explorer is well known to do things it’s own way, but other browsers have their quirks, too. To add another layer to the cake known as surfing the web, different operating systems may also cause browsers with the same name to behave differently, and if you’re looking at your site using a tablet or a smartphone, you might even be looking at a special (and usually simplified) version of the site.
Because of this you should always include the following information to help the technician reproduce the problem:
- What browser(s) you use when the problem occurs, and which version(s)
(E.g. there are major differences between IE6, IE7, IE8 and IE9)
- What operating system you’re using
- Note if you experience the problem on a smartphone or tablet.
Paint a pretty picture
Adding a screenshot or two can really help speeding the process along, especially if you give it a little thought. If the problem relates to the layout and look of the site, a screenshot is bested by nothing in aiding the technician to see what your problem is. If you have the tools to add arrows, red rings etc to the picture you can really paint a picture of what’s wrong. What is important to remember, though, is this:
- Files should be in JPG, JPEG, GIF or PNG format. Everybody can open those files.
- Word files, excel sheets and powerpoint presentations should be avoided for several reasons:
- They are proprietary formats, and the technician may not have purchased the same software as you have.
- The technician working on the issue may not be using a platform that supports the file format/required software at all.
- It adds unnecessary size to the attachment
- Images may be scaled to a size where text on them are rendered unreadable, and/or aspect ratio may be changed.
Especially in cases where something is missing from the site, adding a screenshot with marking on it can help explain to the technician where you want the missing item to appear. He/she can then search the existing source files for the problem, looking in the right place from the start. When the problem is identified the necessary code to produce the results you want can be added or existing code can be altered to work as it should.
“Don’t just forward” doesn’t necessarily mean “go backwards”
In some cases you may not have discovered the problem yourself, but have received it from a coworker or user of your website. Perhaps you are part of the internal support crew or IT department, or perhaps you’re just the “go to guy” – that guy that knows more about computers than most of the others in the office, and because of that end up helping everyone else. You may usually be able to fix things, but from time to time you’re likely to come up short, and you’ll have to escalate the problem and get external help.
If this is the case, it’s important to not fall for the temptation to just forward the last e-mail of your correspondence with your colleague. Why? Because it will add quite some time (that you’ll end up paying for) to the time it takes to understand the problem. Remember: you and your colleague are up to speed on the discussion, you both probably know the site and the jargon, and you may even have talked about it face to face, providing information and insight that is not in the e-mail thread.
If you (like most people seem to do these days) correspond in e-mail by just adding your next part to the top of the e-mail, leaving the entire history (including mail headers, personal footers, company logos, quoting etc) in each e-mail, the technician is going to have a hard time separating the essence from the junk. In addition, he/she will have to do it backwards! (Since the first e-mail will be at the bottom of the history, but trailed by a lot of footers etc. This will be guaranteed to add a lot of frustration to the technicians day. It’s also guaranteed to consume a lot of extra time (that you will be paying for), and it’s very likely to cause confusion and misunderstandings that will ultimately cause more time (that you’ll be paying for) to be spent on identifying and solving the problem.
What you should really do, is read through your e-mail thread, and reformulate a new e-mail for your request. Copying and pasting from your thread is fine – it doesn’t all have to be typed by hand – just make sure the information comes in the correct order so the technician can concentrate on the technical aspects of your description.
Also, removing any footers is OK – it’s actually encouraged. The technician is not likely to need your mailing and/or visiting addresses or anything else there. Since you sent your request by e-mail, he/she already has your e-mail address and will be able to contact you if he/she needs anything else. Company logos etc. should always be removed from the e-mail before sending, since these will accumulate in the support system, making it harder to find the useful attachments.
Sometimes black and white is just fine
Some systems don’t support a lot of formatting, and Jira is one of them. Because of this, adding formatting to your e-mail to emphasise your point is wasted energy (in fact, it’s wasted time that you’re paying for). If you report ever so colorfully that “the red text” has typos in it, “the blue text” should be replaced by “the green text”, and “some text should be in italics”, it will all look like plain old black-on-white text by the time the technician read it.
Keeping things to yourself isn’t the same as keeping secrets
When sending an e-mail to the support address you should never include other recipients in that e-mail. Ever. Why not, you probably ask. Of course you want to inform your superior that the problem is being handled, and perhaps also other colleagues that are struggling with the same problem you are. Sure, that’s a good thing, but you should do so in a separate e-mail. The one that goes to support should go to support alone.
The reason for this is simple: If there is other recipient to the issue, and one of those press the “reply to all” button, support will receive another e-mail regarding an existing problem. Since this e-mail doesn’t contain a valid issue key at this time, the system will generate a new issue that needs to be handled by support. This takes time – come on, everybody; say it with me: – time that you’ll be paying for, and if you send it to more than one person in the supporting organisation, you might end up having more than one person working simultaneously on the same problem, each spending time (yes, time that you’ll be paying for) on it, and in a worst case scenario, they may be preventing each other from finding the solution by altering the same parts of the website. This translates to – bah…. You know it by now, don’t you?
Listen to the music
(The fat lady is singing, but in a good way)
That’s all there is to it, really. Like I said initially, it’s all just common sense, but when your boss is cracking the whip and the deadline is closer than your underwear these things are easy to forget. So, to help you out the next time you’re in it to your neck I have provided something of a big, red emergency-button for you: a PDF containing our “Support Cheat-Sheet”. It’s one simple page with a summary of the most important things to remember when contacting the help-desk.
Use it next time, and perhaps you’ll be able to just enjoy listening to the fat lady singing, rather than seeing your life flash before your eyes. Feel free to use it in your company, too, and make sure your colleagues have a copy. Who knows; it may even simplify your work if you’re that “go to guy”.
(Yes, you must push the button to get the file.)
This work is licensed under a Attribution-ShareAlike 3.0 Unported License