This site focuses on systems administrators, but everyone at every level, technical or not, needs to report problems. As the first point of contact, your trouble ticket (or e-mail, or problem report, or service ticket, or helpdesk request, or whatever your organization might call it) sets the tone for the future interactions necessary to get that problem solved. When you submit an effective trouble ticket, you increase your chances of skipping unnecessary intermediary steps and reaching resolution faster.
[citationic]
An example of a good trouble report:
As you read through the article, you might decide that this example lacks one major piece: What did the user expect to happen? We can expect a reasonable person to look at the contents of this message and understand that the user thought that they would have access to the site. Right away, understand that you need to provide enough information for your recipient to help you without overwhelming them. Everything that follows shows you ways that you can accomplish that. If you can achieve that aim without hitting every bullet point, that’s OK.
The Ground Rules
First, a few things to do or not do to make certain that you don’t turn in an objectively poor ticket:
- Provide information! Remember that support was not there with you. You know what you tried. You know what you expected to happen. You know what actually happened. No one else knows these things. If you don’t include them in your request, then you go through at least one query/response cycle for support to get it out of you.
- Save the backstory. Don’t provide so much information that support can’t determine the actual problem. You have a goal and something stopped you from achieving it. It’s OK to mention that you had the same problem previously, especially if you can supply enough detail for support to check through your history. Definitely mention if you have an ongoing problem that never went away.
- Minimize your own diagnosis. If you report a specific problem, then you might get a specific fix. That works out well if that problem was also the thing holding you back. If it turns out to be something else, then you’ll have to start over. Sometimes, you will know more about the problems and solutions than support. Just take care with your reporting so that you get the help that you need.
- Include the error message. Support staff working through trouble tickets get frustrated with the reports that say, “I got an error,” but don’t include the error message. If you didn’t catch the message, then say that. Otherwise, they will just ask you anyway, causing an extraneous exchange cycle.
If everyone filing a trouble report would follow those few rules, support resolution times would decrease for everyone.
Making it Better
We set the baseline for making a ticket not awful. We can do a little more to make a ticket good (if we can ever call a trouble report that). A few pointers:
- Include screenshots. You can press the Print Screen button to copy the current contents of the entire screen to the clipboard. That grabs everything, though. You could paste it into an image editor to trim it down, but that gets tiresome quickly. Windows has a decent built-in program called the Snipping Tool which easily allows you to select only the portion that you want to capture. While Snipping Tool has come a long way, I still prefer the third-party application Greenshot. It takes over the Print Screen button so that every time you press it, you instantly get a selection tool. It also has a unique feature that I have not found elsewhere: if you right-click the Greenshot icon in your notification area, you get a Capture last region choice that allows you to take repeated shots of the same screen location. That’s perfect for things like getting all the pages of a wizard without constantly sizing a selection tool.
Greenshot menu
You can paste an image from the clipboard right into an e-mail. Some ticketing tools allow that as well. Otherwise, you’ll have to save it to an image. You can do that with the built-in Paint tool or a third-party solution such as Paint.NET.
- Put the most relevant information at the beginning. That advice has a lot to do with how humans consume, absorb, and prioritize information. But, like most other people, support staff lose focus the longer they read something.
- Don’t bury the lede. This has a lot in common with the previous bullet point with a major distinction: what you need to accomplish matters most. As an example, someone might open a case because they cannot send a fax to a specific recipient. Their goal is not to send a fax; it is to send information to someone. If they have another way to send that message, then maybe the fax part doesn’t matter. Open the conversation with what you need to do.
- Try for succinctness. Sometimes, a support person will call the person who filed a ticket and say something like, “I want to hear it in your own words.” Perhaps they just didn’t want to read anything at all. If so, you have a right to be upset. However, make sure that you didn’t give them an overwhelming amount to read.
Any writing skills learned in school will help. Organization and clarity make the biggest difference. You might also need a bit of persuasiveness.
Behave Professionally
Remember that support staff are people, too. This probably seems obvious to you. It also seems obvious to me that many people forget this simple fact. We all have an ethical responsibility to act politely toward each other in any environment. For some, it doesn’t seem like that matters. So, a few supporting points:
- The person trying to help you probably did not cause the problem. They don’t deserve anger.
- Some people take support jobs just for the sake of employment, but most start with a genuine willingness to help and a desire to understand and fix problems. Treat them like allies facing a common enemy. That usually pays off.
- Support has no power in most organizations. Threats to take business elsewhere, product criticisms, demands for refunds, and similar will get you redirected and add time to fixing your problem.
- Routine encounters with aggressive clients results in high turnover of front-line staff. High turnover means that no one sticks around long enough to build up knowledge. So, treating support staff poorly results in support staff that doesn’t know much.
- No one feels like spending any more time with a hostile caller than absolutely necessary. Berating technical support will motivate them to produce quick results, not quality results.
- Advocate for yourself, but gently. You do not need to tolerate dismissal or the waste of your time, though. You can use statements such as, “I feel that you have done your best to help me, but I would like you to escalate this problem.” If gentle doesn’t get you anywhere, try slightly more insistence with simple requests, like, “I need to talk to a supervisor.” When front-line staff escalates a ticket from an angry customer, they often make that anger the centerpiece. If you can help it, don’t begin your relationship with escalation staff on an expectation of belligerence.
Few things can ruin your day quite like a bad support experience. Do your part to keep the interactions civil and upbeat. You will almost always get a superior outcome this way.