Pigs are flying!
You’ve encountered a problem. Something you published doesn’t look like expected. You don’t know how to achieve a desired effect. Some adjustments messed up the design and layout. The website was upgraded, and something doesn’t work like it used to, or a new module doesn’t work as expected. Whatever the problem, whatever the cause, you realize that contacting the helpdesk is the best way to get it fixed.
So, how can you get it fixed as fast as possible? This blog post will let you in on some “secrets” that will help you get your problem solved faster and better, which usually also boils down to cheaper. (Everybody knows time equals money, right?) After you’ve read it you’ll probably realize that it is all just common sense, but when you’re stressed out because something is broken, your trusty sidekick Common Sense is usually the first to leave.
There is usually more than one way to report a problem, but since NXC operate mainly with requests by e-mail, this blog post will mainly cover reporting by e-mail. Also, the fact that we use Jira for handling our support requests will influence the article. However, following the tips and guidelines (or even writing up an e-mail to use as a “manuscript”) can be useful if you intend to report the problem by phone. Some of the parts may not apply to your process of problem reporting, since your support desk may be using other tools for error reporting and handling, or your problem may be of a different character. Whatever support tool you use, though, these tips should be useful on your way to get the help you need. After all, no matter how many bots and automated processes your correspondence passes through on the way, in the end you are still communicating with other human beings.
Starting your error report
Like any e-mail, you start with the subject. This is one of the most important keys to getting help fast. You should always make the subject as descriptive and short as possible. If both are not possible, always go for descriptive. There are several benefits to a descriptive subject:
- It’s easy for the person that receives the error report to assess the type and severity of the problem at a glance.
- The person that handles the incoming request may be able to quickly pick the best person to fix it, or identify what kind of expertise is needed, and forward/assign the issue to the right person.
- When following up later, it’s easier to find the correct issue among others.
- If a similar or the same problem occurs again later, it will be easy to find a possible existing solution.
The worst you could do:
- Not write anything in the subject field of the e-mail. (Jira will ignore and delete messages that have no subject, and the support crew will never know you have a problem).
- Write a too short and non-descriptive subject like “Problem”. When you send an e-mail to support it’s a given that you have a problem. Support needs to know what that problem is before they can help you.
- Write a panicked subject like “ERROR MESSAGE!! NOTHING WORKS!” This will most likely be interpreted as an obvious exaggeration, causing other, more well formed requests to get priority.
Also consider this: It you were making a phone call, would you just start explaining the problem in detail without giving a short synopsis first? Probably not.
Describing your problem
If the subject of the request alone isn’t enough to identify the problem, or when the appropriate person has received your request, the next step is to identify the problem in detail. This is done by looking at the body of your message. There are several things you can do to help describe the problem, and a few things you should keep in mind:
- The person that will be working on your issue may not be familiar with your website, so you should:
- Explain your problem like you would to someone that know nothing about your site, at least to a certain degree.
- Avoid using internal jargon/nicknames for things on/parts of your site.
- Include links to where the problem can be seen. The technician may not know where to find your “signup form”, “the timetable” or any other pages on your site. He/she may not even know the address of “your website”, or you may have several websites, making “our website” a disambiguation.
Adding the link can save several minutes of searching for the technician. This is time that can then be used to actually solving the problem. In any case, this ends up as time you’ll probably be paying for. Providing a link for the tech will also save a lot of frustration, causing him/her to be more effective.
- If a special process is required to reproduce the problem (e.g. adding a certain item to the shopping cart to produce an error during checkout, or doing things in a certain order to crash the page) you should give step by step instructions.
Testing your instructions on someone else in your company before sending them can be a good idea.
- Screenshots usually help. Not always, but they never makes the problem harder to solve. Adding screenshots to your problem report will be covered in detail in a separate section.
- Add relevant environment information such as Web browser version etc. This is also covered in detail in a separate section.
Make your expectations clear
Despite a descriptive problem report, it may not be obvious what you want the outcome to be. A simple and clear problem report stating “The headers on the news article have the wrong font and size” cannot be handled unless you state what font and size you want it to be. The technician will have to spend time acquiring the information (time that you may end up paying for), and the fix of the problem (however simple) will be delayed.
On more complex problems, detailing your expectations on how it should be fixed can speed up the time it takes to fix it, and it can also make the solution more robust.
If your problem report is about some new feature or functionality, outlining future plans for it (if any/if known) might influence the way it’s implemented now, simplifying the process of changing and enhancing it later.
Hungry for more?
Part two will go in detail on what additional information you should include, how to best include screenshots, how to escalate error reports from internal mail correspondence, how to format text, and who to include when sending error reports/help requests by mail. You will also be given a simple tool to help you out the next time you need to contact your help-desk.
This work is licensed under a Attribution-ShareAlike 3.0 Unported License